[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep-cooperating] Federation Protocol Profile
Here is Karl's response to my question: Kathryn: The intent is still that the various modules be implementable separately as well as together. There is no accepted architecture document later than v1 adopted a year ago. </karl> ================================================================= Karl F. Best OASIS - Director, Technical Operations +1 978.667.5115 x206 karl.best@oasis-open.org http://www.oasis-open.org -----Original Message----- From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] Sent: Thursday, May 23, 2002 5:00 AM To: Lisa Carnahan Cc: regrep-cooperating@lists.oasis-open.org; Dale Moberg Subject: Re: [regrep-cooperating] Federation Protocol Profile I like Lisa's suggetsion. That still leaves the issue of IPR. The final word on it is at: http://www.oasis-open.org/committees/ebxml-cppa/documents/ibm_ipr_statement. shtml I am not a lawyer so can someone tell me what the implications are from this statement. -- Regards, Farrukh Lisa Carnahan wrote: > OK. If we don't want to go down the road 'of making a good case' I think > the language that I proposed may suffice. It basically says that ebXML > CPPs are not required, however we have defined their usage (binding...sort > of) and have not defined 'the binding' for any other formally defined CPP. > > --lisa > > At 04:14 PM 5/22/2002 -0700, Matthew MacKenzie wrote: > >Group, > > > >The official word is that specs do have to be independent from one an > >other, but if we can make a really good case that can change. > > > >Regards, > >Matt > > > >On Wednesday, May 22, 2002, at 06:53 AM, Lisa Carnahan wrote: > > > >> > >>Farrukh, > >> > >>Perhaps clarification should also be obtained on whether ebXML specs are > >>still supposed to be independent from each other. I don't have the > >>lastest ebXML architecture document handy. If the requirement for > >>independence still exists, we can make the use of CPP/A informative with > >>a statement saying that 'using CPP/A is not required; however > >>interoperability cannot be guaranteed if other mechanisms are used.' > >>This is similar language to what we used for ebXML messaging. This > >>shouldn't slow you down. > >> > >>Does anyone know that status of the requirement? I hadn't heard that it > >>changed from ebXML V1.0 in May2001. > >> > >>--lisa > >> > >>At 12:23 AM 5/22/2002 -0700, Matthew MacKenzie wrote: > >>>Farrukh, > >>> > >>>I like where CPP/A is going as well, but do you think we should wait > >>>until all of the IPR issues are clarified? I can go either way. > >>> > >>>-Matt > >>>On Monday, May 20, 2002, at 06:14 AM, Farrukh Najmi wrote: > >>> > >>>>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> > >>> > >>> > >>>---------------------------------------------------------------- > >>>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