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

["Zachary Alexander" <zack2003@ebtdesign.com>]

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