Jul 27

Java CAPS 6, JCA, Note 7 – Batch Inbound-Triggered JCA (Non)Transacitonality

By Michael Czapski Sun No Comments »

In Note 6 we explored the transactional behavior of a JCA MDB invoked by a JMS Adapter and orchestrating an Oracle JCA Adapter (a transactional end point) and a Batch Local File JCA Adapter (a non-transactional end point). In this Note let’s explore the issue of transactionality of a JCA Message-Driven Bean invoked by a non-transactional end point.

Let’s take the example from the “Java CAPS Basics: Implementing Common EAI Patterns Companion CD” book, ISBN: 0-13-713071-6, Chapter 11 “Scalability and Resilience”, Section 11.2 “Exception Handling”, subsection 11.2.1 “Exceptions in Java Collaborations”, 11.2.1.2 “Other Java Collaborations”. The book from which this section comes is available on the Companion CD. Let’s re-work this example using Java CAPS 6 JCA Adapters.

The example illustrates exception processing behaviour involving a Batch Inbound Adapter-triggered JCA Message-Driven Bean.
The Batch Inbound Adapter is designed to poll a directory for a file. When it finds a file that matches the name, or the name pattern, it immediately renames the fie by prepending a GUID to the original name then triggers the MDB and passes to it the original name of the file, the current name of the file and the directory in which the file was found. This behavior prevents other possible file pollers from getting hold of the file and gives the first comer exclusive access to the file. The MDB is designed to take the name of the file as given and rename the file to the original name with the suffix “~.in” appended, to indicate the file was read and processed. To do this the MDB will use the Batch Local File JCA Adapter’s capability to post-process the file by renaming or deleting it. To explore the transactional behavior the MDB will explicitly throw an exception after it renames the file.
The complete Note is available in 07BatcyhInboundTriggeredJCANonTransacionality.pdf.

Tagged with: • • • • • • • • • • • • • •
Jul 24

Java CAPS 6, JCA, Note 4 – Streaming FTP Inbound

By Michael Czapski Sun No Comments »

As at now there does not seem to be a way to stream FTP payloads to the local file system, or stream local files to FTP servers in the JBI environment. This kind of functionality may or may not appear in the OpenESB project, perhaps in conjunctions with the FTP BC or the File BC or both. In the meantime, a Java CAPS 6 developer can use the JCA Adapters-based solution to stream payloads of arbitrary size between FTP servers and local file systems in either direction.

This Note walks through the implementation of a Batch FTP JCA solution, which is triggered by a JMS Message, and performs a streaming FTP transfer of an arbitrarily large payload between a remote FTP server and the local file system. This Note re-implements the inbound part of the “Java CAPS 5.1 and Java CAPS 6 – Streaming Large FTP Transfers” Note available at http://blogs.sun.com/javacapsfieldtech/entry/streaming_large_ftp_transfers_with.
It should be easy enough to re-implement the outbound part of that Note using the material in this Note.

The complete Note is available in 04JCAStreamingFTPIn.pdf.

Tagged with: • • • • • • • • • • • • •
Jul 17

Java CAPS 6, Using JCA and JBI, Note 3, Batch Inbound, through Batch Local File to BPEL 2.0

By Michael Czapski Sun 17 Comments »

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 mixed Java CAPS 5.x-like integration solution that retrieves a file from the local file system using JCA Adapters and passes its content to a BPEL 2.0 process executing in the JBI container. This requirement I have seen and heard of being implemented in 5.x many times by many customers.

Most of the material in the first 16 pages of this Note is the same as in Note 2.

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 send the payload as a string to a BPEL 2.0 Business Process, which will be triggered by this message and will execute in the JBI container. 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 OneWay WSDL interface and the JBI NMR to send it, as a String, to a BPEL 2.0 process. Both the JCA MDB and the BPEL process will be a part of the same JBI Composite Application and will communicate with one another using the Normalized Message Router (NMR).

The entire Note is available in 03JCA-BInboundThroughBLFToBPEL2.0.pdf

Tagged with: • • • • • • • • • • • • • • • • • • • • • • • • •
Jul 16

Java CAPS 6, Using JCA, Note 2, Batch Inbound, through Batch Local File to JMS

By Michael Czapski Sun 5 Comments »

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

Tagged with: • • • • • • • • • • • • • •
Jul 14

Java CAPS 6/JBI, Note 5 – HTTP BC to SMTP BC, No BPEL

By Michael Czapski Sun 12 Comments »

Someone asked a question along the lines of “Is it possible to develop a solution in OpenESB where the HTTP BC receives a request and the SMTP BC uses it to send electronic mail with no BPEL logic to tie the two together”. I though that the answer was “Yes” but I felt I had to verify it. Vishnuvardhan Piskalaramesh from Sun, who is looking after the SMTP BC, and Sherry Weng from Sun, who is looking after the HTTP BC, helped along and here is the result.

This note describes, with illustrations, a mini integration solution wherein an appropriately formulated HTTP GET request is used to submit an electronic mail to a SMTP server, using the HTTP Binding Component and the SMTP Binding Component, without the need to provide any transformation logic. This is another example where a
practical JBI-based integration solution can be constructed in minutes.
05JBI_HTTP2SMTP_NoBPEL.pdf provides the illustrated discussion.

Tagged with: • • • • • • • • • • • •
Jun 12

Java CAPS 6/JBI Note 2 – Basic File-to-File projects with multi-record files

