Web Methods - SOA Reference Architecture

SOA Reference Architecture Defining The Key Elements Of A Successful SOA Technology Framework

May 2006

©2006 webMethods, Inc. All rights reserved.

TABLE OF CONTENTS

INTRODUCTION......................................................................................................................... 3

SOA REFERENCE ARCHITECTURE........................................................................................ 4 SERVICES: THE UNDERLYING BUILDING BLOCKS OF SOA....................................................... 5 MESSAGING: ENABLING SERVICES TO COMMUNICATE AND INTERACT ..................................... 6 REGISTRY: PROVIDING THE BASIS FOR REUSE ....................................................................... 7 SERVICES MANAGEMENT: ADDRESSING SERVICE LEVELS AND GOVERNANCE .......................... 7 ORCHESTRATION: LINKING SERVICES INTO BUSINESS PROCESSES.......................................... 8 ANALYSIS: ENABLING CONTINUOUS PROCESS IMPROVEMENT ............................................... 10 USER INTERACTION: INCORPORATING PEOPLE INTO THE SOA EQUATION.............................. 11

SUMMARY................................................................................................................................ 12


INTRODUCTION

Companies across all industries and geographies are becoming increasingly interested in service-oriented architecture (SOA). The basic concept behind SOA is not new – that is, the idea of accelerating return on IT investment by turning those assets into reusable building blocks from which new business functionality can be assembled quickly and efficiently. But what makes SOA different is that, for once, the IT industry as a whole has backed the concept and the core underlying technologies, giving SOA massive support and evolving a wide range of standards to make the idea really work. As a result, it has become possible to bring together a broad spectrum of heterogeneous IT assets into a uniform collection of reusable parts, thereby enabling the rapid and efficient assembly of the new systems that modern business demands.

There are many aspects to SOA that must be addressed in order to succeed. Perhaps the most important is a clear understanding that SOA is not just about technology – it is also an IT strategy to support business transformation and, as such, SOA has extensive organizational, procedural, and process implications. These factors aside, when focusing on the technology dimension of SOA the critical success factor is to ensure that the necessary framework of tools and technologies is in place.

This paper addresses these particular issues by introducing an SOA reference architecture that can be used as a blueprint for delivering the appropriate technology environment for SOA success. Among other objectives, this reference architecture provides a checklist of the key functional areas required to get the most out of SOA investments.


SOA REFERENCE ARCHITECTURE

The webMethods SOA reference architecture is designed to cover all areas of functionality required to support a successful SOA implementation, and it is the result of a logical set of deductions based on the nature and objectives of SOA and webMethods’ experience in the real-world issues of deploying SOA-based production solutions.

The starting point for building the reference architecture is services. An SOA is built around the concept of a business service, this being a reusable piece of logic designed to execute a piece of business process with standard access and invocation interfaces. So the first capability of any SOA reference architecture has to deal with service creation, whether formed of old components or newly written ones.

Once these services have been created, the power of an SOA is derived from joining these services together. The most flexible way to achieve this is to opt for the ‘loosely-coupled’, platform-independent approach of messaging. Now services can be joined together, but there will be no reuse unless it is easy to find out what services exist and what they do, and so a registry capability is required where services can be catalogued in a central repository. Once services become a key part of business operations, the next challenge involves understanding the actual behavior and usage of these services in the production environment. This requires a level of services management technology that not only follows what is happening with the services, but also provides essential governance functionality.

An important aspect of SOA services is that they are clearly related to pieces of business functionality, rather than simply being an IT-centric piece of code. This now allows these services to be assembled into a complete business process by using orchestration technology that can handle service flows to ensure correct execution of the process, based in its business rules and policies. This relationship between business processes and the IT components that underpin them now makes it possible to look at the behavior of the operational system in business terms, and this in turn makes it possible to use analysis technology to understand and predict business performance and the impact of change.

Using these technology areas, IT systems can be matched much more closely to business needs, and change can be handled quickly and efficiently. The final piece of the puzzle is to ensure that the end-user can take advantage of these new capabilities with minimal disruption and retraining. User interaction technology such as personalized portals and role-based tools will limit the disruption of SOA deployments—in terms of changes introduced on the user’s desktop—while improving user productivity and effectiveness.


The diagram below summarizes the SOA reference architecture.

Services: The Underlying Building Blocks Of SOA

The two key requirements of the services functionality in the reference architecture are (1) to allow new services to be created from scratch, for example in Java or .NET, and (2) to enable existing applications to be exposed as SOA services. The most commonly used approach is to make services available as Web services, making use of the considerable standards work done in this area.

Dealing with new services is relatively easy. The main requirement is to ensure that these services are container-independent – that is, the caller of the service should need no knowledge of the environment in which this service will be running. Tools should be provided to support the development of these services and to register them in the corporate repository.

Exposing existing applications as services is more problematic and requires smart technology, such as adapters to the different systems and application environments used by the applications, and wrappers to make these applications look like standard Web services. The problem is that the caller must be shielded from understanding anything about the environment in which the application is running. Therefore, it may be necessary to map different protocols or data formats, using features found in the messaging layer of the reference architecture. But, in addition, decisions may need to be made about the level of service granularity to be used. For example, consider a service for obtaining customer details, including address, contact information, and transaction history, where


these three operations are actually carried out by three separate mainframe applications. Turning each mainframe application into a service might look obvious, but might prove to perform badly since anyone wanting customer details from outside the mainframe would need to make three service calls with six associated trips to and from the mainframe as well as any associated data mappings. An alternative would be to provide some sort of linkage mechanism on the mainframe side that could combine the three operations into a single service.

Key areas of differentiation in this services layer are the ease with which services can be created or exposed, the number of legacy environments supported, and the skill levels required. This last point is particularly important given that services might be built up of parts running in completely different environments such as mainframes or UNIX or Windows servers.

Messaging: Enabling Services To Communicate And Interact

The messaging layer represents the communications capability that allows different components and services to interact within the SOA. The term ‘messaging’ reflects the fact that messaging middleware is frequently the best choice for addressing this need, because of the specific requirements. First, the connectivity must be able to deal with a multi-platform environment, since many platforms may be involved. Second, it needs to be ‘connection-independent’ – that is, the service requestor and service provider should be loosely coupled rather than tightly bound. This is important to achieving the goal of container-independent services and provides the inherent flexibility and operational stability of an SOA. This is usually implemented by using an asynchronous messaging approach, although synchronous messaging may also be required.

Now, just providing the connectivity to allow components and services to interact in a connection-independent way is not enough. In order to achieve clean interfaces between services, data formats may have to be manipulated. The issue is that different programs may have different expectations for data formats; therefore, in order to establish the level of independence an SOA requires, it may be necessary to map one data format into another. In this way, each program receives and outputs data in its native format, with the messaging layer transforming between data formats as required.

Finally, in order to create business services, it is often necessary to implement business rules. For example, a funds transfer service might need to have a supervisory approval step if transferring more than a specified amount. For this reason, the messaging layer also needs to offer some intelligent routing capability to allow the process flow making up the service to be altered based on business policies and conditions.

Differentiators within this layer include the reliability of the messaging layer and its performance capabilities. Some operations may well require guaranteed, once-only communications while others will want to optimize performance rather than recoverability. Another differentiator will be the extent to which the use of standards is a concern. In fact, most messaging layers will make use of the Java specification for message services, JMS.


Registry: Providing The Basis for Reuse

In typical SOA scenarios, the registry is positioned as the repository for information related to Web services. In this reference architecture, however, the registry layer has a broader definition in that it also encompasses the tools required for the registry to play its key role in the SOA implementation effectively. So, at the basic level, tools must be provided that enable services to be modeled, created, and stored. In addition, an import/export capability should be required – some services may have already been created using different technologies or products, and sharing services is a useful and important productivity aid.

Because of the importance of the registry, it is necessary to provide interfaces to monitoring and management tools through which registry activity can be controlled and also to ensure the availability and performance characteristics of the registry. For instance, because the registry will be key to real-time operations, it may be desirable to federate the registry across a range of different locations and environments. Replication might also be of interest to protect against any impact to this critical data store, and a fail-over capability combined with the ability to re-route around problems will help to ensure that registry availability is not an issue.

Then there is the question of usability. For an SOA to be effective, it is vital that programmers can easily find services they can reuse. Otherwise, developers might be tempted to take the potentially more interesting option of writing the functionality themselves, creating redundancy and detracting from one of the key advantages of an SOA. So the registry layer of the reference architecture must offer easy-to-use browse facilities and clear descriptive information about the services so that programmers can quickly identify the specific services that will be of value to them. In addition, because a successful SOA strategy will result in high levels of reuse, it becomes essential that programmers are alerted to any changes to services in the registry, since these changes might affect the way different parts of business operations work.

The registry should also hold a range of associated attributes for each service. These might be dependent on business policies, for example when and where information should be encrypted as it passes between SOA components, or could be installation-relevant attributes such as the name of the service creator. The important factor to consider is that the registry should hold all relevant information regarding each service and present it to browsers in an easily digestible way.

The key differentiator in the registry layer will be the extent to which functionality extends beyond the basic repository requirement to encompass all the other ancillary areas. Many companies looking to SOA have the idea that the registry is just a repository for Web services definitions such as WSDL (Web services Definition Language), but in reality it is much more than this.

Services Management: Addressing Service Levels and Governance

So far, the reference architecture has dealt largely with the mechanics of creating or exposing services, linking them together, and managing their use. However, for success


from a run-time operations perspective it will be imperative that support is provided for managing these services, particularly as numbers start to climb from tens to hundreds or thousands. There are essentially two different areas to consider in this regard: services execution and governance.

On the execution front, facilities are needed to monitor the availability of services and their performance and take appropriate actions when quality-of-service problems occur (such as slow response time). Reporting mechanisms are required, ideally providing both real-time and off-line statistical summaries of operational activity. Support must be provided to allow services to be quiesced, taken off-line, and restarted. Fault avoidance and fault tolerance mechanisms should also be put in place, such as fail-over support and the ability to re-route around failures. Once performance is being monitored, it also becomes desirable to start tracking the Service-Level Agreement (SLA) status of individual services. This is important when trying to ensure that the SOA is serving the business appropriately and delivering the expected benefits. Businesses should be able to specify what the service level requirements are for individual services, and then IT should have the ability to monitor the SLA to detect any out-of-compliance situations.

From a governance perspective, controls are needed to manage development- and change-time access requirements and the processes around modifying and changing services. Audit trail requirements will demand a logging capability, and it should also be possible to track the occurrence of particular business events. This business event tracking is based upon the characteristic of an SOA where services actually represent some distinct business operation. This enables operational information to be related to an actual business event rather than a technical occurrence. In addition, change management will require a clear picture of dependencies between services as well as some sort of service versioning support.

Orchestration: Linking Services into Business Processes

One of the major attractions of SOA is the ability to support dynamic process reconfigurations, delivering much improved business agility. But this cannot be achieved unless some sort of process orientation can be layered on top of the technology components. This is the purpose of the orchestration layer in the reference architecture. The orchestration layer allows processes to be declared in business flow-chart terms, mapping beneath the covers to the individual services that make up the process. Now, when the process needs to be changed to support a new business objective, this can be done quickly and easily by simply linking into the new supporting services.


Figure 2: Reference Architecture - Orchestration

In order to offer this facility, the orchestration layer needs to provide the ability to define and model processes (see figure above), and to analyze them to understand the impacts of any changes. As well as system-to-system interactions, the orchestration layer will also need to deal with human workflow elements where the process passes through a human touch-point. This places distinct requirements on the orchestration layer, such as the ability to manage the assignment of work and tasks to individuals as well as groups, and handle long-running tasks spanning days rather than seconds. This is an important distinction given that in a human-intensive workflow, such as an insurance claims assessment process, there may be long periods between different steps. This may require the system to maintain transaction state for days or weeks, and this need must be addressed by the orchestration layer of the SOA reference architecture.

Finally, the orchestration layer needs to provide support for monitoring and management capabilities at the process level, rather than at the level of the individual service components underneath. It must be possible to start and stop processes, rather than the underlying services and components, and to understand how the process is behaving at an end-to-end level.


Analysis: Enabling Continuous Process Improvement

Once the SOA has been assembled and is operationally active, with a process view enabled through the orchestration layer, attention can turn to business and operations improvements. Because operations can be understood at the process level, it now becomes possible to deal with business performance as it relates to process metrics and business events rather than technology considerations. The analysis layer of the reference architecture provides for these events to be tracked, recorded, and managed. These events form a valuable view of the performance of the business and, as such, provide excellent insight into understanding patterns of business operations and the ability to evaluate them. A facility should also be provided to display the event-related information in order to support improved management decision-making. In short, the analytics layer is what enables businesses to refine and improve their operational business effectiveness (see Figure 3).

Figure 3: Reference Architecture – Analysis

This ability to analyze operations from the business perspective can be particularly valuable when putting in place necessary compliance measures and processes. Once the business behavior of the real-time system can be monitored and understood, it becomes possible to match that behavior to regulatory or corporate policy requirements in order to detect out-of-line situations. This, in turn, ensures that companies can respond much more quickly and effectively to compliance failures, mitigating any associated penalties.


User Interaction: Incorporating People Into The SOA Equation

The final layer in the SOA reference architecture reflects the fact that modern businesses have to be highly reactive and agile, and users must be provided with radically streamlined ways of interacting with business applications. Traditional application programmers have to understand many complex factors in designing and developing their applications, based on the fact that business logic is intertwined with technologies and legacy implementations. But the SOA approach makes it possible for a new breed of application developers to work in a highly personalized, simplified environment. The user interaction layer provides facilities that enable the new breed of application developer to assemble composite applications from a set of uniform building blocks, that is, SOA services. This can be achieved in a portal-style environment where web applications are assembled with no coding at all, simply bringing together different SOA services with an individual portlet.

An effective user interaction layer will enable companies to achieve dramatic time-to-market improvements for new initiatives, efficiently and without the need for high-cost specialized skills.


SUMMARY

SOA offers attractive advantages to companies across all industries as they strive to get increased levels of return from IT investments while delivering the level of agility that competitive business demands. The development productivity and quality of service benefits of reuse offer the potential not just for IT to deliver better service in the near term, but also to ensure that the benefits increase proportionally over time as levels of reuse increase. At a higher level, the ability to gain a clearer view of process execution across the business and to analyze, understand, and act upon this information presents the opportunity for significant improvements to overall business performance and effectiveness. Bringing all of this together, SOA enables companies to address new business challenges with a great deal more agility, quickly composing new business services without the need for extensive investment or skills.

This level of increased competitiveness is only possible by ensuring that the appropriate groundwork has been done and that the foundations to support these benefits are in place. From an IT perspective, the SOA reference architecture is designed as a blueprint for this foundation, outlining each required layer and its associated capabilities so that informed decisions can be made about product selection and implementation. These details may differ between different technology suppliers, but as long as the general principles of the SOA reference architecture are followed then the likelihood of SOA success will be greatly increased.

Worldwide Headquarters 3877 Fairfax Ridge Road South Tower Fairfax, VA 22030 USA Tel: 703 460 2500 Fax: 703 460 2599 US West Coast 432 Lakeside Drive Sunnyvale, CA 94088 USA Tel: 408 962 5000 Fax: 408 962 5329 European Headquarters Barons Court 20 The Avenue Egham, Surrey TW20 9AU United Kingdom Tel: 44 0 1784 221700 Fax: 44 0 1784 221701 Asia-Pacific Headquarters 6 Temasek Boulevard, #24-01 Suntec Tower Four 15 Blue Street Singapore 038986 Tel: +65 6389 3200 Fax: +65 6389 3299 webMethods Japan KK Izumi Garden Tower 30F 1-6-1 Roppongi, Minato-ku Tokyo 106-6030 Japan Tel: 81 3 6229 3700 Fax: 81 3 6229 3701 www.webMethods.com

©2006 webMethods, Inc. All rights reserved. The webMethods logo and Get There Faster are trademarks or registered trademarks of webMethods, Inc. All other names mentioned are trademarks, registered trademarks or service marks of their respective companies.

ABOUT WEBMETHODS, INC.

webMethods provides total business integration to the world’s largest corporations and government agencies. webMethods’ flagship product suite, webMethods Fabric, is the only integrated platform to deliver both SOA and BPM, delivering rapid ROI to our 1,300 customers around the globe. With webMethods, customers can take a process-centric approach to their business problems, allowing them to leverage their existing IT assets, dramatically improve business process productivity and ROI, and rapidly create competitive advantage by making their business processes work harder for their company.

webMethods (NASDAQ: WEBM) is headquartered in Fairfax, VA, and has offices throughout the United States, Europe, Asia Pacific and Japan.

Copyright © 2006 webMethods, Inc. All rights reserved.

Trademarks The webMethods logo, Get There Faster, Smart Services and Smart Processes are trademarks or registered trademarks of webMethods, Inc.

Other product names used herein may be trademarks or registered trademarks of webMethods or other companies.

Statement of Conditions

webMethods, INC. PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL WEBMETHODS BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS, LOSS OF USE OR DATA INTERRUPTION OF BUSINESS, OR FOR INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY KIND, EVEN IF WEBMETHODS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES ARISING FROM ANY DEFECT OR ERROR IN THIS PUBLICATION OR IN THE WEBMETHODS SOFTWARE. webMethods, Inc. may revise this publication from time to time without notice. Some states or jurisdictions do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statement may not apply to you. All rights reserved. No part of this work covered by copyright herein may be reproduced in any form or by any means—graphic, electronic or mechanical—including photocopying, recording, taping, or storage in an information retrieval system, without prior written permission of the copyright owner.

RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the U.S. government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 (October 1988) and FAR 52.227-19 (June 1987).

Web Methods - SOA Reference Architecture

Documents

Transcript of Web Methods - SOA Reference Architecture