[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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] 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----- 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: - 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) - The idea of “An explicit service contract - 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] 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:
Please, send me your comments that I would be able to incorporate them into the materials for the next meeting. Cheers, - Michael |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]