[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 and Matt, My concern is that the Registry Spec seems to be bundled with a webservices interface and tied to a webservices business model. Not all applications are webservices and not all application architectures are client-server. This could very easily affect adoption of ebXML. IMHO, the connection between webservices, which has broad vender support, and ebXML trivializes ebXML. I have read webservices articles that have basically said "Why not take your webservices straight." There are a number of different Internet related standards projects that are underway that could benefit the ebXML community. If nothing else these other internet communities could act as second source opportunities for ebXML. My hope is by formalizing access to the ebXML Registry by other internet communities/application architectures it will broaden the appeal of the ebXML family of standards. The term "Registry Agent Access Layer" is an OSI model metaphor. The lowest level of the OSI model is the "Media Access Layer." The rationale is that the ebXML Registry should not have to know which internet community/application architecture the registry is being plugged into because it is being handled by its "Media Access Layer." I think that defining this layer will take some work. But, I think that the implementation of a Registry Agent Access Manager that implements a Registry Agent Access Layer would go a long way to unbundle the ebXML Registry and the ebXML family of standards. This would also open up the ebXML family of standards to new business models. zack -----Original Message----- From: Matthew MacKenzie [mailto:matt@xmlglobal.com] Sent: Friday, May 17, 2002 2:38 PM To: Farrukh Najmi Cc: regrep-cooperating@lists.oasis-open.org 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> ---------------------------------------------------------------- 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