Web Application Using CABOOSELibrary.jar | NetBeans ZIP Archive CABOOSEServlet | Export<->Import

Team. This evening we exported a simple web application which extends the caboose.core.extension.Servlet class, without any method overriding and after commenting out the primary processing method, in a servlet called Cabbie. It is a simple "Hello World" example of CABOOSE in action. This zip archive can simply be imported by NetBeans, and the application should run after adding the library dependencies. We will do our best and have a meaningful tutorial available online soon.

Hunt...Peck...Think...Happy Coding...The CABOOSE Team...

CABOOSE | *.jar | JAVA archive

Team. We finished the first part of our JAVA archive for CABOOSE. This was the extensible servlet. The archive is available now and a tutorial describing its use will be placed online soon.

The CABOOSE Team

Some of the Potential Benefits of CABOOSE as Described with PHP

Team. Inspired after a brisk walk on a treadmill, we felt enough motivation for zipping a couple of Microsoft Windows folders which contain the source for the CABOOSE Site and placing them on Google Drive. The PHP archive contains the CABOOSE Type-II MVC in PHP and the StoryBoard archive holds the multi-page XHTML 1.0 CABOOSE site. For more details of the pluses and negative of using the CABOOSE approach when we created these few pages, visit our PHP CABOOSE Weblog.

The CABOOSE Team.

CABOOSE MVC Site in PHP and XHTML 1.0 Storyboard

Team. Hopefully, your week has been enjoyable without more fun than you can handle. We are delivering a port of our PHP proof of concept CABOOSE prototype MVC available on Google Drive as listed in an earlier weblog entry. This port is a PHP CABOOSE MVC interpretation of our main CABOOSE site which is a storyboard of a few pages. On the "home" page a hyperlink for the storyboard is along the bottom which will place you in the PHP controller, and in the 'home' view of the PHP MVC is a hyperlink which will teleport you out of the controller and place you back on the storyboard. The source for the storyboard and the PHP CABOOSE MVC will be available as zip archives soon. You will notice that the PHP CABOOSE has been architected slightly differently that out JAVA CABOOSE system. The PHP MVC was a quicker implementation with more pecking and less thinking. So, some redundancy exists in the structure of the xml mapping files. We will improve this in future editions of the PHP CABOOSE which will serve as a point from which we can nearly directly translate and produce our PERL and Python editions. The core of a CABOOSE system is rather small and easily implementable in a few hours. Feel free and experiment with the source code developing your own CABOOSE-style systems in your own favorite language(s). Also, as mentioned earlier this same type of dynamic invocation is useful in developing reuse-able kernels for rapid application development. An extended version of this note can be found on our PHP CABOOSE WEBlog.

Enjoy This Week. Be Diligent, But Get Plenty of Rest...

The CABOOSE Team

PHP-based MVC of CABOOSE Site

Team. The CABOOSE site is currently a few static XHTML pages which have not been validated. If one examines these carefully, one will realize that the header and footer for each page are the same. The only unique content is in the body of the documents. This "primitive" content can be factored out of each page which will leave the base template. We can then supply this template and the appropriate body content when a browser requests that view.

In other words, the CABOOSE site is a good candidate for the model-view-controller (MVC) architecture. Unfortunately, the web hosting package for this site does not support JAVA Enterprise Edition development; however, it supports the LAMP technologies. So, we will spin a quick MVC for the CABOOSE site over the next week using the PHP Hypertext Processor (PHP). We already have the source since we used PHP as a prototyping language for the CABOOSE concept when we proposed a JAVA Specification Request (JSR) for a general-purpose web-script. We shared this PHP prototype with members of the JAVA Community Process(JCP) with a few instructions. Although not immediately accepted, the way in which CABOOSE project partition concerns creates a more cognitively accessible development approach. It also allows for a greater use of existing web standards.

The current PHP prototype is not highly robust; however, it is reliable enough for simple view handling. So, we will start making a few entries on our PHP CABOOSE weblog.

Have a Great Week.

The CABOOSE Team

Website | CABOOSE

Team. This past weekend, we produced the first draft of a website for this JEE CABOOSE project. It can be found here. Take a quick tour of it. Constructive feedback is always welcome.

Happy Coding. Hunt...Peck...Think...!

The CABOOSE Team

Where We Are At, Where We Have Been, and Where We Are Headed With CABOOSE.

Team. This is where we are at...

Over the past few weeks, we have created a short "hello" web application for Oracle's MVC 1.0 platform Ozark. We have also integrated Ozark with our CABOOSE source for producing a reusable controller which one might use for rapid application development. The source for each of these programs was placed online in the form of NetBeans archives. These are both worthwhile code objectives while preparing for Q3 2016 when Ozark will be ready for regular production use.

This is where we have been...

