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. "

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...