Manage Learn to apply best practices and optimize your operations.

Building the bridge to SOA

How does an organization reap the benefits of a service-oriented architecture while retaining the performance and value of its custom-built core systems?

Five bridge components help create a vivid mental picture of the five components an organization needs to expose the unique value embedded in their core enterprise systems and extend that value into a modern service-oriented architecture (SOA). What is an SOA, and why is it desirable?

Although SOA is a complicated subject, the basic premise is fairly simple. The idea is to avoid building new applications from scratch each time, and also to avoid duplicating applications, data and business rules in one part of the organization that already exist in another part of the organization. Instead, applications are built quickly out of existing blocks (like a modular home) and draw information from different places throughout the organization without actually changing where the information lives.

The way this happens is that useful "packages" of data and business rules, called services, are "exposed" as unique modules from a core system, ready to be used or consumed by a new business application or process. These services can be reused over and over in different applications and can be strung together with other services in a process called service orchestration. Reuse of services and service orchestration keep applications from being built each time from the ground up. The results of a properly implemented SOA are, among other things, greater agility, better responsiveness to customer and market demands and significant cost reduction.

A couple of elements of the bridge analogy are worth special comment. First, the core enterprise systems form the deepest foundation of the bridge and each of the piles driven down into the foundation signifies a core enterprise system that is essential to the success of the business. Examples of core enterprise systems are a supply chain system in the retail industry, a customer service system in manufacturing, a stock trading system for large financial institutions, and a policy underwriting system in the insurance industry. In each case, these core systems, often residing on a mainframe, provide competitive differentiation for the business that depends on them. The service-enablement of these systems propagates unique business value all the way to the top of the organization – just as the piles of the bridge provide rock-solid stability to the entire structure. Without the piles going into the bedrock, the bridge would eventually shift around and become unstable.

The analogy of the deck is very appropriate. Just as the deck of a bridge delivers the service value of physical support to each of the vehicles that cross the bridge, the deck of the bridge to SOA delivers the value embodied in each of the business services directly to the business users. In both cases, the deck is the interface. Furthermore, just as the deck of the physical bridge handles many kinds of vehicles, the highest level of the bridge to SOA allows services to be used in many ways. Services are used in building composite applications. Services can also be used as components in a business process management implementation or other piece of technology that directly serves the business.

There are five elements of the Bridge to SOA:

  • Application Composition, which assembles new applications from multiple business services with little or no coding required;
  • SOA Policy Management and Enforcement, which defines, manages and enforces service policies across the entire lifecycle;
  • SOA Governance, which facilitates maximum re-use of Web services within and across organizations;
  • High-Value Business Services, which enables Web services to be "strung together" or orchestrated to create new high-value business services that provide greater alignment of the business with IT;
  • Service Enablement, which extends valuable core applications to SOA environments without extensive programming effort.

Data and business rules
When building the bridge to SOA, it's a good idea to start with the familiar—the part that is already in place in most organizations. The data and business rules that make up core enterprise systems, help to differentiate the organization and make the organization successful. A bridge's piles, analogous to service-enabling an organization's core systems, are the starting point upon which everything else is built.

In order to reuse core mainframe assets in future applications, they must be exposed as services at various levels of granularity. The concept of service granularity is very important to SOA and has to do with the level of complexity of the function. A service of coarse granularity performs a complex function. A service of fine granularity performs a simple function. The process of exposing core applications as re-usable services with differing levels of granularity is called service enablement. There are three basic ways to do service enablement: session integration, transaction integration and data integration.

Many core mainframe applications are only accessible through terminal data streams, typically referred to as "green screen" terminals. This implies that the core applications are written in such a way that business rules and data access interfaces are not cleanly separated from the part of the program that can be viewed on a green screen terminal – the presentation layer.

Separating business rules and data access from the sessions in order to achieve service enablement can be expensive, time consuming and/or risky for some organizations. Session integration intercepts the information passed back and forth between the mainframe and the terminal and is able to convert that information into HTML that can be displayed on a Web browser or the session information can be converted into services that can be reused by other applications.

In some cases, core enterprise applications may be well-structured with distinct layers for data access, business rules and presentation. This situation presents another possibility for service enablement to take place. The opportunity in this case is that the transactions can be exposed as services, similar to session integration.

The technique in transaction integration is for a piece of software to put a "wrapper" around a transaction so that the transaction takes on the modular characteristics of a service. It is similar to the way packets of data are sent back and forth between devices in a communications network.

If a core system is not presently well structured, yet will continue to be developed and extended with new functionality, then it is probably worth the investment to reengineer that application to allow for transaction integration instead of session integration. This ensures a flexible environment to quickly meet the variety of future requirements that may arise. There are tools that will aid you in the reengineering process by providing an in-depth understanding of application logic, interdependencies and external touch points.

A successful transaction integration solution must be able to access many types of transactions, regardless of their language or mode of operation. It is equally critical this solution allow the application components to participate in an SOA without introducing change or risk into the environment. Therefore, these core system transactions need to be "wrapped" in such a way that they can be exposed as services without disrupting the original application in any way.

In certain cases, organizations need to gain direct access to data residing in mainframe databases, bypassing the presentation layer and the business rules layer. This is called data integration and it is the third approach to service enablement. In this case, data access logic is used to create a Web services adapter. The new data access service can then be called from another application, perhaps to support creation of a composite application, corporate portal or even to provide data to a business intelligence or reporting tool.

