W3C home > Mailing lists > Public > www-ws-arch@w3.org > April 2002

EDI and Use Cases

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Tue, 2 Apr 2002 13:46:22 -0600
Message-ID: <3B286631A9CFD1118D0700805F6F9F5A09D09D37@hou281-msx1.chevron.com>
To: www-ws-arch@w3.org
I have reviewed the notes I have taken talking to our EDI people (and talked
some more) and it looks to me like the UC's presently in place cover many of
their concerns, particularly those regarding reliable delivery and
acknowledgement, asynchronous communications and intermediaries.  Although
they are not covered in the use cases yet, I assume that issues involving
security concerns that are important to EDI applications (authentication,
authorization, confidentiality, non-repudiation, etc) will have use cases.

I am, however, a bit concerned about two other issues that appear to be
important to EDI.  The first may be trivial, the second may be impossible --
but they are both things that seem to be heavy hitters in terms of what is
expected from a VAN so let me get them on the table for comment:

1 - Unique message ID and sequencing.  It is very important to be able to
identify a message uniquely, and this identification is generally contained
in the enveloping mechanism.  (There are usually other ID's in the body, but
this is clearly beyond the scope of the infrastructure).  The unique
identification is commonly done by the combination of "To", "From" and a
sequential "control number".  This facilitates queries like, "Did you get
message N sent from A to B?"  "What messages of those sent from A to B are
between N and M?" and so on.  In addition, the datetime of message envelope
creation (not necessarily the datetime sent) is also important.  As in "What
messages were created on Tuesday by A?"  As I understand it, the sequencing
is logical, not a guarantee of order of delivery.  However, in some cases
(as I understand it, this is unusual) the sequencing may be required.  That
is, control number 21 is not a valid message unless (or until?) 20 has been
received.

I think that this may be trivial, but my understanding is that it is very
important, so I think it's worth making explicit in case there is a joker in
the deck somewhere.

Now to the one that may be difficult, impossible or need re-stating somehow:

2 - Tracking.  Being able to answer the question, "Where is message N sent
from A to B?" and get back an answer like, "It's in B's 'mailbox' but they
haven't opened it" or "B opened it on Tuesday" or, I suppose, "It is in
transit to B and at the moment it is stuck trying to get through the gateway
at C".  Now I understand that the Web doesn't quite work exactly that way.
It differs from a private, physical line in that one does not know up front
how a message will be routed or even (perhaps) where it has been??   Or what
happened to it if it disappears (which I understand is uncommon)??  However,
it seems to me that there are some things that the infrastructure might be
able to deliver in terms of tracking -- like a guarantee that the message
arrived or that you will know that it didn't (part of reliable messaging).
Or what about tracking what intermediaries a message went through or asking
where it is in that process?

Sorry, I know that this is a little vague.  I think I need some help here
figuring out what is possible, reasonable and valuable.
Received on Tuesday, 2 April 2002 14:46:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:57 GMT