[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: POC question for CPP-CPA possibly for Vienna agenda
David,
Your question is strongly coupled to the one I just posted to TP, BP, and
TRP. I evaporate in 2 hours and may not be in touch with email again until
I arrive in Vienna Sunday. So, from my viewpoint, this discussion will
have to take place in Vienna and include BP as well.
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
*************************************************************************************
"Burdett, David" <david.burdett@commerceone.com> on 05/03/2001 03:09:51 PM
To: Martin W Sachs/Watson/IBM@IBMUS, Dale Moberg
<dmoberg@columbus.rr.com>
cc: ebxml-tp@lists.ebxml.org, "ebXML Transport (E-mail)"
<ebxml-transport@lists.ebxml.org>
Subject: RE: POC question for CPP-CPA possibly for Vienna agenda
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC