Re: WSDL and pub/sub

Hi Folks,

Please excuse me for jumping into the conversation so late. I have 
been tempted earlier but decided against it for the main reason that 
the WSRP TC, to which I belong, has not yet begun discussions about 
how the Remote Portlet Standard will handle eventing. Since Farrukh 
is now consulting and working with the publish-find-bind 
subcommittee, this has changed, so I am somewhat less concerned about 
sticking my foot in my mouth now that I know he can correct me 
knowledgeably.

I mentioned in another list before subscribing myself to this one 
that I did not think it was wise, or scalable, or anything but 
confusing to put any eventing model into play in the registries, 
either UDDI or ebXML for web services since it will inevitably fall 
to the intermediary, pass-through ws (portal) providers, to notify 
their currently registered transaction partners of events.

I was very careful about the wording of that to stay away from 
WSRP-specific terminology, but I want to mention specifically that 
while it is too late by far to change the ebXML eventing model nor 
its use of the terms for subscription and notification that it uses, 
I think it would be very wise to move from the overloaded 
publish-subscribe model for eventing and notification and move to a 
simpler sender-receiver-acknowledgement model.

The problem, as I see it is that registries are all trying to DO too 
much. We want registries to be reliable first and foremost. The 
important thing is that any eventing opens the door for errors due to 
complexity alone. My opinion, fwiw, is that any eventing done in 
registries should be constrained to information about changes within 
the parameters of the member-entities within the registries, and 
never about content changes within the specific web services provided.

The proverbial example for this is the stock market trader. A change 
in the stock quote itself ought never be part of a registry, while a 
change in the stocks available for quoting from a trader could be 
part of a registry, though, personally, I would not allow even that 
much and constrain eventing within registries to such changes as a 
name change for the stock trader company.

Therefore, regardless of things unchangeable, I would hope that 
information about auction objects never be stored in the registry but 
only and ever be stored within the auction offeror or the object 
itself, and those entities ought to be represented by standardized 
xml documents for the purpose of interoperability.

Long post. Short answer. I'll shut up now.

Ciao,
Rex

At 7:38 AM -0500 2/17/04, Farrukh Najmi wrote:
>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.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request

Received on Tuesday, 17 February 2004 08:39:16 UTC