RE: EDI and Use Cases

EDI and Use CasesRoger,

1. I agree.  Sequencing of reliable messages should be listed as a
requirement, and I for one intend to make sure this is in our requirements.
Additionally, we believe that this should be in scope for one of our first
working groups.  Hence why we supported a routing and reliability WG
formation back in November.

2. Expanding on your notion a little bit, one possible set of requirements
is that the message sender and receipient containers/message
handlers/controls should be a first class object, that messages in the
container should have expressible states, and that containers should be able
to respond to queries against the status of messages in the container.
While I agree with this notion (and other similar notions) in the future,
this seems beyond what we can do in a short time frame.  Again, this is a
clearly obvious step when dealing with asynchronous messaging (these things
don't make much sense in synch/rpc), and there are proprietary
implementations as well as emerging specifications on this.  It's just that
we(BEA) think we(web services arch) should figure out how to do
interoperable asynch/reliable messaging before we figure out how to do all
the control logic around it.  Plus it layers nicely as there is fairly loose
coupling between the runtime message formats and the container control
logic.

I've specifically answered each of your points with additional information
on prioritization and timing, to continue the process of thinking about
ordering and scope of the new working groups.

Cheers,
dave
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Cutler, Roger (RogerCutler)
  Sent: Tuesday, April 02, 2002 11:46 AM
  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.