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

[Anne Thomas Manes]

But JMS is not a transport -- it's a programming API.
(It's just that each JMS implementation comes with a proprietary transport.)

Anne

On 6/29/06, Stanley Stanev <[EMAIL PROTECTED]> wrote:

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

•  Visit your group "service-orientated-architecture" on the web.
   
•  To unsubscribe from this group, send an email to:
   [EMAIL PROTECTED]
   
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---

__,_._,___