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] | [Elist Home]


Subject: RE: T2 - Assertions and Questions


Dan,

You're doing a fine job representing my point of view. I would rewrite the
paragraph about Chris F.'s use case from perspective of the To Party.  I've
added a couple of additional paragraphs as well.

Consider Chris F.'s use case, there's an intermittently connected SME that
"uses an intermediary as a way station" to received messages.  In the "chasm
model", the SME and the way station would be considered part of a single To
Party, and the communication between the two of them would *not be
specified* by the Message Service protocol. In the "chasm model", the
Message Service protocol completes its responsibility upon delivery to the
way station. Communication between the way station and the SME is the job of
some unspecified process.

As far as the To Party in concerned, this "unspecified process" is
well-defined and sufficiently reliable for them, using whatever mechanisms
and proxies it has chosen. It is only unspecified as far as the From Party
is concerned. In that regard, I don't think there is any need for us to spec
this. A company could choose to use ebXML messaging as all or part of the
"unspecified process", but that is their business decision.

In my mind, the "chasm model" can be broken only under the following
condition:

Give a use case in which there is an intermediary which cannot be considered
to be part of either the From Party or the To Party. More specifically, a
use case where the destination for a message specified by the To Party that
is not part of the To Party's "business chain", to coin another term.

(Great... after all is said and done, I'll be known in this group for the
"chasm model" and "business chain". It won't be long before someone suggests
that I be tied up with a "business chain" and thrown into a "chasm model".)

FYI, SME = Small/Medium Enterprise
and  FYI = For Your Information

Later (what's the American equivalent of "Cheers"?)

David Smiley
Director of Standards
Mercator


-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Tuesday, August 14, 2001 3:38 PM
To: mwsachs@us.ibm.com
Cc: David Smiley; ebxml-msg@lists.oasis-open.org
Subject: Re: T2 - Assertions and Questions


   Date: Tue, 14 Aug 2001 13:19:31 -0400
   From: Martin W Sachs <mwsachs@us.ibm.com>

   If X intends the message to go to Y but is not concerned with what
happens
   between C and Y, it either isn't reliable messaging.

Well, I think I disagree (that it isn't reliable messaging), in the
context of the "chasm model".

In David S.'s "chasm model", from the point of view of the Message
Service protocol, the "To Party" is implemented by two computers, C
and Y.  The boundaries between C and Y, and the way they divide their
responsibilities, are modularly hidden from the Message Service level
of abstraction.

As far as the Message Service protocol is concerned, it doesn't matter
whether C and Y are two CPU's of an SMP multiprocessor, or two nodes
of a shared-disk cluster, or two workstations on an Ethernet.  From the
point of view of MS, there is just one To Party.

The CPP for the To Party contains a PartyInfo/Transport/Endpoint
element, in which the To Party asserts "this is the URI that I want
you to use to send stuff to me".  The To Party takes the responsibility
of selecting the URI, and it asserts that if the Message Service,
using its reliable messaging protocol, delivers the message to that
URI, then the To Party promises that it will process the message.

Here's an analogy.  Suppose I want to cancel my American Express card,
and so I send a letter through the U.S. Postal Service, using their
"delivery confirmation" feature
(http://www.usps.com/shipping/deliver.htm).  I address it to whatever
address American Express tells me that I should send such things to; I
just look at my latest bill and there's this address on it.  Now, for
all I know, the address is some generic company in the midwest that
receives mail for lots of different companies and forwards it.  Or
maybe that address is Amex's central North American corporate
mailroom, which will receive my mail and dynamically figure out which
Amex employee (George Foobar) ought to handle my request, and forward
it to him, perhaps indirectly through some other route.  So there are
all kinds of "intermediaries" happening here, entirely invisible to
me.  Months later, it turns out Amex hasn't cancelled my card, which
has caused me to lose money for some reason, so I sue them, and I want
to present evidence in court that I really did ask them to cancel my
card and they really did receive my mail.  I present my "delivery
confirmation".  Does the judge say "Oh, that delivery confirmation
doesn't mean anything at all, because it's not an end-to-end
confirmation from George Foobar himself"?  I don't think so.  From a
business point of view, my letter was reliably delivered to the To
Party, namely American Express Corp.  What happens to it from that
point on is not part of the protocol.

The main drawback (in a sense) to the "chasm model" is that it takes
the position that the protocol doesn't deal with a concept of
"intermediaries" at all.

Consider Chris F.'s use case, there's an intermittently connected SME
(what does SME stand for?) that "uses an intermediary as a way
station".  In the "chasm model", the SME and the way station would be
considered part of a single From Party, and the communication between
the two of them would *not be specified* by the Message Service
protocol.  In the "chasm model", the Message Service protocol
relinquishes responsibility for that kind of communication: it's the
job of some lower-level protocol that is not specified.

So the "chasm model" implies either that the ebXML standard just
doesn't standardize or specify how that kind of communication works,
or else that ebXML needs to specify a new protocol, at a lower level
than Message Services, that would govern this kind of communication.

(David S., if I'm not representing your ideas accurately, I apologize
and please correct me.)

Is this making any sense?

-- Dan


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


Powered by eList eXpress LLC