Java CAPS 6 has the 5.x compatibility infrastructure which allows one to import 5.x projects right into Java CAPS 6, build, deploy and run without changes. One can also develop repository-based projects in Java CAPS 6 – that’s the 5.x-style projects. This is the old way of developing Java CAPS solutions – still good and valid.
If one were to decide to not use the old way there is the JBI infrastructure, which allows development of solutions that use BPEL Service Engine, XSLT Service Engine, IEP Service Engine, Java EE Service Engine, etc., and a variety of Binding Components. The implication is that business logic is implemented in BPEL 2.0, which is used to orchestrate other services and resources, including interaction with external systems through Binding Components. This is the new way of developing Java CAPS solutions – 100% compatible with the Open Source OpenESB project since it uses the OpenESB project-developed container and components.
Someone might ask “so what happened to eGate?”. “eGate” meaning Java Collaboration Definition-like logic components, eWays and the JMS messaging backbone.
While the facility seems underadvertised/downplayed, Java CAPS 6 provides a number of 5.1 eWay-based JCA Adapters and a moderately easy means of developing JCA Message-Driven Beans that can use these adapters to implement JCD-like logic components and, effectively, eGate-like solutions that do not use BPEL or the JBI infrastructure.
This Note discusses and illustrates the implementation of a JCD-like integration solution that retrieves a file from the local file system and writes its content to a JMS destination. This requirement I have seen and heard of being implemented in 5.x many times by many customers.
The JCA Message-Driven Bean, the piece of JCD-like Java logic, will be triggered by a Batch Inbound Adapter (what one would have called the Batch Inbound eWay in 5.1), will read the content of the file using the Batch Local File Adapter (eWay) and will write the payload as a string to a JMS destination. The batch Inbound Adapter will be configured to use a regular expression to match the name of the file. Once it finds the file it will rename the file by prepending the GUID to the name and will pass the new name, the original name and the directory path to the Java code. This is exactly what the 5.1 Batch Inbound does. The JCA MDB will use the new name, the original name and the directory path to dynamically configure the Batch Local File Adapter to retrieve the file content and rename the file (post transfer) to the original name with some string appended to indicate that the file was processed. This, too, is exactly what one would do in a 5.1 JCD in the same circumstance. Once the payload is available the JCA MDB will use the JMS OTD to send it, as a TextMessage, to a JMS Queue. Again, this is something that a 5.x JCD would do.
In effect, this Note describes and illustrates the process of re-creating a 5.x Java Collaboration Definition using Java CAPS 6, but instead of using the repository-based approach it is using JCA MDBs and JCA Adapters.
Complete text of the Note is in 02JCA-BInboundThroughBLFToJMS.pdf
Hi Michael. These are excellent tech tips. However, I wanted to make a comment about one thing you said – "The implication is that business logic is implemented in BPEL 2.0,…".
I think it is more correct to say that the CAPS6 lets you build with 3 different development styles.
* Repository Style (a la JavaCAPS 5.x)
* JBI Style
* JavaEE Style
Where the JavaEE Service Engine is really a bridge to join the JavaEE applications (including Repository apps which are really just JavaEE apps at runtime) with the JBI-based applications.
The JBI style promotes solutions based Service Oriented Integration principles. See Ron’s whitepaper here https://open-esb.dev.java.net/public/whitepapers/JBIforSOI.pdf
SOI promotes communication through service interfaces but does not require BPEL as the means of interaction. BPEL is quite often used as a means of orchestrating services, and is used in many examples for openesb, but it is not required or implied. For instance, see Mark’s example of invoking reusable transformations from different bindings without BPEL: http://wikis.sun.com/pages/viewpage.action?pageId=38211717
Having said that, I agree that it is harder to build "egate"-like applications with the JBI technology that exists in JavaCAPS6 and that JCA adaptors, which are used in the JavaEE style, are an excellent inclusion in the product. One of the goals of OpenESB v3 is the IntegrationFlowLanguage which provides a means of routing and mediating msgs between service interfaces without a full orchestration language like BPEL. I believe it will provide considerably more flexibility than exists in CAPS6 (in any development style) if/when it makes it to CAPS. http://wiki.open-esb.java.net/Wiki.jsp?page=IntegrationFlowLanguageOverview
cheers
Jason
Thanks for putting up these tutorials, as there isn’t much documentation/examples out there to show the ‘new’ way of development.
I understand that writing a JCA component in JCAPS 6 is the ‘new’ way of development (versus the older ‘repository’ based development).
I have to ask though, why is new development in JCAPS 6 such a radical shift from what development is in JCAPS 5.1.3? Why do you have to manually set up connection pools in the asadmin instead of hooking into the extremely useful collab map editor (I’m sure it would need to be tweaked for working with JCA MDBs, but the convenience and usefulness of the tool would be much appreciated?. Is all of this extra hassle really worth getting away from the repository? Are there any more pros/cons of going to JCA MDBs versus staying in the land of JCDs?
Thanks in advance for your time!
Hello, Jason.
True. Once one gets one’s hands on the NetNeans IDE there are lots of development styles one can adopt. The JBI is a major direction for “uber-application” development. It emphasises Service Orchestration, which is the natural model for it. “Pipelining”, which is what Mark’s solution might be considered a component of, is the old-fashioned Messaging, and JBI is not a natural model for it, though Mark’s tutorial certainly demonstrates that it is possible to accomplish. The Integration Flow Language effort is an example of an effort aimed at producing a way or expressing and representing Messaging/Pipelining solutions.
Regards
Michael
Hello, Adam.
Thank you for your comment.
By going to GlassFish as the runtime platform the Java CAPS team must negotiate getting changes into GlassFish. Due to different development schedules this is not easy. There will be improvement in the area of setting up resources in the GlassFish Application Server but the extent and the timing of these developments is unknown at this point. Field input may help in negotiations.
The Java Collaboration Editor in 5.1 was tied to a Java model based on JDK 4. Moving the model to include Java 5 features would have added a considerable amount of effort that would have adversely affected Java CAPS 6 delivery schedule. Java CAPS team are looking into different tools for Java, and there is an initiative to come up with a completely graphical mapper similar to the BPEL mapper.
There is an initiative underway to build a top down design view that may address the issue with no connectivity-equivalent in the JCA space.
To quote the source, “In short: the EE 5 approach has its strengths and weaknesses as compared to the Repository-based approach. We have not overcome all the weaknesses yet.” (but are working on it).
Regards
Michael
Hi Michael,
Can you give us more information on this initiative for a new graphical mapper ?
What will be the technology to which that mapper is linked ? (Java, XSLT, .. ?)
Do you know if/when XLST 2.0 will be implemented ?
Regards,
Geert