[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
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 DescriptionAt 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,RexKenOn Nov 5, 2007, at 6:04 PM, Danny Thornton wrote:
This is off topic from federations, but JAXR isimplemented for Sun's Service Registry. Sun's ServiceRegistry is one registry we are using for the Feb demothat Rex mentioned. I have that up and going at:http://www.integratedresponseservices.net:6480/soarEverything you can do with JAXR as a client app youcan do through the Registry web console.I am now trying to figure out how our RA meta-modelfits into the ebXML RIM model which is what isreferenced in section 4 of the JAXR document. Ifanyone is interested, here is a link to the 3.0version of the ebXML RIM document:http://docs.oasis-open.org/regrep/v3.0/specs/regrep-rim-3.0-os.pdfThe ebXML Registry Information Model does define afederation object but that is to federate an entireregistry with another registry. I think federation atthis level is too course grained to solve a lot of thecross ownership boundary issues that will be common tothe majority of people who jump into a SOA-ecosystem.There are multiple granularity levels that thefederation problem can be approached from.Federation is an important concept and I wanted to getother input about its placement in relation to our RAService 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 theFederated EnterpriseReference 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) andI saw it go nowhere whenI attended the OASIS Symposium up in San Francisco afew years ago. Therewere briefings from the ebSOA TC folks and, again,it has gone absolutelynowhere. In fact, I have not seen it referencedanywhere outside thiscommunity or even the analyst community.I'm really worried that once again, we're gettingdistracted and we NEED TOFINISH THE RA!!!!!! Our work has gone one far toolong in my opinion. Weneed to stay focused as a razor.If you're looking to build out a tool for yourregistry/repository, then youshould leverage the various service metadatainformation models (IMs) outthere. The IM described in JSR 93 (JAXR) is one ofthe best I've seen. Andit supports both UDDI and ebXML standards. I'veattached a copy of theoriginal spec. Check out Section 4 and inparticular, Fig. 11, whichprovides a UML class diagram depicting the IM.Cheers...- Jeff E.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leavethe OASIS TC thatgenerates this mail. You may a link to this groupand all your TCs in OASISat: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 aroundhttp://mail.yahoo.com---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. You may a link to this group and all your TCs in OASISat:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php-----------------------------------------------------------------------------Ken LaskeyMITRE Corporation, M/S H305 phone: 703-983-79347151 Colshire Drive fax: 703-983-1379McLean 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]