[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] 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----- 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] 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] 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----- 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 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]