OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: ebXML Registry --- can work as distributed registries?

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
to take the original piece by itself.  Further, the article was a 
point-in-time assessment of the ebXML technical infrastructure and only
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 
>>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
>>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
>This has *NEVER* been true.
>ebXML Registry has never required ebXML Messaging.
>The registry interface is defined in abstract UML and then three
>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
>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.
>>I think it unlikely that there will be very many other widely used
>>implementations. Probability of achieving critical mass: .3
>ebXML Registry by design is content agnostic. We deliberately did not
>Core Components, UBL and the kitchen sink in our information model.
>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
>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.
>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: 

Michael C. Rawlins, Rawlins EC Consulting
Using XML with Legacy Business Applications (Addison-Wesley, 2003)

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: 

<<attachment: winmail.dat>>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]