OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Progression Plan for WS-R Composability document(s)


Jacques and I propose a 2 phase approach to Composability of WS-R with other WS stds/specs:

Part I:  High level "Compsability Concepts" document, which describes: composability model(s), baseline assumptions for  SOAP HDR processing entities, composability requirements/ functionality, implications, etc.  Some examples and illustrations of ways to compose will be provided.  Implementation details will be contained in part II.

This document is targeted at a wide audience, which includes WS Architects, WS implementors that are using modular WS-R middleware (open source or otherwise), and technical decision makers (that probably have not participated in the WS-RM TC and are not intimately familiar with the WS-R standard). 

Part II.  Composability Case Studies for WS-R and WS-Security

Detailed model and implementation guide for selected methods to compose WS-R and WS-Security, based on high level principles enumerated in Part I. "Compsability Concepts" document

This document is aimed at WS implementors that are working with WS-R and WS-Security middleware (open source or otherwise).  Sections of the translated "WS-R and WS-Security Composability" document will be included in this Case Studies document, as appropriate. 

Note that the latter document assumes that the WS-R entity has intimate knowledge of the WS-Security entity such that they are implemented in the same SOAP HDR processing node.  Other models, such as a pipelined SOAP HDR processing in different nodes may also be considered as a separate case of composability.


Here are a few points to consider for the Part I Composability Concepts document:

-SOAP HDR processing entities are independent of each other and might be implemented in different nodes (or optionally, in the same node).  That is, both integrated WS-R and WS-S processing as well as pipelining of the SOAP HDR processing entities are permitted.  However, the modularity of SOAP HDR processing entities should always be assumed, even if extra HDR processing is the result.

-Routing of WS-R messages should not effect composability and the routing should be independent of the SOAP message contents.  That is, composability should not be constrained by any routing scheme.

-There are various ways to order the WS-R and WS-S entities.  For example, there may be cases where we have: WS-R then WS-S, WS-S then WS-R, WS-S then WS-R then another WS-S (say for encryption or authentication purposes).  In cases where there is no WS-S header, the WS-R entity will bypass the WS-S entity and pass on the received SOAP message body to the WS application entity.

-Encryption of only the SOAP message body, or the SOAP headers + message body should be considered as separate cases.

-Redundant processing of duplicate SOAP messages is permitted.  In some cases, redundant processing is a function of how the entities are ordered and that they are independent of each other.


Hopefully, we can get some email discussion going on this before the next WSRM TC call in early Feb 05.



Alan Weissberger

NEC Labs America
1 408 863 6042 voice
1 408 863 6099 fax

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]