RE: Web services Requirement at the client side in Orchestrati on

The only comment I would add is that if we want machine-to-machine
interactions using Web Services to work on a broad scale for things like
purchasing, a LOT of general agreement and standardization on how a)
purchasing works, and b) how purchasing working with web services, needs to
be done.

Even if we can dynamically discover the specifications of a new way to do
something (e.g. a new way to do purchasing), I doubt you could automatically
create a machine-to-machine (vs a person-to-machine) solution from the
specification without doing a lot of extra (manual) work.

Anyone agree/disagree?

David

-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com]
Sent: Thursday, December 19, 2002 1:05 PM
To: Cutler, Roger (RogerCutler); Pae Choi; www-ws-arch@w3.org
Subject: RE: Web services Requirement at the client side in
Orchestration



I think whether one side needs to implement a "listener" depends on whether 
it is implementing a "push-based" or "pull-based" interaction style.  Both 
styles can be used to implement the same conversational semantics.

In a "push" style, so somebody will call you later, therefore you have to 
provide a listener that they can call.

But you don't need listener in "pull" style, I can think of at least 2 
cases ...

1) Client send a request and then "synchronously" wait for the response 
after the processing is done.
2) Client send a request and immediately get back a receipt which contains 
a tracking number.  Then after a reasonable among of time, the client send 
polling message (along with the tracking number) and get back the response 
when the processing is done.

Rgds, Ricky

At 02:31 PM 12/19/2002 -0600, Cutler, Roger (RogerCutler) wrote:

>I think that the purchasing operation is more an interaction between
>peers than it is a client-server-like operation.  That is, the buyer may
>send the initial request for information, but then the seller sends in
>turn sends various responses and requests for information.  It is a
>conversation.
>
>This, of course, is a view based on the scenario of businesses
>interacting with each other, which is what the purchasing use case is
>pretty much about.  We are NOT really thinking in terms of an individual
>purchasing things, in which case it would be much less an interaction
>between peers.
>
>I don't think tha B2B purchasing operations taking place through web
>services make much sense unless both sides of the interaction are web
>services enabled.
>
>
>-----Original Message-----
>From: Pae Choi [mailto:paechoi@earthlink.net]
>Sent: Thursday, December 19, 2002 2:18 PM
>To: www-ws-arch@w3.org
>Subject: Web services Requirement at the client side in Orchestration
>
>
>
>One quick question in [1]the Web Services Architecture as stated under
>the section, "3.3.3.2.2 Orchestration", as follows:
>
>
>3.3.3.2.2 Orchestration
>
><snip>
>"For example, the seller must have web services that receive request for
>quote (RFQ) messages, purchase order (PO) messages and payment messages.
>The buyer role must have Web services that receive quotes (RFQ response
>messages), invoice messages and account summary messages." </snip>
>
>
>How come the buyer(i.e., client) MUST have "Web services." The client
>should be able to acess and interact with Web sevices provided by the
>seller, i.e., the Web services provider, without having Web services at
>the client side. I cann't think of any scenario that the client, i.e.,
>excluding the intermediary, need to have Web services. Any comments?
>
>Regards,
>
>
>Pae
>
>
>[1] http://www.w3.org/TR/2002/WD-ws-arch-20021114/#id2616565