Service-oriented architecture (SOA) is a way of organizing software. To learn about SOA, see the following sections:
- Introduction to SOA
- Service-oriented applications
- Web and binary-exchange services
- Business implications of SOA
Introduction to SOA
- It handles a business process such as calculating an insurance quote or distributing email; handles a technical task such as accessing a database; or provides business data and the technical details to construct a graphical interface.
- It can access another service. With the appropriate runtime technology, it can access a traditional program and respond to different kinds of requesters, such as web applications.
- It is relatively independent of other software. Changes to a requester require few or no changes to the service. 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
A service can handle interactions within your company and between your company and its suppliers, partners, and customers.
- The applications are monolithic, combining the logic of the user interface, business processing, and data access such that update of one kind of logic requires your company to test multiple kinds of behavior.
- The applications are hard to understand because their logic is monolithic and 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 the updates.
- The application inventory has duplicate logic. Requests for change are disruptive, requiring changes in several places.
From a developer's point of view, a change to a service orientation is a change in emphasis, and many aspects of the development task are unaffected.
Service-oriented applications
The topmost level contains one or more integration services, each of which controls a flow of activities, such as processing an applicant's request for insurance coverage. Each integration service invokes one or more business services.
The second level is composed of services that each fulfill a relatively low-level business task. For example, an integration service might invoke a series of business services to verify the details that were provided by an insurance-policy agent. If the business services return values that are judged to mean "issue a policy," the integration service invokes another business service. The second business service calculates a quote and returns the quote to the software, such as a web application, that invoked the service-oriented application.
The third level consists of data-access services, each of which handles the relatively technical task of reading from and writing to data-storage areas, such as databases and message queues. A data-access service is most often invoked from the business layer, but the easy access of services allows for different uses. For example, a requester such a web application can access a data-access service to assign initial values in a form.
The central point is flexibility. Some integration services provide different operations to different requesters, and some invoke other integration services. In addition, a requester might access different kinds of services from within a service-oriented application. The requester might access an integration service at one point and a business service at another.
Web and binary-exchange services
What is the defining characteristic of a web service? For some people, the answer is that the service exchanges data in a text-based format called SOAP. Other people insist that the defining characteristic of a web service is that the service exchanges data on the World Wide Web by way of the communications software Hypertext Transfer Protocol (HTTP).
To understand the different styles of web services, consider the structure of an HTTP request message, which is the data transmitted from a browser to a web server, and the structure of the HTTP response message, if any, that returns.
- The message begins with an HTTP method to identify what the receiver is to do with the message.
- Several subsequent entries are headers that provide information
that is not specific to your business data. For example, such information
might be the details about the user agent (that is, the requesting
browser). Each header is a name-and-value pair:
User-Agent: Mozilla/4.0 ... - The entity-body is the request data, if any. If the HTTP method is GET (a request for data), the entity-body is empty in most cases.
- The message begins with an HTTP response code to indicate whether the request data was processed.
- Several subsequent entries are headers, including one, Content-Type, that identifies the format of the data in the entity body of the response. The format is specific; for example, one is for a picture of type JPEG. If the format is Hypertext Markup Language (HTML), the response is a web page. At least three other content types provide business data for use in a web application or other requester: Extensible Markup Language (XML); SOAP, which is an XML dialect; and JavaScript Object Notation (JSON), which is data that is easily processed by JavaScript.
- The entity-body is the response data, if any.
The phrase web service implies the transmission of data in a text-based format. In contrast, a binary-exchange service exchanges data in a format that is associated with a particular computer language or a specific vendor.
- Allows a faster runtime response than is possible with web services
- Avoids the need to maintain configuration files
- Avoids the need to learn the technologies related to traditional web services
The cost of using binary-exchanges services is reduced accessibility. A binary-exchange service is directly accessible only to software that transmits data in the binary format that is expected by the service.
Business implications of SOA
SOA has several important implications for business. First, when each component is a relatively stand-alone unit, your company can respond to business or technological changes more quickly and with less expense and confusion.
The ability of a company to respond quickly and well to change is known as agility. A well-crafted SOA increases agility over time.
SOA also affects how people collaborate. Aside from the most technical services, a well-written service is coarse grained. In a coarse-grained service, the area of concern is broad enough so that business people can understand the purpose of the service, even if they know little about software. When a collection of coarse-grained services handles the business procedures of a company, business analysts and software professionals can share information knowledgeably, include users in early deliberations about the purpose and scope of each service, and understand the implications of changing a business procedure. Ease of human communication is an important benefit of SOA; this fact suggests that the architecture might become the primary organizing principle for business processing.
Well-designed services are more likely to be reusable. Companies can benefit from reuse in at least two ways: by avoiding the expense of developing new software and by increasing the reliability of the software inventory over time. You can do less extensive testing if an existing service is placed in a new application, in comparison to the testing required to deploy software that was written from scratch.
You can use SOA to make business processes and data more available. For example, imagine agents at an insurance company sitting at workstations and invoking a mainframe process to quote insurance prices for specific customers. In response to competitive pressure, the company wants to allow customers to request quotes on the web, which traditionally has no direct link to a mainframe. What is necessary before the company can accept personal data from a browser, run the data through analytic software on the mainframe, and respond to the customer? The solution includes developing new services to handle the interaction of browser and analytic software. The business implication is a more modern process, with expanded markets.
Notice
Some of the preceding material is from Enterprise Web 2.0 with EGL (MC Press, 2009; http://www.mc-store.com/5107.html).