Application Integration based on Open Source (FUSE)

Last week i attended a seminar on “Application Integration based on Open Source (FUSE) ” organized by Progress Software and Flusso.

The FUSE brand is based on a set of leading projects from the Apache Software Foundation.
They include products like FUSE ESB (based on Apache ServiceMix),
FUSE Message Broker (based on Apache ActiveMQ),
FUSE Services Framework (based on Apache CXF)
and FUSE Mediation Router (based on Apache Camel).

Besides these products they deliver a plugin for Eclipse for implementing patterns (FUSE Integration Designer).
For managing and monitoring the FUSE based infrastructures you can make use of the FUSE HQ, which is part of the support subscription.

On the blog of one of the FUSE employees i just read they also provide online free virtual trainingen for Apache ServiceMix and Camel.

The agenda for the day

  • Enterprise Messaging with ActiveMQ by Rob Davies
  • OpenWire, Stomp or AMQP by Frank Staijen
  • Introduction to OSGi by Marcel Offermans
  • ServiceMix 4: Integrating OSGi and JBI by Gert Vanthienen
  • Apache Foundation history by Dirk-Willem van Gulik
  • Enterprise Integration Patterns with Apache Camel by James Strachan

Some keywords for me to look at :

  • OpenWire
  • Stomp
  • Camel Rest
  • RESTMQ
  • cachedb
  • osgi/apache felix
  • apache ace
  • apache service mix/apache felix karaf/service mix nmr/service mix jbi
  • apache camel/bam support/camel mock

It was a nice day with some good introductions on the different products. FUSE delivers a nice stack of products for supporting integration solutions. Besides the stacks like Oracle SOA Suite and Oracle/SUN Open ESB/Glassfish ESB, FUSE got good potentional to deliver strenghts on integrations projects. Besides widely used open source software, support from a big community they will give their own support to the customer.

And a nice quote by one of the speakers
The latest is the greatest, as long as i don’t need to demo it!

*update
download the presentation over here.

Advertisements

BEA WorkSpace Studio, import sbconfig.jar

For alsb development we both use the console and the workspace studio of bea.
So once in a while i need to do some changes in the console and import the sbconfig.jar back into the ide.
In the current workspace i delete all projects and ‘try’ to import the sbconfig.jar.

The next error pops up :

Import failed: Validation failed with diagnostic messages. Diagnostics for WSDL <projectname>/WSDLs/<my wsdl>
ERROR: <0> Validation of WSDL <projectname>/WSDLs/<my wsdl> failed:

The simple fix.
Drop the workspace, create a new one and import the jar the in clean workspace. Guess it leaves some artifacts in the workspace which abort the import process.

The Open Group has released their SOA Source Book

The Open Group has released their SOA Source Book.

The introduction tells us “The Open Group’s SOA Source Book is a collection of source material for use by enterprise architects working with Service-Oriented Architecture. The material reflects input from a large number of people from a wide range of Open Group member companies, including product vendors, consultancies, and users of SOA. In some cases, these people have brought concepts developed, not just by themselves, but by groups of people within their organizations. The input has been refined and further developed through discussion within the Working Group. The value in the result is due to the ideas and efforts of the Working Group members.”

The book is free for online reading, go get it!

Oracle Service Bus, use of shared resources

At the moment i’m busy with a migration of an alsb 2.6 enviroment to an alsb 3.0 enviroment.
In the alsb processes extra functionality is invoked by making use of the java call outs.
Nothing wrong with this if you ask me, the only thing which i’m wondering is, wont these java call outs mess up the transactional context of alsb processes itself.

At the moment the libraries which are being used are deployed with every servicebus process itself.
So we have/had some sort of default structure like

  • business services
  • proxy services
  • lib
  • wsdl

Works fine, but not really the ideal situation if you have reusable resources over servicebus projects.
You’re able to reuse the components from other projects and link to them by using relative links (for example when you want to reuse xsd’s from other projects) or link to the library of an other servicebus project.

These situations force you to create dependencies between the projects, something we don’t want either.

Solutions

First solution

The solution we implement at the moment to keep everying on-going is the next.
We created a ‘Shared Resources’ servicebus project with folders for libraries/wsdl/xsd/business services/etc. Every resource which will be reused by other projects will be created in here. Every servicebus project itself which is going to use a resource will link to this project and the resource it needs.

This works great if you’re working with components which exists only in the servicebus itself.
When integration is happening and for example applications from vendors are integrating with our servicebus projects they could use certain resources from the ‘shared resources’ project. But in this case my servicebus project will be some sort of repository of resources available for not only the servicebus projects. So i’m creating an extra dependency between the servicebus and the other applications.

Better solution (imho)

Remove all the re-usable resource from the servicebus itself. We need to bring those to some higher level of sharing of which both the servicebus and the other applications will make use. In this case a product like ‘Oracle Enterprise Repository’ could be used.
In this repository we can store all the resources and artifacts which will be used enterprise wide.

To make use of a java call out, we need to create the resource in the servicebus project itself. So we can’t store these libraries on the repository.
Maybe a short coming which is ok for this situation.

If we want to store these java libraries on a repository we have the intention to share these enterprise wide. But in these situations we must investigate if a plain java class is the best way to make the functionality available or should we ‘service enable’ the java classes so they can be used more easily for integration in other projects.
The userguide / Usage Guidelines gives as a few situations/best practices when to use ejb functionality instead of plain pojos.

Do we have functionality delivered by the java classes which is only used in the servicebus projects to support the servicebus process itself then we could just registrate the libraries in the shared resources servicebus project (jar resource) and reuse it from here.

Conclusion

For reuse of resources and artifacts in servicebus projects we could use the next setup.

Shared Resources servicebus project for storing the business services/proxy services/servicebus-only used java libraries/etc.
Enterprise Repository for storing resources like xsd/wsdl/etc
Service enable java classes which are used enterprise wide,so we don’t need to store functionality on several places

Any of you doing osb/alsb projects and have a better ‘solution’ for these situations ?