It has been eight years now since SOAP and WSDL (Web Service Description Language) were introduced as standards to facilitate communication and data exchange between heterogeneous systems. Since then, a flurry of protocols, collectively named WS*, have also been introduced as extensions to SOAP (and in some cases WSDL) to facilitate specific communication requirements and scenarios. The categories of WS* are broad, and it has reached a point where the sheer number of standards is so great that despite a core set being implemented in many platforms, many in the web service community are confused about which standards they should care about, when and why. Furthermore, concerns over interoperability prevail, as each standard traverses its lifecycle of development, early adoption, ratification and update.
In this latest InfoQ article, part of our Java + .NET coverage, Michele Leroux Bustamante explains the most relevant WS-* standards used today, with a focus on protocols that specifically enable distributed messaging across platform boundaries (with a focus on Java and .NET interoperability) - addressing, large message support, security, reliable messaging, transactions, and metadata exchange among the more relevant. If you are new to web services or to the WS* protocols, or you are having difficulty keeping up with the pace of change in this area, this article should help.
Read Making Sense of all these Crazy Web Service Standards.
Coincidentally, InfoQ also reported on a similar work, Navigating WS-*, by Dan Diephouse earlier this week.
In this latest InfoQ article, part of our Java + .NET coverage, Michele Leroux Bustamante explains the most relevant WS-* standards used today, with a focus on protocols that specifically enable distributed messaging across platform boundaries (with a focus on Java and .NET interoperability) - addressing, large message support, security, reliable messaging, transactions, and metadata exchange among the more relevant. If you are new to web services or to the WS* protocols, or you are having difficulty keeping up with the pace of change in this area, this article should help.
Read Making Sense of all these Crazy Web Service Standards.
Coincidentally, InfoQ also reported on a similar work, Navigating WS-*, by Dan Diephouse earlier this week.
Community comments
Excellent overview
by Abdelkrim Boujraf,
Re: Excellent overview
by David Webber,
Re: Excellent overview
by Guy Crets,
Re: Excellent overview
by Joel Dudgeon,
Re: Excellent overview
by Adomas Svirskas,
Great !
by Fernando Franzini,
Re: Great !
by Bhavesh Amin,
Excellent overview
by Abdelkrim Boujraf,
Your message is awaiting moderation. Thank you for participating in the discussion.
Dear Michele, I was thinking writing such kind of document for my students and colleagues but now I'll share this article with them to ensure they correctly understand the links between the WS-Specifications. It should be nice to create a kind of wiki with such content in order to update it when the final specifications will be released.
Thank you,
Abdelkrim
blog.i14y.net
Re: Excellent overview
by David Webber,
Your message is awaiting moderation. Thank you for participating in the discussion.
Your students may also be interested to compare the eBusiness capabilities of AS2/EDIINT, VAN, ebXML and WS-* in the context of business requirements.
Too often technology is promoted for engineering reasons without regard to fit-to-purpose from the business use.
ebxml.xml.org/Comparison
Helps shed some light on different internet transport metrics here.
Enjoy, DW
Re: Excellent overview
by Guy Crets,
Your message is awaiting moderation. Thank you for participating in the discussion.
David,
I fully agree that the WS-* stack is not ready for real-life B2B communication. Today, I see a lot of file transfer (FTP, SFTP) and EDIINT/AS2 being used for B2B communication.
It is a pitty that WS-ReliableMessaging does not (yet?) provide for a robust, persistent message level protocol. ebMS, AS2 and RosettaNet have provided a reliable and secure communication protocol on top of HTTP for quite some time now.
See also www.infoq.com/presentations/secure-reliable-web... where I address this topic.
Kind regards, Guy Crets
Re: Excellent overview
by Adomas Svirskas,
Your message is awaiting moderation. Thank you for participating in the discussion.
A very good overview indeed, many thanks to the author.
Re: Excellent overview
by Joel Dudgeon,
Your message is awaiting moderation. Thank you for participating in the discussion.
First off, great article!
Now, with regards to the ebXML "comparison" document, I feel it is a little bit biased and unfocused. How is ebMS any easier to implement than Web services? In the real-world ebMS typically involves a small army of niche developers and expensive software (Oracle product suite, Websphere, etc).
Implementing robust, interoperable, messaging services using WCF or GlassFish is comparitively easy. Setting up an ebMS environment is relatively convoluted, from my experience, unless you consider some of the "lightweight" open-source projects like Hermes.
Furthermore, as you begin to factor in additional WS-* standards, ebMS doesn't look as attractive anymore. Similar to ebMS, Web service messages can be sent across non-HTTP transports. For instance, WCF supports transports other than HTTP (named pipes, SMTP, UDP, TCP, MSMQ).
WS-Addressing enabled Web service messages enable support for routing, store-and-forward, transport switching, and, though other mechanisms, publish/subscribe solutions. WS-Security is a much more focused security specification than ebMS's application of XML Encryption/Signature, so much so that ebMS v3 will use WS-Security. Even partner and service requirements definitions, implemented in ebMS using CPA/CPP, are improving in the Web services world (via WS-MetadataExchange and WS-Policy.)
As a messaging specification, ebMS does not offer much more than what is available through today's current Web service standards. I think the challenge for Web service developers working in a B2B environment is to stop treating Web service messaging as a RPC mechanism (which is isn't.)
Personally, I try to architect my business process solutions in such a way that they aren't tightly coupled to the underlying messaging protocol.
Great !
by Fernando Franzini,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm start in WS stuff and I could not to congratulate you.
Regards.
Fernando Franzini
Re: Great !
by Bhavesh Amin,
Your message is awaiting moderation. Thank you for participating in the discussion.
It was hard to convince somebody of using WCF (WS*) over normal web service before this article. Simply great.