Secure and Reliable Web Services
Organizations have numerous IT systems that need to exchange structured data, both within (A2A, EAI) and between organizations (B2B). The exchange of these data is handled in many different ways. The different solutions lead to incompatibility, delays and extra costs when setting up new links between systems or re-using existing ones. Web Services can become the single standard for all exchange of structured data. After waiting over 5 years, 2 important Web Services specifications have finally been endorsed: WS-Security and WS-ReliableMessaging. Will these specifications allow the adoption of web services as a standard for all communication within and between organizations?
Contrary to popular belief, Web Services are not (yet) the primary technical solution for integrating different IT systems. Within organizations, middleware, messaging systems and message brokers are used to interconnect IT systems. These Enterprise Application Integration (EAI) solutions are quite closed, e.g. they use proprietary protocols. All the commercial integration solutions support Web Services, but hardly any are fully based on Web Services.
Web Services are primarily used for communication between different components or tiers of new, departmental applications within organizations. A limited number of applications from large Internet companies such as Google, eBay or SalesForce.com are exceptions to this rule. Typical is also the request/response communication over HTTP: a request is sent and the service immediately returns a response. This synchronous request/response communication ("telephone") contradicts with the loosely coupled, asynchronous communication ("fax") used for business integration.
For the communication between organizations, standardized message formats and protocols are obviously an absolute requirement. The old-fashioned EDI (Electronic Data Interchange) format is still widely used as a common message format, but the closed, proprietary VANs (Value Added Networks) are gradually being replaced by secure Internet communication based on file transfer, VPNs (Virtual Private Networks) and EDIINT/AS2. For file transfer, for example, FTPS (FTP over SSL) and SFTP (FTP over SSH) are quite popular. EDIINT/AS2 - which became very popular in the retail sector due to its adoption by Wal-Mart - is a new protocol for the secure and reliable exchange of data (both XML and non-XML) over HTTP(S).
However, none of the above-mentioned solutions for the B2B exchange of data between organizations is based on Web Services! Even newer XML standards such as RosettaNet, used in verticals such as Electronic Components or Chemicals (CIDX), aren’t based on Web Services either! Why? What is or maybe was missing in Web Services?
The primary solution for securing Web Services was and still is HTTPS. The HTTP communication channel is secured between 2 systems with SSL. But with the adoption of the WS-Security specifications and the support for WS-Security standards in products, security is now well addressed. WS-Security goes from basic authentication to message encryption and digitally signed messages, re-using the elegant XML Signing and XML Encryption standards of the W3C.
Vendors are implementing support for the WS-Security specifications. There are still some growing pains: the adoption of the "Basic Security Profile" by the WS-I will help tackle these. The profiles published by WS-I give extra rules and guidelines to come to interoperable web services, also in the area of security.
Interesting new developments are also underway: XML Firewalls, implementations of new specifications such as WS-Policy, WS-SecureConversation and WS-Trust, integration between Identity Management and Web Services through the use of SAML,...
Messages should never get lost and always arrive, even if there is a network glitch or a temporary problem with a server. The solution is reliable messaging, which basically uses a very simple mechanism: messages are sent to the other party carrying a unique identifier. The receiver returns an acknowledgement carrying the same unique identifier. If a message remains unacknowledged, the sender re-transmits the message until acknowledged. Duplicate messages are filtered at the receiving side based on the unique identifier.
The specification describing a more advanced implementation of the above mechanism is WS-ReliableMessaging. WS-ReliableMessaging was approved in February 2005 and standardizes the protocol for reliably exchanging messages, heavily relying on the draft WS-Addressing specification (WS-Addressing in turn is scheduled for approval by W3C in 2006). Apart from relying on a draft specification, the WS-ReliableMessaging specification has a number of other shortcomings, e.g. no support for polling from behind firewalls.
Still, WS-ReliableMessaging is a very viable protocol that can definitely serve as an alternative for most proprietary and B2B protocols. So the following questions pop up: why is support for WS-ReliableMessaging so limited? Why are there so few products implementing WS-ReliableMessaging? Why are these implementations technically inferior? And why are the big EAI and messaging vendors so reluctant on adopting WS-ReliableMessaging (yet)? It will be quite interesting in 2006 and 2007 to see if and how WS-ReliableMessaging gets adopted.
When secure, reliable and standard Web Services come true, the same technology can be used for synchronous and asynchronous communication both within and between organizations. First of all, this can lead to a very important cost reduction and commoditization. Secondly, Web Services technology becomes an important enabler for Service Oriented Architecture. Services can easily and quickly be published and consumed within and between organizations, leading to an enormous flexibility.
But let’s see if this vision becomes reality by closely watching the evolution of the support for and adoption of the WS-ReliableMessaging and other Web Services technologies.
About the author
Guy Crets is Managing Partner of Apogado and a certified SonicMQ and Tibco BusinessWorks consultant. After graduating as an Industrial Engineer from IHAM Antwerp in 1987, Guy started developing business applications with 4GLs such as Mapper and Informix 4GL. Next came document management, client/server and component based development. But for the last 8 years, Guy has been integrating applications and systems using all sorts of techniques: from screen-scraping and JMS to SAP Netweaver.
Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, Donald F. Ferguson (2005). Web Services Platform Architecture. Englewood Cliffs, NJ: Prentice-Hall PTR.
Eric Newcomer, Greg Lomow (2004). Understanding SOA with Web Services. Boston, MA: Addison Wesley.
Jothy Rosenberg, David Remy (2004). Understanding SOA with Web Services. Indianapolis, IN: Sams.
Good writeup, but feels like a letdown!
I was kind of hoping that an attempt would be made to answer the hypothetical questions raised in the summary and throughout the article.. what does the author actually *think* will happen? I get the feeling there's skepticism - why?
Are there other competing standards in the offing (seems to be par for the course in the WS-* world)? Are there complications that may hamper adaption?
I get the feeling a lot of people are waiting to see how this plays out before betting on a horse. The fact that WS-ReliableMessaging is based on a non-ratified standard (WS-Addressing) shows that this stuff is still in its infancy.
I don't think most people will be making a choice anyway - it will simply turn out that large players (eg Walmart!) choose a platform, and everyone scurries to integrate. Let's just hope that a vast majority of large players make the same (and 'right') choice.
Re: Good writeup, but feels like a letdown!
I must confess that I was pretty disappointed when I learned some time ago that Microsoft WCF (aka. Indigo) would not support persistent WS-RM messaging. But I keep hoping: nice, persistent WS-RM implementations from e.g. BEA or CapeClear are very promising.
I remain convinced that Web Services are the way to go. A single, secure and reliable XML based protocol will really do wonders.
Therefore, I'm not that enthousiastic about the new AMQP protocol. This protocol can be used within the corporate firewall. But WS-RM (or WS-RX) holds the fantastic promise of one single protocol both within and between organizations.
My recommendation: "contract first", start focusing on the message formats, make a language out of the XML alphabet soup. Get the upper layers of your systems to talk XML!