Service-Oriented Architecture

Service-oriented architectures (SOAs) are a significant step forward in aligning information technology with business goals. But SOAs are insufficient when the Web services of which they are typically composed use inconsistent terminologies and present different understandings of the real-world environment that they are meant to support. Enterprises need transparency, a clear view of what is happening in the organization. They also need agility, which is the ability to respond quickly to changes in the internal and external environments. Finally, organizations require integration: the smooth interoperation of applications across organizational boundaries. Encoding business concepts in a formal semantic model helps to achieve these goals and also results in additional corollary benefits. This semantic model serves as a focal point and enables automated discovery and transformation services in an organization.

Technology and the Enterprise

Enterprise Information Technology (IT) units exist to support organizational business goals. They must always be aware of the need for alignment, the challenging task of ensuring that every IT decision, in every department, helps the business side of the organization to get its job done, and requires constant monitoring of IT assets to be sure that they correctly describe the organization as the organization understands itself. To this end, it is not enough to follow the common industry practice of creating new data sources or layering new applications on top of existing data sources. Information sources and the applications tying into these sources must function in a smooth and unified manner, thereby allowing units and individuals to work together. When aligned, all stakeholders can coordinate efforts both within an organization (internally) and across organizational boundaries (externally).

Services-oriented architectures are playing an essential role in the drive to integrate information and applications across the enterprise. With SOAs in place, technical teams respond quickly to provide a collection of applications that function as a clearly understandable whole. In this way, they provide a powerful tool to the rest of the organization; in fact, such an integrated process can create as much value as all the existing unintegrated processes.

However, alignment is impossible when business departments misunderstand one another and when IT misunderstands the business. All the XML and HTTP in the world cannot integrate applications attempting to communicate in different terminologies. To ensure accurate communication, every application must be developed in strict accordance with the same standard (an impossibility in the real world), or else information managers must analyze the business concepts underlying the data and the applications, relate these concepts to existing industry and enterprise standards, and then encode that analysis in discovery and transformation logic, hence bridging the barriers. Today, this analysis must be repeated on every project. Even then, it remains painfully error-prone. With this in mind, Gartner recommends that enterprises "ensure that all developers use the same semantics and agree on the message contents at a business level." (See "SOA and Web Services Offer Little Vendor Independence," in Resources.)

Service-Oriented Architectures

"Service-oriented architecture" is among the latest three-letter acronyms to hit the technology world. But buzzword cynics should know: "SOA" does have a real meaning. The SOA approach is to expose enterprise data and business logic in loosely coupled, discoverable, structured, standards-based, coarse-grained, stateless units of functionality (see "W3C Web Services Architecture Working Group" in Resources). These are defined as follows:

• Loosely Coupled. Applications talk to one other and to other databases - without regard for implementation language.
• Discoverable. A Web service's network location is not predetermined and can be looked up at run-time.
• Structured. Messages have an interface (schema) that defines their structure and which can also be discovered. This allows applications to read messages from other applications and data sources without the service provider needing to define the exact message-deserialization code.
• Standards-Based. The message format and schemas are known to all parties.
• Coarse Grained. Each interaction should provide information or functionality achieving real business value; multiple exchanges of information should not be needed for each step in a business process.
• Stateless. Though not an absolute requirement, it is better that each message does not change the state of the application - though data can be stored. This allows lost messages to be resent without complicated transaction-processing logic.

In practice, SOAs are achieved with the Web services standards stack of XML, XSD, WSDL, SOAP, and UDDI; XML for the message format, XSD for the message structure, WSDL to tie together information on the service, and UDDI for service discovery. In addition, vertical-specific standards constrain the schemas of the messages sent.

The goal of smooth integration is not achieved by SOA alone. Web services must be described and understood in a semantically consistent way in order to resolve terminological ambiguities and misunderstandings, and to avoid the constant revision and redefinition of terms, concepts, and elements of the business. Such inconsistencies make for applications that cannot talk to each other, and subsequently result in slower response times when changes are needed. Business managers cannot get a clear view of their organization through these multiple unintegrated "languages."

To take a simple example, a manufacturing report service may indicate that one million units of a product were manufactured, while a shipping report service states that only 100,000 were shipped. Extensive analysis might be needed to determine that the shipping report is designed to report the number of packages shipped, each of which includes ten of the original manufactured units. If the former report is for a week measured Monday to Monday, and includes all shippable and defective products, while the latter is for Sunday to Sunday, and excludes defective items and returns, more confusion ensues.

Semantic Service-Oriented Architecture: See Figure 1

In a semantically based SOA, an information model expresses a common linguistic understanding of the real-world business environment across individual organizations or even across entire industries. This allows executives, analysts, data specialists, and application developers to share a common understanding of concepts relevant to the business, a partnership, or an entire vertical industry. According to Gartner, "Data semantics becomes a critical barrier for SOA as more participants involve more applications." (See "SOA Will Demand Re-engineering of Business Applications" in Resources.)

In the shipping example above, the semantic model includes concepts such as "Manufactured Unit," "Package," "Date," Week," "Shippable/Defective," and the relationship between such concepts; it also relates to the manufacturing and shipping report services themselves. Business rules show the relationship between the different ways of expressing the same concepts. In this way, the meaning of the Web services is formally expressed through relation to an agreed upon set of business concepts.

In terms of metadata, SOA maintenance means that development teams require an inventory of services, back-end systems, inter-service interactions, and different service versions. From an architectural standpoint, the Web service is only as good as its interface as described in Web Service Description Language (WSDL). To create useful Web services, enterprises require a methodology for modeling their common business language and for inferring consistent WSDLs. To maintain accurate interrelationships, Web services must be mapped to the back-end applications they expose, and to each other as the business and its trading partners evolve incompatible WSDL schemas. In the semantic SOA, organizations manage their disparate WSDLs, which are front ends for different data assets, IT systems, business processes, networks, and applications, by reference to a common business architecture expressed and not in implementation-oriented terms, but rather according to the needs of the business.