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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


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


<Quote>
The email was not meant as a slam against Farrukh.  The email was sent a
process question. 
</Quote>

Please point out what I wrote in my e-mail below that indicated that I
thought so, or that I misunderstood the intent and meaning of Farrukh's
e-mail.

Joe

Zachary Alexander wrote:
> 
> Joe,
> 
> The email was not meant as a slam against Farrukh.  The email was sent a
> process question. What is the process for responding to
> misrepresentation?  What is the escalation procedure? What is the
> disposition of questions/issues once they have been answered? What are
> the means for determining how widely held a misconception is? What
> triggers the process for determining how widely held a given
> misconception is?
> 
> I am new to the team and I am asking an honest question.
> 
> 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: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Tuesday, February 10, 2004 11:32 AM
> To: Zachary Alexander
> Cc: 'ebXML Regrep (ebXML Regrep)'
> Subject: Re: [regrep] FW: [Ebxmlrr-tech] Re: ebXML Registry --- can work
> as distributed registries?
> 
> I personally am fine with Farrukh's excellent response, and believe that
> it is simply a misunderstanding on the part of the poster that arose
> from the article being over 2 years old.
> 
> Joe
> 
> Zachary Alexander wrote:
> >
> > 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
> >
> > To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgr
> oup.php.
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.


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