By Michael Czapski Sun No Comments »

This document is intended to help you get over the initial hurdles of exploring Java CAPS 6/JBI and OpenESB. It walks through the process of creation, deployment and execution of a simple File-to-File integration solution, and a simple File to BPEL Process to File solution, with detailed step-by-step illustrations. Both solutions use inbound files with multiple records. The focus is the practice of using JBI components not the theory of JBI. This document addresses the integration solution developers, not developers of Service Engines or Binding Components. The projects use JBI components only, that’s why they are just as good for OpenESB exploration as they are for Java CAPS 6/JBI exploration. JBI (Java Business Integration) is not discussed to any great extent. JBI artifact names are used in discussion but not elaborated upon. Explanations are provided where necessary to foster understanding of the mechanics of developing integration solutions using JBI technologies in OpenESB and Java CAPS 6/JBI. Java CAPS 6 and OpenESB are two of a number of toolkits that implement the JBI specification (JSR 208). When I use an expression like “In JBI …” I actually mean “In JBI as implemented in Java CAPS 6 and OpenESB …”. The same things may well be implemented differently in other JBI toolkits. Java CAPS 6 “Revenue Release” is used and shown in illustrations. OpenESB can be used instead however the appearance of components shown in illustrations may vary somewhat.

02File2FileMultiRec.pdf contains the complete solution writeup.

Tagged with: • • • • • • • • • •
Dec 28

Java CAPS 5.1.3 – JCD-based Programmatic log manipulation

By Michael Czapski Sun No Comments »

In Java CAPS 5.1 the Sun SeeBeyond Integration Server is a modified version of the Sun Application Server 8.0 Platform Edition. As such a number of things that can be done with that application server can be done with the Sun SeeBeyond Integration Server. Most notably, the Sun SeeBeyond Integration Server uses the java.util.logging API for logging. Integration Server logging can be manipulated from the command line, using the isadmin tool, from a Web-based GUI and, also, programmatically.

This note discusses how IS logging can be manipulated programmatically using Java Collaboration Definitions. This note applies to the Sun SeeBeyond Integration Server included in Java CAPS 5.1.

JCD-based Programmatic Log Manipulation Note

Java CAPS 5.1.3 Project Export

Trigger Data Files

Tagged with: • • • •
Dec 26

Java CAPS 5.1.3 – Sun SeeBeyond IS – Note 1 – Logging management with isadmin

By Michael Czapski Sun No Comments »

In Java CAPS 5.1 the Sun SeeBeyond Integration Server is a modified version of the Sun Application Server 8.0 Platform Edition. As such a number of things that can be done with that application server can be done with the Sun SeeBeyond Integration Server. Most notably, it can be managed at runtime using the isadmin tool much the same way as the Sun Application Server 8.0 PE can be managed using the asadmin tool.

This note discusses how the isadmin tool can be used to manage runtime logging of the Sun SeeBeyond Integration Server. This note applies to the Sun SeeBeyond Integration Server included in Java CAPS 5.1.

Tagged with: • • • •
Nov 25

Java CAPS 5.1.3 Correlation Example 3 – ELS Static Counted and Timed Correlation

By Michael Czapski Sun No Comments »

This example implements a part of the ELS functionality dealing with linking a number of related messages until all are collected or a time period elapses, whichever is the sooner, a counted and timed correlation pattern, or an aggregator pattern with a timer.

Unlike the implementation from Example 2, on which it is heavily based, this implementation will correlate a varying number of messages, statically set at design time, or as many as it receives within a given time period expressed as a static duration. Thus the same implementation can be used to correlate 2, 3, 10 or 30 messages, by modifying the value of a single business process attribute, over a statically configured time period. By obtaining the value of the business process attribute which controls the message count or which controls duration, from the environment or the initial message, one will change the static implementation into a dynamic counted and timed correlation solution.

CorrelationExample_03_CountedAndTimed.pdf discusses the solution and illustrates key points that vary between Example 2 and this example.

CountedAndTimes.zip is the Java CAPS 5.1.3 project export that implements the solution.

Tagged with: • • • • • •
Oct 22

Java CAPS 5.1.3 Data Streaming

By Michael Czapski Sun No Comments »

Handling very large messages in a messaging solution may require memory resources many times greater than the size of the largest message to be handled. Frequently the architect has no choice but to consume or produce a very large message, a file containing a batch or related transactions, for example, or a large and complex XML message generated by, or intended for, an external application. Handling such messages poses special challenges.

Java CAPS can assist with Batch eWay support for data streaming when large messages are manifested as files in a file system.

If it is possible to break large messages up into components and process components individually, or collect components and assemble them into a large message. eTL, another of the products in the Java CAPS Suite, can assist in processing large volumes of data. Whilst ETL (Extract, Transfer and Load) is typically associated with one off batch extraction and load of data, Java CAPS’ eTL can be used both standalone and in-stream as part of a larger Java CAPS solution. In this in-stream mode it will be discussed as a possible means of streaming data between a flat file and database table or between
database tables/views.

This extract from the soon–to-be-released book, “Java CAPS Basics – Implementing Common EAI Patterns”, discusses the Java CAPS 5.1 Batch eWay streaming facilities, and presents and compares a number of data streaming implementations, including an eTL implementation.

Link to Java CAPS 5.1.3 Data Streaming  section of the manuscript.

Tagged with: • • • • • • • • •
preload preload preload