wd 12, section 2.1, general comment

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

[ I am trying to reread through document as a whole and jotting down reactions. I had hoped to raise only typo and style issues. The following may be style but may involve more changes]

 

2.1 Terminology and Concepts

This section defines the messaging model and its main concepts, along with the related terminology in

use throughout the specification.

 

I would like to see this section give an overview of what the apparatus introduced is for, the main parts of the apparatus, and how the various components can be assembled into ebMS MEP level descriptions.

 

By apparatus, I mean

 

MSH and

 

I. Message Types: Signal Message, User Message

II. Message Roles : Sending Receiving

III. Initiating  Responding

IV SOAP MEPs

V aggregate simple distinctionl

 

We should use the terms “public” and “private” and define MSH to consumer or producer relations as in the private process region, and MSH to MSH as in gthe public process region.

 

What I want to understand is how the public process MEPs can be generated by describing two MSH components with different combinations of message roles, communication roles, message types send, and SOAP MEPs.

 

In other words, these combinations of things lead to the different ebMS MEPs to be described. Then have a standard table format for displaying the selected items from each of the set of components.

 

Also,if the MPF is to fit into this as a pattern, can it be related to the earlier MEP apparatus?

 

I think there is a good set of machinery that can be used to explain what patterns are of interest.

 

Finally, I am often puzzled about the information supplied about refToMessageId and the patterns? I am unclear whether the one-way “choreographic atoms” can even be assembled into an ebMS level request response.

 

This is a difficult section, but we need to decide on a systematic way to generate MEPs and what ones we want to explicitly specify in this section. In other remarks, I indicated that it seemed MEPs from the ebMS 2.0 patterns were being left out. We need to be conservative toward ebMS 2.0 functionality, even if it gets described and new SOAP headers are used to carry out old functions.