W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2004

RE: WSDL and pub/sub

From: Martin Chapman <martin.chapman@oracle.com>
Date: Tue, 17 Feb 2004 19:20:12 -0000
To: <david.burdett@commerceone.com>, <Farrukh.Najmi@Sun.COM>
Cc: <chiusano_joseph@bah.com>, <UCorda@SeeBeyond.com>, <Monica.Martin@Sun.COM>, <andyb@whyanbeel.net>, <steve@enigmatec.net>, <public-ws-chor@w3.org>
Message-ID: <000001c3f58b$12d4c8a0$0901a8c0@ie.oracle.com>

This discussion is getting off topic for this list!

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of 
> david.burdett@commerceone.com
> Sent: 17 February 2004 17:26
> To: Farrukh.Najmi@Sun.COM
> Cc: chiusano_joseph@bah.com; UCorda@SeeBeyond.com; 
> Monica.Martin@Sun.COM; andyb@whyanbeel.net; 
> steve@enigmatec.net; public-ws-chor@w3.org
> Subject: RE: WSDL and pub/sub
> 
> 
> 
> Farrukh
> 
> Thanks for the explanation, it makes sense. Here's another 
> question as I am really trying to get my mind around this ...
> 
> Suppose, that you want to build an auction capability using 
> the the following services, for example: 1. User Registration 
> - registers a user 2. Auction Registration - records a 
> registered user's interest in an auction 3. Bid Placement - a 
> user that has registered an interest in an auction places a 
> bid 4. Bid Notification - users that have registered an 
> interest are notified of successful bids placed 4. Bid Result 
> - the winner of the auction (if any) and other interested 
> users are notified of the result of the auction 3. Winning 
> Bid Payment - the winner of the auction pays, by credit card
> 
> Let's go further and assume that:
> 1. There are existing User Registration and Winning Bid 
> Payment services that the operator of the auction wants to 
> use 2. Bids are not automatically accepted, for example they 
> must be higher than any previous bid and perhaps mulitples of 
> $10, if that what the auction rule says 3. Users must be 
> registered before they can bid.
> 
> This sounds to me to be more than what the ebXML Resistry was 
> designed for.
> 
> So some more questions:
> 1. Could you sensibly use the pub/sub part of ebXML RR in the 
> above example. 2. If you can, you still have the problem of 
> defining how you combine the ebXML RR pub/sub protocol with 
> other existing protocols to ensure that they occur in the 
> correct sequence.
> 
> Don't misunderstand me, I do think that ebXML RR has great 
> value in maintaining information about "static" objects, e.g. 
> WSDL definitions, schemas, etc, I'm just not sure that it is 
> the appropriate technology to use for this use case.
> 
> Thoughts
> 
> David
> 
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> Sent: Tuesday, February 17, 2004 4:39 AM
> To: Burdett, David
> Cc: chiusano_joseph@bah.com; UCorda@SeeBeyond.com; 
> Monica.Martin@Sun.COM; andyb@whyanbeel.net; 
> steve@enigmatec.net; public-ws-chor@w3.org
> Subject: Re: WSDL and pub/sub
> 
> 
> david.burdett@commerceone.com wrote:
> 
> >Monica, Joseph, Ugo et al
> >
> >A question. Just suppose you wanted to use the ebXML RR spec 
> with other 
> >XML documents designed to support the Auction use case I 
> described earlier, would there be any issues that you can 
> think of. For example ... would you need to have an ebXML 
> Registry to store information about Auction objects?
> >  
> >
> David,
> 
> Funny you should mention an auction scenario and ebXML 
> Registry. See a 
> recent exchange below where I used the same scenario in the 
> context of 
> ebXML Registry event notification.
> 
> I feel that ebXML Registry event notification could be used 
> to support 
> multi-party collaboration scenarios as the next logical step 
> from binary 
> collaborations exemplified by ebXML Messaging and SOAP.
> 
> As it currently stands, registry events are only triggered when a 
> CREATE/UPADTE/DELETE operation occurs
> in the registry. For example a BiddableObject must be written to 
> registry to represent that something is open for bids. 
> Bidders would be 
> subscribed to BiddableObjects and will be notified. They can 
> then write 
> Bid objects to the registry. The auctioneer would be 
> subscribed to Bids 
> for "their" BiddableObjects and will be notified when a Bid 
> is placed. 
> They would have to write a BidResult object to registry when bidding 
> closes and all Bidders would be notified of the BidResult.
> 
> So yes several objects would have to be written to the 
> registry in order 
> to support this scenario.
> 
> -- 
> Regards,
> Farrukh
> 
> 
> 
> -------- Original Message from Farrukh on regrep in reply to 
> Joe  --------
> Subject: 	Re: [regrep] Direct Data Exchange vs. SOA
> Date: 	Wed, 11 Feb 2004 10:50:12 -0500
> From: 	Farrukh Najmi <Farrukh.Najmi@Sun.COM>
> To: 	Chiusano Joseph <chiusano_joseph@bah.com>
> CC: 	regrep@lists.oasis-open.org <regrep@lists.oasis-open.org>
> References: 	<402A4C2C.C65CF5F1@bah.com>
> 
> 
> 
> Chiusano Joseph wrote:
> 
> >I have an inquiry that is not directly related to our 
> mission here, but 
> >I hope to get some good insight in response please:
> >
> >Let's say we have a purchase order process between trading 
> partners (PO 
> >sent, Invoice received). There are (for the purposes of this 
> inquiry) 2 
> >possible ways to handle this process:
> >
> >(1) Direct Data Exchange (create XML documents based on a common 
> >schema, and exchange them between trading partners)
> >
> >(2) SOA (have a purchase order/invoice shared service that is 
> >discovered in a registry, etc.)
> >
> >My inquiry is: What would drive an organization to use one 
> approach or 
> >the other, from both a business and technical standpoint? 
> For instance, 
> >would "critical mass of services and/or trading partners" be 
> a driver 
> >for SOA vs. direct data exchange?
> >
> >  
> >
> The second approach allows for multi-party colaboration instead of 
> binary collaboration.
> It would rely on Registry Event notification. An example would be a 
> bidding or auction scenario.
> 
> 
> 
> 
> 
> 
Received on Tuesday, 17 February 2004 14:20:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:51 GMT