Service-Oriented Architecture[FROM:http://wiki.ittoolbox.com/index.php/Service-Oriented_Architecture]

A Service-Oriented Architecture (SOA) is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components (services) that can be reused and combined to address changing business priorities.[Bieberstein et al.]

The required characteristics of the component services of an SOA are:

- loosely coupled : the behaviour of the service should not be affected by its context / environment / especially NOT be dependent on the invoking service or system (service consumer)
- invocation / interface is fully defined in a published contract : the contract fully describes the service in terms input data, the resulting anticipated actions and output data; the contract may include quality of service attributes
- this contract, once published, should not be negated by future releases / implementations of the service : if other behaviour is required then a new service, with its own contract should be defined; however a service may be enhanced to provide new functionality if it does not break the previously published contract (backward compatibility)
- contracts should be standardised and self describing : in order to ensure maximum reuse, interoperability, substitutability potential, contracts should be defined in terms of prevailing standards (protocols, data field descritions), the self-describing nature of the contract content must enable its extensibility (i.e. the adding of additional information to it)
- independent of its implementation : the only dependence that an invoking system or service (service consumer) has, is on the contract of the service, never its implementation specifics

While an SOA can be deployed in varying ways, the general direction today is to implement under the terms of the Web Services standards: WS-*. Hence, the required charactteristics listed above are most frequently achieved through the communication of "messages" via SOAP servers among processes running on Internet-connected or Intranet-connected application servers. The outputs of these processes are products of the "services" which they perform. Hence, a "service," in the context of an SOA, is some network-connected functionality that can be accessed by another process. To be more concrete, I might have an application that collects customer information from users on-line. One field of information could be a zip code. To verify whether a user has entered a valid zip code, I could implement a table of zip codes within my application against which to check the entered code. But in a Service Oriented way, I could just send the enetered code, wrapped inside a SOAP envelope, as a message to a "service" which the U.S. Postal Service might have to do the checking for me against the most recent, offical list of zip codes. The Post Office returns a SOAP message to my application telling it whether the zip code is valid. As a result, I don't have to maintain a current list of zip codes. Instead, my application relies on the network-available "service" performed by the Postal Service.

Norbert Bieberstein et al. (2005) "Service-Oriented Architecture Compass - Business Value, Planning and Enterprise Roadmap", Pearson Education, ISBN 0-13-187002-5

More about this book: http://www.ibmpressbooks.com/bookstore/product.asp?isbn=0131870025&rl=1

Or check out your favourite bookshop.