[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep-cooperating] Quality of Service
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC