This chapter is from the book
This chapter is from the book
This chapter is from the book
7.4 Service Abstraction
The appropriate level of abstraction at which services are described achieves additional agility and alignment between business and IT areas of an enterprise. Abstracting information means taking technical details out of a problem to be solved on a higher level. Since the beginning of computer technology, information has been abstracted into higher levels in a number of ways, for example:
- Assembler constructs, which are instructions for a processor, are translated into a series of 1 and 0.
- Operating systems offer access to system resources and APIs that encapsulate lower-level constructs.
- Programming languages, such as Java, introduce a more abstract way of describing logic, which is then compiled into a format that the operating system can understand.
Service-orientation continues the evolution of higher-level abstraction use to make creating and changing solutions easier. For example, a business process defined with WS-BPEL describes a sequence of service invocations and the data flows between them by expressing this sequence in XML form without writing any actual code. A side effect of this increased abstraction is the ability to utilize visual programming tools that support the creation of process definitions via drag-and-drop-style interfaces. The Service Abstraction principle advocates that the technical details of the technology platform underlying a service contract are hidden from the service consumer. It also promotes hiding non-essential details about the service itself.
Abstracting Technology Details
The service contract represents an abstraction of the functionality implemented in the service logic. Included in this notion is the abstraction of technical resources utilized to fulfill a service’s functionality.
Filenames, database tables, machine names, and network addresses should be omitted from the service contract and completely hidden from service consumers. Given that a service contract should always be designed with a particular business purpose in mind, this should never be a problem.
Concerns arise when services are generated straight out of existing code, because technology details which should have otherwise been abstracted away will often be exposed. For example, whether or not a service is implemented in Java or running in a Java environment such as Java EE should be completely irrelevant to the service consumer.
Hiding Service Details
Maximum flexibility is achieved when the technology used to implement a service and additional details about that service are hidden, which can be divided into information about the input or output message format and contextual information.
Hiding the information about the input or output message format may seem counterintuitive. If a service’s input and output messages are hidden, what is left to put into the service contract? Message formats can be abstracted to a generic level without surrendering the message definition altogether.
For example, assume a Credit Check service receives customer information as input. The customer information can be defined and represented by a Customer complex type in the XML schema definition to a detailed level, adding constraint information to each attribute and element of that schema. The length of the lastName character field is limited to 35 characters in Example 7.36.
Example 7.36 XML schema definition with added constraint inheritance can limit the lastName field to a set number of characters.
<complexType name="Customer">
<sequence>
<element name="firstName" type="string"/>
<element name="lastName">
<simpleType>
<restriction base="string">
<length value="35"/>
</restriction>
</simpleType>
</element>
<element name="customerNumber" type="string"/>
</sequence>
</complexType>
The XML schema definition in Example 7.36 maps to a Java class, Customer.java, as seen in Example 7.37. (The generated Javadoc comments are omitted.)
Example 7.37 The generated Java type does not include the schema type restriction.
public class Customer {
@XmlElement(required = true)
protected String firstName;
@XmlElement(required = true)
protected String lastName;
@XmlElement(required = true)
protected String customerNumber;
public String getFirstName() {
return firstName;
}
public void setFirstName(String value) {
this.firstName = value;
}
public String getLastName() {
return lastName;
}
public void setLastName(String value) {
this.lastName = value;
}
public String getCustomerNumber() {
return customerNumber;
}
public void setCustomerNumber(String value) {
this.customerNumber = value;
}
}
On the opposite end of the abstraction spectrum would be a message definition stating that the incoming message is an XML document with a root Customer element. No information is given about individual attributes or elements contained in the document, as seen in Example 7.38.
Example 7.38 An XML schema definition using the <any/> element
<complexType name="Customer">
<sequence>
<any/>
</sequence>
</complexType>
The generic type definition leads to a generic Java class, as shown in Example 7.39.
Example 7.39 The <any/> element is mapped to java.lang.Object.
public class Customer {
@XmlAnyElement(lax = true)
protected Object any;
public Object getAny() {
return any;
}
public void setAny(Object value) {
this.any = value;
}
}
Hiding service details and increasing what is abstracted about a service may always appear to be a prudent step. However, the service consumer is sometimes not provided with all of the necessary information on what exactly the service expects and what will be returned in response. Details of an interaction on both sides are left to be resolved at design-time or runtime (outside of the service contract).
In Example 7.38, the generic version states that a Customer object contains a java.lang.Object, which must be defined at runtime to allow for processing. Generally, more Java code must be written for errors that can occur at runtime. For XML payloads, this consideration is equally valid for SOAP and REST services, as the mechanics perform the same role for both in mapping XML to Java via a binding tool such as JAXB. An abstract service contract can be appropriate in some instances, such as utility services.
Contextual data can also be hidden, as this type of data is commonly about an interaction which does not contain any business-relevant payload information. When using SOAP-based Web services, SOAP header fields store contextual data, such as unique message identifiers, timestamps, and service consumer identity. For greater abstraction, detailed information about contextual header fields can be left out of the service contract altogether. This contextual information can be added or removed depending on the environment in which a service runs, is not relevant for its business purpose, and can often be left out of the contract.
For REST services, in the absence of any kind of a payload envelope, contextual information must be part of a resource representation. Such resource metadata can still be packaged inside specially designated header elements. The technical details of a service that are not part of the service interface, such as a WSDL or service-level information about response times and availability, can be abstracted. The technical details can be important to know, but often change and depend on a particular runtime environment and deployment of a service. For REST services, such service-level agreement characteristics can be described in a separate document.
Document Constraints
Non-technical information about a service cannot be articulated in a standard format. A generic example of this is a service-level agreement, but may also include other constraints about the usage of a service, valid ranges of input data beyond what can be expressed in WSDL and XML schema, and any additional applicable documentation.
A service can be implemented and deployed in different ways throughout an enterprise. As such, this documentation should not be directly linked with a service. Java, for example, is well suited for deployment on multiple platforms and operating systems. A Unix-based environment has different performance, scalability, and availability characteristics than a Windows-based system. Additionally, a Java EE application server can be leveraged to host the Java logic. A service instance can run on just one server instance on a small machine. As reuse of the service increases, the service instance can be moved to a clustered environment with greater computing power.
As per the Dual Protocols pattern, a Web service offered over HTTP can be later exposed via JMS for additional reliability requirements by particular service consumers. Abstract service contracts provide the freedom to make changes throughout the lifetime of the service, without breaking or violating previous versions. REST service implementations are synonymous with HTTP, making transport mechanism abstraction a non-issue. As the information about a service grows in abstraction, the service implementation and service consumer logic must become more flexible to anticipate future changes.