Services Not All Like Laundry

In my post on the Laundry Metaphor of Services, I said that all services are a bit like laundry, and some services are very much like laundry, but few services are totally like laundry.

We need a notion of business services that covers at least five types of service (plus composites, hybrids and cross-overs).

Product Service: "I give/get you something"
Examples: Catering, Information, Certificate

Typically the service is fulfilled in the form of one or more deliveries (events). A product service is typically triggered by a specific request by the service user, and fulfilled by a response by the service provider. The right to trigger product services may sometimes be delegated to the service provider - either by defining some business rules, or by delegating authority as part of a challenge-based service (see below). Charging is typically per product or per delivery. Or it may be governed by a prior access service (such as subscription).

Transformation Service: "I do something to your something"
Examples: Car Repair, Laundry, Haircut,

The service provider takes temporary charge of something that belongs to the service user, and returns it in an improved state (e.g. mended, cleaner, tidier, more fashionable).

Responsibility Service: "I take care of something for you"
Examples: Office Cleaning, Track Inspection & Maintenance

Typically the service provider takes ongoing responsibility for a defined entity or outcome over a defined time period. Beside the core service, the service provider may provide regular or adhoc reports about the state of the entity to the service user. Charging will often be based on a flat fee. An alternative form of charging may be based on time and materials, but this demands a higher degree of trust between the service provider and the service user.

Access Service: "I allow you to do something" Permit/Enable/Empower
Examples: Subscription, Licence, Fishing Permit, Rail Use / Landing Slot

The service is typically delivered in the form of a message that contains a key and/or allocates a resource. Access rights and allocations typically expire if not used. Access is typically tied to a specific identity (e.g. user, machine) and is not normally tradeable or transferable. May also include traded options and the like, which confer a defined right to some other service or trade.

Challenge Service: "I solve a problem for you."
Example: Diagnostics, Develop Software, Adapt Business On-Demand.

The service provider often (but not always) specifies the solution. The service provider may also specify the problem. This entails a high degree of trust. This may also involve some shared risk and professional indemnity. Charging is typically problematic, unless it can be done within an arbitrary “professional” fee structure.

Each type of service requires different kinds of charging and service level agreement, and relies on different forms of quality assurance and trust. In my post on the Business Service Architecture (Railway Edition), I mentioned the difficulty faced by the company in the UK with primary responsibility for the railway network (originally Railtrack, now Network Rail). Railtrack was delegating maintenance work (Responsibility Services) to engineering companies and subcontractors, while selling rail availability (Access Services) to train operating companies. Railtrack seriously miscalculated the complex algebraic relationship between two different kinds of service level agreement, resulting in a serious rail accident in Hatfield.

Not all like laundry then.

Services Like Laundry

Just over a year ago, fed up with the over-use of the Lego brick metaphor, my colleague David Sprott proposed the laundry model of SOA (Explaining SOA to the Business). Antony Reynolds of Oracle quoted this in his blog today (The Laundry Model of SOA), which is what reminded me.

Both David and Antony talk about the contract basis of the laundry model.

• I delegate something (in this case cleaning) to the laundry service.
• Officially I don't care how it's done (although the term "dry cleaning" seems to indicate a preferred implementation).
• The laundry service accepts some (limited) liability for any failure.

These are typical characteristics of pretty much any kind of service, more or less. But there is a particular characteristic of the laundry service I want to talk about.

• I entrust the service with something (an asset) that belongs to me.
• I expect the laundryman to be discrete. I do not want my dirty linen washed in public - in other words, I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to inquisitive journalists.
• If something goes wrong with the service, then my asset is damaged. The potential liability is linked to the value of the asset, not to the value of the service. (If my dress suit is ruined, I am not going to be happy if I just get the cost of the cleaning reimbursed.)
• I do not authorize the service provider to use the asset for his own purposes. (I do not expect the laundryman to borrow my suit for his daughter's wedding.)

These characteristics are common to many services. I do not expect my CRM provider to try and sell things to my customers, nor to allow identity thieves to access their information. (Indeed, the customer information may not belong to me either; it arguably belongs to the customers themselves, who have entrusted me with their information according to the same pattern.) I do not expect my ISP to read my email, or interpret my search history. (Perhaps I'm being naive about that.)

However, there are many services where this is not clearly agreed. Perhaps I get some cut-price service, and this is only economically viable because the service provider expects to be able to broadcast some advertising to me or my customers. But if I am careless with the small print on the contract, I may not have understood this aspect of the deal.

And there are many services where this simply doesn't apply. For example, information services often simply involve transferring information from the service provider to the consumer, while Software-as-a-Service may simply involve transferring functionality. Obviously there are trust issues here as well - I trust the BBC to provide accurate and balanced news, I trust my internet security provider to protect me from viruses, I trust Microsoft Excel to calculate my profits correctly - but these are not linked in quite the same way to specific assets.

So I think the laundry metaphor is a very useful one, but like any metaphor we must be careful not to push it too far. All services are a bit like laundry, and some services are very much like laundry, but few services are totally like laundry.

---

See also

Services Not All Like Laundry (July 2008)
Laundry as Intelligence (Oct 2008)
Understanding Business Services (November 2012)

Contract First

A number of people are championing Contract-First Development within SOA.

For example, Aaron Skonnard of Pluralsight. In a number of recent blog postings on the topic, he reports a sympathetic hearing from Microsoft personnel (Bill Gibson, Simon Guest) and asserts support from Microsoft products (BizTalk Server). [August 27, 2004] [November 11, 2004] [November 11, 2004 (again)] [November 30, 2004]

But I am concerned that some people are basing Contract-First Development on a narrow notion of Service Contract - for example, equivalent to the signature of a service, expressed in WSDL. Sometimes people talk about Schema-First Development, which indicates a concern for semantics as well as syntax. But I don't think this goes far enough.

I previously expressed my preference for the term Design-by-Contract, since this term is strongly associated with a broader notion of Contract including preconditions and postconditions. Even traditional Design-by-Contract doesn't include some of the non-functional obligations expressed in a service contract, such as Service Level Agreements, Security Policy and Commercial Terms, which are essential for distributed computing and SOA. We have used the term Distributed Design-by-Contract to emphasise a broader concern for all these dimensions of a service contract.

Actually, I don't really mind which term we use, provided that we can assume the broadest meaning for the term Service Contract.

BPEL

At CBDI, we are generally supportive of BPEL. However, we do not see it as a complete solution to business collaboration. We have raised a number of issues over the past two years.

In business terms, the basis for collaboration between autonomous business entities is a service contract. This suggests a design process in which contracts are paramount - such as Design by Contract. One of our concerns about the web service stack (including BPEL) is that it lacks proper support for contracts and assertions. We proposed that service contract should be a first-class construct, and we have yet to be convinced otherwise. We look forward to seeing what emerges from WS-Choreography.

Secondly, we think the ideal of distribution or federation remains some way off. For example, while WS-Transaction supports distribution, BPEL assumes that the process management is hosted on a single engine, although there have been hints that a future version of BPEL will support distributed process management. In the meantime, some people are experimenting with alternative approaches to distributed process management, such as OGSA.

See for example Grid Web Services and Application Factories (pdf)

Thirdly, there appears to be a widespread assumption that the orchestration or choreography is established at design time, with only minor modifications (such as the introduction of new, interchangeable partners) at run time. In time we should progress to real time orchestration.

See CBDI Newswire 22nd May 2003 and 28th May 2003 (free access).

See CBDI Reports From Web Services to Web Collaborations (Nov 2002).

Design by Contract

Design by Contract was pioneered by Bertrand Meyer, who refined the assertion-based approach into the Design by Contract method and the Eiffel language. The basic idea is that a component and its clients have a contract with each other. The client guarantees certain preconditions before calling a method, the component guarantees certain postconditions after the call. If the pre- and postconditions are included in a form that the compiler can check, then any violation of the contract between caller and component can be detected immediately. The prime focus of the approach is to deliver reliable software.

Design by Contract has wide theoretical acceptance. It is an intrinsic component of the Catalysis Approach, perhaps the most influential of all component methodologies. However its usage has to date been relatively limited, the most prevalent use being in the Eiffel language.

• CBDI Report Eiffel in the .NET Environment October 2002

---

In business terms, the basis for collaboration between autonomous business entities is a service contract. This suggests a design process in which contracts are paramount - such as Design by Contract.

For distributed collaborations, a contract between provider and consumer needs to have three parts: logical, quality and commercial.

 
The logical contract specifies the function of the Service, typically using a series of logical assertions such as preconditions and postconditions. This includes both syntactic elements (signature) and semantic elements (vocabulary, meaning).

The quality contract specifies the quality of service - often given the rather dismissive label of non-functional characteristics.

The commercial contract specifies the commercial arrangements, including charging for normal operation and compensation for abnormal operation.

Design by Contract allows services to be defined and used without knowing anything about the implementation. It therefore seems ideally suited to the design of web collaborations. Design by Contract has traditionally concentrated on the logical contract, but the same principles and related design techniques can be extended to the quality contract and the commercial contract.

---

The term "web service contract" is sometimes used in the very narrow sense of the syntax/signature of the service call, as expressed in WSDL/XML. Much of the recent discussion on Contract-First Development seems to be focused on these aspects of the contract.

• For example, Simon Guest regards Contract-First Development as an alternative to Data-First Development (which he prefers).
• See also Aaron Skonnard blog on Contract-First Development (August 2004) with many comments
• Eric Newcomer (Description First, September 2004) points out that for Web services, the purpose is to share data over the network. Therefore the Schema is more correctly viewed as the contract, not the WSDL.

Design by Contract has a broader concept of contract, which explicitly includes the semantics of the service call in terms of pre/postconditions and invariants, but against a single semantic vocabulary.

Web services will be implemented in a range of formal languages and protocols. These will not only specify the syntax of the service (e.g. using WSDL/XML) but also the semantic vocabulary (e.g. using RDF or DAML-S) and the pragmatics (e.g. using BPEL). However, these languages do not yet cover the full ground of quality contracts and commercial contracts. In the short term, these aspects of the contract are likely to be covered by legal contracts and SLAs between service providers and consumers. Some vendors refer to this broader notion of contract as the Relationship Contract. Some service management tools include such characteristics within the service repository as metadata.

---

• CBDI Newswire 22nd May 2003 and 28th May 2003 (free access).
• CBDI Reports From Web Services to Web Collaborations (Nov 2002) and Modelling for SOA (Feb 2003).

CBDI materials are currently unavailable.

Related posts BPEL (September 2004), Contract First (December 2004)