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] Management Concept - Jan 29 - 11


Michael,

 

This is one of those places where saying more opens up cans of worms that just open up more cans.  I don’t know about your typical audience, but if I get folks this far, then they at least appreciate there is something that requires deeper thinking.  For many parts of the RAF, bringing our audience this far is victory.

 

Ken

 

From: mpoulin@usa.com [mailto:mpoulin@usa.com]
Sent: Wednesday, February 09, 2011 7:38 PM
To: Laskey, Ken; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Management Concept - Jan 29 - 11

 

Instead of a stronger statement, Ken, I'd propose to make it more accurate in light of our current understanding (do we shared this understanding?). For example:

 

1586 This Reference Architecture Foundation uses the term service description for

1587 consistency with the concept defined in the Reference Model. Some SOA literature

1588 treats the idea of a  "service contract" as equivalent to service description but it is rather an exception than the rule in the SOA ecosystem. In this

1589 Reference Architecturethe SOA-RAF, the term service description addresses the service itself while service contract is an agreement about the service between the service provider and consumer.

1590 Replacing service description with service contract implies just one side of the

1591 interaction is governing and misses the point that  A  single set of policies identified by a

1592 service description may lead to numerous contracts, i.e. service level agreements,

1593 leveraging the same description.

 

 

If you have concerns about explicit coupling of the service contract with the agreement between consumer and provider, please, look into the section Contract in the Management Model where I describe 3 basic types of contracts in SOA, i.e. we address other contracts as well. (I.g. I describe SLA as a special type of contract that is included into the service contract document).

 

I am after general concept of the relationships between the "service description" and derived from it "service contract". The wording may be refined but not the meaning, IMO. 

- Michael

-----Original Message-----
From: Ken Laskey <klaskey@mitre.org>
To: mpoulin@usa.com; soa-rm-ra@lists.oasis-open.org
Sent: Wed, Feb 9, 2011 9:36 pm
Subject: RE: [soa-rm-ra] Management Concept - Jan 29 - 11

Michael,

 

This was written years ago.  It raises an issue as directly as possible with the realization that we weren’t going to get everyone to uniformly use our preferred term.  I’ve actually seen more movement than I expected.  However, I still think it would not be feasible to press for a stronger statement.

 

Ken 

 

---------------------------------------------------------------------------

Dr. Kenneth Laskey

MITRE Corporation, M/S H305              phone: 703-983-7934

7515 Colshire Drive                                    fax:        703-983-1379

McLean VA 22102-7508

 

From: mpoulin@usa.com [mailto:mpoulin@usa.com]
Sent: Tuesday, February 08, 2011 2:16 PM
To: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Management Concept - Jan 29 - 11

 

Gentlemen,

I am sorry for bothering you again with regard to Service Description and Service Contract. Based on the Ken's note below (in bold), I allow myself to re-open this case.

 

We have several years of history of the discussion what is the Contract and what is the Service Contract vs. Service Description. Instead of quoting who said what and when, let me briefly summarise my memories and understanding.

 

Service Description is a document that defines the service for its potential consumers and, sometimes, to its developers. This document has to have enough business, marketing and technical information to 'win the consumer'. Our diagram for Service Description (Figure 15, Editors’ Draft, 17-01-2011) is rich and, probably still incomplete because it does not include EC where the service characteristics are guaranteed by the service provider, but it is not my point of concern for now.

 

Service Contract, even expressed in the form of a bunch of Policies, is an agree subset of the Service Description (in exceptional cases Service Contract may include Service Description in full, i.e. Service Description may be used as a Service Contract for such services as Security, Compliance, and alike) and combined with some policies that the consumer has brought to the table. Nonetheless, in essence, Service Contract is an agreed part of Service Description. For example, if Service Description contains definition of 2 public service interfaces - Web Servces and MOM Messaging - but the Service Contract with Consumer C mentions only MOM Messaging, the Consumer C has no rights to call the Web Service interface (though this interface is public too).

 

Any public service interface including Web Services / WSDL is only an interface and, rhetorically, may be called a PROGRAMMATIC COMMUNICATION contract (thanks to buzz-marketing and Thomas Erl). I do not even attribute it to the programmatic interface because there are no place for EC (communication and execution policies) in it.

 

Based on this observation, I've spotted one place, where we are not that clear Service Contract and Service Description as we, IMO, have to be:

 

1586 This Reference Architecture Foundation uses the term service description for

1587 consistency with the concept defined in the Reference Model. Some SOA literature

1588 treats the idea of a ―service contract as equivalent to service description. In this

1589 Reference Architecturethe SOA-RAF, the term service description is preferred.

1590 Replacing service description with service contract implies just one side of the

1591 interaction is governing and misses the point that a single set of policies identified by a

1592 service description may lead to numerous contracts, i.e. service level agreements,

1593 leveraging the same description.

 

IMO, we may not say "is preferred"; we have to say that in SOA-RAF we clearly distinguish between them (because of the many reasons one of which is partially stated in the followed sentence). Moreover, the expression "numerous contracts, i.e. service level agreements" is incorrect IMO because Service Contract contains much more than SLA, particularly, business functionality, promised results, promised RWE, multiple polices, and so on.

 

Since Service Description is a part of section 4, I do not know how we would clean this potential mess...

 

- Michael

 

 

-----Original Message-----
From: Ken Laskey <klaskey@mitre.org>
To: mpoulin@usa.com; soa-rm-ra@lists.oasis-open.org
Sent: Mon, Jan 31, 2011 8:33 pm
Subject: RE: [soa-rm-ra] Management Concept - Jan 29 - 11

Michael,

 

I had a chance to look through this and have some overall comments.

 

-          At line 2318, you added some words on risk but it seems strange where placed because it’s followed by a list of benefits and then followed again by a list of risks.  Any reason your text shouldn’t be an addition to the list of risks?

-          Need a clearer connection to having maintainable connections (not just text to be edited) from service description to collected information needed for management.  Consumers (including those creating compositions) need information to determine sufficiency of service considering.  Management will have an interpretation of this information but not necessarily the final word.

-          In section 5.3, there are a bunch of short blurbs on an endless set of manageabilities.  What I get is life cycle manageability is the ability to manage life cycles, …, X managemeability is the ability to manage Xs.  Does the elaboration through some 400 lines really add anything that couldn’t concisely be presented as a bullet list in one page?

-          Is the term service contract used the same way as in other parts of the document?  This term has a lot of use in the vendor and user world but little firm understanding beyond the idea that a WSDL defines an interface.  This often gets swallowed in SLAs.  I think we need to take this on at some point and I haven’t checked to see whether other discussion in sections 3 and 4 are sufficient.

-          In section 5.3.5, the detail on what constitutes infrastructure is beyond the scope of the RAF.  However, the immediately following list of things needed for service management is thought-provoking, but it should not be presented as a complete list.

-          How is section 5.3.6 different from what is in the section 5.3 life cycle chunk and how should it relate?  (Above, I questioned whether the 5.3 detail is needed.)

 

There seems to be a few things on which we need to focus:

-          Management to operationalize governance

-          Monitoring so you have data from which to get status and make decisions

-          Specific things to manage in a SOA ecosystem that weren’t of consequence in traditional systems

Capability to manage seems to require policies from governance translated to rules and regulations that get to specifics and then measurement and feedback on the specifics.

 

Ken

 

---------------------------------------------------------------------------

Dr. Kenneth Laskey

MITRE Corporation, M/S H305              phone: 703-983-7934

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