[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
The only sense in which we (as a committee) should be concerned about federation is via any issues it may throw up for sharing information and other resources across ownership boundaries. I think that you would not normally expect to see a single service 'spread' across an ownership boundary: at the worst you would have two cooperating services; each owned by the different owners. As far as information is concerned, we could look at concepts such as 'authoritative' vs non-authoritative information; in support of federation. However, I would argue, that unless federation does throw up fundamental issues we should not deal with it directly. However, we should address any f.i.'s it does throw up if it affects the RA. Clear as mud no doubt Frank On Nov 5, 2007, at 5:58 PM, Ken Laskey wrote: > But I still don't know what it means to federate a single service! > > On Nov 5, 2007, at 7:53 PM, Rex Brooks wrote: > >> 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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]