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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <*> 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/
