Re: [regrep-cooperating] Kickoff of federated registries work item forV3

[Matthew MacKenzie <matt@xmlglobal.com>]

Zack,

I support the notion of separating the registry services API from the 
transport layer, however, I'm not sure how it would be instantiated on 
something like Gnutella, given that RS requires some sort of RPC or 
document based exchange.  Good software, IMHO, is designed as component 
software.

-Matt

On Friday, May 17, 2002, at 06:12  AM, Zachary Alexander wrote:

> Farrukh,
>  
> I am new to the sub-team and I am trying to get better understanding 
> of  what we are trying to accomplish. Do we want to change the Registry 
> spec to accommodate every potential application architecture?  I think 
> that the current ebXML Reg/Rep architecture is a client-server 
> architecture.  P2P, or what I would call decentralized architectures, 
> are very different.  IMHO, as we change the ebXML Reg/Rep spec to 
> accommodate new and potentially conflicting application architectures 
> the Reg/Rep spec will become very brittle. I think that this  will 
> encourage partial implementations and incompatibilities.I was thinking 
> that maybe we could create a "Registry Agent Access Layer" that would 
> sit between the ebXML Reg/Rep and the Application Architecture.  I was 
> thinking that if I am a registry owner. I think that I would want to be 
> able  to plug the ebXML Reg/Rep into a Gnuella, Juxtanet, web services, 
> .Net, or whatever else the next big internet based application network 
> is without changing my Reg/RepImplementation. 
>  
> Here's short list of potential agents:
>     ebXML Messaging
>     webservices (i.e., WSDL Related Messaging)
>     .Net
>     Gnuella
>     Juxtanet
>     AOL
>     URL
>     Mobile
>     Voice Enabled
>     HA (High Availability)
>     Hashed
>    
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> Sent: Wednesday, May 08, 2002 1:47 PM
> To: regrep-cooperating@lists.oasis-open.org
> Cc: Lim Sangwon; zack2@cris.com
> Subject: [regrep-cooperating] Kickoff of federated registries work item 
> for V3
>
>  
> Folks,
>
> The cooperating registry sub-team is about to begin in earnest on the 
> Federated ebXML Registries proposal for V3. The email discussion on 
> this should be carried out on the regrep-cooperating@lists.oasis-
> open.org mail alias. I am also copying some folks who have expressed 
> interest in joining this sub-team and collaborating on this work item. 
> I ask that all those that wish to participate join the 
> regrep-cooperating@lists.oasis-open.org mailing list using the 
> following web page:
>
>     http://lists.oasis-open.org/ob/adm.pl
>
> Next I would like to establish some context for the work item we are 
> embarking upon.
>
> Use Cases Being Addressed By Work Item
>
> Quite some time ago in this team we defined the following use case for 
> federated registries:
>  
>
> Use Case: Peer-to-Peer Federated Registries
> [Zachary Alexander] I would change this to "Decentralized Federated 
> Registries." Instant Messaging is often considered a P2P application 
> but in many cases the architecture is client-server. 
>
> "A group of ebXML Registries wish to project a unified logical registry
> to their clients. To the client it appears as if there is one registry
> that has the sum total of all the data from all the registries. This
> client experience is the same regardless of which specific registry
> within the federation receives the client request."
>
> I would like to also add the following use cases as target for 
> federated registries:
>
> Use Case: Hierarchically Federated Registries
>
> "Two registries wish to have a hierarchical parent/child relationship 
> such that the child registry represents a subset of data  within the 
> larger parent registry. Changes made to the dataset of the child are 
> eventually reflected in the parent dataset. Queries made to the child 
> registry return results that reflect the dataset of both the parent and 
> the child registries combined."
> [Zachary Alexander] Why would a company do this?  How would this differ 
> from local registry managing the relationship with an exchange. I have 
> always thought that companies would use internal registries to handle 
> maintenance of content on Industry Registries. Is this what you are 
> talking about?
>  
> Or, does this describe a  "virtual hosting arrangement?" Internal 
> registry that is used by employees with an external virtual hosted view 
> that is used by customers and/or partners. 
>  
>  Use Case: Caching of Registry Data
>  
> "A target registry wishes to cache some or or all of  the data of 
> another another source registry that is willing to share its data. The 
> shared dataset is copied from the source registry to the target 
> registry and is visible to queries on the target registry even when the 
> source registry is not available."
>
> Note that this use case is a primitive use case that may be used to 
> implement the first two use cases (p2p and hierarchical federated 
> registries). We may decide that this use case should be removed as a 
> separate use case.
> [Zachary Alexander] 
>
> Add Use Case: Client-server Federated Registries
>
> This would allow a ebXML implementation that is built on a 
> client-server architecture to create a single logical view while 
> distributing the load between different physical hosts and/or 
> geographic locations.  This could require HA functionality and/or 
> simple replication.
>
> Add Use Case: Registry Agent Gateway or Registry Agent Access Layer
>
> Create a Registry Agent Gateway that allow an ebXML Registry to 
> participate in any number of  current or future internet 
> communities/application architectures while isolating the reg/rep 
> implementation from potential incompatibilities between 
> individual internet supported communities/application architectures.
>
> Relevant Links
>
> The following thread discusses some high level thoughts on the subject.
>
>     http://lists.ebxml.org/archives/ebxml-dev/200204/msg00127.html
>
> Next Steps
>
> I propose the following next steps. We will finalize things as a team.
>
> 1.	Begin email discussion on use cases with the proposed 3 use cases 
> as starting points
> 2.	Agree to a time for a kickoff meeting where we indulge in some 
> free flowing brainstorming and discussion
> 3.	Determine team rules, milestones, deliverables and action items
> 4.	Meet periodically over phone to sync on deliverables
>
> Proposed Meeting Time
>
> There is no proposed meeting time until we know who is part of the team 
> and where are they located and what are their preferences. Please send 
> me this information privately if you wish to be part of the team.
>
> Proposed Team Rules
>
> Here are some suggestions:
>
> • 	To be a member of the team you must be willing to contribute. 
> Contributions may involve one or more of the following: attending team 
> meetings, authoring spec content, implementing proof-of-concepts (POC), 
> taking action items, taking meeting notes, tracking issues etc.
> • 	No duplication of effort. Every one executes on an agreed plan and 
> action items.
>
> Proposed Milestones / Deliverables
>
> • 	Team formation - by COB (Close of business, 6pm US Eastern) Wed 
> May 15
> • 	Kickoff meeting - by COB  May 24th
> • 	Agreement on Use Cases - by COB May 24
> • 	First draft of written proposal by COB June 7
> • 	POC implementation begins by COB June 7th (Note that it is the 
> intent of this work item to do a parallel implementation so that the 
> specs are ground firmly in reality and practical experience.)
> • 	POC implementation completed by COB July 26th
> • 	Proposed Final draft to TC by COB August 9th
> • 	Final draft to Editors by COB Aug 30th
>
> Immediate Action Items
>
> • 	Confirm intent to be a team member privately to me by Monday 6pm 
> US Eastern. Please indicate preferences for meeting day/time.  (All 
> interested)
> • 	Join the regrep-cooperating@lists.oasis-open.org mailing list ASAP 
> (All)
> • 	Share on team alias, any proposals that you may have in the works 
> related to federated registries. This is to avoid duplication of 
> effort. (All)
> • 	Discuss on team alias, the proposed use cases via email, as well 
> as sends any other comments on this email (All)
>
> --
> Regards,
> Farrukh
>  
>  
>  
>
>
--
Matthew MacKenzie
XML Global R&D
PGP Key available upon request.