Integrated Process Management with Open Source

If you ever tried to create an execution environment to automate business- or integration processes based on Open Source products, you know that this is not an easy task. Although Open Source products like Activiti or Apache Camel are of high quality, they do not run with production grade quality out-of-the-box. For serious usage scenarios typically a lot of work is required to integrate those products into a sound platform. This fact hinders companies to use those great products and turn to closed source alternatives from Oracle, Appian or Inubit, just to name a few.

Now there is an interesting alternative called oparo. oparo is an integrated process automation platform based on rock solid Open Source products. oparo is not limited to BPMN processes only. It rather focuses on the entire process spanning business, workflow, mediation and integration.

The platform does all the plumbing required to turn single products such as Activiti, Apache Camel, Apache ActiveMQ, Lucene/Solr, etc. into a platform that can be used out-of-the box. Even better, oparo is entirely ASF2.0 licensed (today and tomorrow) which offers broad usage options and does not involve any hidden costs for enterprise features.
oparo shields the process engineer (the guy who analyses and automates processes) as much as possible from low level technical tasks such as connecting and transforming Camel and Activiti message payloads. It offers a unified development approach for the process engineer to focus on business functionality instead of technical plumbing. Moreover it comprises additional valuable services such as process flow tracking, humantask integration or a registry. Due to oparos service binding approach, those services can be easily integrated in existing IT landscapes using almost any technology (e.g. .NET, JEE, HTML5/JS/CSS). The runtime is scalable (in terms of technology and licenses), the set up is automated and the whole platform is based on proven standards.

If that sounds promising, you can give it a try. You can find more information and a downloadable jumpstart distribution at oparo – the efficient process platform (German only)

The Future of ServiceMix

In the ServiceMix forum there is an interesting debate going on about the Future of ServiceMix. I’ve collected some quotes from the thread. I know it is sometimes dangerous to cite people without giving the full context, but I think it helps to get a rough idea about the direction in which ServiceMix is heading. If you are interested in more details please read to original post.

Quotes:

“The idea is really to make ServiceMix the best possible container for deploying Camel based integration.”
 
“This also means that there’s really not much to reuse from smx4, so smx5 would have its own new and dedicated svn area.”
 
“Dropping JBI is already a great step in that direction.”
 
“Additional things that could be pushed inside ServiceMix 5 would be a Tomcat based container deployment option (for those that don’t need OSGi), a new manual similar to what we have in Karaf (maybe reusing parts of it).”
 
“For advanced use cases, we should definitely guide users towards Karaf, but for a set of basic things, just using Tomcat and simple WARs may be the simplest thing that works for them!”
 
“To build the added value I’ve been talking about, we don’t really need the NMR imho.  I’m convinced we can do it directly on top of camel without the need for another layer, mostly using Camel interceptors.   That way, OSGi is not really needed anymore, though it’s still the best way to deploy Camel routes  using Karaf and would remain the main and standlone ServiceMix distribution.”
 
“Providing a way to easily deploy Activiti would definitely be a good thing. I don’t think it should part of the default distribution, as I’d like to keep it as light as possible though.”
 
Here is my personal summary: 
  1. ServiceMix 5 will primarily focus on Camel.
  2. JBI is finally dead.
  3. Karaf and OSGi will represent the primary runtime.
  4. Tomcat will act as an alternative container.
  5. Activiti will not be integrated.

Consequences:

If you develop for ServiceMix 4 today, focus on OSGi and Camel instead of  JBI and ServixMix features since those are the stable parts of ServiceMix.
If you have ServiceMix 3 and JBI solutions in place think about migration towards Karaf and Camel. If you plan to integrate Activiti, make sure the required functionality is not already covered by Camel to avoid unnecessary complexity (see blog post Combining Activiti and Camel).

Does Spring dm server help to gain OSGi independence?

Recently when I talked to people or read articles about Spring DM Server it was frequently explained that one reason for using it in favour of plain OSGi is to gain independence from OSGi.
Although Spring DM Server comes with a simple to use POJO-based approach to implement OSGi services, the same can be achieved with OSGi declarative services which is part of the OSGi standard services.
With just one configuration file one can turn a POJO into an OSGi service without any OSGi plumbing. This seems to be often overlooked.

There are other reasons why one would want to use Spring DM server instead of plain OSGi, but achieving independence is clearly not.
Rather the opposite is true. Instead if relying on the widely accepted OSGi industry standard another dependency namely Spring DM server is added.
That is ok if it helps to create a better technical solution, but there is a price to pay.

How to enable request logging for pax-web-service OSGi bundle

Due to lack of documentation enabling request logging for the pax-web-service OSGi bundle can be time consuming task.
This is how it can be achieved:

1. Create a OSGi fragment bundle using Maven 2 like this: pom.xml
2. Add jetty.xml to src/main/resources directory of your project. Example: jetty.xml
3. Install the bundle into your OSGI environment.

This approach works with pax-web-service-0.6.0.jar and Eclipse Equinox 3.4.0.