Mike Rawlins wrote: > 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. If you read what I wrote in my response I said just what you say above: "The article is out of date (was written /November 26, 2001) ".... Also please note that the Federated Registry features were a planned work item for the phased delivery matrix for ebXML Registry TC since well before Mr. Rawlin's article. It was not some reaction to 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. On above I stated that this was just plain wrong (a mistake) and I stand by it. ebXML Registry specs have been supporting the abstract interface bound to multiple protocols and have never required ebMS. There is not much to debate on this point. It was a mistake when you posted it in Nov 2001. If you have any reason to believe it was correct (or debatable due to some ambiguity) please explain. > 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. We agree now and we agreed in Nov 2001 that CC support in ebXML Registry is important. It was one of the main original reasons for creating the ebXML Registry. And we decided (up front) way back then that CC support did not belong in ebXML Registry specs, and we still believe that CC support does not belong in ebXML Registry specs. We believed then, and we believe now, that the generic features of the registry should handle all use cases of CC and that the best way to describe how to do it is through a Technical Note. That is exactly what we are doing and we are glad that you approve of this. > > 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. I second your thought on writing "ebXML - Three Years Later" update. However, this time would it be possible for you to have the relevant TCs review and offer feedback on your article for accuracy prior to its being published? -- Respectfully, Farrukh Najmi > > 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'. My sincere apologies on that mistake. > > 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/msg00009.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/> > > -- 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/>
<<attachment: winmail.dat>>