Data access services also provide a great approach for generating reports. Even if the same data is available through an existing application screen, executing a user interface service hundreds or even thousands of times to produce a report isn't the best approach.

Service enablement
Once core enterprise systems have been service enabled it's normal to discover that these Web services introduce additional complexities into the IT environment. For example, it was mentioned earlier that Web services created by wrapping core system transactions may be too fine-grained to be of much value to other applications in the enterprise. Yet for a variety of reasons, creation of these fine-grained services may have been unavoidable, or even the best choice.

What is the proper course of action when a number of services are too fine-grained to serve the needs of the end applications or processes through an SOA? In such cases, it is often necessary to execute multiple fine-grained Web services in sequential steps with additional business logic inserted between the steps. In doing this, a new, more coarse-grained service is created that is much more useful to a variety of business applications. This stringing together of fine-grained services is called service orchestration and a composite service created from such a process is called an orchestrated service or high-value business service.

Typically, the piece of technology used to perform service orchestration is an enterprise service bus (ESB). Service orchestration is not the only function performed by a full-featured ESB in conjunction with a service-oriented architecture. The ESB also performs high-speed messaging, routing and protocol conversion between systems, as well as supports various levels of security. This means you can be assured your service level agreements (SLAs) or other performance expectations will be met.

SOA governance
Service enablement, like a bridge's piles, and service orchestration, like a bridge's footing, are the first two components of the bridge to SOA. They are great tools for building a flexible and reusable IT architecture that enables a business to react quickly to new market conditions and customer expectations. However, when the adoption of services expands to dozens, hundreds, or even thousands of services in the organization, a number of new challenges appear. With many fine-grained and coarse-grained services being created and reused, the organization must be able to track information about the services.

The obvious question is whether a single technology or set of tools exists that can enable the process of SOA Governance. Analysts agree that a full-featured SOA registry/repository can provide excellent support for a program of SOA Governance. A registry/repository provides standard interfaces so that those who produce services can publish them and allow others in the organization to find those services and reuse them. A registry/repository also allows service producers to attach service contracts to their services, stipulating usage rights, security settings and other important parameters that must be respected by anyone who wants to re-use the services.

Consumers can be assured that whenever they bind or connect to a service, they will do so with the latest service contract. Likewise, service producers gain the ability to track how their services are used and by whom. The resulting implementation of the services registry/repository greatly increases the communication between the service producer and consumers, as well as the development teams. It is the central mechanism from which the various development teams can obtain the latest information regarding the service they need.

Service enablement brings the value of core applications forward into a service-oriented architecture. Service orchestration, through an ESB, creates the kinds of coarse-grained services that are most useful to the business and are most likely to be re-used in a variety of new applications. SOA Governance, through a registry/repository, brings vital control to the process of service re-use, facilitating positive relationships between service creators and service consumers throughout the organization.

Once services are exposed and made available for consumption by various applications they are only at the beginning of the SOA lifecycle. Each service will take on a life of its own as it is consumed in various applications and as changes are made (or not made) to the system(s) from which the service calls data and business rules. All of the changing variables throughout the life of the service have the potential to wreak havoc within the enterprise infrastructure unless various SOA policies are created, managed and enforced. These policies serve to regulate each service throughout its lifespan.

Governing the SOA lifecycle requires specific technology, a scalable SOA policy management platform that can span design, runtime and change time governance requirements. This platform sometimes also includes the registry/repository, combining all aspects of SOA governance under a single umbrella.

One upside of an SOA policy management platform is that it can accelerate SOA adoption by making it easy to synchronize policy enforcement across the SOA lifecycle. Another upside is that SOA policy enforcement technology can enable organizations to consistently meet their SLAs and key performance indicators (KPIs) and automate the SOA processes that support their business objectives.

While service enablement and orchestration came about fairly early in the SOA movement, the need for sweeping policy management and enforcement only became abundantly clear when SOA entered widespread adoption by organizations worldwide. It seems that the early adopters of SOA had little idea how much genuine chaos would be created within the enterprise by the phenomenal success of the methodology they were pioneering. SOA governance, including registry/repository and policy management and enforcement, can now help IT organizations ensure that there is never too much of a good thing.

The composite application
Clearly new applications such those as discussed throughout this article, and the business goals they serve, are one of the primary reasons to build an SOA in the first place. These new applications are the result of a process called application composition and are known as composite applications. They are not developed in the traditional manner, by writing line after line of code in a language such as Java or .NET or COBOL. Instead, composite applications are created in a modular way by combining Web services available both inside and outside the enterprise.

Composite applications are typically accessed by the business user on a Web browser similar to Google or Yahoo, and, in fact, Google Maps is a popular component of many composite applications found on the Web and in business environment. Yet these applications must also have enterprise-level speed, performance and graphical interaction capabilities associated with sophisticated desktop applications.

Efficient, codeless assembly of composite applications for business users requires an enterprise-class Web application development environment. Such a development environment will often have impressive built-in functions, such as Web 2.0 features, sophisticated user management, role-based security and document management capabilities.

Application Composition completes the Bridge to SOA because the user of composite applications will actually be using services to call vital information out of the organization's core systems. Previously a business user might only have accessed this information in isolation by requesting a report from IT or sitting in front of a special green-screen terminal. Now they can receive the information transparently, in a graphical browser on their own computer, in a context that makes sense for the particular business problem they are trying to solve.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.