Wednesday Aug 20, 2008

Java CAPS Users Conference - Registration Open

Registration is now open for the Java CAPS Horizons event.

Thanks to all the OktoberFest hotel prices, we had to push the dates back one week so it will now be October 13-15 in the Sun offices in Munich.

Wednesday Jul 23, 2008

Addendum to the OpenESB Introduction Tutorial

The OpenESB Introduction Tutorial was created back in Jan 2008 and a few things have changed in the tooling since then. This entry shows a few changes I would now make to Part 2: Calling from BPEL to a JavaEE Service through the NMR.

The most important is that the EJB Service exposes its own SOAP endpoint even though I am calling it from the BPEL process. This was due to limitations in the tooling at the time concerning the relationship between JavaEE Service Units and EJBs that implement JAX-WS webservices. These limitations have now been fixed and JavaEE Service Units can now be created without this extra soap endpoint. See this article on the Grok JavaCAPS wiki for more information.

You can see at 5:17 the JavaEE Service Unit has its own SOAP Binding Component Service Unit

This happened because I included binding information in the WSDL of my EJB project back at 1:58, which was required by the tooling at the time. Now I would simply press Finish after creating the Abstract WSDL. The extra SOAP binding will now not be created. Alternatively I could simply disable that SOAP endpoint in the deploy options of my composite application project (see the grok article for details)

The next small change to make is when including the EJB project in the Composite Application Project. At 4:46 I do that by going through the filesystem to find the project. Now I would just drag the EJB project straight onto the CASA canvas and it is included.

Finally, when adding the WSDL for the EJB service to the BPEL project (at 6:03) I once again searched through the filesystem to locate the wsdl. It is now possible to simply drag the WSDL from the Project Explorer directly into the Partner Lane of the BPEL canvas. The tooling will automatically import the WSDL and related XSDs into the BPEL project.

Removing the default SOAP binding for JavaEE Service Units

Sometimes when you create a Service Unit for the JavaEE Service Engine(e.g., an EJB service) you end up with an extra SOAP Binding Component Service Unit which is deployed whether you want it or not. This article on the Grok JavaCAPS wiki explains why that happens and how you can remove / disable it.

Tuesday Jul 22, 2008

Communicating through the JBI Bridge from BPEL to a JCD

One of the features of JavaCAPS 6 is the ability to communicate between the new JBI-based applications and the Repository-based projects of the JavaCAPS 5.x technology. This allows reuse of existing projects and the ability to make use of the 5.x architecture while it continues to provide functionality that is not yet available in the new technology.

This example shows how to communicate from the JBI-compliant BPEL 2.0 engine of OpenESB and JavaCAPS to a repository-based JCD. Though the principle is the same for communicating from any JBI-compliant composite application to a JCD.

The starting point for this example is the OpenESB introduction tutorial. This example also assumes that you are familiar with the JBI-based technology of OpenESB and the repository-based projects of JavaCAPS. If you are not yet familiar with the JBI-based technology, you should definitely start with the aforementioned tutorial.

The first step in the tutorial creates a simple BPEL process, which is exposed using a SOAP Binding Component Service Unit, and then deployed in a Composite Application (a Service Assembly in JBI speak).

The second step shows how to invoke an EJB Service from that BPEL process. But what if you wanted to implement that functionality in a JCD? You might do this for 2 reasons:

  1. You already have the functionality implemented in a JCD and you want to reuse it
  2. That step may consist of considerable mapping logic and it will be easier to implement it using the graphical mapper of JCD collaborations rather than writing the java manually.

The following movie shows how to:

  1. create a JCD using XSD OTDs
  2. build it in a repository-based project
  3. include that project as a Service Unit in a JBI Service Assembly (Composite Application)
  4. test the process and jcd

Demo movie

 (This item is also located on the Grok JavaCAPS wiki)

Monday Jul 21, 2008

Packaging reusable services in OpenESB and JavaCAPS 6

When you need to create reusable services in OpenESB or the JBI components provided in JavaCAPS 6 you are constrained by the packaging and deployment model defined in the JBI standard. This entry will look at the different alternatives and their consequences.

The JBI standard refers to individual services as Service Units (SU) and requires that one or more SUs must be packaged together as a Service Assembly (SA) for deployment. A deployable application would then consist of one or more SAs. You can think of it was being analogous to JAR files and EAR files in JavaEE. These SAs are atomic deployment units to a JBI-compliant runtime such as OpenESB or JavaCAPS 6.

For instance, this Hello World SA example consists of two SUs, one for the BPEL process and one for the SOAP binding component:

Let's look at an example using processes and sub-processes by stretching the Hello World example beyond where it should go. Although I'm talking about BPEL SUs, the principles are the same for packaging and deploying reusable SUs defined for any Service Engine.

