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

[Rex Brooks <rexb@starbourne.com>]

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

I would expect the credentials resource to be the target of the pointer-link contained in a federation element under Policies and Contracts.

Cheers,

Rex

At 8:28 AM -0500 11/5/07, Ken Laskey wrote:

> It would seem (1) the entity being
> described can maintain a resource that lists all its credentials, such
> as federation certificates, and have a pointer in its description to
> the credential resource, and/or (2) a federation can provide a service
> that verifies the entity is part of the federation and the entity
> includes the service invocation in its description.  This should
> handle your registry publisher.  While I hate to even suggest
> this, a set of applicable XML tags could turn into something like a
> WS-Certification.  It might also fit WS-MEX -- I'd have to look
> at that again but my first take was MEX was a mess.
>
> The problem with a specific metadata
> element for federation is I think most of the basic info should
> already be available as other parts of description, and we don't want
> to propagate further redundancy.  That's why I suggest the
> federation metadata is not the information that tells you whether
> something can federate but rather tells you the results, i.e. of what
> federations are you a member.
>
> Ken
>  
> On Nov 5, 2007, at 12:50 AM, 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
>
> -----------------------------------------------------------------------------
> 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 628.p7s (   
> /    ) (00334E88)

-- 

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670