S7: Features Sharing Properties

This is in fulfillment of an action item I took on our last teleconference.  This email discusses features sharing properties, and leads to feature modularity and reuse.

The current trend in creation of specifications around the web services core is to strive for completeness.  For a number of these specifications, the result is that the specification must redundantly require particular properties that appear in other specifications, even though there is no bar in principle to using these specifications together.  As a result, certain combinations of specifications may end up requiring the same information to be supplied with a message several times, which leads to fragility (what if one of the copies contains an error?) and bloat.

The example set forth in the current draft is a "username" property used by both a security feature and a non-repudiation logging feature.  I don't know this particular example, so instead I'll offer some examples that I do know about.

One of the best examples I know of is message correlation.  To my knowledge, the related properties "message id" and "correlation id" are defined in the SOAP experimental binding for email, in WS-Routing, in WS-Reliability, in WSCI, and in BPEL.  That is, the requirement spans the range from enabling certain MEPs for a particular network paradigm (enabling responses in email, which is asynchronous and so requires identification) through functional additions to SOAP (WS-Routing and WS-Reliability both require identification and correlation), into the realm of choreography (WSCI and BPEL, which use correlation for more sophisticated purposes).

Each of these specifications has a clear need for correlation.  None can rely on the others, because they do not require the use of the other specs (the highest-level, WSCI and BPEL, are perfectly happy to be used without routing or reliability), but equally well *could* be used with these other specs.  The result might be that for a routed, reliable message via SOAP over email, defined in a business process/choreography language, each message would contain four conceptually identical identifiers, and each response message perhaps an additional four correlation ids.

Chaos.  These specifications want to use the same concept, but in order to do so, using the current extension mechanism, must define it themselves.  The WS-Reliability specification recognizes this as a problem, and states that redundancy SHOULD NOT happen.  But it cannot resolve the issue for all other specifications; that has to be the job of the core.

Correlation is probably a relatively uncommon case, because it is so likely to be called for in so many circumstances.  Other sorts of properties, though, such as the username in the current draft (username, authentication token, key, access token ...) may also need multiple redefinitions, in the current state of affairs.

How can specifications of additional functionality, higher-level languages, and protocol bindings cooperate to share required information without redundancy?

There are a number of possible approaches, and perhaps the ultimate solution will use several.  One is to make "features" be something smaller than the current set of specifications.  For instance, rather than defining all of WS-Reliability as one feature, define several pieces that the reliability specification can then reference (addressing, timestamps, correlation, acknowledgement, duplication, grouping (if you don't know the specification, don't worry--this 'deconstruction' is possible for quite a few existing specifications)).  This implies smaller, more modular, and more reusable features, and also implies that there ought to be (perhaps WSA would be interested in a long-term task?) a "features registry".  But a central registry is not *required* (though helpful), all that is needed there is to reduce the scope of features.  The "username" property might then be cast as part of an "authentication" feature, which both the security feature-set and the non-repudiation featu!
re-set might reference.

For the higher-level languages, consistency in the definition of features and properties would also be very important (and indeed, consistency in definition would make it easier for the writers of feature sets and the writers of protocol bindings, as well).  This in turn leads us, in the realm of WSDL, toward the conclusion that a consistent syntax, defined by the WSD WG, would improve interoperability of feature-set specifications, higher-level specifications, and protocol-binding specifications.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Wednesday, 19 February 2003 12:15:41 UTC