OpenESB Summit 2010 in Brussels

The OpenESB community now has a new web site:

http://www.openesb-community.org/

Authors write:
"This site is dedicated to the OpenESB community. The aim of this site is not to to create a substitute to the previous sites dedicated to OpenESB. We simply try to fuel up the community with news, papers, blogs users feedback about OpenESB."

The OpenESB community is trying hard to survive the impact of Oracle's acquisition, which has stopped most of OpenESB development and practically killed Project Fuji.

To revamp OpenESB is now mandatory creating a bigger and stronger open community around the product. Some companies seems the most active at present, the ones I know are: Logicoy, ForgeRock and Pymma.

This effort will be illustrated in the forthcoming OpenESB Summit 2010, Brussels (Belgium) Monday 4th and Tuesday 5th of October 2010.

On the other hand, I think the OpenESB (and JBI, as Oracle has never been committed to JBI) communities needs to connect to the wider Netbeans community, to join forces, as OpenESB to survive without Sun needs to keep the pace with newer Netbeans releases much better than what has been achieved so far.

Personally, as from the beginning of this year I'm fully employed with Alfresco Software, I will keep following the OpenESB evolution and experiment with Alfresco integration.

Good luck to all former colleagues involved with this project.

Pymma about BPEL Compensation

Another great technical paper from Pymma Consulting:

http://www.pymma.com/eng/IT-Tech-Papers/Pdf-folder/BPEL-Compensation-complet-guide

"Every Thing You Always Wanted to Know About BPEL Compensation But Were Afraid to Ask ;-).
BPEL compensation is one of the main feature used to provide consistency in a business process. Unfortunately, BPEL tutorials often skip this part of Oasis specifications. Even if on Internet you can find papers on that topic, few propose a complete and progressive explanation with simple exercises. It is the reason why we decided to write a complete tutorial which covers all the features defined in BPEL Specifications. We hope that this paper will be useful for you. Please send us your feedback and your comment."

Download from here.

Fuji Simple Service API, SpringDM and OSGi Integration with JBI

Sujit Biswas wrote an interesting article which:

"[...] shows how to integrate Fuji simple service api with spring/springDM application, We will create a springDM application which instantiates the above provider Implementation , based on spring-config and spring-osgi-config files."

Fuji allows for Spring and OSGi services integration

"The simple service provides the capability to invoke/interact with JAVA code outside of JBI, i.e Service API provides a bridge between code that is hosted outside of a JBI component and service endpoints available on the NMR."

This enables integration of OSGI/POJO services with JBI. Read Sujit's article for more.

About Fuji:

"Project Fuji forms the core component of Open ESB v3 effort and represents Sun's next generation open source integration runtime, focused on providing a lightweight, developer-friendly, and extensible platform for composite application development.

At the core of Project Fuji is a lightweight micro-kernel based on JBI (JSR 208) and OSGi. Packaged as an OSGi bundle, the micro-kernel can be installed in any OSGi R4 compliant runtime (such as Felix, Knopflerfish or Equinox), including GlassFish v3. JSR 208 support introduces a robust, message-based service bus to the OSGi environment and allows the wide range of existing JBI "components" (adapters and containers) to run in Fuji.

Developer experience is a primary focal point in Fuji as evidenced by the level of flexibility and accessibility offered in the platform. Starting with a rapid, top-down development language, IFL (Integration Flow Language), developers can quickly and easily generate an integration application using a domain-specific grammar. The service development model favors convention and configuration over boilerplate code and framework APIs, allowing integration developers to focus on the code that matters. "

GlassFish ESB v2.1 has been released

"New in GlassFish ESB v2.1 is clustering for all components, a great number of bug fixes, the inclusion of the IEP SE and Scheduler BC (a new component!), several component enhancements, inclusion of the latest NetBeans 6.5.1 IDE and the latest GlassFish v2.1 application server, and support for AIX 5.3. "

Look at the release notes for more.

The OpenESB and Java CAPS consulting ecosystem

