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
Service discoverability and other principles



Service discoverability and its relationship with
other service-orientation principles.

Designing services so that they are naturally discoverable enables an environment whereby service logic becomes accessible to new potential service requestors. This is why service discoverability is tied closely to the following service-orientation principles:
  Service contracts are what service requestors (or those that create them) actually discover and subsequently assess for suitability. Therefore, the extent of a service�s discoverability can typically be associated with the quality or descriptiveness of its service contract.
  Service reusability is what requestors are looking for when searching for services, and it is what makes a service potentially useful once it has been discovered. A service that isn�t reusable would likely never need to be discovered because it would probably have been built for a specific service requestor in the first place.

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.