Gee, try to respond in a conciliatory tone and move on, and people still get pissed off - sometimes you just can't win. I do, however, want to correct one mis-perceived implication of my reply. Farrukh says: "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." Farrukh seems to be saying that I'm trying to claim some kind of cause and affect between my article and the Federated Registry features. I find this ludicrous, and this kind of leaping to conclusions reinforces for me why I don't find it worthwhile to further discuss this article on this listserv. The archives are there (I hope) for anyone who wants to resurrect a two year old discussion. (BTW - a distributed registry was a requirement in the initial drafts of the ebXML Requirements Spec, which came well before the phased delivery matrix for the ebXML Registry TC.) I will ask for review of my "ebXML - Three Years Later" update if it seems appropriate and helpful. If people don't have a chance to review it before posting, I'm sure they will have ample opportunity and forum to say whatever they want about it after it's posted. Cheers, Mike At 02:34 PM 2/10/2004 -0500, Farrukh Najmi wrote: >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/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 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 --------------------------------------------------------------- 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>>