Re: [regrep] FW: [Ebxmlrr-tech] Re: ebXML Registry --- can work as distributed registries?

["Chiusano Joseph" <chiusano_joseph@bah.com>]

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