I recently saw several more examples of people making the connection between Web Services and "separation of concerns" (a la Aspect-Oriented Programming). First, the IBM/Microsoft whitepaper entitled "Secure, Reliable, Transacted Web Services: Architecture and Composition" (also available as a pdf from IBM) makes the same overall point I made in my entry regarding aspect-oriented programming (AOP) and SOAP:
1.1 Composable Services
As we've done with SOAP and WSDL, IBM, Microsoft, and our partners have followed the design principle of composability in the definition of Web service specifications. The approach we have followed is based on the design principle of composability in the definition of Web service specifications. Each specification we developed solves an immediate need and is valuable in its own right. For example, developers can adopt reliable messaging to simplify their solution development or adopt BPEL4WS to define their service compositions. And while each specification stands on its own, they are designed to be combined and work with each other.
We use the term composability to describe independent specifications that can be combined to provide more powerful capabilities. Operating system and middleware providers can support composed capabilities, e.g. providers can integrate reliable messaging support for communicating BPEL4WS processes. This example combines two independent specifications to simplify the development of communicating processes by eliminating the need to handle message communication errors during process design.
Composability enables incremental consumption or progressive discovery of new concepts, tools and services. Developers only need to learn and implement what is necessary, and no more. The complexity of the solution increases only because the problem's requirements increase, and is not due to technology "bloat."
Composability has and continues to be one of the key design goals for Web services. Over the last several years we have defined the most basic Web service specifications (SOAP and WSDL) to inherently support composition. One of the fundamental characteristics of a Web service is a regular, multi-part message structure. This structure enables the composition of new functionality. New message elements supporting new services may be added to messages in a manner that does not alter the processing of existing functionality. For example, it is possible to independently add transaction identifiers and reliable messaging sequence numbers. The two extensions do not conflict with each other and are compatible with pre-existing message structures.
This is exactly what I pointed out in my September 2003 entry: "Each header (or set of related headers) deals with a distinct set of concerns." Unfortunately, the IBM/Microsoft whitepaper then goes on to use the term "Service Composition" in a completely unrelated way (see section 3.8) to refer to composing services via BPEL.
I also came across an entry discussing Project Liberty vs. WS-Federation in Radovan Janecek's blog, in which he cites Jeff Schneider saying, "I'm a huge fan of 'concern-based protocols'." Here's the full cite:
I'm a huge fan of "concern-based protocols". Thus, I like having 'trust' as its own protocol - and 'privacy' as another protocol. I don't like mixing concerns in a single protocol; which I believe Project Liberty is guilty of. From a cursory view, it is appears as though WS-Federation covers the bulk of what is actually needed. I'm not an expert in this area - but so far, it looks 'good enough'.
Obviously, Jeff is getting at the same point, but calling it something different: concern-based protocols. I googled the term and found only Radovan's and Jeff's usage.
However, the term "composable specification" is beginning to pick up steam. As of January 2, 2004, there were 118 hits from my Google search, including a draft of the Architecture of the World Wide Web: "Separating the concepts content, presentation, and interaction allows more easily composable specifications."
One other sighting is from xmlhack: "Trends in modular XML specifications at the W3C:" "The recent publication of three W3C documents, XForms Proposed Recommendation, XML Events Proposed Recommendation, and xml:id Requirements may mark a new trend toward fewer standalone XML vocabularies and more "building block" specifications."
So now we have several terms for this evolving concept:
- Composable services (too confused with BPEL-style composition)
- Composable specifications
- Composable standards (used to describe Microsoft's GXA)
- Modular [XML] specifications
- Federated standards (Google search hit Project Liberty, GXA, W3C, UBL etc.)
- Concern-based protocols
I prefer the term "federated specifications" because it highlights the autonomy of the specs being combined. I will have much more to say on this subject.
7:12:04 AM 
