WS-I compliance options

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: WS-I compliance options

Here is a first cut at the basic decisions I see we'll need to make
regarding the WS-I compliance of ebMS V3.0.

I am identifying below the basic issues we are facing, and simply list some
options we have in addressing them. So we can discuss these and narrow the options
before going further.

Jacques

WS-I BP compliance issues:

1. --- Level of enforcement of Profile conformance:

(A) we just make sure the MSH generates profile-conformant message material, but we ignore material that is not generated directly by the MSH, and for which we

can rely on the providing 3rd party for conformance (i.e. don't check received messages, or SOAP body passed to an MSH by its sender app for sending).

So the only messages that would be entirely verified are those totally generated
by an MSH, e.g. Ack signals.

(B) in addition to checks done in (A), we "embed" profile conformance rules (to some degree) for material not generated by the MSH , i.e. received messages, and also SOAP body passed from the user layer (sending side), and flag an error for at least the most obvious profile violations.

(C) A variant to (B) is to support this as an optional verification service, controlled by some header content.

2. --- Which profile should ebMS messages be conforming to:

Sol #1: Use some "inference" rules: e.g. if no attachment is used (no MIME)then "SimpleSOAP 1.0" profile should be the target. If some MIME envelope is there,

 the Attachments Profile (AP 1.0) should be the target.
We can only decide of this when looking at the message one by one.

Sol #2: Or, should a CPA entry specify which Profile should be complied to ?

3. --- WSDL references:

Some Profile requirements need to correlate message content and WSDL content.

(A) Ignore these. Assuming that an MSH is not supposed to know about WSDL asociated with its messages, the MSH will then ignore these rules.

(B) try to do some inferencing, or narrow the profile "options": e.g. we assume the binding is doc-lit (or this could be part of CPA-configured profile requirements). Or, if some synchronous business response is expected,

we assume conformance rules that apply to a WSDL req-resp operation type should apply.

4. --- Level of intrusion in SOAP envelope.

Several profile requirements are about the content of the SOAP body.

Approach #1: leave this out of scope of the MSH: user layer supposed to
handle this aspect of Profile conformance. We only care about this for the messages the MSH is gnerating all by itself (e.g. Acks).

Approach #2: stronger: make this verification an (optional) payload service?

Approach #3: stronger: make this verification built-in the MSH? (would not do this because new profiles may appear later? Or would that be time for a new ebMS version when that occurs?).

5. --- HTTP requirements

These obvioulsy only apply when using HTTP transport. So when the ebMS
binding is not HTTP, should:

(A) all profile reqs implementated in MSH be voided (at least those used to "verify", if not those used to "create" message material) since current WS-I profiles are about HTTP.

(B) only those reqs that relate to HTTP be NOT applied.