Around March 2014, we approached Oracle's JAVA Community Process (JCP) with a proposed JAVA Specification Request (JSR) for a reusable general-purpose servlet as a controller in Type-II MVC web applications. We were seeking an Oracle mentor with experience as a specification lead as a sounding board. After review among key members of the community, it was felt that JSP and JSF are sufficient for the time being. However, we were encouraged by the JCP and told that we should consider starting an open-source project for our servlet project. The JCP said that it would reconsider the JSR if the project gained enough support form the engineering community. So, this is what we have done. Between May 2014 and August 2014, Oracle polled the general JAVA engineering community asking if it would be interested in a MVC package. "Yes" was the response. Ozark began in September 2014. The code libraries for MVC 1.0 became available in March 2015. During October 2014, we started coding and working on this web-based development history. We started with a standard JAVA application project in NetBeans that would print "Hello...". We gradually evolved it, and it eventually became a reflection-based servlet that used an XHTML-template storyboard and string substitution for producing view specifications for a web browser. All of this source was placed in-line within the regular weblogs. We contemplated placing our local source repository online, but decided that this might be a little premature for our code product. Plus, we had some questions about any future limits which we might place upon ourselves by the repository administration choices we made. March through October 2015, included some "fun" times with other projects constraining our available effort. During these months, we posted a few notes about the notion of action-able data structures and how they might find a use in CABOOSE. A few missed documentation deliverables occurred during this period, but for the most part it was moderately productive.

This synopsis leaves us at where we are headed....

We have found that Ozark integrates well with CABOOSE, Controller Application Bundles for Object-Oriented Software Engineering. We could plug-in the reflective capabilities of CABOOSE in less than an hour, plus have realized that a JAX-RS web-service likely is a better choice for this functionality that a servlet. At best, they are equally valid locations for CABOOSE principles. Over the next few months, we must gather all of our documentation, create tutorials for CABOOSE with Ozark, and finish our JAVA archive which contains a CABOOSE-based ViewEngine and Servlet. Also, we must increase our online presence and continue building our community. We have had individuals from around the globe view these development notes. We have spoken at a local IEEE chapter on IEEE about Concern Partitioning and Organization which is at the core of CABOOSE. We have also received an informal request for another talk with a greater focus on CABOOSE in the future. We have also spoken at a local JAVA User's Group (JUG). We must increase awareness about this parallelized development approach for MVC applications.

Thank You For Your Interest And Support,

The CABOOSE Team

Actionable Data Strutures and the New IF-THEN | Cogswell Cogs, Centipedes, And Stop Structures | CABOOSE Aside

