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 asdistributed registries?


I have no doubt both Zach and Joe mean well.

Zach just wants to know what proces we have to fix the inaccurate info 
out there
and how to prevent it in the future.

For the first we should just ask Mike Rawlings nice...

For the second we just need to be vigilant and evangelize vigorously

-- 
Regards,
Farrukh



Chiusano Joseph wrote:

><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.
>>    
>>
>
>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]