fantastic post by Andrew. Made me even more scared of the future that awaits us as WS-*
evolves.
Incidentally, I heard recently that ActiveMQ has a standard wire format called OpenWire:
http://www.activemq.org/OpenWire
Obviously, doesn't help much until it is in the spec.
I deal with the issues you describe with JMS. We use WebSphere MQ and Sonic. It really
isn't too bad. Sonic sells a bridge product, but we just wrote our own. Not ideal, but not
really a problem either.
Compared to other things, I hardly see this as much of a lock-in risk. It really isn't much
harder then your typical upgrade to swap out a JMS vendor.
My concern on the "simple vs. complex" thing is people that don't know better get in too
deep down the simple path. Before they know it, it is too late. It really is a hall of mirrors.
If I did use HTTP a lot for integration, TODAY I'd choose either REST or POX/HTTP just so
I'd be in charge of my own destiny and to keep things simple.
I'm with you on third party integration. I think SOAP / WS-* is fine there if you need that.
Interestingly, my company does a ton of third party integration and the architect in charge
of that group told me that not even 1% of this traffic is SOAP today.
I'm curios what your thoughts are on my post on "future state":
http://fuzzypanic.blogspot.com/2006/04/future-state.html
"Future State" in this case would take effect for future integrations once there is agreement
on the "Future State" so it isn't like it is off in the distant future.
--- In [email protected], "Anne Thomas Manes"
<[EMAIL PROTECTED]> wrote:
>
> Mike,
>
> JMS is a standard API -- not a standard protocol. See Andrew Townley's blog
> post on the subject that Patrick cited in the beginning of this thread:
> http://atownley.org/2005/11/in-search-of-portable-interoperability/.
>
> For example, If you are using IBM's JMS implementation, and I am using
> Sonic's JMS implementation, our two applications can't interoperate unless
> we put an intermediary/adapter in the middle to transform the protocol. JMS,
> like most Java specs, focuses on defining a common programming API that
> works with any MOM implementation, but it is an expressed non-goal to enable
> interoperability between different MOM implementations.
>
> This portability focus (rather than interoperability focus) requires
> symmetric deployment of a single implementation and leads to vendor lock-in.
> Even though, conceivably, you could swap out one JMS implementation for
> another, you would have to do so on every system on which the JMS
> implementation is deployed. And you would have to reconfigure each
> application to use the new JMS provider.
>
> btw -- thanks. You just proved my point. Application requirements should
> dictate what technology you should use. Remember the addage: "as simple as
> possible but no simpler". The purpose of middleware is to externalize and
> hide complex programming from your application. If your application has very
> simple requirements, then it's appropriate to use very simple middleware (
> e.g., REST/POX). But if your application requires *any* type of advanced
> control semantics (security, reliability, transactions, message ordering and
> correlation, etc) then your application requires a meatier middleware than
> REST/POX. Otherwise you have to write a bunch of code to handle these
> advanced control semantics. MOM is one answer, but not especially popular
> for B2B interactions (because of the interoperability issues). I prefer SOAP
> in these circumstances, even though WS-RX hasn't reached formal
> standardization stage yet. There's about a dozen implementations available,
> and the vendors have demonstrated interoperability. So even though every
> product doesn't support WS-RX, enough do to make it a reasonable
> alternative. But there are certainly circumstances where SOAP/WS-RX is still
> insufficient, in which case the application requirements will dictate using
> a proprietary protocol.
>
> Andrew Townley's blog post talks about the fact that currently every
> implementation of WS-RX uses a different API, hence our discussion of
> portability (or lack there of). In the Java community, this will be resolved
> by JAX-WS, which uses a metadata approach similar to the one BEA uses.
> Personally, I prefer the approach taken by Apache Axis2, which externalizes
> the configuration information into a WS-Policy description rather than
> cluttering up your source code with a ton of metadata. Whatever. Sun/JCP
> doesn't listen to me anymore.
>
> I agree that the interop story for WS-* has been filled with potholes, but
> it has improved a lot recently -- but only as long as developers follow a
> few basic guidelines: follow the WS-I basic profile; use document/literal;
> use simple types, structures, and arrays (no Collections); avoid schema
> groups such as <union>. Note that the most critical interop issues revolve
> around the impedance mismatch between the XML Schema type system and
> language type systems. (This is why I always recommend starting with XML
> types rather than language types -- and note that Sanjiva and Eric also
> endorse this practice.) Unfortunately, WS-I punted on creating an XML Schema
> profile, which would have made life much easier for everyone involved. The
> good news is that in December the W3C formed a working group to define "XML
> Schema Patterns for Databinding". See http://www.w3.org/2002/ws/databinding/.
>
>
> Anne
>
> On 4/19/06, Michael Herrick <[EMAIL PROTECTED]> wrote:
> >
> > Sadly the interop story for WS-* hasn't been fantastic. I can only imagine
> > it will get worse
> > as impls of some of the more advanced specs come online and continue to
> > churn.
> >
> > What is your definition of a standard protocol? If JMS counts I'm happy ;)
> >
> > The reason I have tended to use a MOM based ESB approach is because it
> > actually
> > guarantee delivery **today** and hide a lot of complexity that I don't
> > want to deal with.
> >
> > I think what your described on simplicity vs. complexity can be dangerous.
> > HTTP based
> > web services seem simple, but when used extensively for integration, a lot
> > of complexity
> > creeps in because you are using a "simple" approach. I've taken the
> > non-MOM route and
> > gone pure HTTP/web service route on some integrations and the complexity
> > actually
> > ended up being *significantly* greater then a MOM based ESB because we
> > ended up rolling
> > our own guaranteed delivery, fail over, retry logic, etc. We also had to
> > simulate a crude
> > pub/sub. Now I know that today there are WS-* specs for this type of thing
> > (e.g., reliable
> > messaging, eventing) - I just don't think there are many mature impls
> > today. And there
> > certainly isn't an interop story there yet is there?
> >
> > I posted to my blog on the type of integration my company does (financial
> > services):
> >
> > http://fuzzypanic.blogspot.com/2006/04/just-how-much-rest-web-style-are-
we.html
> >
> > 1. Sync Request/Reply
> > 2. Async Request/Reply
> > 3. Async 1:1 (fire/forget)
> > 4. Async 1:M (pub/sub)
> > 5. Async 1:M Request/Reply (pub/sub Request/Reply)
> > 6. Async M:1 (event stream subscription)
> > 7. Batch Feed
> >
> > I write about why I don't think REST is appropriate for many of them. I
> > think the same
> > thing about WS-* given the state of the art today. I am hopeful that some
> > day, we'll get
> > there (perhaps it will be SCA in 2-5 years), but for today, I'm still
> > stuck using MOM.
> >
> > I posted here because I'm trying to challenge my assumptions. Please let
> > me know if you
> > think I'm off base.
> >
> > Thanks,
> >
> > Mike Herrick
> > Portland, OR
> >
> > --- In [email protected], "Anne Thomas
> > Manes"
> > <atmanes@> wrote:
> > >
> > > Portability and interoperability are different issues.
> > >
> > > The WS framework is *not* designed to enable portability. When you
> > implement
> > > a service using a particular SOAP toolkit, that service implementation
> > is
> > > bound to that toolkit, and it can run only in containers supported by
> > that
> > > toolkit.
> > >
> > > The Java community, which always strives to support portability, has
> > defined
> > > WS APIs (JAX-RPC and JAX-WS), which are supposed to enable portability
> > > across Java-based SOAP toolkits, although as Andrew points out,
> > portability
> > > is not so easy. The APIs are the same across different toolkits, but the
> > > configuration and administration tools are not -- hence JAX-RPC/JAX-WS
> > are
> > > about as portable as EJBs. But I repeat: portability is not a goal of
> > the WS
> > > framework.
> > >
> > > The WS framework *is* designed to enable interoperability. Services
> > built
> > > using any WS-compliant toolkit can interoperate, regardless of the
> > toolkit,
> > > language, container, or OS they are implemented with.
> > >
> > > Based on my interviews with Fortune 500 companies, portability isn't
> > > especially important, but interoperability is.
> > >
> > > btw -- I am not a WS-only proponent. Application requirements should
> > always
> > > dictate technology choices. As a rule, I always recommend standard
> > protocols
> > > over platform/product/language-specific protocols unless there is a
> > > compelling reason to use the proprietary protocol. (Hence my
> > reservations
> > > about J/JS and MOM-based ESBs.) I also recommend simpler solutions over
> > more
> > > complex solutions as long as they meet the requirements (e.g., POX wins
> > over
> > > WS in situations where security, reliability, etc, aren't required).
> > >
> > > Anne
> > >
> > > On 4/18/06, patrickdlogan <patrick.d.logan@> wrote:
> > > >
> > > > > So, am I as a coder expected to do all this work myself or can I
> > > > > have a tool to do it? I'd prefer an automated approach as per
> > > > > Sanjiva because I wouldn't want this sort of cruft leaking into my
> > > > > codebase.
> > > >
> > > > Andrew Townley has made the point in this forum previously that there
> > > > are portability issue with SOAP toolkits. Here is his blog entry that
> > > > explains the issue in full detail...
> > > >
> > > > http://atownley.org/2005/11/in-search-of-portable-interoperability/
> > > >
> > > > Anyone who believes they will walk the line with SOAP and remain
> > > > somehow "vendor independent" or even language independent, is only
> > > > consider one factor in the equation.
> > > >
> > > > Theses SOA things are very big costs and the differences between an
> > > > investment in Jini/Javaspaces or some other ESB-like thing are not as
> > > > clear-cut as I think the WS-Only proponents are making it out to be.
> > > >
> > > > Developing in a SOAP system is as binding to a language and an API as
> > > > is developing in Jini/Javaspaces. Only seems *more* proprietary.
> > > >
> > > > -Patrick
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
