[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?
<Quote> The email was not meant as a slam against Farrukh. The email was sent a process question. </Quote> Please point out what I wrote in my e-mail below that indicated that I thought so, or that I misunderstood the intent and meaning of Farrukh's e-mail. Joe Zachary Alexander wrote: > > 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:chiusano_joseph@bah.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: ebxmlrr-tech-admin@lists.sourceforge.net > > [mailto:ebxmlrr-tech-admin@lists.sourceforge.net] On Behalf Of Farrukh > > Najmi > > Sent: Tuesday, February 10, 2004 7:12 AM > > To: 32zahra@niit.edu.pk > > Cc: ebxmlrr-tech@lists.sourceforge.net; mike@rawlinsecconsulting.com; > > ebxml-dev@lists.ebxml.org > > Subject: [Ebxmlrr-tech] Re: ebXML Registry --- can work as distributed > > registries? > > > > 32zahra@niit.edu.pk 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 > > ebxmlrr-tech@lists.sourceforge.net > > 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. > > 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_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]