Service-oriented architecture (SOA) for EGL developers

To learn about EGL support for service-oriented architecture (SOA), see the following sections:

Introduction to SOA

SOA is a way of organizing software and involves the deployment of services, which are units of logic. In most cases, services are deployed on a network.

A service has the following characteristics:
  • Handles a business process such as calculating an insurance quote or distributing e-mail; or handles a relatively technical task such as accessing a database; or provides business data and the technical details 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, Web applications.
  • Is relatively independent of other software. 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

A service can handle interactions within your company and between your company and its suppliers, partners, and customers.

SOA implies a style of development that focuses on the business as a whole and on modularity and reuse. SOA is not only for new code, though; you might migrate existing applications in the following cases:
  • The applications are monolithic, combining the logic of 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 unnecessarily 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.

Structure of a service-oriented application

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

Illustration of a service-oriented application

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.

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, 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 HTTP request message has three components:
  • 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 company's business data; for example, 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 HTTP response message has three components:
  • 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 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. 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 use of binary exchange services provides several benefits:
  • 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 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.

Aspects of a service

Services have the following aspects: a service implementation, elementary access details, and a contract.

Service implementation

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

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.

The location of a service is set when the service is deployed. The requester detects the location in the following ways:
  • You can embed the details on service location in the business logic of the requester, but this usage is inflexible. If the service location changes, you must recompile and redeploy the requester.
  • In most cases, the service location details are provided by configuration files at the site where the requester is deployed. This usage is more flexible because the configuration files can change during the years when the requester is in use, and the requester can access the service even if the service is deployed to a new location.
  • In some cases, location details are passed to the requester at run time or the message is redirected by the SOA runtime software. These usages are flexible but add complexity that is not required for most purposes.


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.

The second part of the contract is the Quality of Service (QoS), which is a set of interaction rules that go beyond those implied by either the elementary access details or the service interface. QoS includes the following issues:
  • Reliability: for example, what percentage of time is a service promised to be available?
  • Security: for example, what ensures that a specified requester is authorized to access a specified service?
  • Coordination: for example, can the service revise database changes that were made but not committed (made permanent) by the requester?
  • Runtime update of message content or destination: for example, can a message be reformatted at run time to allow transmission to a computer that uses a different protocol?

Architectural styles in Web services

A Web service can represent any of three styles: a Remote Procedure Call (RPC), a document-oriented style that is associated with Representational State Transfer (REST), or a hybrid style that is called REST-RPC.

Web services traditionally fulfill the RPC style. You use a business-specific operation name—for example, UpdateEmployeeData—and a set of arguments, as if you are invoking a function. In many cases, you expect a return value.

The RESTful style is based on the transfer of a single unit of business data, at most. The service implementation can do whatever is necessary, but the operation name is generic: for example, GET or UPDATE.

The RESTful style hides detail. For instance, an employee record is said to be handled in only one of a few ways, regardless of what is done with the data. A business-specific operation name such as UpdateEmployeeData is not meaningful in determining what operation to perform.

REST-RPC services use business-specific operation names. In most cases, these services use an RPC style of data exchange, but do not use the complex administrative files that are needed to handle traditional Web services.

RPC-style SOAP services

A traditional Web service receives and returns data in SOAP format. The SOAP envelope is the primary content of the HTTP entity-body:
      <!-- SOAP Headers here, for QoS -->
      <!-- Business data -->

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.

In the traditional Web service, the content of the SOAP envelope is related to the content of Web Services Description Language (WSDL) files, which are complex. Those files are used at the following times:
  • At service design time, to communicate the service interface to developers and other designers
  • At the time of developing the requester, to aid the process by which the developer defines the data that will be exchanged with the service
  • At run time, to fulfill two purposes: to specify the service location, and to allow for runtime validation of the SOAP message

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.

REST services

In EGL, a REST service is one that uses Web facilities to fulfill the RESTful style. In the RESTful style, you transfer a single unit of business data (if any) and use a narrow set of operation names. In addition, the service address includes information about the data being operated on. For example, consider the following address, which is composed of three qualifiers:

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.

REST-RPC services

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.

REST for the EGL developer

This section gives further details on EGL support for REST.

Resource, representation, URI, and action

From a developer point of view, REST involves the following main ideas:
  • A resource—for example, a database row with employee data—has (at a given time) a representation. A representation might be a set of program values that specify the employee number, title, and salary.
  • The resource also has a universal resource indicator (URI), which is a unique name such as "". In this case, the employee number is 0020. In general, the URI gives a name to the resource. Also, the URI provides the main detail needed to access a REST service.
  • An action indicates what is to be done with the resource. The possible actions are few: the resource can be created, read, updated , or deleted.

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.

Path variables and query strings

In HTTP, a URI may specify the resource of interest in the following ways:
  • The URI can include path variables, which are variables whose values identify the resource of interest in a direct way, without requiring that a service process the input to determine the resource. In the following example, the employee number 0020 is the value of a path variable:
    Path variables are appropriate in most cases. You might use multiple path-variable values, with one separated from the next by a forward slash. That use of multiple values suggests a hierarchical relationship. For example, the path-variable values in the following URI identify a corporate division (Consumer) and, within that division, a corporate department (Sales):
    When you write code to access third-party REST services in EGL, you create a URI template, which is an outline of the last part of a URI. Here is an example template, such that employeeNumber is a path variable:

    You identify a path variable in a URI template by embedding the variable name in curly braces.

  • In relation to a GET operation, the URI can be supplemented with a query string, which is a set of name-value pairs. In the following example, the question mark (?) precedes a query string, and each name-value pair is separated from the next by an ampersand (&):
    A query variable is a placeholder for a value in the query string. When you create a URI template in EGL, you specify query variables by using the same syntax as for path variables. In the following example, divisionName and departmentName are query variables:

    In comparison to the use of path variables, the use of query strings is considered less ideal—less RESTful. Use of query strings is most appropriate when a service uses the name-value pairs as input to the service logic. In that situation, the logic might use the input to determine what resource to access.

EGL support for a subset of third-party REST-RPC services

As noted in “Architectural styles in Web services,” a service that exchanges non-SOAP data by way of HTTP might be called a REST service even though the data exchange does not fully conform to the RESTful style. Here are some common variations:
  • Some REST services use a POST request for tasks other than creating a new resource. EGL lets you avoid sending a representation for a POST request.
  • Some REST services require that a DELETE request include a representation (the business data) rather than simply relying on the URI to identify the resource to delete. EGL supports access of REST services that require a representation for a DELETE request, but also supports access of REST services that do not have that requirement.

Sources of additional information

A detailed introduction to REST is Richardson and Ruby's book Restful Web Services (O'Reilly Media, Inc., May 2007).

For an overview of service interaction and some of the RPC-related technologies, see SOA for the Business Developer by Margolis and Sharpe (MC Press, May 2007). That text also gives an overview of the following areas:
  • Extensible Markup Language (XML), which is the basis of the SOAP format used with a Web service and is sometimes the basis for messages exchanged with a REST service
  • XML Schema, which is information—essentially, a code—that is used to validate XML


This essay includes material from Enterprise Web 2.0 with EGL (MC Press, 2009;