accelerate IT

Technology Best Practices

Service Oriented Architecture (SOA)

SOA's primary goal is to provide agility to businesses, allowing them to adapt quickly and cost-efficiently to changes in the marketplace.

SOA separates functions into well-defined components, which computer developers make accessible as services over a network. This makes it possible to run SOA on a variety of distributed platforms, which can be accessed across various networks. Data sharing between different applications is the heart of SOA business applications. These applications are designed to work with APIs, which result in application integration and functionality sharing. Systems located in the same enterprise, as well as different ones, achieve business process integration while adhering to a standardized business process model.

The SOA repository is a database containing metadata, or large amounts of data, which is interactive and constantly changing. This repository allows business-to-business communications through Web services. Test measurements are validated within SOA repositories and workflow support exists throughout the repositories. The SOA repository also includes schemata, policies and processes, which involve the principles and methodologies critical to SOA.

In an enterprise architecture that makes use of an ESB, an application will communicate via the bus, which acts as the single message turntable between applications. That approach reduces the number of point-to-point connections between communicating applications. This, in turn, makes impact analysis for major software changes simpler and more straightforward. By reducing the number of points-of-contact from and to a particular application, it is easier to monitor for failure and misbehavior in highly complex systems and allows easier changing of components.

It is an essential design concept of an ESB that every client directs all its requests through the ESB instead of passing it directly to a potential server. This indirection allows the ESB to monitor and log the traffic. The ESB can then intervene in message exchange and overwrite standard rules for service execution. Possible uses of an intervention are:

  • Buffer and delay a message in a staging area and automatically deliver it when the receiver is ready
  • Monitor messages and services to be well-behaving
  • Enforce compliance with dynamic processing and security policies
  • Marshal service execution based on dynamic rules
  • Prioritize, delay, and reschedule message delivery and service execution
  • Write logs and raise exception alerts

Another common ESB model is "Publish/Subscribe" or Pub/Sub. In this example, the ESB will route data to active data event "Subscribers" from active data event "Publishers". For example, a name change in the customer system may cause a message to be "Published" on the ESB for use by a number of systems un-known to the "Publisher", but managed by the ESB. Data consumers with active listeners for specific event messages called "Subscribers", can then retrieve the name change messages as they are published.

ESB services / Communication Layers

An ESB hosts a large collection of services. There will be many commodity services that are useful and regularly needed by other services. Most services deal with directing and marshaling the routing of messages, doing common and often needed data transformations. Popular commodity service are compressing and encrypting data, splitting data into smaller chunks, filter unwanted data and extract routing information from the content via a rule engine.

Basic commodity services rendered by an ESB are the transformation and conversion of multiple protocols. Delegation of protocol conversion, mapping and transformation to an ESB gives services of many different legacies a convenient and standardized way to easily plug into the bus system, no matter which protocol it decides to use to initiate a request or the response needs to be delivered in. That way even older and exotic legacy systems can be easily hooked up into the SOA without requiring the service client to adapt itself to it.

Commonly needed commodity services:

  • Event handling - Guarantee event processing
  • Protocol conversion - Transparently translate between communication protocols (e.g., HTTP, FTP, REST, SOAP, JSON, DCOM, CORBA, SAP RFC etc.)
  • Mapping - Transfer between tabular data formats
  • Translation and transformation - Change data content based on rules
  • Queuing and buffering - Handle differing data processing speeds between sender and receiver