[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep-cooperating] Kickoff of federated registries work itemforV3
Farrukh, I understand where you are coming from better now. Sounds OK for me. I see some issues developing here, such as pluggable protocol support which probably don't belong in this group...even though I really would like to pursue them. -Matt On Friday, May 17, 2002, at 08:59 AM, Farrukh Najmi wrote: > Just to clarify, I am talking about FederationLeader and Federation > meber as > two new interfaces that may optionally be implemented by a registry (in > addition to the required QueryManager and LifeCycleManager interfaces). > For > implementations migrating from V2 to V3, most of the new stuff would be > encapsulated in teh implementation of these two new interfaces. > > While the two interface names can also be used as role names that is > not what > my intented meaning was. I was strictly thinking of the interfaces. The > next > step would be to define operations on these interfaces, which define new > messages that these operations would support. > > Does that seem to bring our thoughts and collective understanding any > closer? > -- > Regards, > Farrukh > > > Matthew MacKenzie wrote: > >> 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. >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC