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

Sun, 27 Aug 2006 10:43:54 -0700

That might be true in many smaller applications. I'm talking about very large organizations that may have several different JMS implementations. These implementations might have started small and then scaled to where they become a major part of an organizations infrastructure OR through mergers and acquisitions.

I think one thing we have learned in this industry is that many large organizations don't have just one of anything.

Perhaps you don't see that in the area you are working.

William

\
On Aug 26, 2006, at 3:11 PM, Gregg Wonderly wrote:

William Henry wrote:
> I'm actually surprised that JMS has gotten away with this for so long.
> One would think that the Java
> community would have fixed this issue long before now. Then again it
> seems that in the software,
> and particularly the middleware, fashion industry we like to reinvent
> technology and technology
> cycles again and again and again ........

I'd say that typically JMS is not used in a place where interoperability is a
requirement. Instead, JMS is deployed as part of an app server environment
where the clients are already coded with the JMS API, and they just use that
app-server vendors Jars in their classpath to talk to that app server. Java's
ability to plug in implementations via the classpath or other classloader
interfaces is one way that wire protocols become immaterial. I can code to the
public API and plug in an implentation that I need.

In particular, JDBC works this way. Custom vendor specific transport interfaces
and optimizations don't keep me from writing code once and using any vendors
JDBC implementation.

Gregg Wonderly


__._,_.___


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

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to