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

[Stanley Stanev]

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. __,_._,___