EDI Stakeholder Perspective

One of my action items from the F2F was to flesh out as an issue
something that I mentioned in general terms at the meeting but which was
not discussed.  The essence of that issue would be that the current
WS-Arch does not satisfy requrement
http://www.w3.org/TR/2002/WD-wsa-reqs-20021114#AC017, "The WSA must
satisfy the requirements of enterprises wishing to transition from
traditional EDI".  Another way to view this issue might be as a response
to the chair's request to consider the subject of reliability in the
context of models other than the messaging model.
After some thought, I decided that the best way to proceed would be to
draft an EDI Stakeholder Perspective that might be responsive to this
issue.  If this can be incorporated in the document after being suitably
worked over, that would be fine.  Otherwise I think that the following
draft can serve as support to define an issue that I would submit in the
usual way for possible later consideration.
Here is draft text for an EDI Stakeholder's Perspective.  Note that
there are, as generally characterizes a stakeholder perspective,
elements drawn from multiple models.  I have tried to call these out
explicitly where possible.
***********
One of the basic assumptions that many people make about the role of Web
services is that they will be used for functions similar to those
presently provided by traditional EDI.  Since EDI is a well established
technology it is useful to examine the expectations that current EDI
users may have for a technology that is to be used as a replacement.
That is, what do they do now that they will also expect from a new
technology?   The most basic of these expectations concern security,
message reliability and a function which does not have a well accepted
name but which we will here call "tracking".  Security and message
reliability are treated in other sections of this document, so the
discussion here will focus on tracking.

The issue here is what happens when a transaction goes awry for reasons
other than the loss of a message or security violations.  Although it is
possible, and useful, to automate safeguards both at the protocol and
application level, experience indicates that there is a virtually
limitless variety of ways that business transactions can fail.  Informal
interviews with current EDI practitioners have indicated that in
practice the 80-20 of what EDI people actually do is involved with the
issue of finding out what has actually happened in transactions about
which the business partners may initially have a different view of the
situation.   For example, such an interaction may start with a phone
call that goes something like, "Why haven't you paid us?" and continues,
"We think we have paid you".   In these cases there is often a good
faith desire on both sides to figure out what has happened and comply
with the requirements of the transaction, but the information that
people are working with may differ and coming to a common understanding
can take some work.

In current EDI operations many of the questions that must be answered in
these cases can be handled in an automated fashion by the vendor of the
proprietary network used in the transactions.  In a Web services
scenario, where the transactions take place in a distributed
environment, with no central authority, between business partners that
may use different application platforms, some sort of uniform query
interface must replace the current automated queries to the EDI vendor
or the tracking capability will essentially be lost.

The basic requirement here is for companies that are cooperating in a
business transaction to find out at any time what the status of the
transaction is and what has happened in the past related to that
transaction.  A significant complexity is added by the fact that
multiple companies may be involved.  That is, company A may initiate a
transaction by sending a message to B, but the process may then involve
messages between B and C.  In some cases the interactions between B and
C may be known to A (as opposed to being part of an internal process in
B that is opaque to A).   It is not immediately clear whether this
should be handled by A querying both B and C or if a responding to a
query from A to B should carry with it the obligation to query C and
return the results.  This is presumably an issue which must be ironed
out in the creation of the specification(s) for the uniform interface.

As illustrations, here are some of the typical queries that A might send
to B or C:

1 - Did B receive and process message M from A?

2 - Return from B copies of all messages associated with Transaction T.

3 - Return from B copies of all messages between A and B in a given time
range.

4 - Return from C all messages associated with a transactions involving
A during a given time frame (including messages between B and C related
to transactions in which A is involved).  Or ...

5 - Return from B copies of messages between B and other companies
involved with a transaction (or all transactions in a date range).

In all cases it is also necessary to answer the question, "Is A
authorized to receive this information"?

Current EDI practices may automate some of these queries and others may
involve hand processing.  In general, however, there are significant
cost savings to be realized by automating as many such queries as
possible.  In order to do so there are various requirements, some of
which are probably achievable using current or planned specifications
and others of which may require new ones:

1 - A uniform, interoperable interface for the queries so that company A
may send a standard query to all its business partners.  This interface
should be associated with the functional Web services interfaces in much
the same way as the management interface.  In fact, such an interface
might be implemented as part of the management interface itself,
although current discussions of the management interface are focused
more on quality of service issues.

2 - Standard identifiers for transactions, individual messages, and so
on necessary to define the queries.  Note that some of these queries
involve identifiers of participants in a transaction other than sender
and receiver of a particular message.  There are clearly aspects of this
requirement that are related to the choreography domain.

3 - Policies controlling whether A is authorized to make tracking
queries to B.  There may be several variants of such policies:  e.g. A
can query B about messages directly between A and B but not messages
between B and C associated with transactions involving A and so on.  It
may be possible to establish these policies using mechanisms currently
available or under development in the security or policy domain, or
there may be transactional aspects to these policies that are not
currently being considered.

4 - A method to establish the trust relationships necessary to implement
the policies in 3.