[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] For CPPA Next-- FW: Transient Channel Requirementsfor CPP/CPA
>service providers cannot initiate because WSDL does not provide a >way of indicating an address that a service provider can send to since >there is no service requester description. Partially agree. Although all requests must be came from requesters including request for notification; and within a request of notification from requester to provider, the message should included the address. And such service should be describe in WSDL. What do you think? Kit ================================== Lecturer Institute of Vocational Education Tel: 852-97710172 ================================== ----- Original Message ----- From: "Martin W Sachs" <mwsachs@us.ibm.com> Date: Wednesday, April 24, 2002 8:27 pm Subject: Re: [ebxml-cppa] For CPPA Next-- FW: Transient Channel Requirements for CPP/CPA > > I agree with you but the main concern of the memo I was commenting > on were > initiate-only and response-only. It is also true that there can be a > response to initiate-only, so initiate-only (in the memo) is really > request-response. My comment about Web services was also correct > in that > today, service providers cannot initiate because WSDL does not > provide a > way of indicating an address that a service provider can send to since > there is no service requester description. > > In WSDL 1.1, the actual names of the one-way transmission > primitives are > notification and acknowledgment. Nonetheless, as I said above, a > serviceprovider cannot initiate a dialog since it doesn't know > where to send the > message. I hope that the W3C WSDL team will do something about that. > > 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 > > ************************************************************************ ************* > > > > > "Kit K. Ko" > > > <kitko@vtc.edu.hk To: Martin W > Sachs/Watson/IBM@IBMUS > > > cc: <ebxml- > cppa@lists.oasis-open.org> > > Subject: Re: > [ebxml-cppa] For CPPA Next-- FW: Transient Channel Requirements > for CPP/CPA > 04/23/2002 08:34 > > > PM > > > > > > > > > > > > >TERMINOLOGY: > > Martin, > >In Web Services, at the current state of their art, a service > rquestor is > >initiate-only; a service provider is response-only. > > Actually, there are four primitives: > 1/. Request-response > 2/. Solicit-response > 3/. Notification > 4/. Acknoledgement > > 1/. & 2/ above can be modeled abstractly using two one-way messages. > > Kit > ----- Original Message ----- > From: "Martin W Sachs" <mwsachs@us.ibm.com> > To: "Dale Moberg" <dmoberg@cyclonecommerce.com> > Cc: "Cppa (E-mail)" <ebxml-cppa@lists.oasis-open.org> > Sent: Tuesday, April 23, 2002 8:55 PM > Subject: Re: [ebxml-cppa] For CPPA Next-- FW: Transient Channel > Requirements > for CPP/CPA > > > > > > This is a good thing to add. It seems to be one step on the way > to more > > effective SME support. A few initial comments: > > > > TERMINOLOGY: > > > > In Web Services, at the current state of their art, a service > rquestor is > > initiate-only; a service provider is response-only. > > > > GENERAL USE CASE > > > > While the example is specific to an unsophisticated seller and a > > sophisticated buyer, the specification should permit any role to > be the > one > > that has the minimal infrastructure. We should probably allow > for both > > trading partners to have the minimal infrastructure. This might > turn out > > to be the harder one. > > > > DELIVERY CHANNEL > > > > The CPPA spec already has some words about dynamic selection of a > delivery > > channel and about getting the response address from the busines > document.> > > PROPOSED ATTRIBUTE: TRANSIENT CHANNEL > > > > These presumably go in the MessagingCharacteristics element and > not as > > stated in the proposal. > > > > OTHER IMPACT > > > > In particular, in the example cited, the Initiate-only side's > receive> characteristics would omit the endpoint address. However > (see below), I > > believe that initiate-only side still has to have some receive-type > > delivery channel definitions since the other side has to know what > > transports and messaging characteristics to use. > > > > ADDITIONAL COMMENTS > > > > A party with minimal infrastructure would have to pass the > return address > > in the business document or the MSG spec would have to provide a > place in > > the header. I suspect that passing it in the business document > is the > > better choice since one or both parties' minimal infrastructure > probably> would not support conversations or otherwise have a > place to save and > find > > the return address. Having the application get the return > address out of > > the business document and pass it down with the response message is > > probably the lower cost implementation. > > > > If my comment above is correct, it also suggests that one of the > costs of > > minimal infrastructure is moving some function up to the > application.> > > This proposal does not eliminate the need for both sides to specify > > delivery channels in the CPA since each has to know the other's > > capabilities. Especially, an initiate-only party has to provide some > > information about its receive capabilities. That means that each > side has > > to save some configuration information about the other. > > > > There are probably some implications that the MSG team has to > consider> about this proposal. For example, some header elements > and attributes > > might have to be allowed to be empty or not present. > > > > 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@cycloneco To: "Cppa > (E-mail)" > <ebxml-cppa@lists.oasis-open.org> > > mmerce.com> cc: > > Subject: [ebxml- > cppa]For > CPPA Next-- FW: Transient Channel Requirements for > > 04/22/2002 05:34 CPP/CPA > > PM > > > > > > > > > > > > > > Here are some requirements to consider for our future work. > > > > Dale Moberg. > > > > -----Original Message----- > > From: Fenton, Chuck [mailto:Chuck_Fenton@stercomm.com] > > Sent: Monday, April 22, 2002 12:15 PM > > To: Dale Moberg > > Subject: Transient Channel Requirements for CPP/CPA > > > > > > Dale, > > > > Please regard this e-mail as a formal request from the Automotive > > Interest > > Action Group (AIAG) Message Routing WG, to include the attached > > Transient > > Channel Requirements in the next CPP/CPA version discussion. > You may > > regard this as a public document that may be circulated and > reviewed by > > anyone you or your TC deem appropriate. I am the contact for > > questions, > > etc. > > > > Now, having gotten the TC/WG stuff done, I see you are going to > > Barcelona. > > So am I. We will have to catch up. > > > > -Chuck Fenton > > Principal Research Engineer > > Sterling Commerce, Inc. > > chuck_fenton@stercomm.com > > 734.930.7862 - Phone > > 734.930.2301 - Fax > > > > > > <<TransientChannelReqV0.5.rtf>> > > > > > > #### TransientChannelReqV0.5.rtf has been removed from this note > on April > > 23 2002 by Martin W Sachs > > > > > > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <" target="l">http://lists.oasis-open.org/o > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC