[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
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 service
provider 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: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC