[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep-cooperating] Federation Protocol Profile
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC