Gordon Sim wrote:
> Dan Creswell wrote:
>> I think interoperability as a requirement is a red-herring. I think the
>> real issue is that everyone has their own favourite JMS implementation
>> and knows well how to configure that. They don't want to have to learn
>> about another implementation just to glue two queues together.
>
> In a pure JMS situation you may well be right. But where you have
> clients in other languages, using other APIs also participating in a
> queueing system then interoperability becomes more valuable (in my
> opinion!).
>
So, the question outstanding for me is whether you can design a protocol
which can support the various different API's and associated behaviours
across the various languages? I'm thinking especially about security
options etc.
And even if you can, is that the best way to achieve interoperability?
My answer? Dunno - I guess that's reason enough to try.......
>> Thus one solution is a standard protocol but of course, this removes a
>> certain amount of a vendor's ability to innovate and breaks down their
>> lock-in which won't be appealing to them.
>
> You could make the same points for a standard api as well of course.
> However I do agree that standardisation when it works does tend to
> commoditise products and is in fact specifically aimed at breaking down
> lock-in.
>
>> Also, if everyone really can just use their favourite queue, that's
>> going to be interesting re: licensing and support costs. Each team is
>> going to be tempted to go with what they know unless someone yanks on
>> the purse strings and enforces a standard. It may turn out that the
>> standard protocol really only plays out as a useful scenario in B2B
>> integration. The question is, how often does that scenario play out
>> versus others and is the cost of standardizing on a protocol worth it in
>> that context.
>
> Even where standard product choices are imposed within organisations a
> standard protocol allows different choices to be made for different
> parts of the picture. e.g. In the current case of messaging, one vendor
> may be preferred for the java client another for the .net client and a
> third for the broker as well as allowing a homegrown perl client.
>
> Where queueing is used as an integration medium between different
> applications then being able to alter the choice for new applications
> without requiring a simultaneous change to all others is also valuable.
>
>> At the end of the day, a common protocol might be a nice technical
>> option to have but it won't be a silver bullet and technical issues such
>> as this mightn't even turn out to be a key decision point for many
>> organizations in respect of integration.
>
> I agree wholeheartedly. There is no silver bullet!
>
> It is interesting though that the AMQP initiative was begun by JP Morgan
> Chase as a solution to common problems they experience as a major
> consumer of a wide variety of queueing products.
>
That is interesting - I'd certainly like to hear more. From the
outside, one might suggest JPM stands more chance of rationalizing their
broad choice of products than getting all of the vendors to agree on a
protocol.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
