[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
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: 05 November 2007 14:11
To: Ken Laskey; Poulin, Michael
Cc: Danny Thornton; Jeffrey A. Estefan; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Updated Visual Model for Service DescriptionIf we separate polices and contracts we are a train wreck waiting to happen. They need to be in such close association that it is, in practical terms, impossible to create either without direct reference to the other and where it is referenced in the other. I can see Murphy hiding behind the curtains in the wings of the stage here gleefully rubbing his dirty little hands together, saying, "Oh please, please, please, puh-lease do this!"Unfortunately the best I can do is promise to vote against it.Cheers,RexAt 8:32 AM -0500 11/5/07, Ken Laskey wrote: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.KenOn 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"]- MichaelImportant: 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 DescriptionWhile 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(?), ... ?KenOn Nov 4, 2007, at 11:09 AM, Danny Thornton wrote:
The diagram is helpful, I am working on a web app thatwill allow entry of this information and then updatean ebXML/UDDI registry.In doing this, one of the things I think we aremissing in the general description is a hook forfederations. Is this description part of one or morefederations? For the implementation I am puttingtogether, each description has a certificateassociated with it and can be used for things likeforming groups (federations), description revocation,etc.Danny--- Ken Laskey <klaskey@mitre.org> wrote:
Good first pass. Yes, we have always talked aboutthe servicedescription as an artifact, so this makes sense.I still need to sort out the writing to make sureall the salientpoints end up some place. The diagram will guidethe writing andwill itself evolve as the writing tightens up.KenOn Nov 3, 2007, at 12:31 PM, Jeffrey A. Estefanwrote:
Ken,I've created a component diagram for the ServiceDescription
artifact. This is a candidate visual model toreplace the class
diagram in the Service Description section thatyou are updating.
It's not perfect, but it's a pretty good start. Ithink it's more
appropriate to show the Service Description as anartifact that is
made up of (or links to) a number of supportingartifacts that
capture the meta level aspects of SOA-basedsystems, particularly,
for the Reference Architecture.Here's a direct link to a PNG copy of the visualmodel on our Kavi
collection at:http://www.oasis-open.org/apps/org/workgroup/soa-rm-ra/download.php/
25982/Service_Description_Model.pngI've added a couple of notes to the visual model.These are
intended to be our working notes and ultimatelyshould be removed
from the final version of the visual model.Cheers...- Jeff E.------------------------------------------------------------------------
-----Ken LaskeyMITRE Corporation, M/S H305 phone: 703-983-79347151 Colshire Drive fax:703-983-1379McLean VA 22102-7508__________________________________________________Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection aroundhttp://mail.yahoo.com-----------------------------------------------------------------------------Ken LaskeyMITRE Corporation, M/S H305 phone: 703-983-79347151 Colshire Drive fax: 703-983-1379McLean VA 22102-7508-----------------------------------------------------------------------------Ken LaskeyMITRE Corporation, M/S H305 phone: 703-983-79347151 Colshire Drive fax: 703-983-1379McLean VA 22102-7508
Attachment converted: Macintosh HD:smime 629.p7s ( / ) (00334E89) --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]