Say we have a business process, bpHelloWorldMulti which takes two strings in its input msg, the name of the person to say 'hello' to and the language to use when saying 'hello'. If 'language' = "EN" it says "Hello "; if 'languague' is set to "NO" it says "Hei " (norwegian).

Now we have two other processes, bpHelloWorldEN and bpHelloWorldNO. Which expose services to say hello in English and Norwegian respectively. They implement themselves by simply calling the subprocess bpHelloWorldMulti with the language element set to 'EN' or 'NO'

How should these be packaged and deployed in SAs? There are 3 alternatives.

The first alternative is to package the reusable service, bpHelloWorldMulti, with a binding such as a SOAP binding, into a SA and deploy it. bpHelloWorldEN and bpHelloWorldNO are also packaged in their own respective SAs and deployed. The two main processes can then call sub process as if it was a remote service.

  • Advantages:
    • The 3 services are all independent of each other and can be undeployed, modified, and redeployed as needed.
  • Disadvantages:
    • Communication between two services must occur through binding components - over the wire - which is inefficient when all services are hosted on the same node.
    • Some dependency checking needs to be done to ensure that bpHelloWorldMulti is deployed before either of the two calling services are executed. This wont be checked at deploy-time by the runtime environment and will result in a runtime exception if the bpHelloWorldMulti is not deployed when one of the services attempts to invoke it.

The second alternative is to package bpHelloWorldMulti in both of the two SAs which hold bpHelloWorldEN and bpHelloWorldNO. That is, there is a copy of bpHelloWorldMulti in each of the two SAs.

  • Advantages
    • Communication can occur more efficiently by not requiring over-the-wire communication through binding components
    • Developer dependency checking is not a problem because bpHelloWorldMulti is deployed and undeployed with each its calling services.
  • Disadvantages
    • Service Units deployed to the same JBI component require unique xml schema QNames. The two versions of bpHelloWorldMulti in each SA would need to have different namespaces so there are no name clashes during deployment.
    • Maintenance nightmare.

The third alternative is similar to the first - the three services are each deployed in their own SA. However, in this case we register bpHelloWorldMulti as an External Service Unit in the Service Assembly of the two calling Service Assemblies. In this scenario, when we deploy the SAs for bpHelloWorldEN and bpHelloWorldNO , they will be able to communicate through the NMR (i.e., not over the wire) with bpHelloWorldMulti. This is the best alternative in most reuse scenarios.

  • Advantages:
    • Communication can occur more efficiently by not requiring binding components
    • The three Service Units are all independent of each other and can be undeployed, modified, and redeployed as needed.
  • Disadvantages:
    • Some checking needs to be done to ensure that bpHelloWorldMulti is deployed before the two calling services are invoked. This wont be checked at deploy-time by the runtime environment and will result in a runtime exception. Similarly, if the bpHelloWorldMulti is undeployed or the interface is changed, a run-time exception will result.

There is also a fourth alternative, where bpHelloWorldMulti is packaged in the same SA as bpHelloWorldEN, and bpHelloWorldNO refers to it as an External Service Unit. That will have similar disadvantages for bpHelloWorldNO as the third alternative.

Monday Jul 07, 2008

Java CAPS Users Conference - EMEA

The Java CAPS Horizons Summit is returning to Europe with a two-day conference plus post-event hands-on workshops.

The summit agenda is designed for Java CAPS Customers to:

  • Become familiar with the new technology in Java CAPS Release 6
  • Gain insight into migrating to the new platform
  • Get the latest developments and insider tips directly from technology innovators
  • Participate in workshops, technical deep dive and solution sessions
  • Network with your peers and exchange knowledge
  • Become familiar with the components of Java CAPS including: GlassFish Enterprise Server, Access Manager, Sun Java System Message Queue, NetBeans IDE, and MySQL
  • Learn how to participate in the open source communities which will drive Java CAPS going forward.

Another goal of the summit is to provide customers with a chance to interact directly with representatives from the Java CAPS Engineering team. This may be in the form of a common round-table session or as a 1-on-1 session. When registration opens you will have a chance to sign-up for an engineering feedback sessions

The date and location are tentatively set for Oct 6-8 in Munich. Hopefully they will be confirmed in the coming weeks but we wanted to announce as early as possible before people start their summer vacations.

Friday Jun 20, 2008

OpenESB @ JavaDeus

Yesterday was the Austrian Developer Day - JavaDeus. It was a good event with about 450 attendees, not to mention the free beer, dinner, and giant outdoor screen to watch the euro2008 qtr final after the technical sessions had finished. Plenty of Sun technology on show with JavaFX, DTrace, SunSPOTs, Alexis doing his Glassfish spiel, and also one of the MySQL engineers, Kay, doing some sessions.

