[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] RE: updated service description
Ken, I agree with your thoughts that policies and contracts are referenced from the Service Description and can be fully defined elsewhere. Many people in the industry tend to think of the Service Description as a contract. The reasoning behind this is because it can be said the consumer has to abide by the Service Description and therefore it is a contract. At the implementation level, people often equate a WSDL to a contract. I see this view of a SOA contract as a half-truth. As stated in one of Michael’s previous e-mails, WSDL does not capture the business meaning of a service. The meaning of contract is rooted more in the social structure than anything at the implementation level. In business a contract is a legally binding agreement between two or more parties. It may or may not be personalized, it may be human enforceable, it may be electronically enforceable. For electronically enforceable policies and contracts, the computing mechanisms that enforce a policy or a contract can be the same. One person's stated policy can be another person's enforced contract. Not abiding by stated policies can have real world effects just like not abiding by a contract. Loss of a job for not following company policy for example. It is difficult for me to see a clear distinction between a policy and a contract other than what is stated in the OASIS SOA RM. A contract and a policy have a clear distinction at the level of the social structure. At the implementation level, just tell me the rules that need to be enforced, whether it is a policy or a contract doesn't matter to me. The Service Description encompasses more about the social structure than the contracts so I do not put contracts at the same level as Service Description. The contract is a subset of Service Description if the contract is part of the Service Description. Discussions about contracts and policies and Service Descriptions will tend to swirl around the following three questions: What is the distinction at the business level between a policy and a contact? What is the distinction at the implementation level between a policy and a contract? Where do the various forms of a contract fit in relation to the Service Description? Danny --- Ken Laskey <klaskey@mitre.org> wrote: > Michael, > > I started to respond to this hours ago, then printed > out your paper, > and finally make it past numerous distractions > (including a > unexpected 3 inches of snow to shovel) to finally > collect my thoughts. > > On your first point, I think of the service > description as being the > executive summary and table of contents. It gives > you the critical > overview and tells you where to find more details. > So while > Interaction Policies & Contracts in the description > may explicitly > lay out such things, these are more likely to be > fully defined > elsewhere and referenced from the description. Of > course, one > benefit of this is that the policy, for example, > becomes reusable. > > As for the personal nature of policy agreements, if > it is a one-time > agreement, I see it residing in the execution > context (whose > concrete manifestation is still to be discussed). > If the agreement > is intended to be reused, it should be catalogued > somewhere. The > idea of a general purpose somewhere also needs to be > tackled, perhaps > (definitely?) as part of the RA. > > I then read your paper and if you went through the > TC emails, you > could find discussions touching on but never > resolving many of these > issues. So here are some general questions and some > specifics ones > relating to your paper. > > - What is a service component? If we have a > composite service, i.e. > one that shows a single interface but is actually a > combination of > other services, do you consider the constituent > services to be > service components? In the RM, we distinguish > between the capability > and the service that provides access to the > capability. Is an > implementation of the capability also a service > component? > Personally, I think I'd say yes to both where > changes to either can > affect the client experience. > > - Are "service functions" the same as RM actions? > > - One of my favorites: what belongs in a SLA? Some > views have it so > complete that it basically becomes the service > description, i.e. it > describes functionality, constraints, interface > details, and the > birthdays of anyone who ever used it. Personally, I > take a more > minimalist approach and think of SLA as being > strictly a set of well > defined metrics against which compliance can be > measured. I agree > with with your line that "a SOA service ... is > invoked ... when the > client is fully aware of the service behavior and > conditions." (We > could quibble over "fully".) To accomplish this, I > rely on an > adequate service description, of which a > metrics-laden SLA is a > part. However, another part is an indication of how > one can obtain > metrics collected against the service. It is then > up to the client > to compare the collected metrics with the SLA and > determine fitness > for use. For example, if I have a service that says > I will relieve > 80% of world hunger and the metrics show me only > relieving 70%, does > my service provide value? > > Enough for now. > > Ken > > On Feb 25, 2007, at 10:00 AM, > michael.poulin@uk.fid-intl.com wrote: > > > Hi Ken, > > I have two notes to the update (actually, to the > doc as it is with > > the update): > > > > 1) There is an entity in the Service Description > diagram named > > "Interaction Policies & Contracts". I think that > Contract belongs > > to another area than service description because > it is > > 'personalized' based on consumer/provider > agreement. Yes, > > logically, a Contract is a special type of > description but it would > > be more comprehensive if we put it into > Interacting with Services > > Model section. > > > > 2) You have mentioned <A discussion of how version > designation/ > > value should be impacted by change of version of > any of its > > components (or any descriptions?) still needs to > be discussed.> To > > me, a version of the service is one of very > important > > characteristics of the service description (and, > respectively, of > > the service contract). I would propose placing > version as an entity > > in the Service Description diagram either under > Identity or at the > > level of Service Description entity because > version affects Service > > Reachability, Service Functionality, Interaction > Policies, and > > Service Interface entities. I have published a few > thoughts about > > SOA service versioning in SOA-WebServices Journal > (http://java.sys- > > con.com/read/250503.htm ). > > > > - Michael > > ------------------------------------------------------------------------ > > ------------------ > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-983-7934 > 7515 Colshire Drive fax: > 703-983-1379 > McLean VA 22102-7508 > > > > > ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]