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