The OpenESB session went well with a full room of developers and also a couple of JavaCAPS users who were interested in new capabilities. I combined the introductory presentation and demonstration into a single session and also showed off some of the Fuji technology being prototyped for OpenESB v3.

The session before mine was also interesting with a former Sun employee discussing the integration concepts used by Mule2 and SCA (as realised in Tuscany). Combined with the OpenESB session it showed that many of the concepts are analogous (though not equivalent) across all these infrastructures, though the implementations vary in their approach to in-built mediation support, tooling, pluggability, and vendor independence.

The OpenESB tooling really stood out and, though Mule currently has more out of the box mediation capabilities, the Integration Flow Language of Fuji certainly looks like a very flexible alternative. The technology preview shows a lot of promise and IFL generated the most interest amongst people with some experience with integration middleware.

Wednesday Jun 11, 2008

OpenESB at Austrian Developer Day

As Alexis already pointed out, Sun Austria is hosting a Java Developer Day on June 17th 2008. This is a free event with NetBeans, JavaFX, MySQL, OpenSolaris, OpenESB, and of course GlassFish.

I'll be doing a preso/demo of OpenESB. If you are interested in OpenESB or its relationship with JavaCAPS Release 6, come on down.

Thursday May 15, 2008

Differences between Java CAPS 6 and OpenESB

One of the most common questions I get asked is, "Will Sun support OpenESB?" or "Is Java CAPS a supported version of OpenESB?" Developers want to get started now with functionality in Open ESB and feel confident that it will be supported by Sun with a Java CAPS license.

We do already have some JavaCAPS customers who are entering the development phase of their projects with Open ESB in the knowledge that the infrastructure will be a supported part of Java CAPS by the time they go to production. Unfortunately, the answer to the original questions is a little more detailed than simply "yes" or "no". Let me explain...

Java CAPS 6 is, to grossly oversimplify it, Java CAPS 5 + some OpenESB technology. However the first release of Java CAPS 6 will not include all OpenESB components. This is for a couple of reasons:

  • Not all openesb components have been through the necessary QA to make them ready for production yet.
  • Not all openesb components are developed by Sun, so it is impossible for Sun to support them.

When Java CAPS 6 is released, it will consist of some openesb components. For instance:

  • JBI runtime.
  • JavaEE SE

During the rest of 2008, Sun will continue to make other openesb components production ready and make them supported parts of Java CAPS. The exact content and timeline of these "Component Packs" or is still to be released, but you can probably expect them to include:

  • IEP SE
  • JMS BC
  • File BC
  • others.
(note: I'm not in product management so this isn't an official list, just an indication)

Additionally, Sun may enter agreements with the companies who are developing other openesb components and make them "supported" parts of Java CAPS. So it is possible that OpenESB components that are not developed by Sun will also be supported by a Java CAPS license.

To give you an example. I currently have two Java CAPS 6 "customers", even though it has not yet been released.. They have looked at their requirements and see that they need only components which will be available in the initial release of Java CAPS 6 or will most likely be available in Component Packs in 2008. They have started development work now and plan to be in production in 2009. By 2009, all OpenESB components they need will be supported parts of Java CAPS.


Monday May 05, 2008

Overview of OpenESB Sceencast

I've created a new screencast which provides an overview presentation of OpenESB, including how JBI works, and how OpenESB relates to JavaCAPS.

Having run OpenESB workshops with companies for almost 18 months now, I realise that it is easy to misunderstand the how a JBI-compliant infrastructure operates and also what information is needed by developers to design and build solutions.

JBI is a standard for infrastructure developers and the inner-workings really are not always relevant for developers building applications with a JBI compliant infrastructure. However, app developers should have an understanding of the basic concepts to understand what is happening. Many developers also like to know what is happening "under the covers" so that they fully understand how issues like performance, security, and transactions are handled by the infrastructure. Hopefully this presentation provides that information.

The presentation walks through an example, actually the tutorial problem which was detailed in the last entry, and explains how service interaction occurs and the role of the normalised message router from the developer's perspective.

Friday Jan 25, 2008

Introduction to OpenESB tutorial

I've created a set of screencasts showing how to build a simple composite application using OpenESB. The goal is to build something simple which shows multiple Service Engines and Binding Components to reinforce the concepts of Java Business Integration. The Demo Project is an over simplified Loan Application Process (there is an unwritten rule that all vendor demos must use a banking applications :). The composite application consists of the following parts:
  • the process orchestration is implemented in BPEL
  • the process should be exposed to Applicants as a WS-I Basic Profile compliant webservice
  • the process invokes a JavaEE EJB to performing the processing of the loan application
  • after processing, the process invokes a ReportMail Service which is running remotely and can only be communicated with through JMS
  • finally, the capability to invoke the Loan Application Process through the file systems (e.g., incoming ftp msg) in addition to a webservice endpoint is added.

Thursday Mar 16, 2006

Embedding JavaDB as an in-service cache

This entry shows how JavaDB can be used as an embedded database to act as a cache for services deployed in the Sun Application Server.

I was recently working on a project where we needed to wrap a legacy application as a reusable Service. This wrap&reuse situation is something we often encounter. For instance:

  • A read-only Service must exist to return information to external clients
  • The information changes quite slowly
  • That data exists in a legacy backend system.
  • The cost of communicating with the legacy system is relatively high. This can be because of both communication time and financial cost because the legacy system maybe remotely hosted.

So, I thought it would be a good chance to try JavaDB / Derby as an embedded database to cache the results of the legacy system calls in the Service itself to limit the amount of communication with the backend. This is a simplified version of how I got to work.

The first step is to get JavaDB installed on your machine. There is an article over at Linux-Mag that provides a simple guide for doing that.

When JavaDB is used in embedded mode there can only be on client connected to the DB at a time. So you need to create the table, copy the embedded database libraries to the appserver, then restart the appserver. When the appserver restarts it creates and maintains the client connection to the embedded database.

Start by making a table to store the cached data.

bash-3.00$ java -Dderby.system.home=/export/home/jb156719/DerbyDB
ij version 10.1
ij> connect 'jdbc:derby:serviceCacheDB;create=true';
ij> create TABLE SERVICE_CACHE (id_num varchar(11) PRIMARY KEY, serviceData varchar(10000), timestamp TIMESTAMP);
0 rows inserted/updated/deleted
ij> select \* from SERVICE_CACHE;

0 rows selected
ij> quit;

Add the jar for embedded derby to the appserver library path

cp $DERBY_INSTALL/lib/derby.jar $AS_HOME/domains/domain1/lib/ext

Create the JDBC resource and connection pool in the App Server.

In the App Server console create a new Connection Pool in the JDBC Resources section. Provide a connection pool name, in this case it is serviceCachePool , and set the ResourceType to be javax.sql.DataSource

For the datasource classname, set the value to org.apache.derby.jdbc.EmbeddedDataSource

In the properties fields set the DatabaseName to the full path of the database you created previously using the ij tool. In this case it is /export/home/jb156719/DerbyDB/serviceCacheDB.

Create the JDBC resource using the newly created connection pool and make it available on the server you are using. The name in this example its jdbc/serviceCacheDB.

Create your Service. In this example, I've generated an J2EE-based webservice from a WSDL using Netbeans.

Add the necessary JDBC resource references to your Service. For the EJB-based webservice you need to modify the ejb-jar.xml and sun-ejb-jar.xml

Greg Sporar's blog entry has more details on adding these resources.

Then you just write your code to use the JDBC resource within your service. In this simple example, my service endpoint code checks if the data is in the cache, adds it to the cache if it is not, then returns the result.

import ...

public sayHelloWorld( recipientsListRequest) throws, java.rmi.RemoteException {

String resultS = checkLocalCache(recipientsListRequest.recipient);
if (resultS == null)
HelloRecipient hr = new HelloRecipient(recipientsListRequest.recipient + " " + resultS);
HelloRecipient hrs[] = new HelloRecipient[1];
hrs[0] = hr; _retVal = new HelloWorldServiceResponse(
return _retVal;
private String checkLocalCache(String personName) {
DataSource dataSource;
dataSource = getCacheDB();
}catch(NamingException e){
conn = dataSource.getConnection();
String sqlQuery = "SELECT \* FROM SERVICE_CACHE where id_num = '" + personName + "'";
prpStmt = conn.prepareStatement(sqlQuery, ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_READ_ONLY);
rs = prpStmt.executeQuery();
if (!rs.first())
else {
resultS = rs.getString(2);
Timestamp ts = rs.getTimestamp(3);
long millisecs = System.currentTimeMillis();
Timestamp tsOld = new java.sql.Timestamp(millisecs - STALE_CACHE_AGE);
if (ts.before(tsOld)) {
sqlQuery = "delete FROM SERVICE_CACHE where id_num = '" + personName + "'";
prpStmt = conn.prepareStatement(sqlQuery);
}catch(SQLException e){
// close the connection
if (resultS.startsWith(NO_CACHE_RESULTS)) {
return (String) null;
} else {
return (resultS);

That's it. It was certainly fast enough for the solution I was working on. Of course, I've avoided all the intereting questions such as, "How does it benchmark compared to an external database?", "How will your caching strategy work when you have a load-balanced, clustered, HA solution?", "What happens when I want a read-write service?". But an embedded DB is certainly worth a try for speeding up simple "wrap & reuse" services.




« July 2016