synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiranya Jayathilaka <>
Subject Re: Making decisions in the ESB / Workflow / Mediation space
Date Thu, 17 May 2012 06:58:40 GMT
Hi Danny,

On Tue, May 15, 2012 at 11:09 PM, Danny Gallagher <
> wrote:

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

Yes. AFAIK BPEL can only work with SOAP and WSDL based services. So it's
not really a limitation of Ode, but the BPEL language. There may be custom
extensions that allow native RESTful integration but the core language has
no support for such non-SOAP integration. An ESB like Synapse will be
required in that case to make the necessary SOAP-to-REST transformations.

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

I don't see much difference between the 2 alternatives you have listed, but
I get the gist of your proposal. These options will work, but personally I
don't recommend using an ESB product for running long running processes.
ESBs are best at connecting and integrating systems. This capability can be
usually extrapolated to implement simple processes (Paul calls this
lightweight orchestration). But if you are looking at long running
processes which usually require persistence and may involve some human
interaction a BPM solution is the best option IMO.


> Any advice / thoughts are greatly appreciated.

Hiranya Jayathilaka
Associate Technical Lead;
WSO2 Inc.;
E-mail:;  Mobile: +94 77 633 3491

View raw message