Chapter 1: Introduction

Overview

Service-Oriented Architecture (SOA) is a way of organizing software so that companies can respond quickly to the changing requirements of the marketplace . The technology is based on services , which are customized units of software that run in a network.

A service

• handles a business process such as calculating an insurance quote or distributing email, or handles a relatively technical task such as accessing a database, or provides business data and the technical details needed to construct a graphical interface

• can access another service and, with the appropriate runtime technology, can access a traditional program and respond to different kinds of requesters - for example, to Web applications

• is relatively independent of other software so that changes to a requester require few or no changes to the service, while changes to the internal logic of a service require few or no changes to the requester

The relative independence of the service and other software is called loose coupling . The flexibility offered by loose coupling protects your company from excessive costs when business or technical requirements change.

A service can handle interactions within your company, as well as between your company and its suppliers, partners , and customers. The location of service requesters can extend worldwide, depending on security issues and on the runtime software used to access a particular service.

In most cases, the requesting code has no details on the service location. Like the requester, the service can be almost anywhere . The location is set when the network is configured, and changes to the location are sometimes possible at network run time.

SOA implies a style of development, with concern for the business as a whole and with an increased focus on modularity and reuse. SOA isn't only for new code, though. Migration of existing applications is especially appropriate in the following cases:

• The applications are monolithic, combining the logic of user interface, business processing, and data access, with update of one kind of logic requiring your company to test multiple kinds of behavior.

• The applications are hard to understand - first, because the logic is monolithic, but second, because logic was repeatedly patched rather than rewritten as requirements changed. Updates take extra time as developers try to decipher the logic, and as the complexity grows, additional errors accompany updates.

• The application inventory has duplicate logic. Requests for change are unnecessarily disruptive, requiring changes in several places.

From the point of view of a business developer, a change to SOA is a change in emphasis, and many aspects of the job are unaffected. Consider the task of function invocation, for example. When you invoke a function, you aren't concerned with the internal logic of the invoked code or with how the function receives arguments or returns a value. Similarly, when you code a service request, you care only about the syntax for requesting the service. At best, service requests are as easy as function invocations.