OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: TPA Info Rework

Rejoinder in line.



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 10/27/2000 08:13:44 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-transport@lists.ebxml.org, ebxml-tp@lists.ebxml.org
Subject:  RE: TPA Info Rework


Comments inline.


-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Friday, October 27, 2000 12:39 PM
To: Burdett, David
Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
Subject: Re: TPA Info Rework

(Again, I hit the send button in error.  Hmmm....)


I like this proposal.  I am not speechless, however :-)

7.9.1 From and To

   Line 48:  CpaReferences:  Presumably should be CpaReference
##Correct## ConversationId

   Line 65:  Can we delete "or more"?  There are some fairly serious
   run-time issues with more than 2 parties.  I would prefer to leave that
   for the future in both TP and TRP.
##Sounds like a good idea. I'm not sure how it would work in a mult-party
environment. Agreed##  CPA Reference

   Line 81 and 82:  The term we are using in TP Requirements is
   "Collaboration Protocol Agreement".
##Done##  Party Profile Reference

   Line 106 and elsewhere:  Currently, the TP team is using the term
   "Collaboration Protocol Profile".  Could we state that here instead of
   Party Profile.  Alternatively (and more controversially), the term
   Trading Partner Profile is reserved for a profile that contains a CPP
   and higher level definitions.
##For consistency I'll use CPP and CppReference##

   Editor's note, lines 125-131:  In my opinion, if a Party Profile has to
   contain more than one way of exchanging messages, that Party expects to
   work with the other party to select one way.  In other words, that's a
   situation which cries out for a CPA.  The CPA is the additional
   mechanism that the note refers to.  I suggest stating a RECOMMENDation
   that if a Party expects a CPP to be used in lieu of a CPA, it should
   limit the CPP to one way of exchanging messages and if the CPP has to
   state more than one way, a CPA should be used to define the choice for
   one pair of parties.
##Limiting it to one-way is a good idea, however what would you do if you
send a message to the same service using either RosettaNet or EDI?. If we
follow your route then we would have to have to CPPs.

MWS:  I believe that it is extremely unlikely that I would send the same
message using either RosettaNet or EDI since those are very different
functions.  However if a party wanted to advertise that it could support
both RosettaNet and EDI, then it would need to provide it specifications
for both in the CPP.  I suppose that one could provide enough information
in the CPP so the other party would know what to do for each application.
However in general, there can be a lot of combinations and permutations of
function specified in a CPP, so I prefer to start by saying that a CPP to
be used in lieu of a CPA should  specify only one way of doing business.  I
think that we know that we can specify that within the allowed time frame.
We can leave the "multi-way" case for a future enhancement.

I think we need to
think this through some more as it ties in closely to the structure of the
CPP and how you can identifiy it. For example you could have something
the lines of ...

<Service Id='123' type='POAccept' >
<Protocol Id='456' type='EDI' />
<Protocol Id='789' type='RosettaNet' />

... then the CppReference could contain ...


... which I don't like since the content has structure that is not XML, or


MWS:  If I understand the above, it is really specifying several things
that can be done but each can be done one way.  That's an extension we
should be able to manage.  In fact that can be done within the existing
tpaML structure by simply providing a set of action definitions that
includes all the possibilities.  tpaML even permits the use of a different
delivery channel for each action.  A natural extension which we already
thought about in IBM (and I think is in the requirements document now) is
to provide a separate service interface definition within the same CPP for
each of the supported protocols.

... which is better but would require us to definie the structure ...

7.9.2 Service

   Line 193 and elsewhere:  I agree that ServiceInterface is not
   appropriate since that term usually refers to inter-layer interface in a
   protocol stack, and TRP seems to be going in that direction for its
   upper interface.  Other possible terms, some of which have been
   mentioned by members of the TP team are Collaboration Interface,
   Business Service Interface (assuming Stefano is willing to find another
   term for his Business Service Interface), and Logical Port.  Let's try
   to resolve this one on Monday of the Tokyo meeting.
##RosettaNet uses the term "Service", BizTalk uses the term "endpoints", I
am strongly in favor of the term "Service" ... we really need an agreed
glossary of terms.##

MWS: ...and we need it by lunchtime on the Monday of the meeting.

7.10 DTDs

   I prefer the first version (lines 221-242).
##So do I ;) ##



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 10/23/2000 08:30:05 PM

To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject:  TPA Info Rework


The attached PDF and MS Word files contain a re-work for version 7.9 (XML
Header) of version 0.21d of the TRP Message Service Spec. The main reason
for doing this is to support the sending of messages without prior
of a TPA (CPA?). The introduction to the document provides a full
explanation of the changes made and the reasons why.

Comments are welcome. I also think we should discuss this in Tokyo.

 <<TPA Info Alternative 2.doc>>  <<TPA Info Alternative 2.pdf>>

Product Management, CommerceOne
4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC