Re: [regrep-cooperating] Federation Protocol Profile

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

After reading it several times my lay opinion is that IBM will grant anyone who asks
in writing the right to use the patentable aspects of CPP/A as long as they give
reciprocal license to IBM to use (any? all?) of its patents. The last part is not
clear to me and could be an issue to many. Does anyone else have any better
interpretation.

Farrukh Najmi wrote:

> I like Lisa's suggetsion. That still leaves the issue of IPR. The final word on it
> is at:
>
> http://www.oasis-open.org/committees/ebxml-cppa/documents/ibm_ipr_statement.shtml
>
> I am not a lawyer so can someone tell me what the implications are from this
> statement.
>
> --
> Regards,
> Farrukh
>
> Lisa Carnahan wrote:
>
> > OK.  If we don't want to go down the road 'of making a good case' I think
> > the language that I proposed may suffice.  It basically says that ebXML
> > CPPs are not required, however we have defined their usage (binding...sort
> > of) and have not defined 'the binding' for any other formally defined CPP.
> >
> > --lisa
> >
> > At 04:14 PM 5/22/2002 -0700, Matthew MacKenzie wrote:
> > >Group,
> > >
> > >The official word is that specs do have to be independent from one an
> > >other, but if we can make a really good case that can change.
> > >
> > >Regards,
> > >Matt
> > >
> > >On Wednesday, May 22, 2002, at 06:53  AM, Lisa Carnahan wrote:
> > >
> > >>
> > >>Farrukh,
> > >>
> > >>Perhaps clarification should also be obtained on whether ebXML specs are
> > >>still supposed to be independent from each other.  I don't have the
> > >>lastest ebXML architecture document handy.  If the requirement for
> > >>independence still exists, we can make the use of CPP/A informative with
> > >>a statement saying that 'using CPP/A is not required; however
> > >>interoperability cannot be guaranteed if other mechanisms are used.'
> > >>This is similar language to what we used for ebXML messaging.  This
> > >>shouldn't slow you down.
> > >>
> > >>Does anyone know that status of the requirement?  I hadn't heard that it
> > >>changed from ebXML V1.0 in May2001.
> > >>
> > >>--lisa
> > >>
> > >>At 12:23 AM 5/22/2002 -0700, Matthew MacKenzie wrote:
> > >>>Farrukh,
> > >>>
> > >>>I like where CPP/A is going as well, but do you think we should wait
> > >>>until all of the IPR issues are clarified?  I can go either way.
> > >>>
> > >>>-Matt
> > >>>On Monday, May 20, 2002, at 06:14  AM, Farrukh Najmi wrote:
> > >>>
> > >>>>Team,
> > >>>>
> > >>>>Again I am trying to tease apart the conversation into separate more
> > >>>>focused
> > >>>>threads.
> > >>>>
> > >>>>Zach you have mentioned Federation Protocol Profile a few times. Do you
> > >>>>see need
> > >>>>for a CPA between FederationMember and FederationLeader. Since the
> > >>>>CPP/A specs
> > >>>>are not finalized, is it safe to have a dependency on them? I very much
> > >>>>like and
> > >>>>support the work of the CPP/A TC. They are reaching a level of
> > >>>>stability and
> > >>>>maturity that may make this the right time to build upon their work.
> > >>>>
> > >>>>What do others think? Normative dependency on CPP/A or not for V3? Note
> > >>>>that
> > >>>>this is a broader issue for registry-client interface as well. I sense from
> > >>>>Matt's and Nikola's comments that the answer is Yes.
> > >>>>
> > >>>>--
> > >>>>Regards,
> > >>>>Farrukh
> > >>>>
> > >>>>
> > >>>>
> > >>>>Zachary Alexander wrote:
> > >>>>
> > >>>>>Farrukh,
> > >>>>>
> > >>>>>I think these are a good start.  We could get a lot more granular in a FPP
> > >>>>>(Federation Protocol Profile) and support spot markets for "web
> > >>>>>Services" in
> > >>>>>the future. Have you heard of a internet community called Jtrix at
> > >>>>>(http://www.jtrix.org)?  There is a write up in the May issue of
> > >>>>>JavaWorld.
> > >>>>>They have a very interesting take on expanding the definition of "web
> > >>>>>services."
> > >>>>>
> > >>>>>zack
> > >>>>>
> > >>>>>-----Original Message-----
> > >>>>>From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> > >>>>>Sent: Monday, May 20, 2002 7:34 AM
> > >>>>>To: regrep-cooperating@lists.oasis-open.org
> > >>>>>Subject: [regrep-cooperating] Quality of Service
> > >>>>>
> > >>>>>Zach,
> > >>>>>
> > >>>>>Please note that I am splitting the conversation into multiple threads as
> > >>>>>appropriate so that we can have mofr efocused discussions.
> > >>>>>
> > >>>>>I assume by QoS you mean things like:
> > >>>>>
> > >>>>>-Availability guarantees: How often a registry is up or not to fulfill
> > >>>>>federated
> > >>>>>requests
> > >>>>>-Deliver guarantees: Of updates from one FederationMember to another
> > >>>>>
> > >>>>>What else can we think of that is a QoS issue?
> > >>>>>
> > >>>>>I agree that these QoS issues would have to be included in the
> > >>>>>agreement to
> > >>>>>become a FederationMember. Each federation may have its own QoS
> > >>>>>requirements.
> > >>>>>Should these requirements be described as Policy objects in the initial
> > >>>>>infomodel figure I had published?
> > >>>>>
> > >>>>>--
> > >>>>>Regards,
> > >>>>>Farrukh
> > >>>>>
> > >>>>>Zachary Alexander wrote:
> > >>>>>
> > >>>>>>Farrukh,
> > >>>>>>
> > >>>>>>There is no disconnect. I am in complete agreement with everything
> > >>>>>>you are
> > >>>>>>saying.  What do you think about QoS (Quality of Service)?  I think that
> > >>>>>QoS
> > >>>>>>functions could play a prominent role in Registry Federation.  The
> > >>>>>>need to
> > >>>>>>provide strong SLA support doesn't really exist in a non-Federated
> > >>>>>>environment because you are not sharing control of Registry
> > >>>>>>Resources. The
> > >>>>>>RAAM (Regsitry Agent Access Manager) could be a good place to define and
> > >>>>>>monitor Service Level Agreements (SLA)information. The RA (Registry
> > >>>>>Agents)
> > >>>>>>could pass community health and welfare information up and down the stack
> > >>>>>to
> > >>>>>>the RAAM. This could be its main role.
> > >>>>>>
> > >>>>>>zack
> > >>>>>>
> > >>>>>>-----Original Message-----
> > >>>>>>From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> > >>>>>>Sent: Saturday, May 18, 2002 8:14 AM
> > >>>>>>To: zack2@cris.com
> > >>>>>>Cc: Matthew MacKenzie; regrep-cooperating@lists.oasis-open.org
> > >>>>>>Subject: Re: [regrep-cooperating] Kickoff of federated registries work
> > >>>>>>itemforV3
> > >>>>>>
> > >>>>>>Zach,
> > >>>>>>
> > >>>>>>I think this is an excellent discussion to get our collective
> > >>>>>understanding
> > >>>>>>synched and start with a common base.
> > >>>>>>
> > >>>>>>+1 on the concern about web service bent trivializing ebXML. I am not a
> > >>>>>big
> > >>>>>>fan
> > >>>>>>of the web service hype. While it was good marketing to use the term,
> > >>>>>>I am
> > >>>>>>not
> > >>>>>>the least bit of the opinion that basic web services stack is a cure for
> > >>>>>>aids,
> > >>>>>>world peace and hunger.
> > >>>>>>
> > >>>>>>As Matt can attest to (private joke ;-) ), if the registry specs are
> > >>>>>guilty
> > >>>>>>of
> > >>>>>>any bias or bent, it is that they are very OO centric. The governing
> > >>>>>>principal
> > >>>>>>has historically been that the registry is defined in terms of a set of
> > >>>>>>abstract
> > >>>>>>UML interfaces (RegistryService, QueryManager, LifeCycleManager,
> > >>>>>>RegistryClient). These abstract interfaces may be described in multiple
> > >>>>>ways
> > >>>>>>(e.g. CPP/BPS, WSDL). We chose WSDL only because CPP/A was changng too
> > >>>>>>rapidly
> > >>>>>>then. We expect to have CPP/A descripton to follow. The main thing is
> > >>>>>>that
> > >>>>>>they
> > >>>>>>can be described in some XML form as abstract service interfaces and can
> > >>>>>be
> > >>>>>>also
> > >>>>>>be described in some XML form as concrete service interfaces in specific
> > >>>>>>bindings. One notable point is that each interface is separated from
> > >>>>>others
> > >>>>>>and
> > >>>>>>can be implemented independently. For example, we could have 2 different
> > >>>>>>vendors
> > >>>>>>cooperate to build LifeCycleManager and QueryManager and still expect
> > >>>>>things
> > >>>>>>to
> > >>>>>>work.
> > >>>>>>
> > >>>>>>If we are in agreement that the above OO principals are a good thing then
> > >>>>>I
> > >>>>>>view
> > >>>>>>the RAAL as a new name for what we have traditionally called
> > >>>>>RegistryService
> > >>>>>>interface (the principal interface from which you can get to the other
> > >>>>>more
> > >>>>>>task/role oriented interfaces such as QueryManager, LifeCycleManager).
> > >>>>>>
> > >>>>>>> From my perspective we are in agreement on the need to separate the
> > >>>>>>registry
> > >>>>>>access interface(s) from the registry implementation details. We are also
> > >>>>>in
> > >>>>>>agreement on the need to separate federation related interfaces from the
> > >>>>>>current
> > >>>>>>interfaces for a non-federated registry. However, I get the impression
> > >>>>>that
> > >>>>>>you
> > >>>>>>think that the current design is violating this (agreed upon) sound
> > >>>>>>architectural principal of separation of interfaces. I am not sure I
> > >>>>>>understand
> > >>>>>>where our disconnect is. Maybe it is that you think in terms of
> > >>>>>abstraction
> > >>>>>>layers while I think in terms of abstract interfaces. If that is the main
> > >>>>>>difference then I suggest that we first identify the interfaces and then
> > >>>>>map
> > >>>>>>the
> > >>>>>>interfaces to layers in a layered architecture.
> > >>>>>>
> > >>>>>>What do you and Matt think?
> > >>>>>>
> > >>>>>>--
> > >>>>>>Regards,
> > >>>>>>Farrukh
> > >>>>>>
> > >>>>>>Zachary Alexander wrote:
> > >>>>>>
> > >>>>>>>Farrukh and Matt,
> > >>>>>>>
> > >>>>>>>My concern is that the Registry Spec seems to be bundled with a
> > >>>>>>webservices
> > >>>>>>>interface and tied to a webservices business model. Not all applications
> > >>>>>>are
> > >>>>>>>webservices and not all application architectures are client-server.
> > >>>>>This
> > >>>>>>>could very easily affect adoption of ebXML. IMHO, the connection between
> > >>>>>>>webservices, which has broad vender support, and ebXML trivializes
> > >>>>>ebXML.
> > >>>>>>I
> > >>>>>>>have read webservices articles that have basically said "Why not take
> > >>>>>your
> > >>>>>>>webservices straight." There are a number of different Internet related
> > >>>>>>>standards projects that are underway that could benefit the ebXML
> > >>>>>>community.
> > >>>>>>>If nothing else these other internet communities could act as second
> > >>>>>>source
> > >>>>>>>opportunities for ebXML. My hope is by formalizing access to the ebXML
> > >>>>>>>Registry by other internet communities/application architectures it will
> > >>>>>>>broaden the appeal of the ebXML family of standards.
> > >>>>>>>
> > >>>>>>>The term "Registry Agent Access Layer" is an OSI model metaphor.
> > >>>>>>>The
> > >>>>>>lowest
> > >>>>>>>level of the OSI model is the "Media Access Layer."  The rationale is
> > >>>>>that
> > >>>>>>>the ebXML Registry should not have to know which internet
> > >>>>>>>community/application architecture the registry is being plugged into
> > >>>>>>>because it is being handled by its "Media Access Layer." I think that
> > >>>>>>>defining this layer will take some work. But, I think that the
> > >>>>>>>implementation of a Registry Agent Access Manager that implements a
> > >>>>>>Registry
> > >>>>>>>Agent Access Layer would go a long way to unbundle the ebXML Registry
> > >>>>>and
> > >>>>>>>the ebXML family of standards.  This would also open up the ebXML family
> > >>>>>>of
> > >>>>>>>standards to new business models.
> > >>>>>>>
> > >>>>>>>zack
> > >>>>>>>
> > >>>>>>>-----Original Message-----
> > >>>>>>>From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
> > >>>>>>>Sent: Friday, May 17, 2002 2:38 PM
> > >>>>>>>To: Farrukh Najmi
> > >>>>>>>Cc: regrep-cooperating@lists.oasis-open.org
> > >>>>>>>Subject: Re: [regrep-cooperating] Kickoff of federated registries work
> > >>>>>>>itemforV3
> > >>>>>>>
> > >>>>>>>Farrukh,
> > >>>>>>>
> > >>>>>>>I understand where you are coming from better now.  Sounds OK for me.  I
> > >>>>>>>see some issues developing here, such as pluggable protocol support
> > >>>>>>>which probably don't belong in this group...even though I really would
> > >>>>>>>like to pursue them.
> > >>>>>>>
> > >>>>>>>-Matt
> > >>>>>>>
> > >>>>>>>On Friday, May 17, 2002, at 08:59  AM, Farrukh Najmi wrote:
> > >>>>>>>
> > >>>>>>>>Just to clarify, I am talking about FederationLeader and Federation
> > >>>>>>>>meber as
> > >>>>>>>>two new interfaces that may optionally be implemented by a registry
> > >>>>>(in
> > >>>>>>>>addition to the required QueryManager and LifeCycleManager
> > >>>>>interfaces).
> > >>>>>>>>For
> > >>>>>>>>implementations migrating from V2 to V3, most of the new stuff would
> > >>>>>be
> > >>>>>>>>encapsulated in teh implementation of these two new interfaces.
> > >>>>>>>>
> > >>>>>>>>While the two interface names can also be used as role names that is
> > >>>>>>>>not what
> > >>>>>>>>my intented meaning was. I was strictly thinking of the interfaces.
> > >>>>>The
> > >>>>>>>>next
> > >>>>>>>>step would be to define operations on these interfaces, which define
> > >>>>>new
> > >>>>>>>>messages that these operations would support.
> > >>>>>>>>
> > >>>>>>>>Does that seem to bring our thoughts and collective understanding any
> > >>>>>>>>closer?
> > >>>>>>>>--
> > >>>>>>>>Regards,
> > >>>>>>>>Farrukh
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>Matthew MacKenzie wrote:
> > >>>>>>>>
> > >>>>>>>>>Farrukh,
> > >>>>>>>>>
> > >>>>>>>>>FederationLeader could refer to a role, rather than anything more
> > >>>>>>>>>concrete, and our conversations could lead toward discussing how, and
> > >>>>>>>>>how dynamically roles are delegated.  We have to be careful here,
> > >>>>>>>>>making
> > >>>>>>>>>sure we don't delve too far into the transport layer.  Without due
> > >>>>>>>>>care,
> > >>>>>>>>>I can see words like "multicast socket" in our specification!
> > >>>>>>>>>
> > >>>>>>>>>Possible work item: Glossary.
> > >>>>>>>>>
> > >>>>>>>>>Regards,
> > >>>>>>>>>
> > >>>>>>>>>Matt
> > >>>>>>>>>On Friday, May 17, 2002, at 08:37  AM, Farrukh Najmi wrote:
> > >>>>>>>>>
> > >>>>>>>>>>Zach,
> > >>>>>>>>>>
> > >>>>>>>>>>I think that a JXTA project to track development of this part of the
> > >>>>>>>>>>registry spec is a good idea. I would be interested in participating
> > >>>>>>>>>>in
> > >>>>>>>>>>such an activity. I agree that we can learn much from JXTA and P2P
> > >>>>>for
> > >>>>>>>>>>this federated registries. Can you recommend some JXTA and other P2P
> > >>>>>>>>>>material for the team to read?
> > >>>>>>>>>>
> > >>>>>>>>>>BTW, shouldn't Registry Agent Access Layer be called Registry Access
> > >>>>>>>>>>Agent Layer?
> > >>>>>>>>>>
> > >>>>>>>>>>As I try to relate RAAL my own thinking to the model I proposed, it
> > >>>>>>>>>>seems that:
> > >>>>>>>>>>
> > >>>>>>>>>>     RAAL = FederationLeader + FederationMember
> > >>>>>>>>>>
> > >>>>>>>>>>Does that sound right? If not where do you see differences. Please
> > >>>>>>>>>>note
> > >>>>>>>>>>that in my own thought process I tend to view the world in terms of
> > >>>>>>>>>>interfaces and interactions between interfaces.
> > >>>>>>>>>>
> > >>>>>>>>>>One thing that I have been unsure of is whether there should be a
> > >>>>>>>>>>designated FederationLeader or not. I guess in a true P2P model all
> > >>>>>>>>>>members are created equal. But if that were the case then members
> > >>>>>>>>>>would
> > >>>>>>>>>>have to pony up to additional responsibilities that are only
> > >>>>>required
> > >>>>>>>>>>of a member.
> > >>>>>>>>>>
> > >>>>>>>>>>Zachary Alexander wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>  Farrukh,          Here are my thoughts off the top of my head.  I
> > >>>>>>>>>>haven't spent a lot of time drilling down on the implications.  I
> > >>>>>have
> > >>>>>>>>>>been pulling together information on specific P2P implementations
> > >>>>>like
> > >>>>>>>>>>jxta.  I have also been bouncing around the idea of starting a jxta
> > >>>>>>>>>>project to track the development of this part of the registry
> > >>>>>>>>>>spec.zack
> > >>>>>>>>>>
> > >>>>>>>>>>-----Original Message-----
> > >>>>>>>>>>From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> > >>>>>>>>>>Sent: Friday, May 17, 2002 9:36 AM
> > >>>>>>>>>>To: regrep-cooperating@lists.oasis-open.org
> > >>>>>>>>>>Subject: Re: [regrep-cooperating] Kickoff of federated registries
> > >>>>>work
> > >>>>>>>>>>item forV3
> > >>>>>>>>>>
> > >>>>>>>>>>Zach,
> > >>>>>>>>>>
> > >>>>>>>>>>Welcome Zack to the TC and cooperating registries team. Thanks for
> > >>>>>>>>>>getting engaged already.
> > >>>>>>>>>>
> > >>>>>>>>>>Can you clarify the role of the Registry Agent Access layer? Is it
> > >>>>>on
> > >>>>>>>>>>teh client side or registry (server) side.
> > >>>>>>>>>>Could you draw a picture of the prosed architecture and post. Hand
> > >>>>>>>>>>drawn and scanned is fine.
> > >>>>>>>>>>[Zachary Alexander] I see the Registry Agent Access Layer as an
> > >>>>>>>>>>abstraction layer for the registry.  This layer would expose
> > >>>>>>>>>>interfaces
> > >>>>>>>>>>and management functions that agents could use to integrate with the
> > >>>>>>>>>>registry.  The way that I am reading the specs on decentralized
> > >>>>>>>>>>applications there are no clients or servers. They use agents. From
> > >>>>>a
> > >>>>>>>>>>formal standpoint, the web browser is an agent.  However , some of
> > >>>>>the
> > >>>>>>>>>>decentralized applications use "rendezvous points" to distribute
> > >>>>>>>>>>agents. I see a division of labor between the Registry Agent and the
> > >>>>>>>>>>Registry/Repository.  The Registry Agent would implement the
> > >>>>>services
> > >>>>>>>>>>that are required for participation in a given internet community
> > >>>>>>>>>>and/or application specific implementation.  The Registry would
> > >>>>>handle
> > >>>>>>>>>>the specific needs of the ebXML family of standards.  Also, there
> > >>>>>are
> > >>>>>>>>>>really interesting things going on in the distributed agent
> > >>>>>community
> > >>>>>>>>>>that could be of use to the ebXML community. I think that this would
> > >>>>>>>>>>allow the users to purchase any ebXML compliant Registry and plug
> > >>>>>>>>>>applications or internet community into it.
> > >>>>>>>>>>
> > >>>>>>>>>>I will get a drawing out to the list in the next couple of days. I
> > >>>>>am
> > >>>>>>>>>>doing a computer upgrade and my copy of Visio is not compatible. So,
> > >>>>>I
> > >>>>>>>>>>am waiting on software.
> > >>>>>>>>>>
> > >>>>>>>>>>I agree with your observation that client to registry interaction as
> > >>>>>>>>>>essentially client/server today. I am assuming
> > >>>>>>>>>>that there will be no significant change between client/registry
> > >>>>>>>>>>interaction with federated registries. The only change would be
> > >>>>>that:
> > >>>>>>>>>>
> > >>>>>>>>>>-The client would need to specify an optional boolean flad on
> > >>>>>request
> > >>>>>>>>>>to indicated wheher the scope of teh request is federated or local.
> > >>>>>>>>>>
> > >>>>>>>>>>-the registry would be responsible for returning federated results
> > >>>>>for
> > >>>>>>>>>>a federated scoped query
> > >>>>>>>>>>
> > >>>>>>>>>>The main difference in the federated model as I see is that it will
> > >>>>>>>>>>introduce peer-to-peer (P2P) interactions between ebXML registries.
> > >>>>>>>>>>These P2P interactions could be enabled by the registry implementing
> > >>>>>>>>>>the interfaces I proposed (FederationLeader, FederationMember etc.).
> > >>>>>>>>>>The implementation of these interfaces would be isolated from the
> > >>>>>core
> > >>>>>>>>>>registry engine in a reasonable implementation. How a registry
> > >>>>>>>>>>implements these interfaces would be up to the registry though.
> > >>>>>>>>>>
> > >>>>>>>>>>Let me know how your mental model differs from mine.
> > >>>>>>>>>>[Zachary Alexander] With the addition of the RAAL (Registry Agent
> > >>>>>>>>>>Access Layer), the current registry/model could be maintained with
> > >>>>>>>>>>only
> > >>>>>>>>>>minor RIM modifications.  These modifications could be isolated in
> > >>>>>an
> > >>>>>>>>>>"Experimental section" much like they do with mime-types.  The Agent
> > >>>>>>>>>>would be responsible for the heavy lifting.
> > >>>>>>>>>>
> > >>>>>>>>>>It sounds though that we are getting into more interactive
> > >>>>>discussions
> > >>>>>>>>>>and maybe a meeting would be good sometime soon after we get 2.1
> > >>>>>specs
> > >>>>>>>>>>out (week of June 10th). Until then lets make some progress over
> > >>>>>>>>>>email.
> > >>>>>>>>>>
> > >>>>>>>>>>PS: I assume that everyone interested should be a member of this
> > >>>>>email
> > >>>>>>>>>>list so no need to CC folks anymore.
> > >>>>>>>>>>
> > >>>>>>>>>>--
> > >>>>>>>>>>Regards,
> > >>>>>>>>>>Farrukh
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>Zachary Alexander wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>Farrukh,I am new to the sub-team and I am trying to get better
> > >>>>>>>>>>understanding of  what we are trying to accomplish.Do we want to
> > >>>>>>>>>>change
> > >>>>>>>>>>the Registry spec to accommodate every potential application
> > >>>>>>>>>>architecture?  I think that the current ebXML Reg/Rep architecture
> > >>>>>>>>>>is a
> > >>>>>>>>>>client-server architecture.  P2P, or what I would call decentralized
> > >>>>>>>>>>architectures, are very different.  IMHO, as we change the ebXML
> > >>>>>>>>>>Reg/Rep spec to accommodate new and potentially conflicting
> > >>>>>>>>>>application
> > >>>>>>>>>>architectures the Reg/Rep spec will become very brittle. I think
> > >>>>>that
> > >>>>>>>>>>this  will encourage partial implementations and incompatibilities.I
> > >>>>>>>>>>was thinking that maybe we could create a "Registry Agent Access
> > >>>>>>>>>>Layer"
> > >>>>>>>>>>that would sit between the ebXML Reg/Rep and the Application
> > >>>>>>>>>>Architecture. I was thinking that if I am a registry owner. I think
> > >>>>>>>>>>that I would want to be able  to plug the ebXML Reg/Rep into a
> > >>>>>>>>>>Gnuella,
> > >>>>>>>>>>Juxtanet, web services, .Net, or whatever else the next big internet
> > >>>>>>>>>>based application network is without changing my
> > >>>>>>>>>>Reg/RepImplementation. Here's short list of potential agents:
> > >>>>>ebXML
> > >>>>>>>>>>Messaging    webservices (i.e., WSDL Related Messaging)    .Net
> > >>>>>>>>>>Gnuella    Juxtanet    AOL    URL    Mobile    Voice Enabled
> > >>>>>>>>>>HA
> > >>>>>>>>>>(High Availability)    Hashed
> > >>>>>>>>>>
> > >>>>>>>>>>-----Original Message-----
> > >>>>>>>>>>From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> > >>>>>>>>>>Sent: Wednesday, May 08, 2002 1:47 PM
> > >>>>>>>>>>To: regrep-cooperating@lists.oasis-open.org
> > >>>>>>>>>>Cc: Lim Sangwon; zack2@cris.com
> > >>>>>>>>>>Subject: [regrep-cooperating] Kickoff of federated registries work
> > >>>>>>>>>>item
> > >>>>>>>>>>for V3
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>Folks,
> > >>>>>>>>>>
> > >>>>>>>>>>The cooperating registry sub-team is about to begin in earnest on
> > >>>>>the
> > >>>>>>>>>>Federated ebXML Registries proposal for V3. The email discussion on
> > >>>>>>>>>>this should be carried out on the regrep-
> > >>>>>>>>>>cooperating@lists.oasis-
> > >>>>>>>>>>open.org mail alias. I am also copying some folks who have expressed
> > >>>>>>>>>>interest in joining this sub-team and collaborating on this work
> > >>>>>item.
> > >>>>>>>>>>I ask that all those that wish to participate join the
> > >>>>>>>>>>regrep-cooperating@lists.oasis-open.org mailing list using the
> > >>>>>>>>>>following web page:
> > >>>>>>>>>>
> > >>>>>>>>>>     http://lists.oasis-open.org/ob/adm.pl
> > >>>>>>>>>>
> > >>>>>>>>>>Next I would like to establish some context for the work item we are
> > >>>>>>>>>>embarking upon.
> > >>>>>>>>>>
> > >>>>>>>>>>Use Cases Being Addressed By Work Item
> > >>>>>>>>>>
> > >>>>>>>>>>Quite some time ago in this team we defined the following use case
> > >>>>>for
> > >>>>>>>>>>federated registries:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>Use Case: Peer-to-Peer Federated Registries
> > >>>>>>>>>>[Zachary Alexander] I would change this to "Decentralized Federated
> > >>>>>>>>>>Registries." Instant Messaging is often considered a P2P application
> > >>>>>>>>>>but in many cases the architecture is client-server.
> > >>>>>>>>>>
> > >>>>>>>>>>"A group of ebXML Registries wish to project a unified logical
> > >>>>>>>>>>registry
> > >>>>>>>>>>to their clients. To the client it appears as if there is one
> > >>>>>registry
> > >>>>>>>>>>that has the sum total of all the data from all the registries. This
> > >>>>>>>>>>client experience is the same regardless of which specific registry
> > >>>>>>>>>>within the federation receives the client request."
> > >>>>>>>>>>
> > >>>>>>>>>>I would like to also add the following use cases as target for
> > >>>>>>>>>>federated registries:
> > >>>>>>>>>>
> > >>>>>>>>>>Use Case: Hierarchically Federated Registries
> > >>>>>>>>>>
> > >>>>>>>>>>"Two registries wish to have a hierarchical parent/child
> > >>>>>relationship
> > >>>>>>>>>>such that the child registry represents a subset of data
> > >>>>>>>>>>within the
> > >>>>>>>>>>larger parent registry. Changes made to the dataset of the child are
> > >>>>>>>>>>eventually reflected in the parent dataset. Queries made to the
> > >>>>>child
> > >>>>>>>>>>registry return results that reflect the dataset of both the parent
> > >>>>>>>>>>and
> > >>>>>>>>>>the child registries combined."
> > >>>>>>>>>>[Zachary Alexander] Why would a company do this?  How would this
> > >>>>>>>>>>differ
> > >>>>>>>>>>from local registry managing the relationship with an exchange. I
> > >>>>>have
> > >>>>>>>>>>always thought that companies would use internal registries to
> > >>>>>handle
> > >>>>>>>>>>maintenance of content on Industry Registries. Is this what you are
> > >>>>>>>>>>talking about?Or, does this describe a  "virtual hosting
> > >>>>>arrangement?"
> > >>>>>>>>>>Internal registry that is used by employees with an external virtual
> > >>>>>>>>>>hosted view that is used by customers and/or partners. Use Case:
> > >>>>>>>>>>Caching of Registry Data
> > >>>>>>>>>>"A target registry wishes to cache some or or all of  the data of
> > >>>>>>>>>>another another source registry that is willing to share its data.
> > >>>>>The
> > >>>>>>>>>>shared dataset is copied from the source registry to the target
> > >>>>>>>>>>registry and is visible to queries on the target registry even when
> > >>>>>>>>>>the
> > >>>>>>>>>>source registry is not available."
> > >>>>>>>>>>
> > >>>>>>>>>>Note that this use case is a primitive use case that may be used to
> > >>>>>>>>>>implement the first two use cases (p2p and hierarchical federated
> > >>>>>>>>>>registries). We may decide that this use case should be removed as a
> > >>>>>>>>>>separate use case.
> > >>>>>>>>>>[Zachary Alexander]
> > >>>>>>>>>>
> > >>>>>>>>>>Add Use Case: Client-server Federated Registries
> > >>>>>>>>>>
> > >>>>>>>>>>This would allow a ebXML implementation that is built on a
> > >>>>>>>>>>client-server architecture to create a single logical view while
> > >>>>>>>>>>distributing the load between different physical hosts and/or
> > >>>>>>>>>>geographic locations.  This could require HA functionality and/or
> > >>>>>>>>>>simple replication.
> > >>>>>>>>>>
> > >>>>>>>>>>Add Use Case: Registry Agent Gateway or Registry Agent Access Layer
> > >>>>>>>>>>
> > >>>>>>>>>>Create a Registry Agent Gateway that allow an ebXML Registry to
> > >>>>>>>>>>participate in any number of  current or future internet
> > >>>>>>>>>>communities/application architectures while isolating the reg/rep
> > >>>>>>>>>>implementation from potential incompatibilities between individual
> > >>>>>>>>>>internet supported communities/application architectures.
> > >>>>>>>>>>
> > >>>>>>>>>>Relevant Links
> > >>>>>>>>>>
> > >>>>>>>>>>The following thread discusses some high level thoughts on the
> > >>>>>>>>>>subject.
> > >>>>>>>>>>
> > >>>>>>>>>>     http://lists.ebxml.org/archives/ebxml-
> > >>>>>>>>>>dev/200204/msg00127.html
> > >>>>>>>>>>
> > >>>>>>>>>>Next Steps
> > >>>>>>>>>>
> > >>>>>>>>>>I propose the following next steps. We will finalize things as a
> > >>>>>team.
> > >>>>>>>>>>
> > >>>>>>>>>>1.    Begin email discussion on use cases with the proposed 3 use
> > >>>>>>>>>>cases
> > >>>>>>>>>>as starting points
> > >>>>>>>>>>2.    Agree to a time for a kickoff meeting where we indulge in some
> > >>>>>>>>>>free flowing brainstorming and discussion
> > >>>>>>>>>>3.    Determine team rules, milestones, deliverables and action
> > >>>>>items
> > >>>>>>>>>>4.    Meet periodically over phone to sync on deliverables
> > >>>>>>>>>>
> > >>>>>>>>>>Proposed Meeting Time
> > >>>>>>>>>>
> > >>>>>>>>>>There is no proposed meeting time until we know who is part of the
> > >>>>>>>>>>team
> > >>>>>>>>>>and where are they located and what are their preferences. Please
> > >>>>>send
> > >>>>>>>>>>me this information privately if you wish to be part of the team.
> > >>>>>>>>>>
> > >>>>>>>>>>Proposed Team Rules
> > >>>>>>>>>>
> > >>>>>>>>>>Here are some suggestions:
> > >>>>>>>>>>
> > >>>>>>>>>>•     To be a member of the team you must be willing to contribute.
> > >>>>>>>>>>Contributions may involve one or more of the following: attending
> > >>>>>team
> > >>>>>>>>>>meetings, authoring spec content, implementing proof-of-concepts
> > >>>>>>>>>>(POC),
> > >>>>>>>>>>taking action items, taking meeting notes, tracking issues etc.
> > >>>>>>>>>>•     No duplication of effort. Every one executes on an agreed plan
> > >>>>>>>>>>and
> > >>>>>>>>>>action items.
> > >>>>>>>>>>
> > >>>>>>>>>>Proposed Milestones / Deliverables
> > >>>>>>>>>>
> > >>>>>>>>>>•     Team formation - by COB (Close of business, 6pm US Eastern)
> > >>>>>Wed
> > >>>>>>>>>>May 15
> > >>>>>>>>>>•     Kickoff meeting - by COB  May 24th
> > >>>>>>>>>>•     Agreement on Use Cases - by COB May 24
> > >>>>>>>>>>•     First draft of written proposal by COB June 7
> > >>>>>>>>>>•     POC implementation begins by COB June 7th (Note that it is the
> > >>>>>>>>>>intent of this work item to do a parallel implementation so that the
> > >>>>>>>>>>specs are ground firmly in reality and practical experience.)
> > >>>>>>>>>>•     POC implementation completed by COB July 26th
> > >>>>>>>>>>•     Proposed Final draft to TC by COB August 9th
> > >>>>>>>>>>•     Final draft to Editors by COB Aug 30th
> > >>>>>>>>>>
> > >>>>>>>>>>Immediate Action Items
> > >>>>>>>>>>
> > >>>>>>>>>>•     Confirm intent to be a team member privately to me by Monday
> > >>>>>6pm
> > >>>>>>>>>>US Eastern. Please indicate preferences for meeting day/time.
> > >>>>>>>>>>(All
> > >>>>>>>>>>interested)
> > >>>>>>>>>>•     Join the regrep-cooperating@lists.oasis-open.org mailing list
> > >>>>>>>>>>ASAP
> > >>>>>>>>>>(All)
> > >>>>>>>>>>•     Share on team alias, any proposals that you may have in the
> > >>>>>>>>>>works
> > >>>>>>>>>>related to federated registries. This is to avoid duplication of
> > >>>>>>>>>>effort. (All)
> > >>>>>>>>>>•     Discuss on team alias, the proposed use cases via email, as
> > >>>>>well
> > >>>>>>>>>>as sends any other comments on this email (All)
> > >>>>>>>>>>
> > >>>>>>>>>>--
> > >>>>>>>>>>Regards,
> > >>>>>>>>>>Farrukh
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>--
> > >>>>>>>>>>Regards,
> > >>>>>>>>>>Farrukh
> > >>>>>>>>>>
> > >--
> > >Matthew MacKenzie
> > >XML Global R&D
> > >PGP Key available upon request.
> > >>>>>>>>>
> > >>>>>>>>>----------------------------------------------------------------
> > >>>>>>>>>To subscribe or unsubscribe from this elist use the subscription
> > >>>>>>>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>----------------------------------------------------------------
> > >>>>>>>>To subscribe or unsubscribe from this elist use the subscription
> > >>>>>>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >>>>>>>
> > >>>>>>>----------------------------------------------------------------
> > >>>>>>>To subscribe or unsubscribe from this elist use the subscription
> > >>>>>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >>>>>
> > >>>>>----------------------------------------------------------------
> > >>>>>To subscribe or unsubscribe from this elist use the subscription
> > >>>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >>>>>
> > >>>>>----------------------------------------------------------------
> > >>>>>To subscribe or unsubscribe from this elist use the subscription
> > >>>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>----------------------------------------------------------------
> > >>>>To subscribe or unsubscribe from this elist use the subscription
> > >>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >>>
> > >>>
> > >>>----------------------------------------------------------------
> > >>>To subscribe or unsubscribe from this elist use the subscription
> > >>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >
> > >
> > >----------------------------------------------------------------
> > >To subscribe or unsubscribe from this elist use the subscription
> > >manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Regards,
Farrukh