RE: [service-orientated-architecture] Re: SOA and ESBs

Fri, 30 Jun 2006 13:37:59 -0700

Exactly right.  The whole tired old debate of JMS in an ESB is off base in that JMS is simply one of the many ways to  interface an application into the SOA using the bus.  

The only real requirement for an ESB is that it provide an enterprise capable messaging layer (or interface to one) that supports one or more messaging standards for carrying service requests from one place to the next using reliable delivery.  That messaging component may support JMS, it may also support WS-ReliableMessaging, or the next  thing that comes along.  The important thing to focus on is what the messaging layer provides as a value add.  It may provide scalable clustering of message servers via load balancing and distributed queues/topics, and it may also provide things like fault tolerance and failover by replicating and preserving message data/service request traffic across the SOA environment.

Dave

 

From: [email protected] [mailto:[email protected]] On Behalf Of Stanley Stanev
Sent: Thursday, June 29, 2006 8:25 PM
To: [email protected]
Subject: Re: [service-orientated-architecture] Re: SOA and ESBs

 

you can always abstract the transport even if you use the languages you just described just to be able to change transports without any problems, so you do not care if it is JMS or not

you introduce an abstraction layer that decouples you from the transpiort

you still want to go SOAP, no matter what the transport is

thanks,
Stanley Stanev

Anne Thomas Manes wrote:

JMS isn't much use if you're building applications in C#, VB, COBOL, Perl, PHP, Python, Ruby, _javascript_, etc.

Language dependency is an anathma to SOA.

Anne

On 6/28/06, patrickdlogan <[EMAIL PROTECTED]> wrote:

> the JMS requirement was only there because the initial proponents
> happened to be JMS vendors.

There are reasons for this that should be considered.

I know it is an API and not a priori "interoperable" (in all the
dimensions of that term), but many implementations are interoperable
in various ways. And it is fairly simple yet expressive.

I would suggest there are a number of vendors of JMS due to its
simplicity (it can be implemented and used without a ton of effort)
and expressiveness (it can be used successfully, widely). For all of
these reasons it seems something like JMS should be the core of an
ESB.

-Patrick

 




-- 
----------------------------------------
Stanimir Stanev (Stanley)
Senior Java Developer
www.stanev.com
----------------------------------------
__._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to