OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[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 respect to separating contracts from policies, this was the first thing that I thought of when I saw Jeff's artifact diagram.  I think contracts may be closer to Danny's certification as a capture of what arrangements are put in place (i.e. how something is used) rather than the basics of what something is.  Recall that there may be unanticipated uses that have little to do with what is initially felt necessary for description.

Ken

On Nov 5, 2007, at 4:38 AM, Poulin, Michael wrote:

Accidentally, I am also working on a small tool for creating Service Description and Service Contract via UI to put into a repository/registry.
 
Danny, in this context, could you, please, elaborate a little bit on what certificates are and why they are useful for federation (of what?), i.e. for forming groups (of what?). I have included only references to other Descriptions (if this is relevant to the federation)...
 
Other items I added are business execution contexts and technical execution contexts.
 
What I excluded (with regard to the diagram)  is Contracts while Policies are in there. I think that Contracts as private entities may not be used to describe a public entity. (though we know some countries that widely use this model... :-(   ). [This was one of the reasons why I said before: "Policies may not refer to Contracts while opposite is true"]
 
- Michael

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: Ken Laskey [mailto:klaskey@mitre.org]
Sent: 04 November 2007 18:38
To: Danny Thornton
Cc: Jeffrey A. Estefan; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Updated Visual Model for Service Description

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:




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







__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7151 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508





-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7151 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508




smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]