[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
With this description a federation looks like a (ordered) collection of Service Description data-stores/repositories and certificate - as a data-store identity token or user access token for particular data store. Is this understanding correct? Michael Poulin 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 -----Original Message----- From: Danny Thornton [mailto:danny_thornton2@yahoo.com] Sent: 05 November 2007 05:51 To: Ken Laskey Cc: soa-rm-ra@lists.oasis-open.org Subject: Re: [soa-rm-ra] Updated Visual Model for Service Description I am thinking in terms of federation at the granularity of general description only, no finer than that for the moment. The following statements are from the implementaton side of things. As part of the general description, a user can select federations they want the description to belong to. The selection of federations are controlled through certificate associations. Everyone who wants to add a description to the ebXML/UDDI registry either has or is issued a certificate. I have not worked through the implementation details yet but it is something along those lines. I think the Service Description needs to identify meta-data that allows it to be governed in social structures as described in Section 3.4.6, Governance and Social Structures. What I am suggesting is that federations is a description meta-data element that is a tie to section 3.4.6. Danny --- Ken Laskey <klaskey@mitre.org> wrote: > Danny, > > I'll need to read the link on annotations. > > As for federations, we have the same situations as > with a lot of the > action discussion in that the details of how it's > done don't belong > in description, only the description or a link to > information of the > result. > > I'm not sure detailing federations really belongs in > the RA because > it seems a business-specific process and > requirements. Now some of > the description would likely indicate whether some > resource was > appropriate for some federation and the result of > federation > membership might be included in description. > > Do you have something more specific in mind for > federations? > > Ken > > On Nov 4, 2007, at 8:58 PM, Danny Thornton wrote: > > > The first steps into the use of Descriptions in a > > SOA-based ecosystem give rise to the problem of > how > > groups (federations) are formed. I would like to > see > > a direct representation of the ability to > participate > > in groups in the description. To my knowledge, > the > > most common terminlogy for this in the industry > right > > now is federations. > > > > I would also like to hear other opinions on the > > subject. > > > > There is also an alternate approach to annotations > > that follows an extension objects pattern: > > > > > http://72.14.253.104/search?q=cache:YwbrrSremIIJ:www.ccs.neu.edu/ > > > > research/demeter/adaptive-patterns/visitor-usage/papers/plop96/ > > > extension-objects-gamma.ps+patterns+object > > +extension&hl=en&ct=clnk&cd=3&gl=us > > > > Danny > > > > --- Ken Laskey <klaskey@mitre.org> wrote: > > > >> While admitting it forms something of a > catch-all, I > >> thought of > >> certifications (and I guess federation info) > would > >> fall under > >> annotations. Those governing a federation would > >> prescribe what they > >> felt was adequate federation description and the > >> description of an > >> entity would point to it. > >> > >> So, should annotations point to likely types such > as > >> certifications, > >> use/federation, contracts here(?), ... ? > >> > >> Ken > >> > >> On Nov 4, 2007, at 11:09 AM, Danny Thornton > wrote: > >> > >>> The diagram is helpful, I am working on a web > app > >> that > >>> will allow entry of this information and then > >> update > >>> an ebXML/UDDI registry. > >>> > >>> In doing this, one of the things I think we are > >>> missing in the general description is a hook for > >>> federations. Is this description part of one or > >> more > >>> federations? For the implementation I am > putting > >>> together, each description has a certificate > >>> associated with it and can be used for things > like > >>> forming groups (federations), description > >> revocation, > >>> etc. > >>> > >>> Danny > >>> > >>> > >>> --- Ken Laskey <klaskey@mitre.org> wrote: > >>> > >>>> Good first pass. Yes, we have always talked > >> about > >>>> the service > >>>> description as an artifact, so this makes > sense. > >>>> > >>>> I still need to sort out the writing to make > sure > >>>> all the salient > >>>> points end up some place. The diagram will > guide > >>>> the writing and > >>>> will itself evolve as the writing tightens up. > >>>> > >>>> Ken > >>>> > >>>> On Nov 3, 2007, at 12:31 PM, Jeffrey A. Estefan > >>>> wrote: > >>>> > >>>>> Ken, > >>>>> > >>>>> I've created a component diagram for the > Service > >>>> Description > >>>>> artifact. This is a candidate visual model to > >>>> replace the class > >>>>> diagram in the Service Description section > that > >>>> you are updating. > >>>>> It's not perfect, but it's a pretty good > start. > >> I > >>>> think it's more > >>>>> appropriate to show the Service Description as > >> an > >>>> artifact that is > >>>>> made up of (or links to) a number of > supporting > >>>> artifacts that > >>>>> capture the meta level aspects of SOA-based > >>>> systems, particularly, > >>>>> for the Reference Architecture. > >>>>> > >>>>> Here's a direct link to a PNG copy of the > visual > >>>> model on our Kavi > >>>>> collection at: > >>>>> > >>>>> > >>>> > >>> > >> > > > http://www.oasis-open.org/apps/org/workgroup/soa-rm-ra/download.php/ > >>>> > >>>>> 25982/Service_Description_Model.png > >>>>> > >>>>> I've added a couple of notes to the visual > >> model. > >>>> These are > >>>>> intended to be our working notes and > ultimately > >>>> should be removed > >>>>> from the final version of the visual model. > >>>>> > >>>>> Cheers... > >>>>> > >>>>> - Jeff E. > >>>>> > >>>> > >>>> > >>> > >> > > > ---------------------------------------------------------------------- > >> > >>> -- > >>>> > >>>> ----- > >>>> Ken Laskey > >>>> MITRE Corporation, M/S H305 phone: > >> 703-983-7934 > >>>> 7151 Colshire Drive > fax: > >>>> 703-983-1379 > >>>> McLean VA 22102-7508 > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > === 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]