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


Michael,

 

The Twitter example illustrates what I mean by relative value or, in this case, relative magnitude.  The three aspects Boris notes are always present but they all become more formalized (less implicit, more explicit)* as you reach the value threshold.  However, back to Boris’ point, I don’t think you ever have three contracts, and while different monitoring or expertise in evaluating conditions may be needed, can we really make a case that they are independent rather than different aspects of a whole?

 

* There are usually some implicit parts to even formal contracts because, to quote a different part of the RAF, you can never describe everything.

 

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: Monday, March 21, 2011 8:43 AM
To: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] service contract

 

I do understand, Boris, what you omean by 0ne vs. Three. I will add a few words about three parts of single contract or about having three independent contracts working together. What independent?  Becuase each type may be cobered/served by different and independent specialists/teams/companies and I'd not like having formal/legal dependencies between them...

 

I do not see a problem here. Thank you for the note.

 

- Michael

 

-----Original Message-----
From: Lublinsky, Boris <boris.lublinsky@navteq.com>
To: Ken Laskey <klaskey@mitre.org>; mpoulin@usa.com <mpoulin@usa.com>; soa-rm-ra@lists.oasis-open.org <soa-rm-ra@lists.oasis-open.org>
Sent: Sun, Mar 20, 2011 10:50 pm
Subject: RE: [soa-rm-ra] service contract

Michael,

Sorry I am with Ken. Here is a couple of examples. You can use Twitter APIs for any of your applications with the limit on the amount of service invocation. So this is implicit, If you plan to use more invocations, than you need explicit contract. Btw, I have no idea how ESB fits into this discussion.

Another question that I have is your statement

From the management perspective, three basic types of the contracts relate to:

·         relationship between service provider and consumer;

·         communication with the service;

·         control of the quality of the service execution.

This probably should state that a typical contract covers the following areas: . The issue is that I do not have three separate contracts, each covering specific area, but rather on covering all three.

 

 

From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Sunday, March 20, 2011 5:19 PM
To: mpoulin@usa.com; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] service contract

 

Michael,

 

The distinction is almost always the relative value of the business exchange:  when you reach a certain value, there is likely a formal contract.  So when I had storm damage to my house, there was a written contract between me and the contractor because the cost was over $10K.  If it was $500 for the same contractor, the contract would have been much less formal and a lot of it implicit.  Even business has some process for petty cash purchases.  While, I do agree that most B2B interactions are above the threshold and there is more likely a formal, explicit agreement rather than just an implicit one, I have to wonder whether most service transactions will need to be that formal or whether new processes with different expectations (implicit policies) will evolve.

 

In summary, I agree with your statement that “we have to address both loose- and close-coupling aspects of the service contract pointing to the applicability of each of them”.  My concern was that I felt some of the wording gave preference to the traditional contract without providing sufficient context for a deeper look and some real decisions.  I am happy as long as we can provide accurate context.

 

Ken

 

 

From: mpoulin@usa.com [mailto:mpoulin@usa.com]
Sent: Sunday, March 20, 2011 10:56 AM
To: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] service contract

 

Ken, we are walking around a matter that has many forms and appearances. If you are the consumer of Walmart, you have to trust quality of its goods, their capability to process your payment by credit card appropriately and so on but all of this are the part of the implicit contract. At the same time, when Walmart purchase fro any of its suppliers, I  am sure that Walmart checks who was the Grandpa of the supplier's owner... My last paragraph was about those cases, i.e. when Business deals with Business and I disagree that this is less routine than from the business perspective. BTW, ESB appears in the B2B relationships rather than in B2C, however, I gave you ESB as only an example about what means loose-coupling and where its place is in the B2B.

 

I think that we have to address both loose- and close-coupling aspects of the service contract pointing to the applicability of each of them. Otherwise, we risk to get into situation where Thomas Erl is with his Principle of Statelessness: he wanted to promote better development practice aimed to scalability and named the principles based on statelessness while his own definition of this principle says that the service has to minimise the state where possible, i.e. there nothing about statelessness but about smart state management. People did not read the definition and have started to declare that SOA services must be stateless, which is quite wrong theoretically and practically  -  the service state management must adequate to the business task the service solves (there are other means for increasing scalability available besides the statelessness).

 

