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

Re: WSDL and pub/sub

From: Farrukh Najmi <Farrukh.Najmi@Sun.COM>
Date: Tue, 17 Feb 2004 10:51:22 -0500
To: 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
Message-id: <4032387A.5060807@sun.com>

Rex Brooks wrote:

> 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.

I share your primary concern about conflicting/duplicated spec efforts. 
The first step towards avoiding this is to develope specs in open 
standards bodies and not behind closed doors .

>
> Ciao,
> Rex
>
> 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 
>> notification.
>>
>>>
>>> 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.
>>
>>
>> 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].
>>
>> Thanks.
>>
>> -- 
>> Regards,
>> Farrukh
>>
>> [1] freebXML Registry Brohure
>>
>> http://ebxmlrr.sourceforge.net/presentations/freebXMLRegistryBrochure.pdf 
>>
>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>
>>
>> h
>
>
>


-- 
Regards,
Farrukh
Received on Tuesday, 17 February 2004 10:51:29 GMT

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