Gregg Wonderly wrote:
> Anne Thomas Manes wrote:
>> On 8/29/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>>> Okay, I asked too many questions and got a "No" to something. I'll
>>> separate the
>>> questions this time so that we can get answers, hopefully on each item.
>>>
>>> 1. JMS provides a Queuing system. Typically, that queue resides inside of
>>> some
>>> running Java application, somewhere. In order for any two distinct threads
>>> of
>>> execution to access the associated queue they would have to talk to that
>>> queue,
>>> using the vendor's supplied classes which implement the JMS API for the
>>> type of
>>> access desired right?
>> The queue (which is an XA resource) is managed by a JMS vendor's
>> server component. It is disconnected from any particular application
>> to enable completely asynchronous capabilities. Applications talk to
>> the queue using the associated JMS vendor's client component. The JMS
>> vendor's client and server component communicate using a proprietary
>> protocol. (This is the bit that makes JMS not interoperable.)
>
> I guess I don't see how this is an issue for Java applications. Any Java
> software wanting to use a vendors JMS implementation, can obtain the Jar file
> and include it in its classpath. If there are odd problems with classpath
> content, the application can use a Java classloader such as the Jini
> PerferredClassLoader to control which classes are preferred for use by which
> component.
>
> Interoperability at that level is not a requirement for SOA. And the use of
> JMS
> doesn't stop interoperability at all. It merely mandates the existance of an
> implementation of the API that will allow you access to the data that you
> need.
> This no different from any other piece of software.
>
> The only reason why wire protocol seems like the interoperability solution is
> because of the agreements surrounding such a thing. Equally viable and
> valuable
> agreements exist and will come to exist at all levels of software
> architecture
> based on need and value perceived.
>
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.
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.
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.
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.
Dan.
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/
