Re: [regrep-cooperating] Federation Protocol Profile

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

Matt,

Good point about the IPR issue (to be logged by issue keeper). We should all
know what the status is before we proceed down that CPP/A path. I will try and
get some clarity on this.

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>

--
Regards,
Farrukh