- Michael

 

-----Original Message-----
From: Ken Laskey <klaskey@mitre.org>
To: mpoulin@usa.com; soa-rm-ra@lists.oasis-open.org
Sent: Sun, Mar 20, 2011 12:45 am
Subject: RE: [soa-rm-ra] service contract

Michael,

 

As our present RA approach is to keep things simple, I think we can just talk about technical/interface coupling and business/contract coupling and not delve into too much detail.  That is especially true of ESB details.

 

As for the business viewpoint, it is interesting that typically the consumer know about the provider but the provider often knows little about the consumer.  If I walk into a Walmart, I may know a lot about the company, its practices, the goods it sells, but it knows nothing about me.  Our “contract” is I will act appropriately when in the store and I will pay for the goods I leave with.  With that, Walmart will sell me anything in its inventory.

 

An interesting extension of these ideas is if I go into a car dealership, many aspects of the contract is the same until I actually want to make a purchase.  At that point, I need to be authorized, i.e. there is a credit check to see if I have the financial resources to qualify.

 

In both the Walmart and the car examples, the coupling between the consumer and provider is very loose and nothing is specialized in the interaction to the particular provider and particular consumer.  In the Walmart example, there is never an explicit contract.  In the car example, the explicit contract is the terms of financing, and that contract isn’t necessary if the consumer pays in cash.

 

So your last paragraph is applicable for a major engagement between a provider and consumer but may be missing completely for something more routine, as I expect/hope much of the service interactions will be.

 

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: Saturday, March 19, 2011 7:19 PM
To: Laskey, Ken; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] service contract

 

Ken, while I agree with majority of your comments and currently think how to put them in, here is one thing I have to discuss as well. 

I think that your concern about coupling via contract has to be observed from two viewpoints, which will explain where the softness is appropriate. First, the  most familiar to IT viewpoint, is technical loose-coupling: if two services interact their interaction should not tie their internal implementation but they both must understand/share semantics of the exchange messages and exchange pattern. In this area we step on the tail of ESB that can not only indirect end-points (P2P) but also modify the messages. To me, the implementation of such ESB is far from the service ESB pattern and centers in the technical integration rather than in service orientation. But I cal live with it.

 

Second, the less familiar and frequently omitted viewpoint roots in the business ownership of business functionality realised via technical means - technical parts of the SOA service  (applications). In this case, IT must follow the business ownership model, business transaction model and business collaboration model. In all these models consumer knows its provider and this is the basis for the business trust. During the business deal and each related transaction they are coupled and this is the 'rule of engagement', i.e. there is nothing wrong with coupling. In the business world, ESB either takes business responsibilities as a middle-man or disappears and becomes a part of consumer or service inheriting their business responsibilities accordingly. (I've wrote a big article about this matter). 

 

Having SOA ecosystem in between Business and Technology, we have no choice that respect both types of contracting. In this line of logic, in my educational presentations I always say that for business services the explicit service contracts are mandatory; that service consumer and service provider take business obligations getting into such contracts that should be managed and monitored from technical and business/legal perspectives.

 

- Michael

-----Original Message-----
From: Ken Laskey <klaskey@mitre.org>
To: mpoulin@usa.com; soa-rm-ra@lists.oasis-open.org
Sent: Sat, Mar 19, 2011 7:21 pm
Subject: RE: [soa-rm-ra] service contract

Michael,

 

This captures a lot of the extended discussion we had last Thursday.  A couple other points come to mind:

-          Something on the order of the following needs to be said:
One of the often espoused benefit of applying SOA principles is the loose coupling between the providers and consumers.  The emphasis is often on the technical coupling and the specifics of the interface through which the consumer and provider communicate.  However, there is an equal danger of tight coupling through service contracts that may be point-to-point, binding a specific consumer to a specific provider for a specific set of interactions.  The SOA view of management must consider how to standardize the processes and specifics of service contracts or risk losing many of the benefits a SOA implementation is expected to deliver.

-          A great blog that highlights the change in thinking – I especially like having a section titles of “Dorothy, you’re not in Kansas anymore” and “The best way to avoid failure is to fail constantly” –  can be found at http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html

-          Instead of “a consumer may be allowed to use a service description as an implicit default service contract”, I ‘d suggest “a service description may be used as an implicit default service contract”. That would follow well the previous italicized text in your write-up.  It could be followed with something like (which got longer as I started writing)

“In some cases, the service description may identify alternatives that the consumer may use, e.g. which versions of a vocabulary will be recognized, and the specifics of the contract are satisfied when the consumer uses one of the alternatives. In other cases, the service description may indicate mandatory policies, e.g. for security purposes, and the consumer satisfies the service contract by abiding by those policies.  Another alternative could have a consumer identifying a policy they require be satisfied, e.g. a standard privacy policy on handling personal information, and a provider that is prepared to accept a policy request would indicate acceptance as part of the service contract by continuing with the interaction.  (Note, a consumer should not assume such a request is accepted unless the service description indicates such requests can be accepted.)  Numerous other alternatives are possible and are likely to evolve as variety of use of the SOA ecosystem grows.”

-          The idea of “An explicit service contract alway always requires a form of up-front interaction” needs to be softened a bit to be consistent with the examples I gave above.  The consumer is certainly aware a priori of the vocabulary alternatives and decides it is possible to comply, but the provider doesn’t know about the consumer’s decision until the moment of the interaction with the service.  There is no real need for the consumer to announce this in advance.

-          There are certainly situations where an explicit contract is appropriate in advance, and nothing I’ve said above is meant to preclude that.  However, that does result in tight coupling through the contract and the participants really need to consider to what degree that is necessary or how a different approach may lead to a more robust solution.

-          A nit: priory should be replaced with a priori

 

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: Saturday, March 19, 2011 10:35 AM
To: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] service contract

 

Hi All,

 

executing the assigned action set in the last meeting, let me represent a fragment of Management Model section related to the service contract. It sets 3 types of the contracts (that discussed later in the section) and 3 definitions that are the key to the rest of related discussions

 

So, here is the fragment:

As described in sections “Participation in a SOA Ecosystem view” and “Realization of a SOA Ecosystem view”, there are several types of contracts in the SOA ecosystem. From the management perspective, three basic types of the contracts relate to:

·         relationship between service provider and consumer;

·         communication with the service;

·         control of the quality of the service execution.

 

Before a service is invoked the first time, SOA ecosystem assumes that the consumer gets into agreement with the service provider about the service features and characteristics that will be provided by the service and available to the consumer; this contract is known as a service contract:

a service contract is an implicit or an explicit and documented agreement between the service consumer and service provider about the use of the service based on the commitment by a service provider to provide service functionality and results, and realize real world effects as well as on the commitment by a service consumer to interact with the service in the manner described in the service description.

 

In some situations, a consumer may be allowed to use a service description as an implicit default service contract; in other situations, the service description may be set as a mandatory service contract, e.g. for security services. In the case of business services, it is anticipated that the service contract is explicit and the agreement between business consumer and business service provider is formalized. So, an implicit service contract is an agreement on the consumer side with the terms, conditions, features and interaction means specified in the service description "as is" that do not require any priory interactions between the service consumer and the service provider. An explicit service contract alway requires a form of up-front interaction between the service consumer and the service provider regarding the choice or selection of the subset of of the elements of the service description that would be applicable to the interaction with the service and affect related joint action. The examples of the explicit service contracts are: 1) a consumer can choose which one of the offered policy alternatives  or interface alternatives the consumer wants to use in the service interaction; 2) a consumer wants to use only a subset of the business functionality offered by the service and pay a prorate cost for this.

 

 

Please, send me your comments that I would be able to incorporate them into the materials for the next meeting.

 

Cheers,

- Michael


The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]