- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Tue, 2 Apr 2002 13:46:22 -0600
- To: www-ws-arch@w3.org
- Message-ID: <3B286631A9CFD1118D0700805F6F9F5A09D09D37@hou281-msx1.chevron.com>
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 UTC