An SOA can be thought of as an architectural style of software development in which the service, representing some business initiative, makes itself available over a network to other service(s) or consumers (clients) for the purpose of transporting data or processing information. This service within the SOA is uniquely identified by smart organizations as having certain design characteristics that serve them. Theses characteristics are discussed next.
SOA Design Principles
An SOA, one that aligns with strategic goals and objectives of an enterprise, is more that just the technologies that make it up. With an SOA “...it isn't just the use of XML and Web services, and it's a good deal more than a development methodology” (Russell 2004).
We can begin now to look at the distinction that enables a service to become part of an SOA that serves the enterprise. The important distinction is the service oriented design principles. By instilling these design principles into service design and development the SOA grows to become a visionary SOA, one that serves the enterprise by isolating key business logic.
Each design principle effects the organization as it is designed into services. For example the design principle that states a service should have a service contract means a service interface must be designed and implemented with the idea that it will be exposed to other services via this contract. This means considerations must be taken into account when designing services. Considerations such as exposing the service behavior (security) or defining data types (compatibility) or attaching policy assertions all fall under the guise of the service contract.
Design principles rely or coincide with certain other design principles in customizing the SOA in this manner. Loose coupling is a precursor to reuse as loosely coupled services are independent of other services and consequently more reusable. Independence itself is a key concept about services in a SOA and coincides with autonomy and abstraction.
Below is a complete list of the service oriented design principles and their importance within the organization. The aim of each principle is to define what properties a service must posses to realize an SOA that aligns with the enterprise. I begin each principle with a quote from Thomas Erl, the renowned author of SOA. A service architecture that follows these design principles will have more leverage in realizing an SOA for the enterprise that meets its needs as expected.
- Service Contract – “Services express their purpose and capabilities via a service contract” (Erl 2009). In an SOA when two services communicate there must be a mutual understanding between processes about the information passed in the message. This understanding consists of service behavior (the operations) and its data. It also concerns the data type. This agreement between services is fundamental to the SOA.
When Web services interact, for instance, it is the WSDL file that provides this understanding. The WSDL file represents an abstract interface definition and concrete implementation definition. These two definitions form the service description or contract between two services which must be mutually understood by both requestor and provider.
- Loose Coupling – “Coupling refers to a connection or relationship between two things. A measure of coupling is comparable to a level of dependency” (Erl 2009). In service orientation this dependency must be of a limited nature as each service provides independent behavior that is separate from other services. The service logic does not rely and is not relied upon in a true loosely coupled service. This independent behavior serves the enterprise by allowing for reuse while promoting continued reliance on service functionality by consumers.
- Abstraction – “On a fundamental level, this principle emphasizes the need to hide as much of the underlying details of a service as possible” (Erl 2009). When a consumer consumes a service the processing logic or service behavior is hidden away from the consumer (representing a Black box). The complex details are hidden. This makes services more reusable. The only visible aspect of the service is the immediate need of the consumer.
- Reusability- “Reuse is strongly emphasized within service-orientation; so much so, that it becomes a core part of typical service analysis and design processes...” (Erl 2009). A service has qualities making it reusable; autonomy, loose coupling etc. It becomes valuable to the whole enterprise as a result of being reusable. A traditional component class in a software system is tied or coupled to other components. Services are agnostic from other services. They employ their logic independently from other service logic, within some context, making them reusable.
- Autonomy – “For services to carry out their capabilities consistently and reliably, their underlying solution logic needs to have a significant degree of control over its environment and resources” (Erl 2009). The solution logic of a service should serve a particular interest only for the enterprise. A service should not contain solution logic that is coupled to other services. It should serve its own purpose within some context of the enterprise.
- Statelessness – “The management of excessive state information can compromise the availability of a service and undermine its scalability potential” (Erl 2009). If a service is tied to its state, or its representations of various conditions of a system, it becomes less available to consumers.
- Discoverability – “For services to be positioned as IT assets with repeatable ROI they need to be easily identified and understood when opportunities for reuse present themselves” (Erl 2009). A service is best when it is reusable. A reusable asset gives a good ROI when it is designed and developed as being easily discovered. Quality of communication (with other services) and its individual capabilities should be examined for this discoverability to materialize.
- Composability – “As the sophistication of service-oriented solutions continues to grow, so does the complexity of underlying service composition configurations” (Erl 2009). Services form alliances with other services. Independence is key for a service in a service oriented environment, but hooking into other services programmatically to serve the particular interest of the service and enterprise, is becoming more and more complex. Designing services so that they can easily enlist other services to satisfy an interest of the organization is the goal of this principle.
- Interoperability – “interoperability is fundamental to every one of the principles we just described” (Erl 2009). Services by their very nature should be interoperable or able to operate, hook into, other systems easily. Designing services to be interoperable is part of the goal of all the previous design principles discussed.
The service positions itself outside of the application scope meaning its developed with a wider emphasis on enterprise needs than the component classes it works with. It is situated within the cloud meaning it has its own URL. It represents some unique enterprise initiative and is discoverable by other services through a service contract. It is this service that sits as the enterprise’s main asset when designed properly.
A service is similar to traditional components comprising a software system in that they provide independent functionality. Traditional component development creates behavior in code, in the form of a method or function, which is tightly integrated with other components. A service, on the other hand, serves its own interest within a network apart from the classes and components comprising the application.
It may enlist the help of component classes or other services, either internal or external, but these other entities just become a part of the service. A service can therefore be made up of other component classes and/or other services. This configuration of services and component classes to meet a central need for the enterprise is referred to as service orchestration.
Services interact with other services, the way objects in an object oriented system would. The service’s solution logic would represent the object’s methods that interact with other objects only with services you’re interacting over a network, in a distributed environment, with other services.
Furthermore these available services represent some enterprise wide need as opposed to components that just serve the application environment. Services strategically then may serve as a commodity that an enterprise can situate on a network where each service is able to interact with consumers.
Thus the service solution logic becomes a vital asset, if properly designed, as it waits for requests from consumers on a network. Furthermore it is the goal of the successful enterprise to integrate a set of characteristics into service interface development so that this exposed behavior provides a unique advantage to the organization.
The characteristics, or design principles, associated with services within an SOA are customizable to serve various enterprise needs in various ways. For example consider the principle that says a service should be autonomous. An autonomous service serves a particular interest of the enterprise. “This means that each service is responsible for its own domain, which typically translates into limiting its scope to a specific business function (or a group of related functions)” (Erl 2009). To participate in an SOA the service should be autonomous so that reuse is maximized. The other design principles have equal importance in realizing an enterprise SOA. These design principles are discussed next.
The most common type of service used in business today is the Web service. The Web service distinguishes itself by communicating data formatted as XML documents over network protocols, usually HTTP. The Web service typically adheres to the design principles as it is part of service oriented architecture.
Web Services are the service of choice for most organizations. The Web service technologies that underlie it are a collection of specifications customized for the purpose of communication between disparate pieces of business logic over a network to serve some enterprise wide initiative.
Simple Object Access Protocol (SOAP), Extensible Markup Language (XML), Web Service Description Language (WSDL), and Universal Description Discovery and Integration (UDDI) are all specifications used to support the SOAP and XML based Web service. Depicted below are the relationships between these specifications as they enable communication between Web services. Each one is discussed further below.
Figure 1. First generation SOA model. Source- SOABooks.com
For superior support, support for the enterprise and a realization of a portion of Web 2.0, one has to develop services that adhere to the Second Generation WS-* Web service standards. These standards are appended to the first generation Web service principles and provide to the Web service, and the organization, features not present but envisioned in the first generation of Web services. See Figure 2.
Figure 2. Second generation WS-* Web services model.
Extensible Markup Language (XML)
XML is the tool in the Web service arena. It is only a tool in this respect. Each specification mentioned in this section utilizes XML to perform some function. XML, on the other hand, does not utilize any other specification.
XML formats data (marks-up), which can then be transported via SOAP over a network. Because XML is text based Web services are supported over many platforms, programming languages and operating systems. WSDL and SOAP as well as UDDI rely on it.
If you know HTML and its pre-defined tags you can understand the markup in an XML document. An XML documents marks-up content using customized tags that serve a particular interest as opposed to HTML tags that have pre-determined meaning.
Web Services Description Languages (WSDL)
The Web Service Description Language is an XML document and describes the Web service to service consumers. The WSDL document, formatted in XML, provides a description of a Web service.
Specifically the WSDL document describes an abstract definition of the service interface (behavior). This amounts to a high level description of what the service does. There is also a concrete, implementation definition that defines the operations and data used in the transport. This would be the low level description of the service operations (methods) and data to be transported.
Together these abstract high level and concrete low level definitions make up the contract between services- the service description. Each Web service and Web service consumer has this service description or one similar so they can communicate. In fact any service in an SOA shares a contract about the service. This is a vital principle of the service oriented architecture. The WSDL customized tags for these service definitions, both abstract and concrete, are mentioned now.
The abstract interface definition in a WSDL document is defined by the XML customized tags DEFINITON, INTERFACE, and OPERATION while concrete implementation definitions of the operations and data are defined with the XML tags SERVICE, BINDING, and OPERATION. Together these tags provide to the consumers of Web services a means of understanding and accessing a Web service.
These XML tags serve in their entirety as the service description or WSDL document. They abstractly define what the service behavior does while also supplying the concrete implementation behavior as well.
Simple Object Access Protocol (SOAP)
We now know that XML is the tool for Web services, WSDL provides a description, but how do you access the content of a provider in one application from another. The communication channel that allows for the transfer of information from consumer to provider and from provider to consumer is provided by SOAP. SOAP is also an XML document.
As an XML based specification SOAP provides a set of XML customized tags of its own. The purpose of these tags is to send and receive messages formatted and described in XML between the consumer and service. ENVELOPE and BODY tags are required. The HEADER tag is optional and is used to carry information such as the WS-* next generation Web service standards features.
A SOAP node- a node is used to describe the SOAP roles in this context - is that of a sender and a receiver. Corresponding to the service requestor and provider roles of the service message, a SOAP sender sends the message request to the SOAP receiver, also a service provider.
In essence you have a SOAP node (See Figure 3.), the sender, wrapped around the message request on one end and a SOAP node, the receiver, wrapped around the message response at the other end. The transfer of data is then allowable through XML and executed by SOAP.
Figure 3. Sending and Receiving service data.
Universal Description and Discover Language (UDDI)
This specification serves as a repository for publicly available services in which other service may avail themselves. The repository can be public, as available to many organizations, or private, available within a single organization.
Web services thus contain the necessary ingredients to discover a service, define a service, and transport data between services.