Regarding the first citation from my article, Farrukh notes "the loosely coupled federated model" was finally added in version 2.5, about 18 months after I wrote the article. Regarding the second citation, If I recall correctly there was a good deal of discussion about this and some related points on the ebxml-dev listserv shortly after I posted the article. Farrukh and I probably still disagree in our interpretations of parts of the May, 2001 specification as well as some of the points I made, but I don't think it's worth anyone's time to re-open those discussions. Suffice to say that I am glad to hear that at least the current version of the specification supports a wide range of protocols for interfaces. That is the important point regarding what the specification supports, not what I wrote two years ago. In regard to the third citation about lacking native support for Core Components, I will point out that I was far from alone in raising this concern, it having been voiced by several prominent members of Core Component team. Again, I am glad that the ongoing work has finally addressed what we viewed as a short coming. In the broader context, I ask that Zahra and other readers also consider the update in http://www.rawlinsecconsulting.com/ebXML/ebXML5a.html and not to take the original piece by itself. Further, the article was a point-in-time assessment of the ebXML technical infrastructure and only has value if it is understood as such. Farrukh makes an interesting suggestion, and I am considering writing an "ebXML - Three Years Later" update. If I do I will review my original assessments and note how the specifications and the market have evolved since May 2001. P.S. Farrukh - feel free to repost this reply to the ebxmlrr-tech list if you wish, and BTW - it's "Rawlins" without a 'g'. At 07:12 AM 2/10/2004 -0500, you wrote: >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/msg00010.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 ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The >list archives are at http://lists.ebxml.org/archives/ebxml-dev/ >To subscribe or unsubscribe from this list use the subscription manager: ><http://www.oasis-open.org/mlmanage/> --------------------------------------------------------------- Michael C. Rawlins, Rawlins EC Consulting www.rawlinsecconsulting.com Using XML with Legacy Business Applications (Addison-Wesley, 2003) www.awprofessional.com/titles/0321154940 The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The list archives are at http://lists.ebxml.org/archives/ebxml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://www.oasis-open.org/mlmanage/>
<<attachment: winmail.dat>>