Re: WSDL and pub/sub

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

Received on Tuesday, 17 February 2004 10:04:31 UTC