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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[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



That's correct.  The initial contact between a requester and a  Web service
must come from a requester so that the requester can provide a return
address.  One the requester has provided a return address, the service
provider an initiate subsequent exchanges. That's what I was trying to say.
The CPP provides an endpoint address for another party to use, so with
ebXML, either party can make the initial contact once they have discovered
each other's CPP and/or created a CPA.

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/24/2002 10:11                                                                                                     
                      AM                                                                                                                   
                                                                                                                                           
                                                                                                                                           



>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