Sun's new open-source strategy offers interesting consulting opportunities. In the last months I have worked closely with former SeeBeyond and Sun colleagues to build a network of partners able to independently support the free OpenESB and commercial Java CAPS platforms at all levels. A set of very skilled professional left Sun recently and joined the freelance market or started new companies. Most of these expert people were actually also in charge of developing core aspects of the Glassfish ESB, Java CAPS and MDM suites, so it is possible to even offer product's enhancements and customizations. Sun is supporting this effort, so we are more and more closely coordinating activities with Sun Services in US and EMEA.

It is a huge paradigm shift from SeeBeyond. When I was in SeeBeyond everything was closed and even secret, while Sun is now growing as an open company embracing open-source as a way to tackle the market from a very different angle than its competitors. At the beginning many Sun employees were doubtful about new Sun strategy, it is so distant from the company's culture. Sun was, and partially still is, an hardware and infrastructural software vendor, a company built by engineers for engineers, with a technology language and culture. Integration and SOA are much more related to pure business aspects, customer's expectation are very different because they take for granted that the technological problems are solved, what they want is business integration, which requires a lot of consulting expertise. This kind of combination of technical and business expertise is exactly in the DNA of former SeeBeyond consultants.

The network of partners is growing and able to fill the business gap. SOA is not much related to technologies, it is about designing and fitting an Enterprise Architecture, it requires first to understand customer's business needs. The OpenESB ecosystem is made of a set of commercially supported open-source tools which provides the possible best value for money. Now there exists also a worldwide consulting services offering able to put this software effectively in production.

OpenESB is an open community, where Sun, its partners and customer can collaborate to create the best set of features, pro-actively suggesting functionalities and corrections. In which ways OpenESB offering is different from both big vendors and other similar open-source products?

• It is fully open-source and supporting open standards, so you can really avoid any vendor lock-in
• Full commercial support and indemnification is optionally provided by Sun at much cheaper prices than any other big vendor
• You can download the suite, develop your solution and then decide if and when buy commercial support
• Comparing to other open-source ESB, support is provided by a much bigger company, the one who invented Java
• The set of development and runtime environments (Netbeans, Glassfish, OpenMQ, JBI) is very mature and allows for better developers productivity than other open-source ESB
  

Netbeans make a big difference: this is a great IDE and the company behind it is the same building OpenESB, so you get a closer integration between the IDE and the ESB in the whole development cycle. Other products require you to edit by hand lot of configuration files, IDE integration is weak and often provided by third parties, unless you decide to buy a much more expensive commercial ESB from any other big vendor. Glassfish V2 is now a great JEE 5 application server, Glassfish V3 is going to be the market leader in terms of features.


So, what are the real services a customer can expect from the network of professional OpenESB partners?

• High level consulting expertise, most consultants are former SeeBeyond and Sun professional services. No kids, senior people only with up to 25 years experience
  
• Possibility to leverage both Sun's technical support and the open-source community, to get independent advices
• Ability to modify or create custom JBI adapters, as many companies in the network are OpenESB code committers and some were even Sun product managers (can you really ask your Big Vendor to create a custom adapter for you?)
• For previous SeeBeyond customers there is also a lot of added value, as the network can offer tailored migration plans from DataGate, eGate 4.x, ICAN 5.0, JCAPS 5.1 to OpenESB and Java CAPS 6
• Ability to support big enterprises worldwide. I'm in touch with partners from Israel to Scandinavia, and in US also. We are looking for partners in Australia and New Zealand shortly.
• Any vertical market: retail, healthcare, telecommunications, finance, energy, ...
• Any EAI experience: SAP, Siebel, Oracle, CICS, SWIFT, Microsoft, ...
• Identity management, Role management & provisioning, Security, Master Data Indexes, federated SSO, SOA Governance, Business Process Management, Rule Engines.
• On going partnership discussions with Savvion, Fair Isaac, Autonomy and other specialized vendors.

An independent and comprehensive review of Glassfish ESB can be read here.

For more information about the "unit-42" partnership network, please drop an email to me or my business partner.

Tom Barrett's Open ESB and Mural Tutorials

Sun's Tom Barrett has produced a set of very well written and easy to follow tutorials, which can gently lead the reader toward a step by step introduction with many of the newest OpenESB related technologies, together with Netbeans and Glassfish. Good job Tom!

Tom Barrett's OpenESB Tutorials

Synchronous JBI with Apache Camel and OpenESB

Introduction

The present tutorial shows how to expose a JBI InOut synchronous endpoint through CamelSE, the Apache Camel Service Engine of OpenESB.
OpenESB works with a collection of different Service Engines, the mainly known are JavaEE-SE and the BPEL-SE. Have a look at the Components Catalogue for more. Some useful SE are in the incubator phase, I'm especially interested in the POJO-SE and CamelSE because they expose a simple and clean programming model. I'm personally not the biggest fan of BPEL as I feel much more comfortable with programming by textual representations instead of the arrow-and-boxes visual flows of BPEL (much like I usually find more effective to write actual code instead of UML drawings, while I like the option to create drawings from working code). In this article I want to point out some very nice possibilities provided by alternatives and also underline that it is not mandatory to use BPEL inside OpenESB at all.

Unfortunately (IMHO) most efforts of the OpenESB community are still headed to the BPEL stuff and optimization of the related SE, while I think majority of developers are more interested in classical textual programming paradigms, first of all because of a much better productivity when implementing typical Enterprise Integration Patterns and Event-Driven SOA solutions.

Here I want to present how to expose a JBI endpoint from the CamelSE, as the sample service definition provided by the CamelSE wizard still can create a One-way operation only. In a future example I will show how to rewrite the Report Incident Camel tutorial within OpenESB, and I will show why I think OpenESB is probably the most effective environment to develop Apache Camel based EIP.

Apache Camel

Apache Camel is a Spring based Integration Framework which implements the Enterprise Integration Patterns with powerful Bean Integration. Camel lets you create the Enterprise Integration Patterns to implement routing and mediation rules in either a Java based Domain Specific Language (or Fluent API), via Spring based Xml Configuration files or via the Scala DSL. This means you get smart completion of routing rules in your IDE whether in your Java, Scala or XML editor. Apache Camel uses URIs so that it can easily work directly with any kind of Transport or messaging model such as HTTP, ActiveMQ, JMS, JBI, SCA, MINA or CXF Bus API together with working with pluggable Data Format options. Apache Camel is a small library which has minimal dependencies for easy embedding in any Java application.

CamelSE

Apache Camel JBI Service Engine (a.k.a CamelSE) is a JBI Component that can be used to run Apache Camel Application in a JBI platform such as OpenESB. The CamelSE also enables Camel Applications (via Camel endpoints) to do message exchange with the service providers and consumers deployed in other JBI Components such as BPEL SE, HTTP BC etc. by providing a Camel Component to the Camel framework that can create Camel Endpoints mapped to the JBI Service Endpoints (consumer or provider) in the CamelSE.

The Example

Preparation

Follow the standard CamelSE installation instructions. I tested this with Camel 1.5.0 and OpenESB nigthly build # 20081209 (based on Netbeans 6.1), but it should work with the latest GlassfishESB as well.

CamelSE Project

1. In Netbeans click "New Project", then select "Camel JBI Module" from "Service Oriented Architecture" folder:


2. Choose a project name (I went for "CamelInOut") and leave other options as default. Click finish button. The wizard creates the typical CamelSE project structure:


3. The default jbi2Camel.wsdl contains a one-way operation only, it is necessary to modify it to create a request-reply operation to implement our scenario.

So change the original jbi2camel.wsdl, replacing the one-way operation

<portType name="CamelInOut_interface">
<operation name="oneWay">
<input name="oneWayIn" message="tns:anyMsg"/>
</operation>
</portType>

With a request-reply

<portType name="CamelInOut_interface">
<operation name="exchange">
<input name="exchangeIn" message="tns:anyMsg"/>
<output name="exchangeOut" message="tns:anyMsg"/>
</operation>
</portType>

4. Edit the default AppRouteBuilder.java

package cameljbimodule1;

import org.apache.camel.Exchange;
import org.apache.camel.Processor;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.spring.Main;

/**
 * A Camel Router
 * @author maurizio
 */
public class AppRouteBuilder extends RouteBuilder {

    /**
     * A main() so we can easily run these routing rules in our IDE
     */
    public static void main(String... args) {
        Main.main(args);
    }

    /**
     * Lets configure the Camel routing rules using Java code...
     */
    public void configure() {
// Use this route when receiving messages from jbi endpoint
// jbi uri format = "jbi://

        String jbiURI = "jbi:http://openesb.org/jbi2camel/CamelInOut/CamelInOut_service/jbi2camel_endpoint";

        System.out.println("@@@ jbiURI=" + jbiURI);

        from(jbiURI).multicast().to("seda:log").process(new Processor() {

            public void process(Exchange exchange) throws Exception {
                String outBody = "OK";
                exchange.getOut().setBody(outBody, String.class);
                System.out.println("@@@ return: " + outBody);
            }
        });

        from("seda:log").process(new Processor() {

            public void process(Exchange exchange) throws Exception {
                String inBody = exchange.getIn().getBody(String.class);
                System.out.println("@@@ received: " + inBody);
            }
        });
    }
}

The idea is to use the Camel JBI URI as the entry point for the service:

String jbiURI = "jbi:http://openesb.org/jbi2camel/CamelInOut/CamelInOut_service/jbi2camel_endpoint";

This is the default jbiURI string as created by the wizard.

Then add a Camel multicast() method to start a parallel flow of execution. There are two legs of the multicast: first is a to("seda:log"), then a Processor inline class which actually sends back the response as a JBI Exchange:

from(jbiURI).multicast().to("seda:log").process(new Processor() {
    public void process(Exchange exchange) throws Exception {
        String outBody = "OK";
        exchange.getOut().setBody(outBody, String.class);
        System.out.println("@@@ return: " + outBody);
    }
});

The seda: component provides asynchronous SEDA behavior so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread to the producer.

Next the seda:log queue is read in a separate thread, so that the service response anf further processing are excute physically in parallel

from("seda:log").process(new Processor() {
    public void process(Exchange exchange) throws Exception {
        String inBody = exchange.getIn().getBody(String.class);
        System.out.println("@@@ received: " + inBody);
    }
});

5. Create a new Composite Application (CA), drag and drop the CamelInOut project into the CASA window, add a SOAP-BC, connect it to the JBI module then build and deploy:


6. Create and run a Test Case to see what is going on. As usual, right-click over the Test node of the CA to create a New Test Case. Your input.xml of this test could be something as follow:

<soapenv:Envelope
xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cam="http://openesb.org/jbi2camel/message/CamelInOut">
<soapenv:Body>
<cam:AnyMessage>Here is the input message</cam:AnyMessage>
</soapenv:Body>
</soapenv:Envelope>

The output.xml after executing the test, should be like this:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<cam:AnyMessage xmlns:cam="http://openesb.org/jbi2camel/message/CamelInOut"
xmlns:msgns="http://openesb.org/jbi2camel/CamelInOut">OK</cam:AnyMessage>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The flow is really executed in multiple threads, as you can verify by checking the server.log of your Glassfish domain:

