Jun 12

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:
Jun 08

As implemented in OpenESB and Java CAPS 6/JBI, JBI at first put me off completely. I had no idea where to start and what to do. This was particularly annoying as I was reasonably effective in developing solutions using Java CAPS 5.x and did not look forward to trying to figure out how to do in OpenESB the same thing I already new how to do.

This document is intended to save you the anxiety and help you get over the initial hurdles. It walks through the process of creation, deployment and execution of a simple File-to-File integration solution, with detailed step-by-step illustrations. 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.

01File2File.zip contains the document that documents the example in an illustrated, step-by-step fashion.

Tagged with:
May 14

A couple of years ago I worked out how to supplement WS-Security infrastructure in Java CAPS 5.1.1 with additional services that WS-Security 1.0 (2004) supports, namely SOAP Message Security, X.509 Certificate Token Profile and Timestamp Token Profile. Together these provide Java CAPS solutions with XML Digital Signatures, XML Encryption, Sun Access Manager-mediated Username-based authentication and Timestamp support.

The attached document is 1 and a half years old. It makes statements about Username Token support in Java CAPS 5.1.1 being broken. Java CAPS 5.1.3 supports Username Token just fine so these statements are no longer true. Java CAPS 5.1.3 U2 adds a mechanism for hooking SOAP envelope handlers into the Java CAPS Web Services framework so what I did and described in the document can now be done differently – perhaps better and more transparently. I have not tried.

This material is provided on request on “all care but no responsibility” basis. Sun Java CAPS Support will not support this and neither will I. JAC-RPC from WSDP 2.0, which is at the heart of the implementation, is deprecated and has long since been replaced by WSIT/JAC-WS/Tango. Still, here it is if anyone is interested.

JCAPS with JWSDP 2.0, Implementing WS-Security_1.1_JCAPS5.1.1.pdf” – discussion paper

Supporting materials are over 40Mb so I can’t post them to the blog. If anyone is interested says so.

Well, someone said so. The archive, WSSecSampleProject_1.2_JCAPS5.1.1.zip, is posted. Please understand that this is “all care and no responsibility” material. I don’t have the time to spend working through issues with individual people. It all worked at the time I put it together and on occasions since. It ought to work for you as well 🙂

Apr 05

Transferring large payloads, on the order of tens or hundreds of megabytes, between a FTP server and a local file system, in either direction, requires selection of appropriate features of the Batch FTP and Batch Local File eWays, and tuning certain timing parameters.

Default timing parameter values result in timeout exceptions when transferring large payloads.

The Batch FTP eWay and the Batch Local File eWas are typically used to receive the entire payload before writing it out. This results in attempts to allocate memory many time the size of the payload being transferred and, for large files, causes memory exhaustion and application server failures.

Discussion in the attached document points out which timing parameters need to be tuned to facilitate transfer of large payloads. It also presents sample Java code that uses facilities of the Batch FTP and Batch Local File for streaming payload between the FTP server and the local file systems without using excessive amount of memory.

The material covered in the document was prepared using Java CAPS projects developed and tested in Java CAPS 5.1.0, exported, imported into Java CAPS Release 6 and tested again. It is expected that the code will work in all versions of Java CAPS from 5.1.0 up.

Streaming Large FTP Transfers with CAPS 5.1 and 6.pdf

FTPtoLocalFileStreaming_5.1.0_project_export.zip

LocalFiletoFTPStreaming_JC6_project_export.zip

Tagged with:
Feb 26

APAC Extended Horizons is on in Sydney, May 25th through May 27th. Although it is and Asia Pacific event in intent all are welcome.

Here is the link to the flayer that has mode details.

The event web site with preliminary agenda and additional details should be up and running mid March (after Sydney Tech Days, http://au.sun.com/sunnews/events/2008/techdays/index.jsp, are over).

Tagged with:
Jan 11

By default, the Sun SeeBeyond Integration Server domain uses a single log to log all events, whether arising out of execution of the Integration Server or arising out of execution of Java CAPS solutions deployed to it. This log is named server.log and is kept in the <JavaVACPInstallRoot>/logicalhost/is/domains/<domainroot>/logs directory.

This note discusses how the Integration Server can be configured to deliver all or selected events to an additional log handler and how XML-formatted event information can be obtained. This note also presents some ideas on multiple logging destinations and notification.

Here is the Note itself: Java CAPS 51 – logging to additional destinations.pdf

Warning

The writing of this note, and the underlying development and configuration work, were prompted by repeated questions about logging in Java CAPS, in particular how it could be made to behave like it used to in the non-J2EE versions of the SeeBeyond EAI products. For these readers who are still waiting for the answer they like – there will be no such answer coming. It is not possible to configure logging for ‘your interface’ separately from logging for all other ‘interfaces’ since there is no notion of ‘your interface’ as a separate component in Java CAPS. There is no way to collect logging information pertaining to a specific project or deployment in such a way that all relevant information is collected, no information is lost and no information on unrelated components is included.

Tagged with:
Dec 28

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

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

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.

Nov 25

This example implements a part of the ELS functionality dealing with linking a number of related messages, a counted correlation pattern, or an aggregator pattern.

Unlike the simple implementation from Example 1, this implementation will correlate a varying number of messages, statically set at design time. 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. By obtaining the value of the business process attribute, which controls the message count, from the environment or the initial message, one will change the static implementation into a dynamic counted correlation solution.

CorrelationExample_02_StaticCounted.pdf discusses the example and addresses key points in its implementation.

CountedStatic.zip is a Java CAPS 5.1.3 project export that implements the correlation in this example.

preload preload preload