W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2003

Comments on the message oriented model

From: Hugo Haas <hugo@w3.org>
Date: Fri, 1 Aug 2003 18:30:41 -0400
To: www-ws-arch@w3.org
Message-ID: <20030801223041.GI1460@w3.org>
As per the common action item from the face-to-face meeting, I am
sending my comments regarding the message oriented model here, against
the following version:


Comments are inline below.

| 2.3.1 Message Oriented Model
| Correlation

Correlation is a feature and should be moved to the future features
section rather than be in the concept section IMO.

| Message envelope
| Definition
|    A message envelope is that meta-data associated with a message that
|    permits the message to be delivered, intact.

A message envelope doesn't guaranty integrity, and a SOAP envelope
doesn't give information about the message delivery. I would propose
the following:

  A message envelope is the meta-data structuring a message.

| Explanation
|    The message envelope is that information needed to actually deliver
|    messages. It must at least contain sufficient address information so
|    that the [241]message transport can deliver the message.

This is not true in the case of SOAP, which is part of our definition.
I would move to simply dropping this sentence.

More on this below when discussing message path below.

| Message Identifier

I think that we should drop this concept and simply use an identifier.
I don't think that there is anything about a message identifier that
isn't applicable to a general identifier.

| Message Path
| Definition
|    A message path is the sequence of [280]agents that process a
|    [281]message; starting with the [282]originating sender of the message
|    and terminating with the [283]intended recipient of the message.

Is the message path really terminated by the intended recipient?

One could imagine an agent being the intended recipient of a message.
This agent may end up forwarding the message for processing to another
agent, in which case I think that it is not the end of the message

  Requester -------------> Intended recipient -------------> Agent used
  						     by the intended recipient
  				  Message path

I think that the concept of intended recipient is going to be
difficult to deal with, and that we should adopt SOAP's ultimate
recipient concept.

| Message Transport
| Explanation
|    The message transport is the actual mechanism used to deliver
|    messages. Examples of message transport include HTTP over TCP, SOAP
|    transport, message oriented middleware, RMI and so on.

I am not sure what is meant by SOAP transport here.

|    The primary responsibility of a message transport is to deliver
|    messages intact. Other responsiblities may include timeliness,
|    privacy, reliability and so on.

Again, I don't think that integrity should be mentioned here. I would

  The responsibility of the message transport is to deliver a message
  from a sender to one or more recipient, i.e. transport an SOAP
  Infoset from one agent to another, possibly with some implied
  semantics (e.g. HTTP methods semantics).

  Message transports may provide different features (e.g. message
  integrity, quality of service guaranties, etc.).

Note that this implies the following relationship:

  Message transport has
    zero or more features

I think that this captures the above paragraph since I believe that
the message transport semantics can be captured in the form of a

|    For a message transport to function, the sending agent must place the
|    address of the initial recipient in the message envelope. Iin the case
|    of a [317]message path involving [318]intermediaries, then the initial
|    recipient is the first intermediary.

As mentioned above, the envelope may not have an address on it. I
would remove this paragraph and open an issue about how do agents
indicate where the recipients, and possible intermediary, are. IOW,
how is the message path known?

| Reliable messaging

Same comments as for correlation: I think that it should be moved to
the features section.



Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Friday, 1 August 2003 18:30:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:08 UTC