Re: [soa-rm-ra] Updated Visual Model for Service Description

[Danny Thornton <danny_thornton2@yahoo.com>]

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