← Prev in month ← Prev in thread
Next in thread → Next in month →

wd 12, section 2.1, general comment

From
Dale Moberg <>
Date
2006-04-18T21:59:52+00:00
ID
Thread
wd 12, section 2.1, general comment
[ 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.
← Prev in month ← Prev in thread
Next in thread → Next in month →