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

Re: WSDL and pub/sub

From: Rex Brooks <rexb@starbourne.com>
Date: Tue, 17 Feb 2004 08:32:03 -0800
Message-Id: <a06020419bc57ee1fda5f@[]>
To: Farrukh Najmi <Farrukh.Najmi@Sun.COM>, Rex Brooks <rexb@starbourne.com>
Cc: david.burdett@commerceone.com, chiusano_joseph@bah.com, UCorda@SeeBeyond.com, Monica.Martin@Sun.COM, andyb@whyanbeel.net, steve@enigmatec.net, public-ws-chor@w3.org

Thanks, Farrukh,

I was hoping you could bring better clarity to there issues, which 
you have. I apologize for covering ground that has already been 
through the process of discovering where boundaries appear to be in 
reality as opposed to theory. My own concerns are that we may end up 
with conflicting overlaps of eventing models and specs, which has 
already occurred in principle if not in actual fact with the 
ws-eventing and ws-notification proposals. What we see are similar 
terms used in similar but not identical ways. Since these trial 
balloons have not yet been cast in concrete, we can, hopefully, head 
off conflicts.

However, since we are at a stage in the development of web services 
where we have just seen recent updates to SOAP and RDF/OWL, it seems 
like a good time to reassess what needs to be done vis a vis looking 
for better coordination among W3C, ISO, OASIS--which we are also 
seeing, so this is helpful to understand. I have a lot of reading to 
do. The brochure now joins the list.

My main concern is duplicated and possibly conflicting efforts and 
scalability. As long as we avoid those pitfalls I will be happy with 
whatever solutions prove out.


At 10:04 AM -0500 2/17/04, Farrukh Najmi wrote:
>Rex Brooks wrote:
>>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 assume you are questioning the wisdom of using registries for 
>multi-party collaboration and not the wisdom of supporting event 
>notification in registries.
>I too occasionally wonder about whether registries *SHOULD* play a 
>role in multi-party collaboration but have no doubt about their need 
>to support a content based event notification feature.
>>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.
>It is never too late to improve things. However, as I said on this 
>thread before the requirements for ebXML Registry event notification 
>are based on real world needs and are unlikely to change. How ebXML 
>Registry spec addresses them may evolve over time as the standard 
>evolves and builds upon new open standards in the area of event 
>>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 
>>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.
>The above fits with the classic  definition of registries in the 
>past. ebXML Registry in its original vision fit that description but 
>found it too narrow. It has since evolved to support much broader 
>use cases.
>The role of ebXML Registry in practice is quite broader than a 
>registry of ebXML CPP/A and Core Components as envisioned originally 
>or as a web services registry. It is much more a general purpose 
>content management system.
>It is being used much like a shared database for web service much in 
>the manner that relational databases were used by enterprise 
>applications. Unlike databases though it provides support for 
>arbitrary content and standardized meta data, a loosely coupled 
>federation model with secure access, role based accessed control and 
>HTTP and SOAP interface in a standard API.
>If one believes like I do that:
>"ebXML Registry is to web services what relational databases were to 
>enterprise applications"
>Then I see no reason why a auction objects should not be stored in 
>the registry.
>In my experience with nearly 200 ebXML Registry users of the open 
>source freebXML Registry project only a handful use it for the 
>classic use cases. The vast majority use it as a general purpose 
>Content Management system serving that provides content for web 
>services and portals. For some examples of use cases please see [1].
>[1] freebXML Registry Brohure
>>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?
>>>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 
>>>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.
>>>-------- 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 10:31:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:03 UTC