[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TPA Info Rework
Rejoinder in line. 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 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 Marty Comments inline. David -----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....) David, I like this proposal. I am not speechless, however :-) 7.9.1 From and To Line 48: CpaReferences: Presumably should be CpaReference ##Correct## 7.9.1.2 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## 7.9.1.3 CPA Reference Line 81 and 82: The term we are using in TP Requirements is "Collaboration Protocol Agreement". ##Done## 7.9.1.4 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 along the lines of ... <Cpp> <Service Id='123' type='POAccept' > <Protocol Id='456' type='EDI' /> <Protocol Id='789' type='RosettaNet' /> </Service> </Cpp ... then the CppReference could contain ... <CppReference>cppid:123:protocolid=789</CppReference> ... which I don't like since the content has structure that is not XML, or ... <CppReference> <cppid>123</cppid> <protocolid>789</protocolId> </CppReference> 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 ;) ## 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 10/23/2000 08:30:05 PM To: "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org> cc: Subject: TPA Info Rework Folks 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 agreement 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. David <<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]
Powered by eList eXpress LLC