Making decisions in the ESB / Workflow / Mediation space

[Danny Gallagher <da...@gmail.com>]

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.

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

[Hiranya Jayathilaka <hi...@gmail.com>]

Hi Danny,

On Tue, May 15, 2012 at 11:09 PM, Danny Gallagher <dannygallagher2@gmail.com
> 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:
> 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)
>

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.

Thanks,
Hiranya


>
> Any advice / thoughts are greatly appreciated.
>



-- 
Hiranya Jayathilaka
Associate Technical Lead;
WSO2 Inc.;  http://wso2.org
E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com