Forum Home » General » SOA Architecture, Issues and Technologies Discussions

Thread: Making decisions in the ESB / Workflow / Mediation space

 

Permlink Replies: 1 - Last Post: May 28, 2012 9:19 AM Last Post By: davsclaus
johngalt

Posts: 4
Registered: 04/09/12
Making decisions in the ESB / Workflow / Mediation space
Posted: May 15, 2012 6:01 PM
  Click to reply to this thread Reply
We have been evaluating different available technologies in
this space for a large project. The project, at its core, is a need
to orchestrate web services (sync and async). The enterprise needs involve the
ability to move large digital files globally, along with metadata related to those files.

We have found it difficult to really evaluate different ways of implementing this, other than
looking at high level features published by various projects / products / etc.

It's seems that without doing a somewhat involved POC using a few chosen platforms, we really won't
have the information / experience that we need to make a good decision on which pieces to use.
Add in the cost of various support licenses vs. no licenses, etc, etc, and things get even more cloudy.
This seems to just be the nature of the beast.

So after some time spent looking at different options I am left with a few questions that perhaps some experts
here could shed some light on. Or set me straight if I'm completely off base.

We started down the road that we wanted to use BPEL (because it's a standard) to implement the workflow that
ties the services together. However, it seems that all the java based BPEL products out there use apache ODE
under the covers. From what I can gather, ODE doesn't really support calling REST services from a workflow.
Looks like something that is under consideration for a future release:
http://ode.apache.org/roadmap.html
http://ode.apache.org/bpel-extensions.html

That means that if we go the BPEL route, we need to then use some type of ESB product so that we can proxy the REST services
from the esb with a wsdl. Correct? (which defeats the whole purpose of REST)

As alternative #1, use Mule/WSo2/ServiceMix(FuseSource) - implementing the workflow in manner supported by each:
Mule: homegrown?
WSo2: based on synapse
Service Mix: Camel

As alternative #2, use synapse or camel to implement the workflow on our own and deploy into Tomcat, adding pieces
from alternative #1 if we need them.

Do I sound like I'm in a rational spot for my three potential paths? Are there large things I'm not considering?

Any advice / thoughts are greatly appreciated.
davsclaus

Posts: 1,893
Registered: 10/14/08
Re: Making decisions in the ESB / Workflow / Mediation space
Posted: May 28, 2012 9:19 AM   in response to: johngalt in response to: johngalt
  Click to reply to this thread Reply
Yes you should definitely do your own POC and set aside a good time period to do your own investigations, and try out the products - eg kick the tires.

Many of the open source products is free to use. And if you want FuseSource offers subscriptions.
http://fusesource.com/enterprise-support/support-offerings/

In terms of BPEL, I would not recommend that. Its not really catching on anymore, and is becoming legacy/dead.

Instead you may want to look at BPM. We had a discussion on this recently at the Apache Camel user forum
http://camel.465427.n5.nabble.com/Camel-EAI-patterns-vs-BPEL-processes-tp5713573.html

Kai refers to BPM and he did a recent talk at CamelOne about using Camel and Activiti together. The video of his talk will be published soon on the CamelOne website, when the production company have processed all the videos.
http://fusesource.com/apache-camel-conference-2012/

And there is a book Activiti in Action which is soon to be published
http://manning.com/rademakers2/

At least I would suggest to kick the tires of Activiti combined with Apache Camel.

And then maybe check out the Fuse ESB Enterprise, which is a great container for running your applications
http://fusesource.com/products/fuse-esb-enterprise/