[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 agree with Danny on this, Ken, I think that it fits into Jeff's component diagram under Policies and Contracts in polices stereotype. I think it should be included in the RA as a category of policy that would have links to specific federations that a given RA may offer as options. This will become quite a bit more obvious once a number of these kinds of federations get established, especially in the emergency management arena where it is a natural fit as a way make trusted networks operational in a clearly understood set of requirements and expectations. I would consider short descriptions of requirements and expectations as annotations, btw. Cheers, Rex At 9:50 PM -0800 11/4/07, Danny Thornton wrote: >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 -- 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]