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!).
> 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.
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/
