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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: RE: [ebxml-msg] Review of ebMS-3.0 Draft 06


Comments on Hamid's comments... (for Intro and Messaging Model only)

Agree with many, differ on a few.

Will propose some rewording in messaging model.

 

Jacques

 

 


From: Hamid Ben Malek
Sent: Monday, November 07, 2005 2:52 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Review of ebMS-3.0 Draft 06

 

I have tried to carefully review the whole spec draft, and so far I managed to review everything except for the following:

 

·         Security Module (page 38 to page 50)

·         Reliable Messaging Module (page 58 to page 64)

·         Reliable Messaging Profiling (page 66 to page 68

·         The rest of protocol binding (page 69 to 76)

 

The parts listed above that I have not yet reviewed were only because of time constraints, and I intend to review them as soon as time permits.

 

Attached are two documents. The document "ebMS-draft-06_Review.pdf" contains my review and comments on the parts of Draft 06 I have reviewed. The second document "ebMS3-ErrorModule.pdf" is a re-write of the Error Module section. Reviewing the error module section of the draft turned out to be too verbose and the cleanest way of doing it was to re-write the whole Error Module. I have not yet read the latest version of Error Module that Jacques posted to the list. So my review of the Error Module is really about what is currently written in draft 06 and does not reflect later changes to the draft. I am returning back to office on Thursday, and most likely my document about the Error Module will be merged with Jacques's latest re-write of the Error Module section.

 

Hamid.

Introduction (lines 217-319) 
=============================

• Remove line 218 
- Fine.
• End of line 226, beginning of line 227: replace “XML framework” by “SOAP framework”. 
- Fine
• Remove the two paragraphs (lines 233 to 238), 
- Why? It is useful to show the shortcomings of alternatives.
. delete “For example,” at the beginning of line 239, and capitalize the letter I (It instead of it). 
- Fine
• Remove “– either at SOAP or ebMS level –“ in line 248 (because it does not any meaning). 
- It has meaning, but not appropriate for an introduction. OK.
• The last part of the sentence in line 248 (“and experiencing restrictions in initiating a message transfer”) 
is not clear and suggest to delete it. 
- Fine.
• Replace the beginning of line 250 (“The choice of an XML messaging framework…”) by “The choice of 
a SOAP messaging framework…” 
- Fine.
• In line 254, replace “communications protocol” by “transport protocol”. 
- Fine
• In line 255, add SMTP to the list of protocol supported in Part 1 of ebMS-3. In other terms, 
replace “This version of the specification provides bindings to HTTP (Core Messaging Part), SMTP 
and FTP (advanced Messaging Part)” by “This version of the specification provides bindings to HTTP, 
SMTP (Core Messaging Part), FTP (advanced Messaging Part)”. 
- Right, SMTP should be in Core.
• In line 272, replace “the domains of reliability and security” by “the domains of reliability, security, and addressing”. 
- Not so sure - security and reliability have a clear QoS meaning, addressign is just a mechanism.
• Remove paragraph (lines 289 to 290). 
- Fine.
• Remove section (lines 291 to 294) 
- I am OK with that, though TC already discussed that and I don't recall the decision...
• Remove section (lines 295 to 319): Rules for normative interpretation should part of a “Conformance” chapter
 (the “Conformance” chapter should be an Appendix, and not a real chapter of the core spec). 
- A general  intro on how to interpret the keywords may still be good at the beginning. 
I agree we need a more complete conformance section - not in Appendix, but at the end.
(many specs have a full section for conformance Clause.)

Messaging Model (lines 320 to 563) 
=================================

• Definition of ebMS MSH in line 326 is using the term “ebMS message” while this 
term is defined only at later time (in line 344). 
- Fine, replace: "...able to generate or process ebMS messages," with "...able to generate 
or process messages that conform to this specification."

• In lines 338-339: “… a programming object combining payload and header elements, a SOAP message, 
etc.” A SOAP message is also a programming object, so the sentence is not well formed because it does 
not say much… There is no SOAP message concept in software that is not an object. 
- Fine. Propose to just remove the sentence.

• Figure 1 on page 11: The picture is misleading. A message producer could be a queue or some storage area, 
and the “submit” operation in this case is an act initiated by the MSH itself and consists in fetching 
(or picking up) a message from the queue or storage area. The arrow representing the “submit” 
operation on the figure suggests that it is the producer who invokes this operation on the MSH. 
The submit operation could be invoked by the MSH itself (the MSH could be configured to periodically
 fetch messages from a queue or storage space). 
- We had this discussion before, and forgot to follow-up: We need to make it clear that these arrows
do not represent a control flow (operation invocation), but a data transfer controlled by an operation. E.g. add: 
"NOTE: the arrows in all figures do not represent a control flow, i.e. do not represent a component 
invoking an operation on an other component. They only represent data transfer under the control of an operation
which may be implemented on either component."

• Lines 347-351: The definitions provided for the terms “ebMS Signal Message” and “ebMS User Message”
 are using semantics only. A definition should only be based on syntax. Semantics could be added to a 
definition at a second step only to add illustration and provide intuition (not as part of the definition itself). 
For example, the term “ebMS Signal Message” should be defined as being a SOAP message that contains 
at least one eb:Message/eb:SignalMessage element inside its SOAP header block. An ebMS User Message 
should be defined as a SOAP message that contains only one (one and only one instance of) element 
eb:Message/eb:UserMessage within its SOAP header and does not contain the element 
eb:Message/eb:SignalMessage. 
- But at this level (model) the definitions must also have semantic meaning, and in fact can be expressed
regardless of syntax - in terms of what abstract operations are used or not - e.g. only user messages
are "delivered", not signals . We will reword this anyway. Mention of syntax may be too detailed here,
 and is a forward reference hard to understand. These defs must be intuitive enough - they  may be completed later
in the packaging section. We could add a note: "a more formal definition of these concepts in
terms of message structure, will be given in the Message Packaging section". 
The intent of the "model" is to show the general foundation and concepts - should be possible
in abstraction of syntax.

• Lines 347-351: Maybe should also provide a new term for an ebMS message that contains many 
user messages (user messages together with their payloads all bundled in one SOAP message). 
And another term to call a SOAP message that is both a user message and a signal message. 
- We need to be more consistent with this possibility indeed - will revisit these defs.

• In lines 360-362: It talks about the “receiving” role that could be played by an MSH. How about when 
sending an asynchronous response (a response correlated to a previous request)? Is the MSH considered 
in the “receiving” role when it sends an asynchronous response? 
- No. Same as for synchronous req-resp MEPs: Any MSH sending a user message is in Sending role.

• Lines 371-373: The “Notify” operation does not always exist. Consider the deployment scenario where 
an MSH is a JAX-RPC handler among other handlers. In this deployment scenario, the “producer” becomes 
the JAX-RPC handler that is deployed just before the MSH (that is the handler that processes messages 
before the MSH does). In this example, the MSH has no way of “notifying” the producer as this later does 
not even exist most of the time (it is instantiated and called by the stack runtime only 
when a message is to be processed, afterwards it is destroyed by the runtime). 
- So if the MSH generates an exception, how is it captured? The stack environment itself can be 
abstracted as the Producer, and whatever way is used to capture this exception, 
can be seen as impementing Notify. And if that did not work out, then we have a conformance problem... 
(could be relaxed at conf clause level).

• Lines 407 to 410 should be written as a footnote. 
- OK.

• In line 413, RMP is used instead of MSH. It should be MSH instead of RMP. The same thing is happening 
at lines 422 and 424. 
- Right.

• From line 424 to 427, the definition is general enough to seem to include the asynchronous 
Request/Response MEP. Is this true? If yes, it should be clearly stated. 
- OK, I just checked the SOAP defs. Only the specified binding (HTTP) requires synchronous exchange,
not the formal def of the MEP. So propose to remove:
"..(For example, this association can be realized by the use of a request-response underlying protocol such as HTTP.)"
And move it to the HTTP binding section, where we would be more explicit about synchrony. 
So I don't think we need to be more specific here.
Note that we may want to consider some more recent HTTP binding (POAS from Liberty Alliance)
that breaks synchrony of the (SOAP) Req-Resp MEP.


• Line 439: “This MEP involves a single ebMS user message.” This should also include a batched message 
(many user messages batched together in one SOAP message). The line should be modified to something like 
“This MEP involves a single ebMS user message or a batched message.” 
- We need to make our defs "upward compatible" to bundling. Will propose something.
Note: we could decide that in case of bundling, several ebMS MEPs could be carried over 
a single SOAP MEP. The ebMS Req-Resp MEP is defined in terms of exchange of UserMessage entities.
i.e. in an ebMS Req-Resp MEP instance, a request is defined as one "UserMessage" element over 
a SOAP Request (regardless whether there are other UserMessage bundled in same SOAP message) , 
and one UserMessage in a response, with a RefToMessageId pointing at teh first UserMessage .


• Line 442: “… the latter must NOT contain an ebXML user message.” This statement is not very precise. 
Consider the case where a response SOAP message contains data (i.e. SOAP envelope not empty) and 
yet the response does not contain the “eb” namespace in its SOAP header (in other terms, 
the response is not 
an ebMS User Message). Furthermore, the term “ebXML user message” has never been defined. 
- we need to revise this indeed.

• Figure 2: The “Send” operation is not only about a “user message”. A batched user message should also 
be mentioned. 
- proposal: ebMS MEPs will be defined in terms of single UserMessage entities. (A SOAP
message could carry several (bundled) ebMS User Messages.)

• Line 460: “The ebMS reply refers to the message ID of the ebMS request via the eb:RefToMessageId 
header element”. Is this really necessary? Normally we don’t need to correlate a response 
to a request when a synchronous Req/Resp MEP is used. Only in the case of an asynchronous 
Request/Reply that the correlation might be necessary.
 The described MEP is not about the asynchronous Request/Response. 
- But we want an explicit correlation that should be transport-independent, even binding-indeptdt.
It also reflects some application-level correlation, like in ebMS2.0. 
that should be traceable just by looking in the SOAP envelope.
You could say "but the mere use of SOAP Req-Resp MEP ensures correlation".
Maybe, but at the very least, we would need to use something like wsa:RelatesTo element. 
Problem is: we would need to rely on wsa:MessageId. That causes issues, such as for future bundling.

• Line 462: “The eb:syncresp attribute MUST be set to ‘true’ on the request user message.” 
The “MUST” is maybe 
a too strong statement. There are situations when an MSH is deployed as one 
JAX-RPC handler among others, and in this case, the MSH has no knowledge whether the MEP 
is a SOAP Oneway or a Req/Resp. The spec should rather say something like: 
“The MSH MUST set the eb:syncresp attribute to true only when it knows
 that an ebMS Req/Resp MEP is being used. 
- Maybe. Although an MSH *must* know what ebMS MEP it uses... otherwise who does?
I realize that "synchronous" is a misleading term (too much transport-specific)
Maybe we need to rename: syncresp--> soapresp.

• Line 474: “mode of transfer…” Mode of transfer is a term that has not been introduced before 
(only MEPs have been introduced without using the expression “mode of transfer”. 
- Right. We could say "way of tansfering messages over SOAP".

• Line 475: “… is only dependent on implementations…” It does also depend on the “transfer mode”, 
not just implementations. 
- Right, poor wording. We could say: "... is controlled by the MSH based on its context of operation or 
application input."

• Lines 482-483: This is not very clear. Persistence maybe understood, but not recovery and security.
- messages waiting in your persistent store are at risk of server failure, attacks.
 
• Lines 484-488: Message Queues or Message Bags are part of the definition of a pipe. 
In other terms, each pipe is associated with a queue or bag of messages (the queue or bag 
may be logical only or of a real 
persisted nature). What is out of scope of this spec is how the bag/queue is implemented and 
associated with a pipe. The queue/bag concept exists and is associated with a pipe (one-to-one 
relationship between queues and pipes). The sentence “Support for assigning…” in line 484 
suggests that associating a queue/bag with a pipe is optional. 
- Having thought more about this, I think we do not need to make the hypothesis of a queue or a bag.
I will try to improve def of pipes. The only requirements and operations for pipes are:
o When submitted, a message is assigned to a pipe.
o the pipe being an association of (sending MSH URL, receiving MSH URL, transfer mode, pipeID)
is enough to determine how the message will be transferred.
o when a pipe is "pulled", the send operation is triggered only on reception of a PullRequest
for this pipe ID.
o no requirement on the sending order, only recommendation that the submitting order be followed.

• Line 490: “… ore more generally an IRI.” There is no need for a pipe’s name to be an IRI. 
-Maybe. URI is enough indeed as an internal ID.

• End of line 495, beginning of line 496: “if it is defined” This comment does not make 
any sense. When we talk about the default pipe, it is assumed that we are talking about 
a pair of MSHs one of which we know the address of. If both MSH do not have addresses 
or don’t know the address of the other, there is no default pipe in between. 
- OK, fixing this.

• Lines 536 and 537: The request/response MEP talked about may be synchronous or asynchronous. 
It is better to state it clearly that both cases are considered. 
- these are ebMS MEPs. Whether synchronous or not is determined by their transport binding.
The only thoing we know at this level, is what SOAP MEP is used and how.

• Line 542: How about the first leg of a PullRequest MEP? What pipe does it use? 
- it uses a pipe in the other direction. But I propose to make it more explicit that
only UserMessages are considered in this section.

• Line 552: “The RIT mode is intended…” Need to stick to one terminology only (Pull or RIT).
- saw that before. 



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