[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep-cooperating] Kickoff of federated registries work itemforV3
Farrukh & Zack, First off, I don't think there is anything wrong with the OO view of the world. For the senior engineer in all of us, OO is probably a good middle ground. Next, while Zack makes a good point about the web services marketing machine trivializing ebXML, the solution proposed is far from ideal for practical reasons. Every protocol adds a lot more spec development and maintenance work, for which there are very few volunteers. On top of that, by making these protocols somewhat normative, other groups such as ebxml-iic will have to develop and maintain a monstrously large set of conformance and interoperability work, and that team also has very few volunteers. The solution, in my opinion, is to fight fire with fire. The web services machine only has an up on ebXML in perception, not technology. What we have to do is work on improving the facilities within the web services space for supporting ebXML, such as improving WSDL with an ebXML binding. By doing things such as adding a web services interface to ebXML Registry, we are in fact marginalizing ebXML Messaging, albeit in a subtle way. I know for a fact that there is a HUGE amount of interest in ebXML Messaging among large (and rich) companies who thing vanilla SOAP is a toy, because I am partially attached to my company's ebXML Messaging product team, and interact with a seemingly endless flow of very deep technical questions from these companies. ebXML Registry has to support the other ebXML technologies first and foremost, so that the ebXML institution keeps the lead in large enterprise. That said, let's start in on federated registries. This is an extremely useful discussion, but it seems to be tangential to the task at hand. Regards, Matt ps> Are either of you in Barcelona this week? If so, maybe we can meet up. On Saturday, May 18, 2002, at 05:13 AM, Farrukh Najmi wrote: > 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> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC