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


Title: Re: [soa-rm-ra] Updated Visual Model for Service Descripti
I have just finished one of those nasty little less interesting things, and now I'm off on another.

Sigh,
Rex

At 10:35 AM -0500 11/5/07, Ken Laskey wrote:
basically +1.  I expect the RA will need to capture principles but not the details of (yet to be established) best practice.  I agree the clutter of unusable/unenforceable policies should be minimized but I don't think we can police those who can't differentiate between policy and wishful thinking.  I agree policies and contracts need to be closely aligned and so the challenge now is how closely is enough while realizing the flow from one to the other is somewhat leaky.

On item 5, I never intended we'd be going through logs but rather the execution context would be displayed in a standard, relatively easily read format.

Now back to less interesting things I've been avoiding :-)

Ken

On Nov 5, 2007, at 10:14 AM, Rex Brooks wrote:

At 9:49 AM -0500 11/5/07, Ken Laskey wrote:
Rex,

There is a definite connection between policies and contracts but I think making it too tight could also be a problem.

1. Policies work nicely for a resource description because they are a property of a resource independent of their use or user.  Policies can be stated as the the desired state of the world but they may not be reflected in every (or any) actual contract or other use.

2. Contracts are pairwise (at least) and reflect an agreement on policies and likely include details that go outside policy.  A contract can reflect policies that are not part of a resource description, i.e. something introduced by one of the other parties to the contract.  Thus, there is not always an absolute connection between the stated policies and the eventual contracts.  In fact, a final contract may run counter to a stated policy.

True. Thanks for making my point. I'm not advocating that policies must be reflexively instituted in contracts. I'm saying that they need to be in close-cross-referenced or easily cross-reference-able association so we can "run" automated "checks"  to see which polices are specifically cited in contracts, and thus encourage that practice, or discourage the practice of making policies that can't be included in contracts.


3. I expect policies to eventually be referenced by identifier and there will be standard policies, such as for privacy, that can be easily referenced so matching policies will be easier.  This is along the lines of what WS-Policy envisions.

So, we'll be ready for it, eh?

4. Contracts may eventually point to the identifiers of the policies to which we agree (I don't know what the lawyers will require) and may have identifiers themselves.  But like business-level services, I'm not sure how reusable we will find contracts unless they are for the same business events and same/similar parties.  There are likely many more contracts than policies, and the number of contracts will grow over time.  Also, many contracts will be private, so I expect only contracts that have an anticipated public use will be made visible.

This happens to be critical in the emergency management, health informatics field for liability reasons, but also, making this easier, and more sensible, is in everyone's interests. We want to encourage our lawyer-bot developers to do their job in  such a way that emergencies don't need special "emergency powers," and don't tempt authorities to act like Alexander (I'm in charge, here") Haig.


5. Agreed upon policies (I consider as piecemeal agreements) and formal contracts (I consider a collection of agreements for a given purpose) will be reflected in the execution context that captures all the recordable details of an interaction.  This tells you how things were done and the conditions enforced.


Agreed. But I don't want to have to look at web-logs to trace the connections from policy to contract to practice to application misalignment in the post foul-up real world effect. I want to be able to find it in batch simulations.

So I think Murphy will be after us no matter what we do.  I think federations are closer to contracts than policies and I think will be handled in similar (as yet to be determined) fashion.  I am still chewing on how I'd suggest the policy and contract pieces all be represented, and do not dismiss the possibility I'll come around to agreeing they all fit together.

In essence, my theory is to put policies and contracts in such close proximity that they trip all over each other until they come up with something sensible. ;-)

Cheers,
Rex


But no yet :-)

Ken


On Nov 5, 2007, at 9:11 AM, Rex Brooks wrote:

If 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,
Rex

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

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:



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







__________________________________________________
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





-----------------------------------------------------------------------------
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 629.p7s (    /    ) (00334E89)


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


-----------------------------------------------------------------------------
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 630.p7s (    /    ) (00334ECD)


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


-----------------------------------------------------------------------------
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 632.p7s (    /    ) (00334F31)


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