Deployment Model for web services and an ESB

[jpuro <jp...@sterlingtesting.com>]

I am trying to determine what the best approach is to web service deployment
when using an ESB.  There seems to be 3 options.

1)  The first option proposes that you deploy your web services within the
ESB itself using service-units.  These web services will do everything from
process business rules, perform business logic, and connect with a database,
everything that a web service typically does (for example, an order
fulfillment or inventory check web service).  This approach seems to couple
the web services deployed within an enterprise with the ESB and the
applications connecting to them (perhaps this is a no no when talking SOA). 
Some of the benefits of deploying web services this way include:
    
    a)  It?s easier to deploy since all you need to do is create your
service as a POJO and deploy it as a jsr181 endpoint in the ESB using JBI
service-units.

    b)  Your applications do not have any indirection when connecting to
these web services.  All they have to do is point to an address exposed on
the ESB and they will get a direct connection to the web service.  This
avoids the associated overhead in transformation and routing of messages if
you were to deploy the web service outside of the ESB.  The alternative is
described below.


2)  The second option proposes that you deploy your web services outside of
the ESB.  The ESB acts as a pure message broker.  Applications talk to the
ESB by sending messages to a JMS Queue or to a WSDL exposed on the bus.  The
ESB then performs any necessary transformations and routing and sends the
message to a producer endpoint that calls the destination web service.  The
actual web service is located on a completely different machine than the ESB
is (perhaps its deployed in Tomcat as an XFire service).  You will still use
service unit deployments for the transformation/routing information in the
ESB, but you will never deploy the actual business object inside of the ESB. 
The ESB is a pure message broker and that?s all, essentially it acts as more
of a pass through system than anything else, a gateway from an applications
perspective to the services within your organization.  The benefits of this
approach include:

    a)  It allows for a more distributed architecture with your web services
and applications.  If you need to move a particular web service to a
different server or location it is easier to do, since all that needs to be
done is update the addressing in the ESB.

    b)  You keep your ESB only concerned with transformation and routing of
messages to your different systems.  So let's say you have several routes in
your ESB require a bunch of complex transformations, this could require a
lot of processing power, especially if you're dealing with XML.  So by
keeping your business services separate in a different cluster, outside of
your ESB, you are essentially allowing your architecture to scale and
perform better, since your business services won't get bogged down by the
processing loads of your ESB.

    c)  This model better supports services that are deployed across
different languages and keeps consistency in your deployment model.  For
example you may have a company that has .NET and Java web services.

    d)  You are not tied down to a single ESB implementation.  Since your
business objects/services are located and deployed in an ESB agnostic manner
you can easily swap out your ESB if necessary (perhaps one ESB doesn't
perform as well as it should).


3)  The third approach says that you can use either approach #1 or approach
#2.  The approach of choice will depend on the business need at hand.  If we
are facing a simple business problem where we need a web service that
fulfills some arbitrarily easy requirement we can use approach #1.  However,
where we need to address a more enterprise level potentially distributed
situation we can use approach #2.

Any thoughts on this would be greatly appreciated.

Regards,

Jeff Puro
-- 
View this message in context: http://www.nabble.com/Deployment-Model-for-web-services-and-an-ESB-tf2357693.html#a6567639
Sent from the ServiceMix - User mailing list archive at Nabble.com.