Service Contract Template

Abstract

Summary form only given. Loose coupling is a cornerstone for service-oriented architecture (SOA). Service contracts enable loose coupling, because they hide service-internal details from the outside world behind a facade. In the Web services world, the service contract is commonly understood as a WSDL document possibly decorated with WS-policy annotations. Such formal XML description is not immediately useful to business people. This paper proposes the notion of a service metadata document that contains human-readable business aspects of the service in addition to technical artifacts. Stakeholders at the business and technical level work collaboratively on the service metadata document and use it as a common framework for discussion. We see the service contract as a composition of functional metadata and a set of policies, such as security constraints, access restrictions for user groups, transport and service level agreements, charging, etc. For example, enterprises often have different security requirements when a service is consumed from within the company than when it is consumed by an external business partner. The service lifecycle is initiated by business people on the basis of a service contract template; the first step is a high-level description of the desired service characteristics. In an iterative process the document is then successively refined as it percolates from the management level to service architect and other stakeholders and as business requirements are tested against technical realities. Technical artifacts (WSDL, XSD, etc.) are added to the service contract and could be placed in a registry so that the service is visible to other departments or external partners. The clear distinction between service metadata and policies also helps maintaining a consistent model over runtime WSDL proliferation. Typically, policies are enforced by intermediaries, such as XML firewalls, enterprise service bus (ESB) or other WS-infrastructure. Each such intermediary offers a virtual service endpoint to the actual service implementation. Because different policies may be enforced at each endpoint and because of the different locations, the WSDL for each of these virtual service endpoints is different