Web Services
-thoughts on service orientated architectures


Wednesday, November 27, 2002

Web Services and Standards  

There are inconsistent views of the nature of standards, especially today around web services. The prevailing view is that once standards are agreed on the issues of interoperability will disappear. This is not true for several reasons I will discuss. First what is a standard and how does it impact design decisions. For this discussion I suggest that there are two types of standards:


  1. Protocol Standards: These standards dictate the fundamental wire protocols between two protocol stacks and are typically very specific. Depending on how far down the stack they are is tighter specificity about the interactions and less about the payload. Good examples would be TCP it is very low level with no room for extensions, through HTTP which has well defined semantics but has room for evolution.

  2. Framework Standards: These standards group other technologies or broad semantics together in such a way applications can understand the intent of the other party. They are intended to help interoperability but not solve it. In here I would put WS-Security, WS-Coordination and other similar standards. They do not dictate a specific technology but enable several different technologies to be identified as participating in an interaction, hence the name framework standards.They also typically allow for broad degrees of extensibility and innovation from the implementers.


These are arbitrary groupings, but they are made to enable discussion. The clear distinction I am making is that Protocol Standards must inter-operate transparently without any application logic to inter-operate the intent of the protocol.Framework standards enable grouping of technology and then require an application level negotiation agent to complete the conversation. While this may seem like a blow to interoperability it is a good thing for loose coupling. The need for negotiation among nodes carrying out framework standards are often overlooked, but to enable widespread adoption of web services it needs to exist.

The discussion around the mediation layer is where should it exist - in the middle as shared infra-structure or carried out by each node. (The need for mediation assumes that the world is heterogeneous rather than homogeneous, given that it is today heterogeneous and appears to be staying that way, I will take this as a given.) Implementation at the edge requires the construction of monolithic architectures that understand all technologies within every framework standard being used by the node. Consider WS-Security, today it supports username/password, PKI, Kerberos, and one of the stated objectives of the standard is to be extensible. Therefore to support WS-Security at the edge there would be need for each edge node to support all standards ( and providers of those standards) and potentially be able to negotiate new implementations. Similar arguments can be made for other framework standards to different degrees.

Therefore framework standards by themselves do not solve interoperability at all levels they do however make it easier at the application level to determine how different technologies will inter-operate. There is a clear distinction among protocol standards and framework standards. To enable inter-operability among nodes and promote loose coupling a mediation layer needs to exist. Moving the mediation layer to the middle reduces complexity on the edge and enables the construction of loosely coupled systems.

posted by John McDowall | 8:04 AM

links
home

soapenv
webservices.org
Loosely Coupled
Doug Kaye
Mark Baker
Jorgen Thelin
Brent Sleeper
Carlos Perez

contact
archives