Re: [service-orientated-architecture] Re: Client Side Invocation Frameworks?

Sun, 27 Aug 2006 08:52:56 -0700

Anne,
 
I guess I didn't express myself clearly.  Maybe "if" would be a better word there than "once" - what I mean is that if and when JMS vendors support AMQP they will be able to talk to each other.  AMQP therefore represents a potential solution to the problem of JMS interoperability.
 
Your point is whether or not vendors with a vested interest in proprietary messaging technology will decide to support AMQP - and I agree that's a very valid question.  Only time will tell of course, and your guess is as good as mine.  However alternatives exist, such as open source, for delivering technology to market, and paying customers can influence vendor decisions. 
 
On the plus side for AMQP is that it's already in production use at JPMC, and that the code will soon be going into a recently approved Apache incubator project.
 
I think an even more interesting question, though, is whether AMQP is a good fit for SOA infrastructure, especially since it provides a good solution to the key requirement for loose coupling.  

Eric

----- Original Message ----
From: Anne Thomas Manes <[EMAIL PROTECTED]>
To: service-orientated-architecture@yahoogroups.com
Sent: Sunday, August 27, 2006 7:34:35 AM
Subject: Re: [service-orientated-architecture] Re: Client Side Invocation Frameworks?

On 8/27/06, Stefan Tilkov <stefan.tilkov@ innoq.com> wrote:
>
> On Aug 26, 2006, at 9:37 PM, Eric Newcomer wrote:
> > Yes, and this is exactly why we are working on AMQP...
> >
> > Once both JMS vendors support AMQP they they will be able to talk
> > to each other.

That's not a realistic assumption. What makes you think that IBM and
TIBCO will convert their MQ products from their extremely successful
lock-in protocols to the AMPQ protocol? I'm not even convinced that
folks like Sonic and Fiorano would be willing to do so.

The reason that JMS doesn't support interoperability is that the
specification does define a standard protocol. And the reason it
doesn't define a standard protocol is that the vendors control the JSR
that defines the specification, and they don't want a standard
protocol.

Anne

> >
> Exactly -- which matches my original point: Wire standards are IMO
> much more important for SOA, as SOA is about interop, not portability.
>
> I like the idea of AMQP, by the way -- it seems to make much more
> sense to create a protocol specifically suited for asynchronous,
> reliable messaging than trying to turn HTTP into one.
>
> Stefan
> --
> Stefan Tilkov, http://www.innoq. com/blog/ st/
>
> >
> > Eric
> >
> > ----- Original Message ----
> > From: Stefan Tilkov <stefan.tilkov@ innoq.com>
> > To: service-orientated- architecture@ yahoogroups. com
> > Sent: Saturday, August 26, 2006 3:05:14 PM
> > Subject: Re: [service-orientated -architecture] Re: Client Side
> > Invocation Frameworks?
> >
> > On Aug 26, 2006, at 5:56 PM, Gregg Wonderly wrote:
> >
> > > I can only suppose that you know something that I don't know, such
> > > as the date
> > > that JMS will no longer work to allow messaging between so equipped
> > > Java
> > > programs?
> >
> > Gregg: Two programs that use JMS *can't* talk to each other just
> > because they're both using JMS. They can only talk to each other when
> > they're using the same JMS implementation.
> >
> > Stefan
> > --
> > Stefan Tilkov, http://www.innoq. com/blog/ st/
> >
>


__._,_.___


SPONSORED LINKS
Computer software program Computer software spy Computer job
Database software Discount computer software

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to