[#|2008-12-31T11:56:29.012+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out
|_ThreadID=31;_ThreadName=caCamelInOut-CamelInOut;|
@@@ jbiURI=jbi:http://openesb.org/jbi2camel/CamelInOut/CamelInOut_service/jbi2camel_endpoint|#]

....

[#|2008-12-31T11:57:11.307+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out
|_ThreadID=35;_ThreadName=pool-5-thread-3;|@@@ return: OK|#]

[#|2008-12-31T11:57:11.309+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out
|_ThreadID=33;_ThreadName=seda:log thread:2;|@@@ received: Here is the input message|#]

[#|2008-12-31T11:57:11.314+0100|INFO|sun-appserver9.1
|camel-jbi-se.org.openesb.components.camelse.CamelSEComponentLifeCycle
|_ThreadID=36;_ThreadName=pool-5-thread-4;| Message Exchange Provider received DONE : END of service invocation|#]

Conclusions

This short tutorial shows how easy it is to use Apache Camel together with OpenESB, allowing for a simple and very effective implementation of a routing and transformation ESB language. It also demonstrate how to glue JBI endpoints with Camel, exposing JBI request-reply synchronous services directly from CamelSE modules. In a second tutorial I will rewrite a classic Apache Camel example to show that using OpenESB it requires less coding and efforts.

References

- Apache Camel Tutorials
- Implementing Fuji integration scenario using Camel SE [Louis Polycarpou's blog]

Sun Releases Milestone 1 for GlassFish ESB

Today Sun made the public release of Milestone 1 for GlassFish ESB.

"GlassFish ESB is a binary distribution of OpenESB. It consists of subset of the components in OpenESB. Sun will provide commercial support for GlassFish ESB."

GlassFish ESB delivers a lightweight and agile ESB platform that packages the innovation happening with Project OpenESB into a commercially supported, enterprise-class platform. In essence, GlassFish ESB is a binary distribution that combines technology from Project OpenESB, the GlassFish application server and the NetBeans IDE communities into a supported, commercial distribution.

• GlassFish ESB is a binary distribution from the open source bits in OpenESB.
• Sun will support GlassFish ESB just like any other product: it will not just support the latest version, but also older versions. Once released, fixes to GlassFish ESB will be made on a branch behind the firewall and will be merged periodically to the head of the OpenESB code repository. This is an important point for customers who don’t like to continuously upgrade in production.
• Sun will continue to develop in open source on the OpenESB head.
• GlassFish ESB will be released on Dec 5th; there will be two more milestone releases in between.
• The GlassFish ESB site will soon live on sun.com. There are a few pages for GlassFish ESB on OpenESB just temporarily. We’re trying to separate the commercial aspects (i.e. GlassFish ESB) from OpenESB as much as possible: OpenESB is and should remain an open source community.
• The GlassFish ESB downloads will remain on OpenESB because the bits are being developed in Open Source.
• This does not change anything for the ESB Suite, MDM, and JavaCAPS: we will continue to develop them. There is and will remain a value differentiation between GlassFish ESB and the other products.
• There will be separate component releases next to GlassFish ESB. E.g. IEP will release soon as a separate component.
  

Main Features

• A flexible platform supporting multiple architectural styles (SOA, EJB, MoM, BPM)
• Modular architecture enabling a tailored solution platform for specific project and enterprise needs.
• Leading SOA and WS-* (WS-IT/Metro) support with industry leading interoperability with other platforms
• Integration tooling, based on the award-winning NetBeans IDE with integrated service development, deployment and testing
• Support for JBI, Java EE 5 and a wide range of other key industry standards
• Based on fully open communities Project OpenESB, GlassFish and NetBeans
• Backed by Sun's software support services
• Backed by a large and growing community with an exciting roadmap and future vision
  

Learn more

• Full list of components and standards supported.
• Feature comparison with other other Sun products.

What BPEL stands for?

I have been involved in several projects where one recurring request was to "use BPEL", or more generically "to implement some level of Business Process Management (BPM)". BPEL means Business Process Execution Language and the OASIS Standard defines it as:

"WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces."

An extended definition of SOA says:

"Service-oriented architectures (SOA) promise to implement composite applications
that offer location transparency and segregation of business logic. Location
transparency allows consumers and providers of services to exchange messages
without reference to one another’s concrete location. Segregation of business logic
isolates the core processes of the application from other service providers and
consumers."
(from: Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK - Sun Microsystems)

So basically BPEL allows to segregate business logic into pieces of reusable sequences of atomic business activities, expressed through an XML syntax. SeeBeyond and Sun JavaCAPS 5.1 supported the BPEL 1.x standard through the eInsight engine, while the new, opensource Sun OpenESB supports BPEL 2.0., but there are of course many other products from different vendors.

However the point is that BPEL is about "segregation of business logic", it is not about "arrow and boxes programming". I underline this because I am seeing many projects where BPEL is very misused and abused: they are kind of replacing Java with BPEL because the latter is more buzzword-oriented and all those arrows and boxes look nicer. But then it happens that resulting BPEL is just polluted by technical activities, while I'm stressing the fact it should contain pure business logic. So my hint is to always put your orthogonal concerns (logging, error handling, auditing, etc...) somewhere else and leave your BPEL as clean as possible. For example, with OpenESB (commercially aka JavaCAPS 6) there is a nice JavaEE-SE which is the JBI Service Engine to execute EJBs (practically, it is a JBI bridge to the below application server). Here is a list of all JBI components you can use, have a look at Aspect SE, Camel SE (Apache Camel Service Engine) and Scripting SE for other very interesting opportunities to avoid messing-up your business logic...