| 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
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 nowhere. In fact, I have not seen it referenced anywhere outside this community or even the analyst community.
I'm really worried that once again, we're getting distracted and we NEED TO FINISH THE RA!!!!!! Our work has gone one far too long in my opinion. We need to stay focused as a razor.
If you're looking to build out a tool for your registry/repository, then you should leverage the various service metadata information models (IMs) out there. The IM described in JSR 93 (JAXR) is one of the best I've seen. And it supports both UDDI and ebXML standards. I've attached a copy of the original spec. Check out Section 4 and in particular, Fig. 11, which provides a UML class diagram depicting the IM.
Cheers...
- Jeff E.
---------------------------------------------------------------------
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
__________________________________________________ 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
----------------------------------------------------------------------------- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7151 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
Attachment converted: Macintosh HD:smime 634.p7s ( / ) (0033555B)
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
----------------------------------------------------------------------------- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7151 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
|