When creating a Web service or an entire service-oriented architecture (SOA) for an enterprise, sometimes the easiest thing is the actual coding. Much more difficult can be coming to an agreement about exactly what the supplier and consumer of each service will do.
To help solve this problem a new concept is emerging with regards to Web services and SOAs, what's called a service contract. Although it's not yet in widespread use, there are many who believe that most Web services will ultimately involve a service contract, or at least when the Web service is being created between business partners, rather than for internal user in an enterprise. In this first part of a two-part column, we'll look at what a service contract is, and whether it's really needed. In the next column, we'll look at what should go into a contract, and how to draw one up.
What is a service contract?
When I refer to a service contract, I'm not talking about an actual legal document. Rest easy -- no lawyers need be involved.
Instead, the service contract specifies a set of technical data, and possibly business information. The contract is between whoever is providing the Web service, and whoever is consuming the Web service. Put in the simplest terms, the contract provides details about the service being created by the provider. By agreeing to a contract, both sides understand exactly what will be provided, possibly before any coding is done.
"A service contract is a set of metadata about a service, and there are a lot of different levels on which it can operate," explains Miko Matsumura, vice president of technology and standards for Infravio. "You can have a low-level contract within systems like the Microsoft .NET Indigo services stack that expresses how you communicate, and what are the expectations of communications."
But that low-level contract, he continues, is not nearly as important as the higher-level contracts, what Infravio refers to as a "service delivery contract."
This higher-level contract is far more important, he says, particularly because these contracts frequently have business implications, not just technical implications. For example, a contract may include details of how the service will be authenticated, and so have details about authentication, encryption and authorization. It can also include service level agreements (SLAs). And it can also contain business information, including how billing, metering and monitoring will be done.
These contracts are particularly important for enterprises that are providing services, Matsumura says, because it allows a company to create a single service, and then sell that service to many different customers, by simply creating a separate contract for each customer. That makes it exceedingly easy for the company to sell its service.
For example, an enterprise may provide a service, but may charge more for that service if it responds more quickly to an identity. Or it may charge more for a higher level of reliability. So the enterprise could draw up two separate contracts for the service -- one for a company which wants a higher level of service, and is willing to pay more, and one for a company not willing to pay as much, and will settle for a lower level of service.
"What's powerful about this notion is that you describe the customized aspect of the service in the metadata, which make it much easier to configure than if you were embedding the terms in the service itself," Matsumura explains.
By including the information in the contract rather than the service, the service only needs to be created once. To reuse it with a different partner, only the contract needs to be changed. This allows for quick deployment of services in an almost cookie-cutter like fashion.
If all this sounds abstract, let's take an example, provided by Matsumura. Let's say a telecommunications provider wants to provide network services to a wide variety of customers, using a portal for generating trouble tickets, order entry, billing and integration. It creates a service to do that, and then for different customers, creates different contracts, based on each customer's business and technical requirements.
So a large airplane manufacturer may want to authenticate users with a SAML token, while another customer may want to authenticate with a different method. That would be detailed in each customer's contract. Perhaps a state university has lower service level requirements than an airplane manufacturer because the university can't pay for as high a level of service. That's detailed in each contract as well.
Are contracts real yet -- Or even needed?
There's not yet universal agreement that these kinds of contracts are needed. Michael Liebow, Vice President of Web Services and SOA for IBM Global Services, notes that "We're not seeing these kinds of contracts."
The reason? "Most of what we're seeing in Web services are on the trusted internal network, rather than with external partners, so a contract is not really needed," he explains. "It's still too early for it, I think, because the ecosystem you need for them hasn't evolved yet."
Rather, he says, today, WSDL can be used instead of service contracts. "The need for contracts will come as the market evolves, and a lot of things need to happen before there's a need for them," he concludes.
But in Matsumura's view, these contracts are vitally important. In fact, he says, "As soon as you treat an SOA as something that has a real impact on your business, you need to start thinking about contracts -- Contracts are a hot topic right now because people are seeing that they can impact the delivery of business services."
In my next column, we'll continue our discussion of services contracts, what goes into one and how to draw one up.