[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] Updated Visual Model for Service Description
I have two comments here. 1.Certainly, XACML can help to "handle cross ownership boundary issues" via access control rules but there has to be a query mechanism capable of requesting access to particular federated registry. XACML cannot do this. We have to have a cross-registry mechanism for this. 2. Regarding "In a SOA-ecosystem federation can be handled at the registry level" - agree; "... description level, or even at the description element level" - disagree unless we are saying that one Service Description may refer to another description of the same service in the same or federated/another registry. I think it is too complex from governance, management and administrative perspectives. - Michael -----Original Message----- From: Danny Thornton [mailto:danny_thornton2@yahoo.com] Sent: 06 November 2007 15:05 To: Ken Laskey; Poulin, Michael Cc: Rex Brooks; Danny Thornton; Jeffrey A. Estefan; soa-rm-ra@lists.oasis-open.org Subject: Re: [soa-rm-ra] Updated Visual Model for Service Description As Ken has pointed out, the ability to define interactions across multiple ownership boundaries quickly becomes a complex problem. For Sun's Service Registry, I will probably handle cross ownership boundary issues through access control policies defined in XACML. This is what is already supported by the registry. To state the implementation details in a way that relates to the RA - In a SOA-ecosystem federation can be handled at the registry level, description level, or even at the description element level. The process of federating descriptions may be separate from the creation of the description itself, a security administration activity for example. Danny --- Ken Laskey <klaskey@mitre.org> wrote: > The problem with propagating federated queries is if > a query to > federation 1 is propagated to federation 2 and then > propagated from > federation 2 to federation 3, then if a member of 3 > is also a member > of 1, you are in an infinite loop. The ebXML 2.5 > draft had this > problem and they handled it in 3.0 by saying you > could only propagate > one level. I noted there are other simple > strategies one could use > and was told that in the absence of compelling use > and need, this > restriction was sufficient for the first pass. > > Ken > > On Nov 6, 2007, at 8:57 AM, Poulin, Michael wrote: > > > I have one example from old CORBA world - there > was/is so-called > > CORBA Object Trading Service ( a prototype of > modern Web Services > > and UDDI ) and it had a concept of federated > service repositories. > > > > When one looked up for the service, it was > possible to specify the > > "depth of federation" where the service may be > searched by the ORB > > (Broker), i.e. how many close neighbouring > repositories (federated) > > should be searched through to find the service > with specified > > characteristics. > > > > This may be a meaning of "federate a single > service"... > > > > - Michael > > Important: Fidelity Investments International > (Reg. No.1448245), > > Fidelity Investment Services Limited (Reg. No. > 2016555), Fidelity > > Pensions Management (Reg. No. 2015142) and > Financial Administration > > Services Limited (Reg. No. 1629709, a Fidelity > Group company) are > > all registered in England and Wales, are > authorised and regulated > > in the UK by the Financial Services Authority and > have their > > registered offices at Oakhill House, 130 Tonbridge > Road, > > Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 > 361144. Fidelity > > only gives information on products and does not > give investment > > advice to private clients based on individual > circumstances. Any > > comments or statements made are not necessarily > those of Fidelity. > > The information transmitted is intended only for > the person or > > entity to which it is addressed and may contain > confidential and/or > > privileged material. If you received this in > error, please contact > > the sender and delete the material from any > computer. All e-mails > > sent from or to Fidelity may be subject to our > monitoring > > procedures. Direct link to Fidelity's website - > http://www.fidelity- > > international.com/world/index.html > > > > > > From: Rex Brooks [mailto:rexb@starbourne.com] > > Sent: 06 November 2007 00:54 > > To: Ken Laskey; Danny Thornton > > Cc: Jeffrey A. Estefan; > soa-rm-ra@lists.oasis-open.org > > Subject: Re: [soa-rm-ra] Updated Visual Model for > Service Description > > > > At 7:35 PM -0500 11/5/07, Ken Laskey wrote: > >> So what would it mean to federate a single > service. Isn't that > >> just being authorized and then using the service? > >> > >> Now federating registries is usually federating > queries across > >> registries, and there are tons of things involved > that I would say > >> are outside the scope of the RA. If you haven't > seen the > >> Discovery Service Reference Architecture from the > IC SOA (and now > >> joint with DoD) work, it has some real > interesting aspects and > >> some others that gloss over fundamental > questions. But that is > >> for other discussions. > > > > I will be interesting to see what happens. I think > we'll be > > federating registries as well as services, so both > types will need > > to be handled. Federating services seems the more > straightforward > > unless the federated registries operate as a VPN. > Also for other > > discussions. > > > > Cheers, > > Rex > > > >> Ken > >> > >> On Nov 5, 2007, at 6:04 PM, Danny Thornton wrote: > >> > >>> This is off topic from federations, but JAXR is > >>> implemented for Sun's Service Registry. Sun's > Service > >>> Registry is one registry we are using for the > Feb demo > >>> that Rex mentioned. I have that up and going > at: > >>> > >>> > http://www.integratedresponseservices.net:6480/soar > >>> > >>> Everything you can do with JAXR as a client app > you > >>> can do through the Registry web console. > >>> > >>> I am now trying to figure out how our RA > meta-model > >>> fits into the ebXML RIM model which is what is > >>> referenced in section 4 of the JAXR document. > If > >>> anyone is interested, here is a link to the 3.0 > >>> version of the ebXML RIM document: > >>> > >>> > http://docs.oasis-open.org/regrep/v3.0/specs/regrep-rim-3.0-os.pdf > >>> > >>> The ebXML Registry Information Model does define > a > >>> federation object but that is to federate an > entire > >>> registry with another registry. I think > federation at > >>> this level is too course grained to solve a lot > of the > >>> cross ownership boundary issues that will be > common to > >>> the majority of people who jump into a > SOA-ecosystem. > >>> There are multiple granularity levels that the > >>> federation problem can be approached from. > >>> > >>> Federation is an important concept and I wanted > to get > >>> other input about its placement in relation to > our RA > >>> Service Description. > >>> > >>> Danny > >>> > >>> --- "Jeffrey A. Estefan" > >>> <jeffrey.a.estefan@jpl.nasa.gov> wrote: > >>> > >>>> Danny, > >>>> > >>>> Where are you going with this federation > business??? > >>>> > >>>> Are you proposing something along the lines of > the > >>>> Federated Enterprise > >>>> Reference Architecture (FERA) model? > >>>> > >>>> > >>> > http://xml.coverpages.org/SemantionSOA-Runtime200509.pdf > >>>> > >>>> (See Section 3.0) > >>>> > >>>> There was a big play in the ebXML world on this > >>>> (see, e.g., > >>>> http://www.ebxmlsoft.com/papers/ebxml-fera.pdf) > and > >>>> I saw it go nowhere when > >>>> I attended the OASIS Symposium up in San > Francisco a > >>>> few years ago. There > >>>> were briefings from the ebSOA TC folks and, > again, > >>>> it has gone absolutely > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]