Team. We are continuing our background reading on Bean Validation (BV), Context Dependency Injection (CDI), plus making another pass of the fundamentals in the JAVA Standard Edition Tutorial (https://docs.oracle.com/javase/tutorial/) for review.

Cogs from a Centipede

While doing this reading, some more thoughts on the possible behaviors for actionable data structures have arisen. We mentioned in an earlier note that a pair of cooperating circular queues could mimic a traditional for, while..do, or repeat..until structure without requiring any conditional branching and pipeline stalls. A pair of such cooperating queues would rotate upon one another like cogs in a mechanical timepiece. This would produce infinite repetition, and would likely be very rapid since it would not necessitate flushing the instruction pipeline on an erroneous branch prediction. Earlier, we labelled such a structure a centipede since the action of the data structure conjured up images of an 1980s video game of the same name.

Jane Stop This Crazy Thing

What we now need are stop structures. This is achievable with an actionable map whose get-key method results in the invocation of behavior. Such a map would hold a pair of action-sets associated with conditional truth values. On get( true-condition ) or on get( false-condition ), the resulting actions would permit the continuance of the iteration or halt it. Such a map would simulate an IF-THEN which always calculated the proper offset of the next action-set without branch prediction.


Buyer Beware

Much of these notions on Actionable Data Structures (ADS) are speculation with limited testing.

Enjoy This Upcoming Week. More will be coming in terms of CABOOSE source soon.

The CABOOSE Team.

0.75 Hour Hasty OzarkCABOOSE Integration | Kludgy

Team. Below is the link for a NetBeans archive which contains a hybrid Ozark-CABOOSE web application.

OzarkCABOOSE
https://drive.google.com/file/d/0B101EUHMgepNSWlpaU44a1JqMVk/view?usp=sharing

The application is rather kludgy and the support which connected CABOOSE with Hibernate and web-service data sources has been removed. The was simply melded quickly and the fat needs trimming. This is only a draft. Ultimately, the CABOOSE functionality will be bundled in a JAVA archive.

Have a Great Week... The CABOOSE Team

Four Extra Hours of Effort | CABOOSE - Ozark Integration | Early Draft Release for the Ozark Specification (EDR)

Team. Although we have not put the finishing touches on the CABOOSE source and placed it in a JAVA archive for distribution, we are melding the CABOOSE and Ozark products this week with the production of a ViewEngine for "caboose" views. Hopefully, we will have a NetBeans archive available early next week. With the completion of a five month project, an extra four hours of effort have been "freed up" in our work schedule for CABOOSE. This should allow for more weblog entries and development.

We had promised a summary of the first EDR of the Ozark Specification a month or so ago. Well, a second document has been released by Oracle now which exceeds the content of the first. So, we shall start working on a summary of that one.

Enjoy This Weeks Work Efforts...

The CABOOSE Team

CABOOSE Source Draft And "Hello" Example WebApp

Team. We missed celebrating our birthday. Based on the records in this draft source, we started this NetBeans project in mid-October 2014. The development process for this code is in-line in earlier post from 2015 and possibly late 2014. We probably should have placed these NetBean project (*.zip) archives on-line earlier this year. This would have eased creating a working sample of the CABOOSE servlet which we are evolving for service in an Ozark controller. Copy the source from the weblog is a tedious approach. We apologize for the lack of instructions for this, but it should be a breeze if you are comfortable with importing project for NetBeans. Our final goal will be a JAVA archive for use in future web applications. Note: This source is under a copyright as described at http://java.net/projects/caboose.

CABOOSE
https://drive.google.com/file/d/0B101EUHMgepNd19KM1JwU1JZTUE/view?usp=sharing

JAXRSHello
https://drive.google.com/file/d/0B101EUHMgepNQ1l3NWtCbktpNDA/view?usp=sharing

JAXWSHello
https://drive.google.com/file/d/0B101EUHMgepNeDVkUWdnQVZjT2M/view?usp=sharing

These can be imported, compiled, deployed, and run in NetBeans. A fully functional example web app will require completing the table design and configuration for the Hibernate transaction.

We are attracting more web traffic. Thanks for the interest....Hunt, Peck, and Think....

The CABOOSE Team

Bean Validation and Context Dependency Injection - Super Records

Team. We have been doing some reading on Bean Validation (BV) and Context Dependency Injection (CDI) over the past few weeks. We are hoping the we can include some of these features of JAVA in our solution. The constrained parameter list in BV would be very useful in enforcing the programmatic contracts found in our source which we placed in the earlier posts around January 2015. Also, CDI and Beans might prove useful in partitioning and organizing the concerns associated with processing the view directory XML file. This is since each mapping between view, page replacement variable, and rendering method is store-able in a Bean (record).

Super Records

In all honesty, we have not mastered JAVA Beans at the highest level. They are a very novel and interesting approach at processing data and take the place of those "old-fashioned" records found in languages such as COBOL, FORTRAN, and C from the 1970s, 80s, and beyond. In fact, they are "super records" in that a Bean can contain "inspector" methods which supply its properties values or combinations thereof. So, one can incorporate the "business logic" calculations found within an application in a Bean. They are a vital part of the JAVA Persistence Architecture (JPA) and products such as Hibernate. Plus, with bean validation one can apply some of the program correctness measures common in more formal programming approaches quite easily. They might also be found in the common JEE MVCs: Struts, Spring, and Hibernate. We will be working on mastering these concepts before delivering CABOOSE in a JAVA archive (*.jar) form.

Thank you for reading our posts over the past year. We appreciate your interest.

The CABOOSE Team

Actionable Data Structures (ADS) in CABOOSE

Team. We have been looking for ways in which we could include an actionable data structure (ADS) in CABOOSE. Considering the current design which has been somewhat organic because we are developing an evolve-able prototype, the primary goals of our use of ADSs should be easy integration with the current code-base, a reduction in the overall number of instructions, increased readability and maintainability, plus a better partitioning of the CABOOSE concerns.  

The Value of an ActionHashMap as a Request Processor
  
Each page concern whose content specification is drawn by a controller application bundle (CAB) represents an entity which is requesting a fulfillment service from the CABOOSE controller. The request is in the form of a unique user-defined identifier such as #PRODUCT_TABLE#. Such a label is a placeholder in an markup template for each concern. This placeholder also doubles as a string replacement variable within its XHTML stencil. In other words, the controller will replace this label with a markup string which provides a specification of the appropriate dynamic content. This content specification is the return value of a given method within a class that provides a bundle of one or more rendering services for the controller. An XML directory file contains a mapping between the user-defined placeholders and its associated rendering methods for each view that the application requests.

So, one can build an ActionHashMap which invokes behavior given a key versus returning only an object. An ActionHashMap can be built for each view based on the XML directory mappings, and when a web application requests that a given #PLACEHOLDER# be drawn with the appropriate markup specification, this placeholder might be used as a key for the ActionHashMap. The resulting object returned by this map's keyed behavior would the markup content string which the controller would inject in the XHTML stencil at the position of the placeholder.

Finally, a traditional HashMap could be built which holds all of the ActionHashMaps as values which are keyed by their associated view name.

It seems that we might have some slight convergence between ADSs and CABOOSE.

Hunt. Peck. Think. Happy Coding. The CABOOSE Team.

Ozark Tutorial for Netbeans 8.0.2 and the Bundled Glassfish Server + Maven

Team. The work hours are mounting on other projects. Fortunately, the roll-out for Ozark (MVC 1.0) is the Q3 of 2016. From the reading in the early draft it seems that CABOOSE would fit best as a ViewEngine for MVC 1.0 with possible support for the reflective JSP/JSF tags. Ozark has been available for review with the associated test archives since March of 2015. These with a sample Maven project archive are available at the following Google Drive locations:

Googlge Doc Shareable Links for Ozark Archives
java-ee-8-mvc-master.zip
https://drive.google.com/file/d/0B101EUHMgepNTVpGTWNZY0JuTm8/view?usp=sharing
javax.mvc-api-1.0-edr1.jar
https://drive.google.com/file/d/0B101EUHMgepNSHlrU2xaVHR2MHc/view?usp=sharing
ozark-1.0.0-m01.jar
https://drive.google.com/file/d/0B101EUHMgepNVW03RFdVem5JcVU/view?usp=sharing


The following is the first draft of a simple tutorial which shows one how he can compile and run the sample project "getting-started" contained in java-ee-8-mvc-master.zip plus create his own project called the OzarkTemplate.

The tutorial should take about 45 minutes or less:

Compiling and Testing the GettingStarted Ozark MVC Project

A. Transfer the java-ee-8-mvc-master.zip archive from the Google Docs link or GitHub
B. File>Import Project>From ZIP...
C. Browse for the above archive and select Import. Complete any remaining importing steps.
D. Right-click the "getting-started" Maven web archive and select Build with Dependencies.
E. Select Green Run Triangle on Toolbar which will run the project.
F. Select the blue link on the index page which appears and the controller should return hello.jsp.

Preparing for Creating your Own Ozark MVC Project

X. Transfer javax.mvc-api-1.0-edr1.jar and ozark-1.0.0-m01.jar from their listed Google Docs links, java.net, or the web.
Y. These will be used as package denpendencies in our project.
Z. They might be needed if your IDE does not find them automatically.

Creating an Ozark MVC "Hey" Project (Maven-Netbeans 8.0.2 IDE)

1.File>New Project>Maven>Web Application on the the Choose Project Page
2.Select Next
3.Enter OzarkTemplate for Project Name: (Everything else can use the default values) on the Name and Location Page
4.Select Next
5. Ensure that the GlassFish Server 4.1 is the chosen Server: and the Java EE Version: is Java EE 7 Web on the Settings

Page of the New Web Applciation Widget
6. Select Finish

Adding Dependencies

7. In the Project Explorer, right-click the Dependencies Folder under the OzarkTempalte Maven Web Application>Add

Dependency.
8. Enter the following values:
    groupId:     com.oracle.ozark
    artifactId:    ozark
    version:    1.0.0-m01
9. Select a scope of compile.
10. The jar files, ozark-1.0.0-m01.jar and javax.mvc-api-1.0-edr1.jar, are added in the project dependencies.

Adding RESTful web-service

11. In the Project Explorer, right-click the OzarkTemplates Maven Web Application >New>RESTFul WebServices from Patterns
12. Select Simple Root Resource>Next
13. Enter the following value:
    path:         ozark
    Class Name:    OzarkController
14. Select Finish

Editing OzarkController.java

12. In the generated OzarkContoller.java source add the following imports:

import javax.mvc.Controller;
import javax.mvc.View;

13. The annotate the class as a Controller:

...

@Controller
@Path("ozark")
public class OzarkResource {

....

14. The add the following resource method:

...

    @GET
    @Controller
    public String ozarkString(){
        return("/WEB-INF/jsp/hey.jsp");
    }

...

Creating "hey.jsp"

15. In the Project Explorer, right-click the OzarkTemplates Maven Web Application >New>JSP
16. Enter the following value:
    FileName:     hey
17. Select Finish.
18. Place the following content in hey.jsp:
...
<title>Ozarkian HEY</title>
...
<h1>Hey! From the Ozarks</h1>
...

19. Right-click the WEB-INF folder>New>Folder
20. Enter the following value:
    FolderName:     jsp
21. Select Finish.
22. Drag hey.jsp and drop it on the newly created jsp folder.

Creating a link which activates the controller.

23. Place the following content in the body of the index.html file:
...
<a href="ozarkHey/ozark">Ozark</a>
...

Testing WebApp

19. In the Project Explorer, right-click the OzarkTemplates Maven Web Application >Set As Main Project
20. Select Green Run Triangle on Toolbar which will build and run the project.
21. Select the Ozark link on the index page which appears. The hey.jsp page content should appear.


Hope it was fun! The CABOOSE Team... Hunt...Peck...Think...!

Loopy Fiasco | Do No Harm | Social Responsibility | Earning an Education | Good Neighbor Day (01.15.nnnn) Proposal

Team. This morning upon awakening an old college experience occurred. It is a rather natural event that occurs in the life of many. Whether it is a divine action as some believe in historical religious accounts, the result of an overactive mind taxed with many new concepts or ideas, or the hypersensitive nature of hearing upon falling asleep or awaking, modern medicine classifies it as mundane. Those who are neurotic become scared when it occurs; however, hypnogogic and hypnopompic hallucinations do not indicate any form of psychological, psychiatric, or neurological disorder.

Loopy Fiasco

Upon waking this morning, a crowd of happy, excited voices where talking about the possibility of extremely tight loops which actionable data structures. A queue with a length that exceeds that of the CPU's pipeline might have a dequeue which results in a node action followed by an immediate enqueue of the same (dequeued) node. If the action, enqueue, and dequeue source lack any conditional branches, these would prevent any pipeline stalls in an iterative structure. This might produce a very quick loop, possibly faster than doing the same in a while(true),for(;;),or do...while(true). This might be worth benchmarking. Might not. This would produce an infinite loop, and some say infinite loops are "bad". But, they have uses in computing. Remember, one can spawn new threads with any given action. Also, forgive the grogginess; this might require at least a pair of cooperating action-able structures who request dequeues from each other after an initial operation on the start structure.

Do No Harm 

If this barrage of audible ideas this morning was reliable and this does produce a faster iterative structure (loop), please do not create any malware with it. It would be worse than a worm; it would be a venomous centipede (VC) since such a structure could mount a URL request attack that might overtax a server. This would be compounded if it asexually reproduced with any of the action nodes stored in its queue. This would definitely be a "bad" modern computing version of the 80's video game.

Social Responsibility    .....    Earning an Education

Please, be socially responsible with the information which you glean during this life's experience. One earns his education with the way in which he handles it after getting the degree. If one harm others with the knowledge that one has for any reason, he really never merited having an education since there are an abundance of other "positive" things one can do with an education.

Good Neighbor Day (01.15.nnnn) Proposal

In the spirit of "do no harm", we suggest that those who read javacaboose promote the idea of an international "Good Neighbor" day. There have been many wonderful teachers throughout history who have promoted harmony among the various groups of the human people for the ant is a people, the coney is a people, and the locust are a people. A united, peaceful society is much better that the fragmented, warring one which we currently have. We will probably perform a deliberate act of social kindness for someone in an opposing social group on 01.15.nnnn; however, in honor of all the great teachers through history, chose any day of the year which you see fit and be a Good Samaritan.

Forgive the recent tangential nature of this weblog, more Ozark and CABOOSE is coming soon. Everything which converges must rise.

Have a Peaceful Week. The CABOOSE Team.

Reflection versus Interfaces in CABOOSE

Team. We have been thinking and doing less hunting and pecking recently. One thought which has made itself apparent is the use of interfaces for realizing the "dynamic nature" of reflection when invoking page concern handlers in CABOOSE and the action-able data structures which we mentioned in the last few web-post. As with many design decisions in computing, trade-off exist. Using an interface requires that not only is the method signature of the behavior under a contract, but also its identifier likewise is fixed. This might be a non-issue in some implementations, but in some development environments identifier names must follow an "organization-dependent" standard. So, simply calling the method "render" or "draw" might not be acceptable in all cases. Also, a developer might decide that the identifier for the method which fills-in the page content should reflect the purpose of the content which it is drawing in the form of page markup. This would increase the readability and maintainability of the source.

Interfaces for Actionable Data-Structures

The use of interfaces in the creation of action-able data structure nodes might be worthwhile since an informal form of name standardization exists among the behaviors found in these structures. So, an ActionableNode interface with an "action" method which bundles the methods which it should invoke in the before or after events of a push, pop, peek,enqueue, dequeue, and etc. would be acceptable. This is only true if the design permits a constant set of behaviors for a node with each data structure action. If this set of behaviors is variable, then using reflection might be the best choice.

A few simple notes for this day. Since we lost our text files of the second chapter summary, we will deliver the summary of the Ozark 1.0 early draft specification which we promised weeks ago when we find time for recompiling it.

Enjoy This Week....

The CABOOSE Team

Continued Aside: Actionable Data Structures, Object Machines of Various Types, Implementation, and CABOOSE

Actionable Data Structures

As mentioned before in the last couple of post, an actionable data structure can perform zero or more specified tasks when one of the standard operations of that abstract data type (sort) occurs. Each one of these tasks is a method contained within the object node stored in the abstract data type (ADT).

Object Machines of Various Types

Computing machines are modeled using various data types. For instance, a queue of instructions might simulated a pipe-lined processor. Another popular sort for computation is the stack ADT. Stack machines are quite common and are at the heart of many programmable calculators such as the HP 11-C. They are useful in the evaluations of expressions and conversion between prefix and postfix notation. With this in mind, if one constructed and actionable object stack machine, then he could evaluate a language of object expressions based upon the available libraries of a modern object-oriented language.

Implementation

More than one approach exist for creating actionable data structures as with traditional ADTs whose physical structure might be realized with fixed length arrays or dynamic link lists. One might produce the "actionable" behavior of these sorts using reflection, aspect-orientations, or an event-driven programming model like that found in Visual Basic.

CABOOSE

How will CABOOSE use actionable data structures? This is a great question. This dynamic behavior should be available within the model data structure which provides the views which automatically render the specification (HTML, XHTML, DHTML or XML) of the browser's requested content.
We will be revising our implementation of CABOOSE in light of these thoughts on actionable data structures.

Have a Great Week. We are still working on the summaries which we promised.
Hunt... Peck...Think....Please pardon any typos.

The CABOOSE Team

Another CABOOSE MVC Aside : Actionable Data Structures and Object Machines

Team. We promise simplicity, but for brevity we often omit supporting facts which will make the content of these post more accessible for new computing students and other experienced professionals who do not work with these specific concepts. As we said in an earlier post, we have very limited skills with the functional programming paradigm. This is because the use of command (imperative) lists is more common in traditional high level languages used for computing such as COBOL, FORTRAN, C, C++, JAVA, Ada, and etc. Other computing professionals learned functional programming as freshman at certain colleges. So, please search for more web-based information on the terms which seem uncommon. This is what we usually do when we meet unfamiliar terms. Once you supply this missing content, these pages will seem more sensible.

Over the last few post, we have been discussing actionable data structures. This arose from comments on our efforts at learning functional programming in JAVA 8 with its lambda expressions. We mentioned how these lambda expressions which are unnamed (anonymous) functions might be useful for implementing actionable data structures such as a map of behavior (actions). We also discussed how, for decades, data and behavior resided in the same program space but were not grouped (encapsulated) in bundles of related data and behavior. We also discussed how the creation of objects in the late 1980s was the realization of this concepts. Objects are not a final resting place, but a naif -like step toward more expressive ways of describing software modules when they model real-world entities. 

Shortly, after the development of the first object-oriented language, C++, many started discussing the notion of an object machine. Such a device would likely be purely virtual; however, instead of processing individual low-level commands such as those found in processor microcode or assembly instructions, these (non-physical) virtual processors would process streams of objects or commands which manipulated various class instances(objects) which one found stored in the virtual machine's memory.

With a dab of imagination, one can envision an actionable data structure such as a processing queue that functions as a virtual processor for such a non-physical machine. Being a queue, it would be naturally pipe-lined, and, being non-physical, it could do branch-prediction on the enqueue operation. This would alleviate pipeline stalls when a branching instruction decides that it must redirect the program's flow of control. The only constraint is that any object between the head and tail of the queue could not modify the state of the branching condition. This might restrict the length of the queue by not permitting any future enqueues until the next "object" for processing can be definitively identified. This is a stall of sorts for a processing queue, but does not require a flushing (ignoring) of instructions currently in a processor pipeline which are unusable.

All physical computer's use what one calls a Von Neumann architecture. The processing capacity and the memory exist in differing physical spaces. Since objects represent a bundling of related behavior and data, an object machine implemented with an actionable queue is a slight departure from this logically. Ultimately, the computing work is done on a Von Neumann machine, but it might be possible that one can reason about the processing differently when using an object machine. Since one inevitably is solving some sort of problem with each computing task, reasoning with more powerful, higher order paradigms might produce simpler solutions for difficult tasks.

For more information, search the web for notes on object-based virtual machines or object machines.
Please pardon the typos. This was a "fun" post as the German descendants in this area say. We did not properly implement our bird foraging procedure..Hunt.. Peck...Think..........
Enjoy your week, The CABOOSE Team.

CABOOSE Aside: Actionable Data Structures - Stacks, Queues, Maps, etc.

Team. This posting is simply a side note in the CABOOSE pages about a concept which might benefit its development. For those of us who were computing majors and studied data structures, we learned about various abstract data types such as Stacks, Queues, Trees, HashTables, and etc. It might have been a few semesters later when we discovered the dynamic invocation behavior available in most high-level languages. With this span between learning these concepts, it would be highly unlikely that one would consider combining them unless one was regularly working on projects which used both.

    Traditionally, abstract data types (ADTs) held data only and had rules for creating, reading, updating, and deleting the values within them. These ADTs were an extension of the primitive types found in high-level languages such as integers and floating-point numbers of various sizes plus characters. Being the precursor of modern objects, they represented a grouping of state and related behaviors; however, their purpose was storing state and providing methods for the creation, reading, updating, and deletion of this same state based upon the the rules of their interface. Early ADTs might store individual primitive types or a grouping of such types in a "record of data". When objects became available, they were the entities stored in these structures, such as Queues. Yet, presently, most of the implementations of these common data structures do not support the dynamic invocation of the methods contained within the objects that they store upon pop, dequeue, get, or etc. An interesting class of modern data types would be the actionable data structure. Upon the pop, dequeue, get, visit, or etc. of the object stored within the structure, the atomic action of a specified method would occur. There might also be value in associating behavior with the "insert" operations of these data structures. The dynamic behavior of these actionable data structures also might be toggle-able.  

Just a note before the sheep start flying overhead. Enjoy this upcoming week.
Hunt.... Peck... Think.....

The CABOOSE Team.

Passing Behavior and Custom JSP/JSF Elements + Behavioral Maps + Writing and Summary

Team. One of the primary goals of CABOOSE is simplicity in software development. The organization of webpage concerns and their associated rendering behaviors should be as intuitive as the use of a Task-Object-Event (TOE) chart in the development of a Visual Basic application. Also, a software engineer does not need a enormous set of knowledge, skills, or tools in his belt. He can be  effective with a few simple yet powerful paradigms.

JAVA Server Pages (JSP) and JAVA Server Faces (JSF) support the development of custom tags for rendering page content. We have suggested the creation of a general purpose tag which might  be useful in accelerating web application development depending upon a manager's development resources. Using the Reflection features of JAVA, it could dynamically invoke methods of any class. Also, with the advent of simplified lambda expressions in JAVA 8, behavior might also be made available which supplies page content.

Support for such a custom element might be available in the first release of CABOOSE. We must learn more about programming with lambda expression which are just anonymous functions provided through a Functional Interface with a single abstract method. We are not aware of any limitations which might possibly prevent realizing this goal. Also, we must decide whether we supply support through the functional paradigm only or also supply a general purpose tag which supports reflection.

Weaving the source which provides the custom page content and storing it in a package or library might be much easier using a general purpose tag which invokes behavior written with mundane JAVA methods or lambda expression than crafting custom tags. It would definitely lessen the learning curve for an engineer who has not created custom tags before.

Finally, it seems that a great place for all of this behavior is in a map. Such keyed behavior could be invoked with a constant time complexity provided that the number of behaviors in the maps is small. Also, when these behaviors represent a well-designed instruction set with a given command format, one can provide a set of registers for holding the parts of the imperative. This combined this the behavioral map would provide a simple and intuitive processor in an interpreter architecture when creating a command shell or meta-VM.

ASIDE: A similar behavioral data structure is possible in PERL, PHP, and Python and other UNIX-like scripting languages. Such an Abstract Data Type (ADT), the behavioral map, is viable in most modern high-level imperative languages.

We freed up some extra time this weekend so we will redraft the summary of the end of the second chapter of the Ozark MVC 1.0 specification. It should be online before the end of next week.

Also, CABOOSE might seem like vaporware if you had difficulty compiling the source which we included in-line with these post (See January-March 2015). We have simply adjusted our delivery date after we discovered that Oracle was producing Ozark. We are hoping that we can ride that "Razorback" as it is adopted within the development community. Our tentative delivery date is one hundred and eighty days after the availability of the first production-grade release of Ozark.

Pardon the long message and enjoy this upcoming weekend.

The CABOOSE Team. 

Still Searching for Early Draft Notes for the Second Chapter | Oracle's Lamba Expressions MOOC

Team. It has been a couple of weeks since the last posted comments. The summary notes from Oracle's Early Draft of Ozark, MVC 1.0 or JSR 371, are still missing. We will continue looking. If all else fails, we will simply regenerate them soon. With our current work schedule, we have only found time in the past week for participating in Oracle's Massive Open Online Course covering Lambda Expressions in JAVA Development Kit (JDK) 8.

Oracle broadcast the lessons with a YouTube viewer so they are likely available for public consumption at youtube.com. Being that functional programming is not in our skill-set. This course is quite interesting and informative. We are aware that functional programming became a viable part of JAVA before JDK 8. We are also knowledgeable of the fact that JAVA is supporting other programming paradigms than that of the imperative one in its efforts of become the first truly "universal" language. With declarative and functional features, it lets one choose the most effective paradigm for the programming task at hand.

The lambda expressions in JDK8 are a concise representation of previous functional programming features in JAVA with its support of functional interfaces. These contained large amounts of "boiler-plate" code which the Oracle engineers have subtracted from the syntax used with lambda expressions.

Upon completing the first lesson of this MOOC, we realized that it might supply a means of supporting the dynamic invocation of behavior found in the CABOOSE model, since one can pass lambda expressions as arguments. These expression are ultimately anonymous functions in the form of a functional interface. We use this term, function, in the computer science sense, because it might have void inputs or return values which are not found in the traditional functions in the field of mathematics.

But, passing behavior as an argument is quite an intriguing concept. We are only novices at the use of lambda expressions, but wonder if we can get around their "anonymous" nature by placing these functional interfaces in a HashMap, requesting them as needed with a key, and placing them in a method's argument list.

In terms of CABOOSE, we could associate each page concern with a lambda expression which handles rendering that concern.  As compact as these expression are, this would enhance the readability and maintainability of a CABOOSE project; however, it would require that a manager have development resources who are comfortable with the functional paradigm.

One feature of functional programming is that it is "stateless". We have not fully grasped how this is in that lambda expressions might modify state in the surrounding scope. Yet, it does not modify state in a certain context of the program's execution.

We apologize for the lack of activity on this weblog for the past few weeks. Things should pick up soon.

Happy Coding. The CABOOSE Team.

MVC 1.0 Early Draft - Second Chapter Summary of Final Sections Missing | Very Busy

Team. Although we have been rather busy, we completed the summary of the rest of the second chapter last week but could not find a convenient time for placing it online. In the meantime, the electronic files containing the summary have been misplaced. We must spend some time searching our various USB drives. We apologize for the lack of post over the last four weeks. Our work week has included 60+ hours of activities since 06.01.2015. We are hoping that we can free up twelve or more hours after 09.01.2015. Please, check back periodically.

The CABOOSE Team. Hunt. Peck. Think. And Keep Singing. La-La.

Community Participation in JAVA 8 | Consider IT

Team. For those of you who have the time and interest in developing and evangelizing JAVA technologies for the 8th Edition visit:

https://glassfish.java.net/adoptajsr/?elq_mid=19509&sh=17122328192691122150139523&cmid=WWMK15020783MPP039C002


There is currently a big push at Oracle for more community involvement. It is expected that JAVA 8 will have the most participation from rank-and-file engineers than any other release.

This link was available in the OTN Java Developer Newsletter - June 2015 which arrived in my inbox on the 18th of June.

The posts recently have been rather sparse since we have been preoccupied with other work. Everything happens at the right place and time. We will continue posting comments on the Early Draft of MVC 1.0 Ozark plus more on CABOOSE in future weeks.

Happy Coding...Hunt...Peck...Think...Be a Pensive Programmer...

A Summary of Section One of the Second Chapter on Oracle's Ozark MVC 1. 0 - Early Draft

The entire second chapter provides a concise summary and introduction for the three main components found in Oracle's Ozark product: the model, the view, and the controller. Oracle sets aside a section for each.

The components are addressed in order of importance and detail. The first and longest section is on controllers. The second on models, And, the last on views.

Section One of the Second Chapter : Controllers

A controller for an Oracle's MVC 1.0 architecture is a JAX-RS resources method annotated with "@Controller". One might make all of the resource methods in a JAX-RS service controllers by placing the "@Controller" annotation on the class representing all of the resources. Also, one can produce a hybrid JAX-RS webservice with a mixed of "@controller" annotated methods and regular resource methods.

The following is a definition of a simple "Hello World" controller:

//the "hello" controller method returns the path for a JSP resource.
@Path("hello")
public class HelloController {
    @GET
    @Controller
    public String hello() {
        return "hello.jsp";
    }
}

Controller methods and the regular JAX-RS resource methods interpret the String return type differently. Controller methods see a String return type as a path for viewable instead of text content. A controller might might have one of four different return types: void which requires that the method be annotated with @View, String ( a path for view content ), Viewable which bundles information about a view and how it should be processed, and JAX-RS response whose entity type is any one of the aforementioned types. It should be noted that the default content-type returned by a controller is text/html unless one specifies differently using the @Produces annotation. Also, the "@View" annotation is only applicable for controller methods with a void return type. Although only four possible return types from controller methods are allowed, the parameters of such methods do not have any limitations other than any of those imposed on regular JAX-RS service methods. Also, like regular JAX-RS services, the default resource class instance is per-request. Despite this similarity with regular JAX-RS services, controllers must be CDI-managed beans. This includes any hybrid classes.

//The controller methods in this class are all equivalent

@Controller
@Path("hello")
public class HelloController {

    @GET
    @View("hello.jsp")
    public void helloVoid() {
    }


    @GET
    public String helloString() {
        return("hello.jsp");
    }

    @GET
    public Viewable hellowViewable() {
        return new Viewable("hello.jsp");
    }

    @GET
    public Response helloResponse() {
        return Response.status(Response.Status.OK).entity("hello.jsp").build();       
    }

}


The summaries for the next couple of sections of this chapter will be coming later this week or next week. It seems that the 40+ hours of "fun" each week recently will continue for some time. This has limited the available effort on Saturdays. We will gradually adjust and hopefully resume our Monday,Wednesday, and Friday post.

Happy Coding. La-La.

The CABOOSE Team.

Second Chapter Summary Coming | Continued Thoughts on a General-Purpose JSP/JSF Tag

Team,

    The summary of the second chapter of Oracle's Early Draft Documentation for Ozark should be available by the middle of next week.

    Some thoughts arose about the notes posted earlier in this blog which suggested the use of reflection with a custom JSP/F tag for invoking behavior from a method within a classes. Also, this can be done using expression language, #{fully.qualified.class.name.method(parameters,...)}. If an application can tolerate the overhead of reflection, all of the behavior needed for generating its necessary views is encapsulate-able in JAVA packages. This might be a reasonable alternative for "custom" tag support depending upon a development teams skills set. It places most of the JEE concerns in a single custom tag which is already written and tested. The tag is extensible through the creation of libraries for the support of HTML processing.

   Another approach for achieving a similar result is the technique of  "byte-code" injection which allows for weaving compiled instructions within the fabric of existing class code. This would remove the cost associated with reflection, dynamic invocation, found in the previous paragraph.

 Simply a few thoughts for this weekend which might have some value. Some of which might have been repeated from earlier entries in the web history.

Enjoy This Weekend,

The CABOOSE Team.

 

The Final Notes for the First Chapter of the Early Draft of MVC 1.0 (Ozark)

Team. For those who are interested, Ozarks issue tracking system for the first release is located at https://java.net/jira/browse/MVC_SPEC, the API documentation is at https://mvc-spec.java.net, and one can find the reference implementation at https://ozark.java.net. After reading through part or most of the documentation, you can provide the expert group with any inputs which  are valuable by mailingusers@mvc-spec.java.net.

For those who actual read through the early draft, they should be aware that most of the terminology used comes from the JAX-RS and Context and Dependency Injection (CDI) specifications. The following pairs of terms: per-request and request-scoped plus per-application and application-scoped, are synonymous. Also, the following terms should be interpreted as they are described in RFC 2119, http://www.ietf.org/rfc/rfc2119.txt, "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional". Plus, all assertions are formatted using a descriptive name plus a label and can be found in Appendix A of the Early Draft. Also, all JAVA code fragments use a courier font and line numbering. Uniform Resource Identifiers (URIs)n of the general form "http://www.example.org" and "http://www.example.com" are application or context-dependent URIs.

A summary of the second chapter will likely come during the beginning of next week.

Enjoy a week of Enlightenment, Endeavor, and Success,

The CABOOSE Team

Slight Delay In the Fun

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.

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

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.

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.