It recently stuck me that the WS-* architecture
is implicitly based on two distinct notions of "service", only one of
which is explicitly referred to as a service. The obvious type of service is one
defined using WSDL. Let's call these "endpoint" services. The subtle
type of service is the kind provided by a SOAP node when it acts on a SOAP
header. For example, when a WS consumer receives a SOAP envelope containing a
WS-Security header, it must invoke a "service" to process the header,
e.g., decrypt the SOAP body. Let's call these "protocol" services.
What's interesting is that endpoint services are
"first class" services--they are getting all the attention and there
is active work in improving the description of such services. They are also the
services that one typically implies when one speaks of "composing
services". Protocol services on the other hand are clearly "second
class" services--hardly anyone is focused on them. However, there is
growing discussion of "protocol
composability" : "Web service protocol composition is based on the
modular architecture of SOAP. SOAP's architecture anticipates the composition of
infrastructure protocols through the use of a flexible header mechanism".
Of course, as I pointed out previously, such protocol composition essentially
enables "aspect-oriented
protocols". (Thus, one might think of "protocol services" as
"aspect services".)
Now the obvious language for describing a
composition of endpoint services is BPEL. In fact, BPEL requires "atomic
actions" to be described via WSDL interfaces. But there is no language for
describing a composition of protocol services. The SOAP spec gets confusing
here. It speaks about "features" and requires that new features
describe how they affect other headers (i.e., other protocol services).
It is my belief that WS-* architecture must be
generalized to provide a unified concept of service that encompasses both
protocol and endpoint service descriptions as "first class" concepts.
This might entail generalizing WSDL and BPEL. BPEL would then be used to
describe the processing dependencies among various protocol services, e.g.,
WS-Security service is invoked first, then WS-Reliability, then WS-BusinessActivity.
Where different protocol services do not have sequencing dependencies, the BPEL
operator for simultaneous execution would indicate that. BPEL would then serve
as both a functional composition language (in the case of composing endpoint
services) and an aspect composition language in the case of composing protocol
services (aka aspect services).
9:57:07 AM 
