RE: POC question for CPP-CPA possibly for Vienna agenda

["Burdett, David" <david.burdett@commerceone.com>]

Dale/Marty

I recently posted an email to the TRP list
(http://lists.ebxml.org/archives/ebxml-transport/200104/msg00103.html) on
the need to include the "From Service" in the header, that I think may
relate to this thread. 

The basic ideas is that the "From Service" is needed for routing purposes
when sending a error, status, acknowledgment and Delivery Receipt messages
back to the From Party. For example, currently routing for the "Message
Status Request" message is likely based on the following pieces of
information:
* the To PartyId, e.g. urn:duns:nnnnnnn
* the Service, currently FIXED at uri:www.ebxml.org/messageService/
* the Action, currently FIXED at "StatusRequest"

If only this information is used (and I don't think there is anything else)
then as the Service and Action are FIXED, resolution of this information can
result in only ONE URL.

If you wanted to make this work, it would mean that, if a Party had more
than one MSH, then they would all need to be co-ordinated and share a common
repository of MessageIds. This is just not scalable.

What I propose is that we include the id of the sending Service in each
message and use this when sending messages back to the From party. This
would mean that you would have in the error, status, acknowledgment or
delivery receipt messages ...
* the To PartyId, e.g. urn:duns:nnnnnnn
* the Service, contains the "From Service" of the message that was received
* the Action, FIXED at, for example,
"uri:www.ebxml.org/messageAction/StatusRequest"

This would then mean that only the MSHs used by a Service would need to be
co-ordinated and more often than not there would be just one. 

So far there has been no discussion of this on the TRP list, so I guess we
will be talking about it in Vienna. However I would much prefer discussion
on the list so that a broader selection of folks can be put forward their
views.

Thoughts?

David


-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Thursday, May 03, 2001 6:59 AM
To: Dale Moberg
Cc: ebxml-tp@lists.ebxml.org
Subject: Re: POC question for CPP-CPA possibly for Vienna agenda



Dale,

1.  Service element

   I agree that we have a mismatch with TRP.  We will need to discuss this
   in Vienna (and we will need Chris for this one).  I don't think the
   answer is that the value of the CPA's name attribute should be the value
   of the TRP's type attribute because that still leaves the question of
   what to do with the value of the TRP service element.  I think that we
   have two choices:

     1. Specify that the value of the Name attribute SHALL be a URI.

     2.  Add an additional IMPLIED attribute for service type and repeat
     the TRP rules about when the type attribute is needed. We could go a
     step further and make it exactly like TRP (Service element as child of
     ServiceBinding and type attribute of Service). This is probably
     preferred since it is in the spirit of using the same XML grammar in
     both specs.

   I suggest that the POC  assume choice (1) and implement accordingly.
   This should work regardless of our final decision.

2. Action element

   We resolved the Action element definition in ver. 0.96 after Chris and
   Karsten finally intersected last week and resolved some of the open
   questions in TP-BP synchronization.  In short, Override identifies a
   delivery channel to be used for messages received from the business
   transaction identified by the Action element. Note that this is a TP-BP
   question, not a TP-TRP question. You will see the fix in the version I
   distributed yesterday afternoon but here it is.

     7.5.7     Override element
     The Override element provides a Party with the ability to map, or
     bind, a different DeliveryChannel to Messages of a selected Business
     Transaction that are to be received by the Party within the context of
     the parent ServiceBinding element.

     ...(stuff ommitted here)

     7.5.7.1   action attribute
     The REQUIRED action attribute is a string that identifies the Business
     Transaction that is to be associated with the DeliveryChannel that is
     identified by the channelId attribute. The value of the action
     attribute MUST match the value of the Name attribute of the desired
     BusinessTransaction element in the Process-Specification document that
     is referenced by the ProcessSpecification element.

   I don't believe that our definition is at odds with the definition of
   Action in TRP; both ours and TRP's are really the same animal.  CPA
   optionally specifies a delivery channel to be used with a particular
   business transaction (Action).  When the application sends a message, it
   supplies the name of what TRP calls the process within a Service.  If
   the service is defined by the BP Specification Schema, then I think that
   Service is the name of the applicable Binary Collaboration and Action is
   the name of the Business Transaction within that Binary Collaboration.

   Regarding your final questions, I believe that both TP and TRP are OK
   though perhaps TRP should have some words pinning down service and
   action to BPSS constructs. However TRP has been even harder-nosed than
   our team about avoiding any appearance of dependencies between TRP and
   TP/BP.  In any case, I believe that the semantics are simply that a
   message is from a process within a service and is routed to a process
   within a service.  We (TP) might want to add a statement that when the
   BPSS provides the Process Specification document, the Service is the
   Binary Collaboration.  Then again may be it's better to leave it loose.

   As to the agreement being or not being reflected in the CPA, the
   agreement IS reflected in the CPA, indirectly, by the agreement to use
   the same Process Specification document.  The contents of that document
   are as much a part of the agreement as the base CPA is.

   I suspect that most of your problem here is caused by our taking until
   ver. 0.96 to finally resolve the semantics of Action.  Look over the
   material in 0.96 and see if you agree.

   I will add this topic to our agenda.

   Regards,
   Marty

 
****************************************************************************
*********

   Martin W. Sachs
   IBM T. J. Watson Research Center
   P. O. B. 704
   Yorktown Hts, NY 10598
   914-784-7287;  IBM tie line 863-7287
   Notes address:  Martin W Sachs/Watson/IBM
   Internet address:  mwsachs @ us.ibm.com
 
****************************************************************************
*********



"Dale Moberg" <dmoberg@columbus.rr.com> on 05/03/2001 08:55:15 AM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:
Subject:  POC question for CPP-CPA possibly for Vienna agenda



Hi Marty,

I have been wearing my developer hat the last 1.5 weeks for the Vienna POC.
While most issues pertain to TRP, one or two pertain to CPA 0.95. While
writing
xslt code for CPA to ebXML header population,
(or equivalently, for MSH DB configuration),
I discovered possible issues.

Maybe I have missed something but here they are:

1. The TRP group says that its Service element is a URI when the type
attribute
is missing, but is some string when the type attribute is used that
reflects
a bilateral agreement (section 8.4.4 and 8.4.4.1). TPA says (7.5.6.1) that
the value is a string. If the string is not syntactically well-formed as a
URI, a type value must be used. What would be useful is a convention for
indicating that the CPA-specified service string
is an agreed upon value for the ebXML
header Service element's type attribute.

In other words, something like:

uri:www.ebxml.org/CPP-CPA

could be the value for the type attribute when
the service string is not syntactically a URI.

While the missing convention may not
strictly be a defect, it does make interoperability
dicier partly because TRP asserts:
If it is not a URI and no type attribute is
present, the MSH has to emit an error response.

Implementationally, one needs a basis for deciding
whether to add a type value or not-- and a URI syntax
check can do that. Then if not a URI, add a type
specifier. While there is no way to anticipate all
possible extensions here, we can at least specify
how the one established extension mechanism (CPA)
is indicated.

Comments?

2. I have lost track of where the value for the TRP Action
element comes from. There is no place in the CPA where
we connect the Action value of TRP with anything in the
CPA. (unlike the Service element)
Nor have I found anything in the BPSS that is referenced
by the CPA that clearly provides this value. Like the previous
issue, this is a system coherence issue that stradles
TRP,TPA and BP. Could you update me on what has happened
to the Action value? TRP is pretty vague about it in 98b and 99.
We seem to omit saying where it can be specified. Have we
decided that CPAs pertain to _any_ action within the same service?
(Nothing necessarily wrong with that but it might help MSH
implementers if that were stated explicitly.)
What is the action value doing? Will all actions within a service
be routed to/from its "consuming/generating application"
the same way? I believe we are not providing
a clear semantics for the action value within
the overall ebXML architecture at present. If we can't
say how it is used and what difference it makes, maybe
it should go? If we say that it is bilaterally agreed upon,
then that agreement is not reflected within the CPA except
possibly through some pointer off to BPSS.
Are we confident that TRP,TPA,and BP have congruent
and compatible presumptions about the Action element's
semantics?






------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org