[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] FW: [Ebxmlrr-tech] Re: ebXML Registry --- can work as distributed registries?
Joe, The email was not meant as a slam against Farrukh. The email was sent a process question. What is the process for responding to misrepresentation? What is the escalation procedure? What is the disposition of questions/issues once they have been answered? What are the means for determining how widely held a misconception is? What triggers the process for determining how widely held a given misconception is? I am new to the team and I am asking an honest question. Zachary Alexander The IT Investment Architect ebTDesign LLC, (703) 283-4325 http://www.ebTDesign.com | http://www.p2pspeaker.com http://www.p2peconomy.com | http://www.itinvestmentvehicle.com -----Original Message----- From: Chiusano Joseph [mailto:email@example.com] Sent: Tuesday, February 10, 2004 11:32 AM To: Zachary Alexander Cc: 'ebXML Regrep (ebXML Regrep)' Subject: Re: [regrep] FW: [Ebxmlrr-tech] Re: ebXML Registry --- can work as distributed registries? I personally am fine with Farrukh's excellent response, and believe that it is simply a misunderstanding on the part of the poster that arose from the article being over 2 years old. Joe Zachary Alexander wrote: > > Team, > > I saw this response from Farrukh to couple of registry related concerns. > Should there be a more coordinated response to this email from the > Regrep team? What is the proper venue? Is this email an isolated > instance of misrepresentation or a more widely held misunderstanding? > What are the capabilities available to us determine how spread the > issues are? Should the issues raised here be added to the ebXML Registry > FAQ? Is it appropriate to list the issues raised here as concerns to be > addressed and/or reinforced in the Semantic Content Management work? > > Zachary Alexander > The IT Investment Architect > ebTDesign LLC, (703) 283-4325 > http://www.ebTDesign.com | http://www.p2pspeaker.com > http://www.p2peconomy.com | http://www.itinvestmentvehicle.com > > -----Original Message----- > From: firstname.lastname@example.org > [mailto:email@example.com] On Behalf Of Farrukh > Najmi > Sent: Tuesday, February 10, 2004 7:12 AM > To: firstname.lastname@example.org > Cc: email@example.com; firstname.lastname@example.org; > email@example.com > Subject: [Ebxmlrr-tech] Re: ebXML Registry --- can work as distributed > registries? > > firstname.lastname@example.org wrote: > > >Hi folks, > > in the process of defending that ebxml is better for distributed > >registries i found these two > > > >very controversial paragraphs..... > >Now i am confused! which one is true! > > > > > >refernce: http://www.rawlinsecconsulting.com/ebXML/ebXML5.html > > > > > Dear Zahra, > > Thanks you for bringing this article to my attention. > The article is out of date (was written /November 26, 2001) /as well as > incorrect. > > >Registry Services - The registry services specification faces several > >obstacles to widespread adoption. The main obstacle is that the > >specification was not developed completely in terms supporting a > >distributed, networked registry. Without this key feature, the value > added > >by the specification is difficult to justify when considering it > against > >less capable registry approaches. > > > > > ebXML Registry has had a sophisticated loosely coupled federated model > since June 2003 when version 2.5 was approved by the TC. > > >Another handicap is that all messages exchanged with an ebXML compliant > >registry must be formatted in an ebXML MHS envelope. This in itself > >requires a somewhat heavy weight client, such as a Java application or > >applet, rather than a lightweight client like a browser with Java > support > >disabled. > > > > > This has *NEVER* been true. > > ebXML Registry has never required ebXML Messaging. > The registry interface is defined in abstract UML and then three > normative bindings to HTTP, SOAP > and ebXML Messaging are provided. Only HTTP (REST) bindings are > required. One or the > other between SOAP and ebXML Messaging are also required. freebXML > Registry implements > an HTTP and SOAP interface and does not currently have an ebXML > Messaging interface. It > is still fully spec compliant. > > The SOAP interface is defined by a normative WSDL and thus the registry > is itself a web service. > It currently has no dependency on any other part of the ebXML platform > either in spec or in the freebXML > Registry implementation. > > >Another failing is that, even though the ebXML registry offers a very > >flexible mechanism for organizing registry objects into categories, it > >doesn't offer native support for perhaps the most important objects > that > >need to be stored, ebXML compliant core components and business > >information entities. It is near certain that the current OASIS > registry > >will be made ebXML compliant and that > > > >CEFACT will eventually bring on-line an ebXML compliant registry. > However, > >I think it unlikely that there will be very many other widely used > >implementations. Probability of achieving critical mass: .3 > > > >reference: > http://lists.ebxml.org/archives/ebxml-dev/200311/msg00014.html > > > > > ebXML Registry by design is content agnostic. We deliberately did not > throw > Core Components, UBL and the kitchen sink in our information model. > Instead > we provide a pluggable architecture which allows publish, management and > > discovery of > any type of content in a content specific way using plugins for: > > -content validation > > -content cataloging > > -content-based ad hoc queries > > -content-based event notification > > As for Core Components we have an entire sub-committee call Core > Component in Registry Information Model > with ebXML Registry TC that is defining a Technical Note that describes > how to publish, manage and discover > Core Components within an ebXML Registry taking advantage of all the > pluggable features of the registry. > > >"That said, ebXML Registry architecture is flexible. One can operate a > >giant, monolithic, centralized > >ebXML Registry using the current specs. Or one can operate many smaller > >ebXML Registries that can federate > >together in a loosely coupled manner. The effect to the end user is the > >same. A federation of registries look like > >one giant monolithic registry as far as discovery is concerned. > However, > >a federation scales better and has better distributed > >owebrship and management." > > regards > > Zahra Zahid. > > > > > > > > > I am copying Mr. Rawlings in the hope that he will publish an update to > his web site so that the above inaccuracies can > be corrected. I am also copying ebxml-dev so I can relieve people from > some of the above misconceptions regarding > ebXML Registry standard. > > -- > Regards, > Farrukh > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > ebxmlrr-tech mailing list > email@example.com > https://lists.sourceforge.net/lists/listinfo/ebxmlrr-tech > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgr oup.php.