- From: Ricky Ho <riho@cisco.com>
- Date: Thu, 19 Dec 2002 13:04:59 -0800
- To: "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>, "Pae Choi" <paechoi@earthlink.net>, www-ws-arch@w3.org
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
Received on Thursday, 19 December 2002 16:05:39 UTC