Service-oriented architecture (SOA) for EGL developers

A service-oriented application is an application composed largely of services, which are often in a hierarchy.

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 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, which 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.

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, which once stood for Simple Object Access Protocol. 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 service, consider the structure of an HTTP request message, which is the data transmitted from browser to Web server, and the structure of the HTTP response message, if any, that returns.

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. For example, a service that is written in EGL can be deployed as a Web service or as an EGL service. The latter exchanges binary data in a proprietary format.

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.

SOA has several important implications for business. First, when each component is a relatively standalone 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 will increase agility over time.

SOA also affects how people collaborate. Aside from the most technical services, a well-written service is coarse grained, which means that 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 end 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 will 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 be able 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.

A service implementation is the core business logic, which you might write in EGL or in any other programming language. The terms “service” and “service implementation” are often used interchangeably; service implementation is used when the focus is on the details of the business logic.

Elementary access details include the location, which is the address of the service implementation, and the binding, which identifies the protocol that formats a message at the start of transmission and unformats the message at the end of transmission. For Web services, the protocol is Hypertext Transfer Protocol (HTTP). Formatting occurs when the invocation message originates at the requester; unformatting occurs when the message arrives at the service location. Formatting also occurs if the service issues a response; in that case, unformatting occurs when the response arrives at the requester.

A contract describes the intended behavior of a service and is independent of the implementation details. A contract has two elements: a service interface and a Quality of Service.

The service interface includes a description of the data that can pass between a requester and a service and details about each operation that the service provides. The interface includes information about the messages and answers questions such as “What is the format of a message (for example, two strings and an integer)?” and “What are the restrictions on content?” The interface also includes details about the message exchange pattern, which indicates how the requester and service interact. The interface indicates whether the service always responds to the requester.

Some aspects of the service interface are implicit in the service interface. For example, a service might provide a stock quote but return an error message if the submitted stock symbol is invalid.

An interface is an aspect not only of a service but also of a high-level design for the service. Typically, the interface precedes the implementation and is said to implement the interface.

<Envelope>
   <Header>
      <!-- SOAP Headers here, for QoS -->
   </Header>
   <Body>
      <!-- Business data -->
   </Body>
</Envelope>

The SOAP message is not complex. The headers provide the main benefit of SOAP, allowing for support of security and of service coordination. The body holds the data used by the service implementation during a service request or by the requester during a service response.

One benefit of the traditional technology is that you can do as follows to cause the requester to access the same-named service at a different location: update the WSDL file that is used by the requester at run time. In this way, you can respond quickly to technical change, as might accompany a merger.

Developers and deployers use automated tools to work with the WSDL file.

www.example.com/employee/123

The address doesn't refer to a Web page, but to information about an employee, as indicated by the second qualifier; and, in particular, about a specific employee (number 123), as indicated by the third qualifier.

Both Web sites and REST services are associated with many addresses. In the case of a Web site, an address provides access to a Web page. In the case of a REST service, an address provides access to a unit of business data.

A REST service provides at least one of the following four operations: GET, for reading data; POST, for creating data; PUT, for updating data; and DELETE, for deleting data. These operations correspond to the major HTTP methods that can be specified in the HTTP request message.

REST services generally do not involve WSDL definitions. To allow for flexibility over time, EGL provides a way to quickly update the service locations accessed by a requester. The update requires the requester's redeployment. However, the details of operation name and service interface are simpler, and complex administrative files are not required.

When an HTTP message is used for a REST service, the entity-body often holds business data in the form of Extensible Markup Language (XML) or JavaScript Object Notation (JSON). In most cases, a SOAP envelope is not present.

Some authors anticipate a greater use of the SOAP envelope for data exchange with REST services; or at least a greater use of SOAP (or HTTP) headers so that the SOA runtime software can better handle QoS issues.

Although this topic distinguishes between REST and SOAP services, the real distinction is between the RPC and RESTful styles.

The industry provides many kinds of REST-RPC services. EGL REST-RPC services are the type of REST-RPC service that is written in EGL.

You use an RPC style to access an EGL REST-RPC service. Parameters and a return value identify the data to exchange, and you can think in terms of a business-specific operation name such as GetEmployeeData. The request message always uses an HTTP POST method, but that detail is not visible to you.

The requester of a REST service identifies a resource, specifies an action, and (if the action involves resource creation or update) provides a representation of the resource.