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 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
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
|