Introduction
 About this Site
 About the Principles

Common Principles of Service-Orientation
 Service reusability
 Service contract
 Service loose coupling
 Service abstraction
 Service composability
 Service autonomy
 Service statelessness
 Service discoverability

How Service-Orientation Principles Inter-relate
 Service reusability
 Service contract
 Service loose coupling
 Service abstraction
 Service composability
 Service autonomy
 Service statelessness
 Service discoverability

Service-Orientation and Related Principles and Paradigms
 Separation of Concerns
 Object-Orientation (Part I)
 Object-Orientation (Part II)
 Object-Orientation (Part III)

More
 Advanced
   service-orientation

 Submit your opinions
 Training for SOA and
   Service-Orientation
 About the author
Services share a formal contract
Service contracts provide a formal definition of:

 the service endpoint

 each service operation

 every input and output message supported by each operation

 rules and characteristics of the service and its operations

Service contracts therefore define almost all of the primary parts of an SOA. Good service contracts may also provide semantic information that explains how a service may go about accomplishing a particular task. Either way, this information establishes the agreement made by a service provider and its service requestors.


Service contracts formally define the service, operation, and message components of a service-oriented architecture.

Because this contract is shared amongst services, its design is extremely important. Service requestors that agree to this contract can become dependent on its definition. Therefore, contracts need to be carefully maintained and versioned after their initial release.

Within the Web services framework, service description documents (such as the WSDL definition, XSD schemas, and policies) can be viewed collectively as a communications contract that expresses exactly how a service can be programmatically accessed.

This page contains excerpts from:

Service-Oriented Architecture:
Concepts, Technology, and Design

by Thomas Erl

(ISBN: 0131858580, Prentice Hall/PearsonPTR, Hardcover, 792 pages).

For more information, visit
www.soabooks.com.
Opinions

"Procedural and Object-oriented designs typically equate type compatibility with semantic compatibility. Service-orientation provides a richer model for determining compatibility. Structural compatibility is based on contract (WSDL and optionally BPEL4WS) and schema (XSD) and can be validated.

Moreover, the advent of WS-Policy provides for additional automated analysis of the service assurance compatibility between services.

This is done based on explicit assertions of capabilities and requirements in the form of WS-Policy statements."


- Donald F. Ferguson (IBM), Tony Storey (IBM), Brad Lovering (Microsoft), John Shewchuk (Microsoft)






www.soasystems.com

Copyright © 2005-2007 SOA Systems Inc.