[regrep-cooperating] Quality of Service

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

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>