RE: EDI and Use Cases

Roger,
 
I absolutely agree that these are important requirements from EDI point of
view. I would argue
further that these are important requirements from B2B communications point
of view for EDI, XML, ... as well.
Actually, at least one e-business standard addresses some of these issues.
 
Even though EDI standards (X12) do not require globally UniqueID, in
practice unique IDs are generated based on different keys 
(such as Trading Partner ID, date, time, Interchange Control Number,...) for
transactions. 
 
The eminent ebXML Messaging Specifications v2.0 [1] built over SOAP,
provides the following techniques to address 
the Unique ID and ordering issues you cite below (1). 
 
ebXML Messaging  2.0 specification (the latest version under review)
requires a GUID (globally unique id) for all messages.

3.1.6.1 MessageId Element
The REQUIRED element MessageId is a globally unique identifier for each
message conforming to MessageId [RFC2822]. 

ebXML Messaging (reliable messaging protocol) has an optional message
sequence number that can travel with a message and you can optionally turn
on behavior at the server that will guarantee that messages are delivered to
the "application" in sequence (this functionality is called the MessageOrder
Module - Section 9 of [1]). Thus, as a web services messaging
infrastructure, ebXML Messaging places high importance on both message
identity and message sequencing.
 
The tracking issue (2) you cite below, as you observed, is partially
addressed in ebXML MS in the form of Acknowledgement
from the recipient. The acknowledgement/tracking from intermediaries is not
yet addressed (as far as I know). Tracking,
I believe, is a more general term that involves some sort of logging such
that the logs are used outside of the main business transaction for
tracking. 
 
How much of these requirements should be addressed in WSA, and how much
should be left for the e-Business
standards such as ebXML to build over WSA is something we can debate.
Applicable use cases would be a great start in either case.
 
Regards,
-Suresh
 
[1] http://www.ebxml.org/specs/#technical_specifications
<http://www.ebxml.org/specs/#technical_specifications> 
 
 

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
Sent: Tuesday, April 02, 2002 1:46 PM
To: www-ws-arch@w3.org
Subject: EDI and Use Cases



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.