[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep-cooperating] Federation Protocol Profile
Farrukh, I bring up the need for Federation Protocol Profile as place holder. You have a better handle on where the CPP/A than I have. If the CPP/A family of spec aren't ready that's okay. I envision Registry Federations as a normal part of doing business on the internet. I think there should be Core Components devoted to it. We can define Registry Federation in v3.0 however we like and call it a "simple" Federation Protocol Profile. I don't even know that it has to be dynamic in this first release. zack -----Original Message----- From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] Sent: Monday, May 20, 2002 9:14 AM Cc: regrep-cooperating@lists.oasis-open.org Subject: [regrep-cooperating] Federation Protocol Profile Team, Again I am trying to tease apart the conversation into separate more focused threads. Zach you have mentioned Federation Protocol Profile a few times. Do you see need for a CPA between FederationMember and FederationLeader. Since the CPP/A specs are not finalized, is it safe to have a dependency on them? I very much like and support the work of the CPP/A TC. They are reaching a level of stability and maturity that may make this the right time to build upon their work. What do others think? Normative dependency on CPP/A or not for V3? Note that this is a broader issue for registry-client interface as well. I sense from Matt's and Nikola's comments that the answer is Yes. -- Regards, Farrukh Zachary Alexander wrote: > Farrukh, > > I think these are a good start. We could get a lot more granular in a FPP > (Federation Protocol Profile) and support spot markets for "web Services" in > the future. Have you heard of a internet community called Jtrix at > (http://www.jtrix.org)? There is a write up in the May issue of JavaWorld. > They have a very interesting take on expanding the definition of "web > services." > > zack > > -----Original Message----- > From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] > Sent: Monday, May 20, 2002 7:34 AM > To: regrep-cooperating@lists.oasis-open.org > Subject: [regrep-cooperating] Quality of Service > > Zach, > > Please note that I am splitting the conversation into multiple threads as > appropriate so that we can have mofr efocused discussions. > > I assume by QoS you mean things like: > > -Availability guarantees: How often a registry is up or not to fulfill > federated > requests > -Deliver guarantees: Of updates from one FederationMember to another > > What else can we think of that is a QoS issue? > > I agree that these QoS issues would have to be included in the agreement to > become a FederationMember. Each federation may have its own QoS > requirements. > Should these requirements be described as Policy objects in the initial > infomodel figure I had published? > > -- > Regards, > Farrukh > > Zachary Alexander wrote: > > > Farrukh, > > > > There is no disconnect. I am in complete agreement with everything you are > > saying. What do you think about QoS (Quality of Service)? I think that > QoS > > functions could play a prominent role in Registry Federation. The need to > > provide strong SLA support doesn't really exist in a non-Federated > > environment because you are not sharing control of Registry Resources. The > > RAAM (Regsitry Agent Access Manager) could be a good place to define and > > monitor Service Level Agreements (SLA)information. The RA (Registry > Agents) > > could pass community health and welfare information up and down the stack > to > > the RAAM. This could be its main role. > > > > zack > > > > -----Original Message----- > > From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] > > Sent: Saturday, May 18, 2002 8:14 AM > > To: zack2@cris.com > > Cc: Matthew MacKenzie; regrep-cooperating@lists.oasis-open.org > > Subject: Re: [regrep-cooperating] Kickoff of federated registries work > > itemforV3 > > > > Zach, > > > > I think this is an excellent discussion to get our collective > understanding > > synched and start with a common base. > > > > +1 on the concern about web service bent trivializing ebXML. I am not a > big > > fan > > of the web service hype. While it was good marketing to use the term, I am > > not > > the least bit of the opinion that basic web services stack is a cure for > > aids, > > world peace and hunger. > > > > As Matt can attest to (private joke ;-) ), if the registry specs are > guilty > > of > > any bias or bent, it is that they are very OO centric. The governing > > principal > > has historically been that the registry is defined in terms of a set of > > abstract > > UML interfaces (RegistryService, QueryManager, LifeCycleManager, > > RegistryClient). These abstract interfaces may be described in multiple > ways > > (e.g. CPP/BPS, WSDL). We chose WSDL only because CPP/A was changng too > > rapidly > > then. We expect to have CPP/A descripton to follow. The main thing is that > > they > > can be described in some XML form as abstract service interfaces and can > be > > also > > be described in some XML form as concrete service interfaces in specific > > bindings. One notable point is that each interface is separated from > others > > and > > can be implemented independently. For example, we could have 2 different > > vendors > > cooperate to build LifeCycleManager and QueryManager and still expect > things > > to > > work. > > > > If we are in agreement that the above OO principals are a good thing then > I > > view > > the RAAL as a new name for what we have traditionally called > RegistryService > > interface (the principal interface from which you can get to the other > more > > task/role oriented interfaces such as QueryManager, LifeCycleManager). > > > > >From my perspective we are in agreement on the need to separate the > > registry > > access interface(s) from the registry implementation details. We are also > in > > agreement on the need to separate federation related interfaces from the > > current > > interfaces for a non-federated registry. However, I get the impression > that > > you > > think that the current design is violating this (agreed upon) sound > > architectural principal of separation of interfaces. I am not sure I > > understand > > where our disconnect is. Maybe it is that you think in terms of > abstraction > > layers while I think in terms of abstract interfaces. If that is the main > > difference then I suggest that we first identify the interfaces and then > map > > the > > interfaces to layers in a layered architecture. > > > > What do you and Matt think? > > > > -- > > Regards, > > Farrukh > > > > Zachary Alexander wrote: > > > > > 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> > > ---------------------------------------------------------------- > 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