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