- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Sat, 8 Nov 2003 12:28:59 -0600
- To: www-ws-arch@w3.org
- Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E03132831@bocnte2k3.boc.chevrontexaco.net>
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.
Received on Saturday, 8 November 2003 13:29:48 UTC