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

[Matthew MacKenzie <matt@xmlglobal.com>]

Farrukh,

FederationLeader could refer to a role, rather than anything more 
concrete, and our conversations could lead toward discussing how, and 
how dynamically roles are delegated.  We have to be careful here, making 
sure we don't delve too far into the transport layer.  Without due care, 
I can see words like "multicast socket" in our specification!

Possible work item: Glossary.

Regards,

Matt
On Friday, May 17, 2002, at 08:37  AM, Farrukh Najmi wrote:

> Zach,
>
> I think that a JXTA project to track development of this part of the 
> registry spec is a good idea. I would be interested in participating in 
> such an activity. I agree that we can learn much from JXTA and P2P for 
> this federated registries. Can you recommend some JXTA and other P2P 
> material for the team to read?
>
> BTW, shouldn't Registry Agent Access Layer be called Registry Access 
> Agent Layer?
>
> As I try to relate RAAL my own thinking to the model I proposed, it 
> seems that:
>
>     RAAL = FederationLeader + FederationMember
>
> Does that sound right? If not where do you see differences. Please note 
> that in my own thought process I tend to view the world in terms of 
> interfaces and interactions between interfaces.
>
> One thing that I have been unsure of is whether there should be a 
> designated FederationLeader or not. I guess in a true P2P model all 
> members are created equal. But if that were the case then members would 
> have to pony up to additional responsibilities that are only required 
> of a member.
>
> Zachary Alexander wrote:
>
>  Farrukh,          Here are my thoughts off the top of my head.  I 
> haven't spent a lot of time drilling down on the implications.  I have 
> been pulling together information on specific P2P implementations like 
> jxta.  I have also been bouncing around the idea of starting a jxta 
> project to track the development of this part of the registry spec.zack
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> Sent: Friday, May 17, 2002 9:36 AM
> To: regrep-cooperating@lists.oasis-open.org
> Subject: Re: [regrep-cooperating] Kickoff of federated registries work 
> item forV3
>  
> Zach,
>
> Welcome Zack to the TC and cooperating registries team. Thanks for 
> getting engaged already.
>
> Can you clarify the role of the Registry Agent Access layer? Is it on 
> teh client side or registry (server) side.
> Could you draw a picture of the prosed architecture and post. Hand 
> drawn and scanned is fine.
> [Zachary Alexander] I see the Registry Agent Access Layer as an 
> abstraction layer for the registry.  This layer would expose interfaces 
> and management functions that agents could use to integrate with the 
> registry.  The way that I am reading the specs on decentralized 
> applications there are no clients or servers. They use agents. From a 
> formal standpoint, the web browser is an agent.  However , some of the 
> decentralized applications use "rendezvous points" to distribute 
> agents. I see a division of labor between the Registry Agent and the 
> Registry/Repository.  The Registry Agent would implement the services 
> that are required for participation in a given internet community 
> and/or application specific implementation.  The Registry would handle 
> the specific needs of the ebXML family of standards.  Also, there are 
> really interesting things going on in the distributed agent community 
> that could be of use to the ebXML community. I think that this would 
> allow the users to purchase any ebXML compliant Registry and plug 
> applications or internet community into it. 
>
> I will get a drawing out to the list in the next couple of days. I am 
> doing a computer upgrade and my copy of Visio is not compatible. So, I 
> am waiting on software. 
>
> I agree with your observation that client to registry interaction as 
> essentially client/server today. I am assuming
> that there will be no significant change between client/registry 
> interaction with federated registries. The only change would be that:
>
> -The client would need to specify an optional boolean flad on request 
> to indicated wheher the scope of teh request is federated or local.
>
> -the registry would be responsible for returning federated results for 
> a federated scoped query
>
> The main difference in the federated model as I see is that it will 
> introduce peer-to-peer (P2P) interactions between ebXML registries. 
> These P2P interactions could be enabled by the registry implementing 
> the interfaces I proposed (FederationLeader, FederationMember etc.). 
> The implementation of these interfaces would be isolated from the core 
> registry engine in a reasonable implementation. How a registry 
> implements these interfaces would be up to the registry though.
>
> Let me know how your mental model differs from mine.
> [Zachary Alexander] With the addition of the RAAL (Registry Agent 
> Access Layer), the current registry/model could be maintained with only 
> minor RIM modifications.  These modifications could be isolated in an 
> "Experimental section" much like they do with mime-types.  The Agent 
> would be responsible for the heavy lifting. 
>
> It sounds though that we are getting into more interactive discussions 
> and maybe a meeting would be good sometime soon after we get 2.1 specs 
> out (week of June 10th). Until then lets make some progress over email.
>
> PS: I assume that everyone interested should be a member of this email 
> list so no need to CC folks anymore.
>
> --
> Regards,
> Farrukh
>  
>  
>
> 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
>  
>  
>
>
>  
>  
>
> --
> Regards,
> Farrukh
>  
>
>
--
Matthew MacKenzie
XML Global R&D
PGP Key available upon request.