Team. We have not completed the synopsis of the final sections of the first chapter of Oracle's Early Draft of MVC 1.0. With work demands, the fun is becoming overwhelming, and we must slow down before we fall down. We will likely find a few hours on our regular CABOOSE workday, Saturday. The summary should be available by 06.03.2015.
Enjoy This Weekend. The CABOOSE Team.
Friday, May 29, 2015
Wednesday, May 27, 2015
If One Cannot Beat An Oracle, Align Oneself In Agreement With Him
Team. We have already stated that we would not be much competition for the Oracle. Basically, we would be "scrubs" on the tournament roster. Knowing that we would be "erased" from the competition brackets as a "non-contender" before any play began, the CABOOSE team is simply seeking a place near the Oracle bench when the action commences.
In this vein, we will be reviewing some of the goals, features, and characteristics of the Ozark product as we continue with our CABOOSE effort. The following is a summary of the first chapter in the MVC: Model-View-Controller API dated March 25, 2015. It is listed as the Early Draft of Version 1.0. A complete PDF of the document can be found at hyperlinks found previously in this weblog. With this summary will be some technical commentary.
The model-view-controller (MVC) architecture is the most common one among HTML web applications. It comes in three fundamental parts.
Firstly, the model comprises the entity classes associated with the application's data. Within the CABOOSE controller pattern for servlet, we encapsulated HTML templates associated with the view in the model. These templates represented view specifications which the controller would provide for a client application which could render the desired view instance based upon their specification and other appropriate data from the model. In short, these templates were models of various views within the application.
Secondly, the view is a rendering of data within the model whether in a CABOOSE pattern or traditional MVC application. The view represents a boundary and interface between the system user and the application. Input validation concerns in an MVC should be handled by the client when every possible. This limits traffic between the secondary and primary processes. This frees the primary process for servicing more clients and increases web query throughput.
Finally, the controller marshals the flow of data between the entity classes and the view. One can design a controller in a number of ways, but a simple interpretation of the abstract controller is as a command or message processor. The controller receives a request message (command) and provides a response message (command). As such, the abstract logic governing a controller is: read a request on the input stream, process it, and finally, write a response on the output stream. The challenge in writing a controller well is the logical details of the "process it" step.
The MVC architecture comes in more than one form. Among desktop applications the most common form is the Type-I architecture which allows a callback between the view and model so the interface content refreshes itself with "real-time" accuracy.
Achieving this is more challenging on the web. So, a view refreshes itself with each HTTP request of the webserver. As a result, view data can conceivably be "stale" based upon the actual state of the entity classes. This form of MVC is called a Type-II.
The Type-II MVC fits the natural layered architecture that arises from working with networked enterprise applications. The early editions of these from around the millennium contained four layers: the presentation layer which contained the view, the business logic layer which contains the controller, a layer for middleware technologies, and finally the entity class layer which contains the data. Forgive us, if we have misspoken about the content in each layer of these early models. This was stated from memories which are nearly a decade old and have not been refreshed by reading older text. The latest web-based layered models have only three layers. The business logic and the middleware layers have been merged.
Some might say "Wrong!". A Type-I MVC is the mixture of servlets and JSP in an application working in similar roles for returning content, and the Type-II MVC is an advance in thinking were the servlet fulfills the role of a controller which returns a JSP/JSF as a view. You know we would not argue with you, because you would be absolutely correct. Yet, we would add that we are also!
We have called this distinction made among MVCs Style-I and Style-II. This removes the ambiguity of using the term "Type" in both places. Computing is a rather new field which lacks an abundance of terms for uniquely describing every concept and a rich set of synonyms for variety in description. But, this is a topic which could fill many books and not the purpose of these few paragraphs.
The Oracle documentation describes web user interface frameworks as action-based or component-based. It states that in an action-oriented framework the controller which fields each client HTTP request maps them with server-side actions in application code. In contrast, component-based frameworks use server side components for the processing of request with very little interaction from application code. So, in a component-based application, the framework encapsulates the majority of controller logic. This it has abstracted away from the application.
The MVC API provided by Oracle is an alternative for component-based systems such as JSF and not an intentional replacement.
A Summary of the Goals of Ozark MVC API are:
a. Make the most of the existing JAVA EE technologies.
b. Provide seamless inter-workings with CDI and Bean Validation
c. Define a solid kernel of features for MVC development. All of the features might not be implemented in its first version.
d. Consider building upon a JAX-RS foundation so Ozark might reuse its matching and binding layers.
e. Provide inherent support for JSP and Facelet view languages.
The following are not goals of Ozark:
a. The creation or definition of a new view (template) language or processor.
b. Support stand-alone implementations of MVC running outside of the JEE.
c. Support Restful services which are not based on JAX-RS.
d. Provide built-in support for languages which are not part of JEE.
This summarizes the first couple of sections of chapter one which are the bulk of the reading for it. We will provide a synopsis of the third through seventh section on 05.29.2015.
Please pardon any typos. This text was created in “fun-mode” as the German descendants in my locale say. Things have been busy and tons of “fun” for the past couple of weeks.
Happy Coding!
The CABOOSE Team
In this vein, we will be reviewing some of the goals, features, and characteristics of the Ozark product as we continue with our CABOOSE effort. The following is a summary of the first chapter in the MVC: Model-View-Controller API dated March 25, 2015. It is listed as the Early Draft of Version 1.0. A complete PDF of the document can be found at hyperlinks found previously in this weblog. With this summary will be some technical commentary.
The model-view-controller (MVC) architecture is the most common one among HTML web applications. It comes in three fundamental parts.
Firstly, the model comprises the entity classes associated with the application's data. Within the CABOOSE controller pattern for servlet, we encapsulated HTML templates associated with the view in the model. These templates represented view specifications which the controller would provide for a client application which could render the desired view instance based upon their specification and other appropriate data from the model. In short, these templates were models of various views within the application.
Secondly, the view is a rendering of data within the model whether in a CABOOSE pattern or traditional MVC application. The view represents a boundary and interface between the system user and the application. Input validation concerns in an MVC should be handled by the client when every possible. This limits traffic between the secondary and primary processes. This frees the primary process for servicing more clients and increases web query throughput.
Finally, the controller marshals the flow of data between the entity classes and the view. One can design a controller in a number of ways, but a simple interpretation of the abstract controller is as a command or message processor. The controller receives a request message (command) and provides a response message (command). As such, the abstract logic governing a controller is: read a request on the input stream, process it, and finally, write a response on the output stream. The challenge in writing a controller well is the logical details of the "process it" step.
The MVC architecture comes in more than one form. Among desktop applications the most common form is the Type-I architecture which allows a callback between the view and model so the interface content refreshes itself with "real-time" accuracy.
Achieving this is more challenging on the web. So, a view refreshes itself with each HTTP request of the webserver. As a result, view data can conceivably be "stale" based upon the actual state of the entity classes. This form of MVC is called a Type-II.
The Type-II MVC fits the natural layered architecture that arises from working with networked enterprise applications. The early editions of these from around the millennium contained four layers: the presentation layer which contained the view, the business logic layer which contains the controller, a layer for middleware technologies, and finally the entity class layer which contains the data. Forgive us, if we have misspoken about the content in each layer of these early models. This was stated from memories which are nearly a decade old and have not been refreshed by reading older text. The latest web-based layered models have only three layers. The business logic and the middleware layers have been merged.
Some might say "Wrong!". A Type-I MVC is the mixture of servlets and JSP in an application working in similar roles for returning content, and the Type-II MVC is an advance in thinking were the servlet fulfills the role of a controller which returns a JSP/JSF as a view. You know we would not argue with you, because you would be absolutely correct. Yet, we would add that we are also!
We have called this distinction made among MVCs Style-I and Style-II. This removes the ambiguity of using the term "Type" in both places. Computing is a rather new field which lacks an abundance of terms for uniquely describing every concept and a rich set of synonyms for variety in description. But, this is a topic which could fill many books and not the purpose of these few paragraphs.
The Oracle documentation describes web user interface frameworks as action-based or component-based. It states that in an action-oriented framework the controller which fields each client HTTP request maps them with server-side actions in application code. In contrast, component-based frameworks use server side components for the processing of request with very little interaction from application code. So, in a component-based application, the framework encapsulates the majority of controller logic. This it has abstracted away from the application.
The MVC API provided by Oracle is an alternative for component-based systems such as JSF and not an intentional replacement.
A Summary of the Goals of Ozark MVC API are:
a. Make the most of the existing JAVA EE technologies.
b. Provide seamless inter-workings with CDI and Bean Validation
c. Define a solid kernel of features for MVC development. All of the features might not be implemented in its first version.
d. Consider building upon a JAX-RS foundation so Ozark might reuse its matching and binding layers.
e. Provide inherent support for JSP and Facelet view languages.
The following are not goals of Ozark:
a. The creation or definition of a new view (template) language or processor.
b. Support stand-alone implementations of MVC running outside of the JEE.
c. Support Restful services which are not based on JAX-RS.
d. Provide built-in support for languages which are not part of JEE.
This summarizes the first couple of sections of chapter one which are the bulk of the reading for it. We will provide a synopsis of the third through seventh section on 05.29.2015.
Please pardon any typos. This text was created in “fun-mode” as the German descendants in my locale say. Things have been busy and tons of “fun” for the past couple of weeks.
Happy Coding!
The CABOOSE Team
Wednesday, May 20, 2015
Integration Possibilities ( Ozark CABOOSE )
Team.
This is not your typical Burlington Northern Sante Fe – Union Pacific merger.
Integrating Ozark and CABOOSE will likely be a smoother transition. At first
glance, Ozark (JSR 371) seemed somewhat disruptive for our efforts, but we have
found that we might easily find a nice niche in it. The most obvious place
where CABOOSE would fit is any method of an Ozark JAX-RS web-service controller
which returns a string. We are still reading on Ozark and sketching notes. We have not
yet configured and tested it with the sample project provided through the
Ozark mailing list. Also, Ozark might allow for the extension of CABOOSE so it can
return any of the four types expected by JSR 371.
Our
primary goal was simplicity in controller development through the creation of a
general-purpose reusable servlet. The team at Oracle which has a greater depth
of knowledge in the capabilities and facilities of the JAVA Enterprise Edition (JEE) decided
that a JAX-RS web-service would be a better choice for supporting controller
development. These are simply the iterations of ideas which occur in computing.
Software development is necessarily iterative and ultimately optimizing, and we
can make steady progress as long as our goal does not move.
We
have reassessed our goal and will be working toward a reusable and generic Ozark controller
using the concepts from CABOOSE. This will be our Ozark CABOOSE. It will allow
for the same approaches for page concern partitioning and the division of roles
between pure scripters and JAVA resources. One added bonus is Ozark's support
for returning JAVA Server Pages (JSP) and JAVA Server Faces (JSF) with greater
syntactic ease than CABOOSE.
Enjoy Your Week's Activities and Keep Singing (La-La). The
CABOOSE Team.
Friday, May 15, 2015
A Continued Study of the Modern MVCs (Model-View-Controller)s
Team. Oracle's Ozark offers
substantial promise for the rapid development of controllers in enterprise applications on the JAVA platform.
Help spread the word of its development. Also, freely use the CABOOSE pattern
for other high-level language platforms which do not have the support for a
generic controller such as Microsoft's .NET has had for a few years or Oracle is
developing with JAVA Specification Request (JSR) 371. Seeing that the model-view-controller
architecture has a number of general types and styles within languages plus is
the most common and effective structure for graphical user interface
applications found on the Internet and desktops, it is worth mastering.
Enjoy This Week's Valley. The
CABOOSE Team.
Wednesday, May 13, 2015
Thinking and Reading on Modern MVCs
Team. We are continuing our study
of Ozark plus the Microsoft MVC and considering how lessons learned from these
examples might profit PERL, PHP, and Python implementations of the CABOOSE
pattern for a controller. We are also considering ways in which we might integrate the Ozark (JSR 371 Draft) and CABOOSE.
Mid-week is the Top of the
Mountain; Coast On Your Trip Down. The CABOOSE Team.
Monday, May 11, 2015
Contractual Message Passing
Team. As a future goal in
computing and possibly CABOOSE systems, we present a paradigm for Contractual
Message Passing (CMP). Most modern high-level languages provide a mechanism for
dynamic invocation of behavior. As such, one can create a data structure which
not only stores information but also provides mechanism for delivering the
results of the actions within the public interface of stored objects. Consider
a hashtable which stores performance contracts for constructing an object or
invoking an object's method. In terms of the JAVA Virtual Machine (JVM), the
object which one constructs or method of an object that one invokes must have a
class definition accessible by the byte-code interpreter. Such behavioral maps
might exists on a pair or more nodes in a network structure. These action
dictionaries for object construction and method invocation would hold the
contracts whose properties consist of a fully qualified class name, a
collection of actual parameters, plus a list of formal parameter types. These
"contract objects" could be exchanged within a network of virtual
machines using serialization. Upon producing a result on the servicer node using a behavioral map, the
requestor would be sent a result acknowledgement. Each service node could
contain a directory of publicly accessible class definitions providing
sub-services for the node and interface definitions for each method of each
class. This would reduce the source code coupling found in large web-services
such as JAX-WS. Remember a contract is simply an agreement been portions of a
system. Computing contracts include the common requests and agreements also
found in their business counterparts for performance, delivery, timeliness and
etcetera. Passing contractual messages is nothing new since the equivalent
behavior occurs in modern computing; however, this approach might be more
compact.
Have a Marvelous Week of Hunting,
Pecking, and Thinking. The CABOOSE Team.
Saturday, May 9, 2015
Reading and Thinking
Team. We are still working through last week's reading material along with other documents. We will post any interesting notes or thoughts next week.
Enjoy This Weekend. The CABOOSE Team.
Enjoy This Weekend. The CABOOSE Team.
Thursday, May 7, 2015
Still Thinking and Reading.
Team. We are still thinking and reading about Ozark and planning future directions. Please pardon the missed post yesterday.
The CABOOSE Team
The CABOOSE Team
Monday, May 4, 2015
Reading and Thinking
Team. This week, we are working on reading and thinking about the future direction of CABOOSE in light of Oracle's Ozark. This will adjust our direction. We have so many opportunities with the development of Ozark that we must assess which are truly value-able. We appreciate your readership and hope this weblog has sparked some useful ideas and opportunities for the students, developers, and academicians who might read it.
The CABOOSE Team.
The CABOOSE Team.
Friday, May 1, 2015
Following Ozark | Looking for Insights and Learning
Team. We have been following the JCP's JSR 371 since we became aware of it a few weeks ago. As you know, it currently has a pair of names, MVC 1.0 and Ozark. Oracle decided that a RESTful web-service would be a better choice for a controller than a servlet. This is a wise decision since a web-service is a more powerful and abstract concept.
Following Ozark
We have been spending our development time each week reviewing the Ozark/MVC 1.0 documentation. At this time, it is rather small and manage-able, and the original vision of the development team is discernible. In short, one can see a panoramic view, the "big picture", of the team's development goals. This aspect of a technology is not always visible when first acquiring a new computing skill. For those among you who are JEE engineer's and architects, we recommend that your become proficient in Ozark. It will likely be a standard that displaces the popular modern open-source projects commonly used for MVC development. It also should become a high demand skill that is foundational for a JEE developer's toolkit, such as Hibernate.
Looking for Insights and Learning
Our primary motivation for following Ozark is that it is a disruptive boon for our CABOOSE efforts. In some ways, it displaces a need for a CABOOSE in JEE. In other ways, it helps us find a niche in the JEE platform and provides insights on how we might produce the best controllers when developing for LAMP technologies which is a goal that we still have set before us. We hope that can learn and incorporate some of Ozark's features in our JEE CABOOSE. Since Ozark still makes use of JSP/JSF technologies, we are considering creating a few ways of blending reflection through the use of a generic custom JSP/JSF tag as previously discussed in these javacaboose pages.
We are rather glad that we were not working at a feverish pace foolishly thinking that we would create a technology that would displace JSP/JSF. The hunting..., pecking..., and thinking... has been a relaxing diversion each week. We also have gathered some new basic skills along the way by incorporating Hibernate and reading on the design of Struts and Spring. Besides, we are well-positioned so we can continue and improve upon CABOOSE development, gather "early adopter" experiences with Ozark (JSR 371), and perfect our Bird Foraging Technique for software development and life in general. We will simply adjust our sights on the new grains that Oracle's developments have set before us, and enjoy some of them along with that which we already had found.
This Saturday's work schedule will be shortened, being about four hours. We plan on learning more about Ozark, dusting off the CABOOSE code which has been shelved for about a month, and starting a text on the LAMP languages. We finished our C# text before we were aware of the MVC offering from Microsoft. We also will be finishing the reading on the links which we provided earlier this week before Monday.
Keep a Song in Your Heart (La-La) and Enjoy This Coming Weekend In Your Part of This World,
The CABOOSE Team
Following Ozark
We have been spending our development time each week reviewing the Ozark/MVC 1.0 documentation. At this time, it is rather small and manage-able, and the original vision of the development team is discernible. In short, one can see a panoramic view, the "big picture", of the team's development goals. This aspect of a technology is not always visible when first acquiring a new computing skill. For those among you who are JEE engineer's and architects, we recommend that your become proficient in Ozark. It will likely be a standard that displaces the popular modern open-source projects commonly used for MVC development. It also should become a high demand skill that is foundational for a JEE developer's toolkit, such as Hibernate.
Looking for Insights and Learning
Our primary motivation for following Ozark is that it is a disruptive boon for our CABOOSE efforts. In some ways, it displaces a need for a CABOOSE in JEE. In other ways, it helps us find a niche in the JEE platform and provides insights on how we might produce the best controllers when developing for LAMP technologies which is a goal that we still have set before us. We hope that can learn and incorporate some of Ozark's features in our JEE CABOOSE. Since Ozark still makes use of JSP/JSF technologies, we are considering creating a few ways of blending reflection through the use of a generic custom JSP/JSF tag as previously discussed in these javacaboose pages.
We are rather glad that we were not working at a feverish pace foolishly thinking that we would create a technology that would displace JSP/JSF. The hunting..., pecking..., and thinking... has been a relaxing diversion each week. We also have gathered some new basic skills along the way by incorporating Hibernate and reading on the design of Struts and Spring. Besides, we are well-positioned so we can continue and improve upon CABOOSE development, gather "early adopter" experiences with Ozark (JSR 371), and perfect our Bird Foraging Technique for software development and life in general. We will simply adjust our sights on the new grains that Oracle's developments have set before us, and enjoy some of them along with that which we already had found.
This Saturday's work schedule will be shortened, being about four hours. We plan on learning more about Ozark, dusting off the CABOOSE code which has been shelved for about a month, and starting a text on the LAMP languages. We finished our C# text before we were aware of the MVC offering from Microsoft. We also will be finishing the reading on the links which we provided earlier this week before Monday.
Keep a Song in Your Heart (La-La) and Enjoy This Coming Weekend In Your Part of This World,
The CABOOSE Team
Subscribe to:
Posts (Atom)