RE: T2 PLEASE READ - Suggested Change - add "From" Service and Ac tionto the header

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Title: RE: T2 PLEASE READ - Suggested Change - add "From" Service and Action to the header

Hi All,

In EDI, we have some business documents in which the sender may include data which serves no business purpose to the recipient.  Yet the recipient is expected to return that data to the sender, so that he sender's internal system can process the information that came from his sending application within his receiving application (seems the two applications don't share the same information internally.  I and many

others conside that an ugly kludge having no place in a properly modeled business system.

The issue described below seems to fall into the same category as the one I described above.  I therefore recommend the issue be dismissed without further action.

Cheers,
         Bob Miller

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Friday, September 07, 2001 7:41 PM
To: ebXML Messaging (E-mail)
Subject: T2 PLEASE READ - Suggested Change - add "From" Service and
Action to the header

Folks

Here I go again with another issue that I think we need to resolve. This one
is a lot simpler than the Reliable Messaging discussion as there are only
two changes required. But it is still one which I think we need to discuss
as I think there is a bug that needs to be fixed and we need to discuss it.
I have mentioned this bug previously (see
http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00128.html) however
no-one responded to that email.

As before, AS CHAIR OF THE T2 EFFORT I AM GOING TO ASSUME YOUR SUPPORT OF
THE SUGGESTED CHANGE IF YOU DO NOT RESPOND to this email. But really I want
to start a discussion and come to a consensus ;)

David
PS If anyone else thinks there is a "MUST DISCUSS" issue that has been
previously raised but not adequately discussed that needs a similar
treatment to this or the RM issue, please contact me separately and directly
so that we can discuss how to raise it.
============
SUGGESTED CHANGE: ADD FROM SERVICE AND ACTION TO THE HEADER
Change 1
--------
Summary: Add "From Service" and "From Action" elements to the Message Header

Rationale: This change is required to fix the problems that a To Party MSH
that is generating a response message does not always know what to put in
the To Service and Action.

Consider the following Use Case involving a bank and a bank customer that
uses the bank for funds transfer purposes:
1. The bank accepts account transfer requests from its customers to transfer
funds from one account to another.
2. The bank wants to make sure that the transfer request is authorized (i.e.
the ebXML request is digitally signed with a valid certificate) but doesn't
care to know, in fact it is none of the bank's business, why the transfers
are being made.
3. The bank's customer uses the funds transfer facility for a variety of
different business reasons for example: Customer Refunds and Invoice
Payment. In ebXML BPSS terminology there are two different business
processes going on here: Refund Payment and Invoice Payment.
4. Both the Refund Payment and the Invoice Payment Business Transactions use
*identical* message flows consisting of a Transfer Request (to the Bank) and
a Transfer Acknowledgement (back to the Customer)
5. The Customer Refund and Invoice Payment business processes are supported
by different applications where each generates their own funds transfer
requests.

The problem as I see it with the current approach is as follows:
1. There is nothing in the ebXML message header to indicate which "Service"
at the From Party is sending the message. Therefore the Bank does not know
which service to send the response to unless the bank has separate
agreements with its customer for each business transaction on what to use.
2. The bank should not need to know anything about the customers business
transaction but with the current solution this would be a requirement
3. If the customer wanted to make a payment for a new reason, for example to
buy stock, then it would need a new agreement with the bank which presents
an additional unnecessary barrier to using the service
4. If the bank, as it cannot know any better, puts something like
Service=FundsTransfer, Action=TransferAcknowledgement in the header, then
the Customer that receives the message does not immediately know which
application to forward the message. It would have to store information from
the the original message that was sent and use the RefToMessageId to
determine which application had made the original Transfer Request.
5. To support 4, the customer will have to save data from even if they were
sent with DeliverSemantics of BestEffort, as they need to look up the
message they sent.

Adding the "From Service" and "From Action" solves these problems as the
recipient of a message (e.g. the bank) can use them to populate the To
Service and To Action when generating a reply.

Change 2
--------
Summary: For error, delivery receipt, acknowledgment, ping/pong and status
request/response messages, make the To Service specify the original From
Service and make the To Action identify the type of message.

Rationale: In the current spec, you can only send an error, delivery
receipt, acknowledgment, ping/pong or status request/response message to a
**single** MSH for a Party. For example the Service and Action for an error
message is currently defined as ...
*       The Service element MUST be set to:
uri:www.ebxml.org/messageService/
*       The Action element MUST be set to MessageError.

So if you are looking up where to send a message to using PartyId, Service
and Action then there will be only one URL that you could have for the
Party. This means that the Party could have only one MSH.

I know that you could, instead, hold the information in a CPA, but then you
would HAVE to have a CPA before you could send a message and we are
designing ebXML MS so that use of CPAs are optional.

The alternative suggestion is to change error (and the other similar
elements) to read ...
*       The Service element MUST be set to the "From Service" on the message
that was in error
*       The Action element MUST be set to uri:
www.ebxml.org/messageService/MessageError

This means that you can route the message based on Party and Service and
therefore allow multiple MSHs for a Party.

Product Manager, xCBL, XML Standards
Solution Strategy, Commerce One
4400 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>