The IBM advantage for SOA reference architecture standards

IBM SOA standards

This article describes how the SOA reference architecture has been developed and used by IBM to help customers increase business flexibility as well as IT flexibility. The SOA RA reference architecture being used to help organizations achieve advanced levels of business agility and IT flexibility through service integration that are specifically in line with their unique SOA business objectives. IBM is also using an SOA reference architecture along with the Cloud reference architecture to help organizations define their cloud solutions.

Heather Kreger (kreger@us.ibm.com), Destinguished Engineer, CTO International Standards, IBM

Heather Kreger is IBM’s CTO of International Standards and lead architect for SOA Standards in Software Group. She has 15 years of standards experience and has led the development of standards for SOA, Cloud, Web services, Management and Java in ISO/IEC, W3C, OASIS, DMTF, and The Open Group. Heather is the author of numerous articles, specifications, “Java and JMX, Building Manageable Systems” book, and editor of 'Navigating the SOA Open Standards Landscape Around Architecture'.



Vince Brunssen (brunssen@us.ibm.com), Senior Software Engineer, IBM

Vince Brunssen is a Senior Software Engineer at IBM working in the Standards Organization. He is currently leading efforts in OASIS to standardize SOA Repository Artifact Model and Protocol (S-RAMP). He is also a contributor to SOA standards efforts in The Open Group.



Robert Sawyer (rsawyer@us.ibm.com), SOA Marketing Lead, IBM

Robert Sawyer is a product marketing manager for IBM WebSphere, focusing on SOA Solutions. Prior to this role, he worked closely in the event processing space, helping to define IBM's business event processing (BEP) category level messaging and go-to-market strategy. Past roles also include software engineering responsibilities with several IBM groups and products, including ECM, the electronic media management system (EMMS) and IBM SCORE (Solution for Compliance in a Regulated Environment), a healthcare and life sciences industry solution.



Ali Arsanjani, Ph.D. (arsanjani@us.ibm.com), IBM Distinguished Engineer, CTO SOA Emerging Technologies, IBM

Dr. Ali Arsanjani is CTO of SOA Emerging Technologies within IBM Global Services. He leads a team responsible for developing worldwide competency in SOA and increasing delivery excellence of SOA solutions using IBM and non-IBM tools and SOA offerings, most of which he has co-developed. He is responsible for IBM vision, strategy and execution of that strategy in the SOA space of emerging technologies and SOA offerings. He is a hands-on, sought-after architect around the world on IBM's largest accounts. To accomplish this Dr. Arsanjani works with IBM Software Group, Research as well as other parts of IBM Global Business Services to delivery SOA Solutions for clients using IBM tools, technologies and latest SOA offerings. In his role as Chief Architect for the SOA and Web Services Center of Excellence within IBM Global Services, he and his team specialize in harvesting and developing best-practices for the modeling, analysis, design and implementation of SOA and Web Services. He leads the internal IBM worldwide SOA and Web Services Community of Practice (6000+ members) and is the principal author of the (Service-oriented Modeling and Architecture) SOMA method for SOA as well as other assets, offerings and tools around SOA.He has been focusing on SOA Tooling with an extension and plug-in to Rational Software Architect called SOMA Modeling environment (SOMA-ME) which provide tooling support for IBM's SOA Methods and assets for SOA Solution development. This has been described in the August 2008 edition of the IBM Systems Journal. Dr. Arsanjani is engaged in developing SOA competency around the world in multiple industries and countries, working not only to develop teams to support the deployment of IBM tools and assets in the SOA space, but also to engage on a day to day basis with IBM's largest clients. Dr. Arsanjani not only works in executing a global strategy for GBS but also works to assess and develop tools to support IBM's offerings. He represents IBM in standards bodies such as The Open Group and is responsible for co-leading the SOA Reference Architecture and SOA Maturity Model standards within that body. Inside of IBM he leads research efforts in emerging technologies, tools and consulting offerings that combine services with the software required to successfully deliver those services, effectively, in a scalable and repeatable fashion across the world to more than 6000 practitioners.



Rob High (highr@us.ibm.com), IBM Fellow, VP - BPO Foundation, IBM

Rob High is the chief architect for the SOA Foundation, an IBM Fellow, Vice President, and member of the IBM Academy of Technology. He is responsible for ensuring an open industry architectural definition of the principles of business and IT alignment enabled by SOA and Business Process Optimization, as well as ensuring IBM's software and services portfolio is architecturally grounded to enable for efficient SOA-based solutions. This responsibility extends across the IBM software portfolio, including WebSphere, Rational, Tivoli, Lotus, and Information Management products relevant to enabling SOA.



17 January 2012

Also available in Chinese Japanese Vietnamese

Introduction

A Service Oriented Architecture (SOA) facilitates the creation of flexible, reusable assets for enabling end-to-end business solutions. As companies embrace the principles of SOA and the techniques associated with SOA for different types of projects in different industries worldwide the need for a reference architecture has become more evident. The usage of the SOA Reference Architecture is a key enabler for the achievement of the value propositions of an SOA.

The new Open Group SOA Reference Architecture (SOA RA) standard provides guidelines and options for making architectural, design, and implementation decisions in the architecture of service oriented solutions, including the architecture of cloud solutions. The goal of the SOA Reference Architecture standard is to provide a blueprint for creating and evaluating architecture. Additionally, it provides insights, patterns and the building blocks for integrating fundamental elements of an SOA into a solution or enterprise architecture.

The value of SOA

This style of architecture has come to be known as service oriented architecture (SOA), where rather than the implementations of components being exposed and known, only the services provided are published and consumers are insulated from the details of the underlying implementation by a provider. Essentially, the decoupling of interface from implementation at the programming level has been elevated to an architectural level by loosely coupling the interface of a service used by a Service Consumer from its implementation by a Service Provider as well as decoupling the implementation from its binding.

SOA enables business and IT convergence through agreement on a (contract consisting of a) set of business-aligned IT services that collectively support an organization's business processes and business goals. Not only does it provide flexible decoupled functionality that can be reused, but also provides the mechanisms to externalize variations of quality of service in declarative specifications such as WS-Policy and related standards. This loose-coupling enables a more flexible composition of software components in a software solution. This composition enables application developers to more rapidly modify their solutions in response to changes in business requirements. New solutions can be delivered quickly to satisfy new business requirements using this same compositional construct: i.e. by re-using components created in prior applications. Components can be designed to more closely align with discrete business needs for different situations.

Key Business Benefits of SOA

As a flexible and extensible architectural framework, SOA has the following defining capabilities:

  • Reducing Cost: Provide the opportunity to consolidate redundant application functionality and decouple functionality from obsolete and increasingly costly applications while leveraging existing investments.
  • Agility: Structure business solutions based on a set of business and IT services in such as way as to facilitate the rapid restructuring and reconfiguration of the business processes and solutions that consume them.
  • Increasing Competitive Advantage: Provide the opportunity to enter into new markets and leverage existing business capabilities in new and innovative ways using a set of loosely coupled IT services. Potentially increase market share and business value by offering new and better business services.
  • Time to Market: Deliver business-aligned solutions faster by allowing the business to decide on the key drivers of a solutions and allowing IT to rapidly support and implement that direction.
  • Consolidation: Integrate across silo-ed solutions and organizations, reduce the physical number of systems and enable consolidation of platforms under a program of "graceful transition" from legacy spaghetti dependencies to a more organized and integrated set of coexisting systems.
  • Alignment: Enable organizations to better align business goals to IT, enabling the business to associate it with capabilities that an organization wants to achieve in alignment with its strategic plan, leading to both sustained agility and reuse over time.

The purpose and usage of a reference architecture

The purpose of a reference architecture is to provide solution and enterprise architects a standardized blueprint from which to architect solutions for their businesses. As shown in figure 1, architectures, like reference architectures, exist on a continuum from very abstract where architectural decisions and assumptions are identified and not made, to very concrete where most of the assumptions and architectural decisions have been made.

Along this continuum exist domain, industry, enterprise and solution reference architectures. To understand this diagram in its entirety you can reference the Navigating the SOA Open Standards Landscape Around Architecture White Paper that can be found at http://www.opengroup.org/soa/source-book/stds/index.htm.

Figure 1. Reference Architecture Continuum
Reference Architecture Continuum

Reference architectures can be used to set the context for an architecture, to provide a common foundation of understanding for vendors and customers to map products to and design services for, and to articulate a set of building blocks for solutions.

For SOA, reference architectures are used by architects in a variety of scenarios which include jump starting organizations that are adopting an SOA, helping integrators that are providing services in the construction of an SOA, helping SOA product vendors that are building an SOA component(s) to position their products in a standard way that can be understood by their customers and helping organizations that are building other SOA specifications and standards.

The value of a standardized SOA Reference Architecture

The standardization of the SOA RA gives an industry endorsed, vendor neutral starting point for customers creating SOA solutions. As such it can be used in situations where multiple companies are partnering, in spite of changes in vendors or systems integrators, etc. The SOA RA provides a common taxonomy and terminology for designing, building and describing SOA solutions. This can save money and time and improve results.

For organizations that are adopting SOA, the SOA RA helps to create solutions that are driven by business processes, business tools, message exchange, service integration, data access and encapsulating legacy software and components. As architects apply the SOA modeling and delivery methodologies every element of an SOA that is identified is mapped back to the SOA RA providing a view of how the SOA solution is progressing. This also provides a very useful communication tool for business and IT stakeholders within a given company or industry.

The SOA RA is also used to define capabilities and feasibility of solutions. This is done through a checklist of key elements that must be considered when an SOA solution is architected. The SOA RA provides this through a definition of layers and architectural building blocks within those layers. Even taking it a step further within the layers and architectural building blocks there are design decision points and interaction patterns that help to define thee SOA solution. For example, from a technical perspective, the architect needs to answer questions such as:

  • What are the considerations and criteria for producing an SOA solution?
  • How can an SOA solution be organized as an architectural framework with inter-connected architectures and transformation capabilities?
  • How can an SOA solution be designed in a manner that maximizes asset reuse?

In order to address these issues, The Open Group SOA Reference Architecture standard presents a reference architecture for SOA-based solutions. It provides a high level abstraction of an SOA partitioned and factored into layers, each of which provides a set of capabilities required to enable the working of an SOA solution. Each layer addresses a specific subset of characteristics and responsibilities that relate to unique value propositions within an SOA.

Underlying this layered architecture is a meta-model consisting of layers, capabilities, architectural building blocks (ABBs), interactions patterns, options and architectural decisions and relationships between capabilities, ABBs and layers. These will guide the architect in the creation and evaluation of the architecture.

What is going on in the real world with using an SOA Reference Architectures

The path to adopting services and SOA often requires organizations to deal with unique project goals and constraints. Many organizations experiment with Web services (by wrapping existing applications) as a means of exploring the world of service integration, use the results to determine how to proceed beyond an initial phase. Some organizations engage in an enterprise-wide business transformation. Other organizations define their road maps, vision, strategy, and criteria for assessment and governance. For any of those organizations, it’s useful to have an objective standard against which to measure current Service and SOA maturity and to create a roadmap to reach the desired level of maturity not for the sake of maturity alone, but to effect different business outcomes that can result from achievement of a specific level of maturity.

IBM recognized and led the separation of specific technology approaches like Web services from SOA as a solution and business architecture. Through engagement with thousands of customers and governments, IBM established world class industry leadership in the development of SOA solutions, and delivery of products to enable those solutions. IBM has developed industry leading assets to support those engagements. Some of these key, tried and true, assets have been used as the basis of recent Open Group SOA standards on governance, maturity models, terminology, and now The SOA Reference Architecture. Other papers are available to explain how IBM helped develop and now supports these standards on governance and service adoption. This paper will focus on IBM support of The Open Group Standard SOA Reference Architecture, now available here (http://www.opengroup.org/projects/soa-ref-arch/).

Overview of the SOA Reference Architecture

The SOA RA consists of a set of abstractions that collectively provide a, logical design of an SOA. Thus it answers the question of "What is a SOA?" by providing a set of architectural building blocks that collectively answer the question in detail. During assessments of architectures or the design of a solution architecture, or enterprise architecture, the SOA RA allows architects to use its contents such as the building blocks as a checklist of elements: architectural building blocks and their relations in each layer, the options available, decisions that need to be made at each layer. The layers provide a starting point for the separation of concerns needed to build an SOA. Each group of the separated concerns are represented in their own "layer."

The design of the SOA RA provides architects with a blueprint that includes templates and guidelines that are used within the software development life-cycle. These facilitate and ultimately enable automation and streamlining the process of modeling and documenting the architectural layers, the capabilities and the ABBs within them, options for layers and ABBs, mapping of products to the ABBs and architectural and design decisions that contribute to the creation of the SOA.

The SOA RA is intended to support organizations adopting SOA, product vendors building the SOA infrastructure components, integrators engaged in the building of the SOA solutions and standards bodies engaged in developing further specifications for SOA.

Figure 2. Logical solution view of the SOA RA
Logical solution view of the SOA RA

The functionality of the SOA portfolio is realized at the operational systems layer and the component layer. The interfaces exposed are provided at the services layer. Note that these layers have a set of cross cutting concerns such as Integration, Information, Quality of Service and Governance that are included as considerations in each of the above layers. Thus, three of the layers address the implementation and interface with a service (the Operational Systems Layer, the Service Component Layer and the Services Layer). Three of the layers support the consumption of services (the Business Process Layer, the Consumer Layer and the Integration Layer). And four of the layers support cross-cutting concerns of a more supporting (sometimes called non-functional or supplemental) nature (the Information Architecture Layer, the Quality of Service Layer, the Integration Layer and the Governance Layer). The SOA RA as a whole provides the framework for the support of all the elements of an SOA, including all the components that support services and their interactions.

Within each of the layers depicted in figure 2 there are Architectural Building Blocks (ABBs) that represents a basic element of reusable functionality and fulfill the key responsibilities of that layer. Each ABB resides in a layer, supports capabilities, and has responsibilities. ABBs are also connected to one another across the layers and provide a natural association between layers. If a particular connection between ABBs occurs consistently across layers to solve a certain problem this then defines a pattern of ABBs as well as the valid interaction sequences between the architectural building blocks.

Along with the ABBs there are also the capabilities that they support. A capability is defined by the Open Group in TOGAF 9, as "an ability that an organization, person, or system possesses". So, expanding on that definition, ABBs provide the technical resource to allow an organization, person or system to be able to provide their defined capability. An ABB, providing support for one or more capabilities, that can be realized by one or more components or products; examples of the responsibilities of an ABB include: service definition, mediation, routing, etc.

Summary of the layers:

The layers that are defined in an SOA RA are as follows:

  • Operational Systems Layer - The Operational and IT Systems layer captures the organization's infrastructure, both new and existing, needed to support the SOA solution at design, deploy and run time.

    This layer represents the intersection point between the actual runtime infrastructure and the rest of the SOA which runs on that infrastructure. In addition, it is the integration point for an underlying Infrastructure as a Service (IaaS) construct and the rest of the SOA in the wider context of cloud computing. Key requirements for this layer are outlined in the capability section describing the capabilities provided to fulfill those requirements.
  • Service Component Layer - The Service Component layer contains software components, each of which provide the implementation or "realization" for a service, or operation on a service. The layer also contains the functional and technical components that facilitate a Service Component to realize one or more services. Service components reflect the definition of the service they represent, both in its functionality and its management and quality of service interactions. They "bind" the service contract to the implementation of the service in the operational and IT systems layer. Service components are hosted in containers which support a service specification.

    The service component layer enables IT flexibility through encapsulation and by enabling loose coupling. The separation of concerns is such that the consumer assumes that the realization of the service is faithful to its published description (service compliance) and the providers ensures that such compliance is achieved. The details of the realization are of no consequence to the consumer. Subsequently, the Provider organization may decide to replace one component with another with the same description with no impact on consumers of the Service.
  • Services Layer - The Services layer consists of all the logical services defined within the SOA. This layer contains the descriptions for services, business capabilities, and IT manifestation that are used/created during design time as well as service contracts and descriptions that are used at runtime.

    The Services Layer is one of the horizontal layers which provide the business functionality supported in an SOA and describes functional capabilities of the services in an SOA.
  • Business Process Layer - The Process Layer covers the process representation, composition methods, and building blocks for aggregating loosely coupled services as a sequenced process aligned with business goals. Data flow and control flow are used to enable interactions between services and business processes. The interaction may exist within an enterprise or across multiple enterprises.

    The business process layer in the SOA Reference Architecture plays a central coordinating role in connecting business level requirements and IT-level solution components through collaboration with the integration layer, quality of service layer, information architecture layer as well as the services layer.
  • Consumer Layer - The Consumer Layer is the point where consumers, whether if be a person, program, browser or automation, interact with the SOA. It enables an SOA solution to support a client-independent, channel agnostic set of functionality, which is separately consumed and rendered through one or more channels (client platforms and devices). Thus it is the point of entry for all internal and external interactive consumers (humans and other applications/ systems) and services (e.g. B2B scenarios).

    This layer provides the capability to quickly create the front end of the business processes and composite applications in order to respond to changes in the marketplace. It enables channel independent access to those business processes supported by various applications and platforms. This decoupling between the consumer and the rest of the underlying SOA provides organizations the ability to support agility, enhanced reuse and improved quality and consistency.
  • Integration Layer - The integration layer is a cross-cutting concern that enables and provides the capability to mediate, which includes transformation, routing and protocol conversion to transport service requests from the service requester to the correct service provider. It supports the capabilities required for enabling an SOA such as routing, protocol support and conversion, messaging/interaction style, support for heterogeneous environment, adapters, service interaction, service enablement, service virtualization, service messaging, message processing and transformation. The integration layer is also responsible for maintaining the coherency of the solution in the presence of a loosely-coupled system.

    The integration that occurs here is primarily the integration of service component, service, and process layers (the "functional" layers). For example, this is where binding (late or otherwise) of services occurs for process execution. This allows a service to be exposed consistently across multiple customer facing channels.
  • Quality of Service Layer - The Quality of Service layer is a cross-cutting concern that supports non functional requirement (NFR) related concerns of an SOA and provides a focal point for dealing with them in any given solution. It provides the means of ensuring that an SOA meets its requirements with respect to: monitoring, reliability, availability, manageability, transactionality, maintainability, scalability, security, safety, life cycle, etc. It has the same scope as the traditional FCAPS (Fault, Configuration, Accounting, Performance, Security) from ITIL or RAS (Reliability, Availability, Serviceability) The same kinds of management and monitoring that apply to businesses today are important for managing services and SOA solutions and may need extensions to handle the service oriented nature and the cross domain boundaries of many SOA solutions.
  • Information Architecture Layer - The Information Layer is a cross-cutting concern that is responsible for manifesting a unified representation of the information aspect of an organization as provided by its IT services, applications, and systems enabling business needs and processes and aligned with the business vocabulary – glossary and terms.

    This layer includes information architecture, business analytics and intelligence, meta-data considerations and ensures the inclusion of key considerations pertaining to information architectures that can also be used as the basis for the creation of business analytics and business intelligence through data marts and data warehouses. This includes meta-data content that is stored in this layer. It also supports the ability for an information services capability, enabling a virtualized information data layer capability. This enables the SOA to support data consistency, and consistency in data quality.
  • Governance Layer – The Governance layer is a cross-cutting concern that ensures that the services and SOA solutions within an organization are adhering to the defined policies, guidelines and standards that are defined as a function of the objectives, strategies and regulations applied in the organization and that an SOA solutions are providing the desired business value. SOA governance activities shall conform to Corporate, IT and Enterprise Architecture governance principles and standards. The Governance layer will be adapted to match and support the target SOA maturity level of the organization.

Types of Services:

Services are naturally a key concept in any service oriented architecture and it is important to realize that there can be many different categories. The SOA Reference Architecture defines a standard categorization scheme for services. Services here are categorized according to what they do, i.e. their function or purpose (though categories are not mutually exclusive) in order to aid in ensuring both coverage and shared understanding. Of course, other categorization schemes are also possible and helpful.

Partitioning services into groups is a common activity in the development of the services and service portfolio in a services oriented architecture. Categories and groups of services affect how both business and IT views and understands the architecture and the portfolio of services that supports it.

The figure below shows a functional categorization scheme for services found in a typical enterprise.

Figure 3. Types of Services
Types of Services

The categories of services are broken down in figure 3. Services connected to the 'Service Integration Services', such as interaction services, process services, information services, etc., are considered to be domain specific. These are solution specific and require implementations unique to the domain or solution being developed. Domain specific services may be purchased, but generally require extensive customization or extension.

The remaining services categories are considered to be domain independent. These domain independent categories include development services, management services, etc. Services of this category can be used directly in many different domains or solutions. In general domain independent services are used to plan, develop, support and manage the domain specific services in the solution. Often domain independent services can be purchased and used without extensive customization.

Note that the Interaction, Process and Information service categories support the Model-View-Controller Pattern. The value of separating these aspects in the traditional view of architecture still holds true for SOA.

Services categories are:

  • Mediation Services - responsible for binding service consumers with service providers – transparently resolving location to achieve an optimal routing of requests across the network and meet the goals of the business. Mediations typically adds additional value by doing some useful activity, like logging or translation, in addition to the connectivity.
  • Interaction Services – provide the presentation logic of the business design and supports the interaction between applications and end-users.
  • Process Services - include various forms of compositional logic, especially business process flows.
  • Information Services - provide the data logic of business design. Implementations provide access to the persistent data of the business, support data composition of the business, and provide their own sub-architecture for managing the flow of data across the organization.
  • Access Services - integrate legacy applications and functions into the service oriented architecture solution.
  • Security Services - address protection against threats across the vulnerable dimensions of an SOA. They are responsible for protecting interactions between service consumers and service providers as well as protecting all of the elements that contribute to the architecture.
  • Partner Services - capture the semantics of partner interoperability that have a direct representation in the business design.
  • Lifecycle Service – support managing the lifecycle of SOA solutions and all of the elements that comprise them across development and management ranging from strategy to infrastructure.
  • Asset and Registry Services - provide access to the assets that are part of the overall architecture. This includes service descriptions, software services, policy, documentation and other assets or artifacts that are essential to the operation of the business.
  • Infrastructure Services - provide efficient utilization of resources, ensure the integrity of the operational environment, and balance workload to meet service level objectives, isolate work to avoid interference, perform maintenance, secure access to confidential business processes and data, and simplify overall administration of the system.
  • Management Services - provide the set of management tools and metrics used to monitor service flows, the health of the underlying system, the utilization of resources, the identification of outages and bottlenecks, the attainment of service goals, the enforcement of administrative policies and recovery from failures.
  • Development Services – supports the entire suite of architecture tools, modeling tools, development tools, visual composition tools, assembly tools, methodologies, debugging aids, instrumentation tools, and discovery agents needed to construct an SOA solution.
  • Strategy and Planning Services - supports creating vision, blueprint and transition plan for improving business outcomes, along with the services that process the strategies of the business to create an implementation roadmap covering both business and IT.
  • Business Application Services - implement core business logic where the implementations are created specifically within a business model.
  • Business Services - capture the business function and are offered to as course-grained services to external consumers.

The SOA RA provides comprehensive scope and detail. It enables to architects be confident nothing is missed' when thinking about the services and solution building blocks. Based on extensive real world project experience, IBM is uniquely equipped to provide the breadth of experience and products needed to support SOA and this SOA RA standard.

How IBM supports the SOA RA Standard

Services Products

IBM not only has a comprehensive set of fire tested services offerings, but is the market leader in SOA, with experience helping customers with SOA.

Perhaps you have already started your SOA transformation but want an evaluation of how you are doing. Maybe you are experiencing performance issues and would like an assessment of the design, infrastructure or implementation. Perhaps you need help sizing your SOA solution and ensuring the solution will operate under peek loads. IBM Services can help assess your plans and recommended improvements for greater business value. The SOA Diagnostic looks at the overall SOA strategy, governance (including security), infrastructure readiness, and ongoing SOA development projects. In addition we focus on capacity and performance evaluations to ensure your SOA will meet all your business and IT requirements.

The Open Group SOA RA standard is based on IBM's SOA Solution Stack, a key asset that is part of the services mentioned above, as well as Service Oriented Modeling and Architecture (SOMA), IBM's world famous method for identifying the right services for your solution.

Now, IBM is using this breadth of experience in applying SOA to Cloud solutions for your organization. See http://www-935.ibm.com/services/us/index.wss/offerfamily/gbs/a1028751.

Software Products

IBM has the broadest scope of products in the industry to implement the right SOA solution for you. At every step along your roadmap, in every layer of your architecture, you can use IBM products to provide you the right tools and infrastructure for your SOA at any stage in its lifecycle – plan, develop, deploy, manage. IBM uses the following diagram as an architectural reference model to illustrate the aspects of implementing an SOA.

The IBM products and services can also be mapped to the common types of services that the SOA Reference Architecture standardizes:

Figure 4. IBM Software Product Mapping, Part 1
IBM Software Product Mapping
Figure 5. IBM Software Product Mapping, Part 2
IBM Software Product Mapping

IBM brands support the Model/Assemble/Deploy/Manage lifecycle of your SOA solution:

  • Rational supports Model and Assemble by providing tools to model your SOA solution and business processes. It also provides products to support development services.
  • WebSphere supports Deploy by providing runtime for services implementations, service clients, and business processes. It also provides products to support the operational services needed to deploy your SOA solution.
  • Tivoli supports Manage by providing monitoring and operational management of your services, solution, and infrastructure. It also provides products to support Management services.
  • Lotus provides tools to integrate access to people and collaboration to your business processes. It provides support of the Interaction services. Looking at the IBM SOA reference architecture above here is a sampling of the vast array of IBM products available for each of the aspects of an SOA.
  • Information Management supports Deploy by providing information management services throughout the information supply chain.

IBM products provide both support for the layers and the services in the SOA RA.

  • Strategy and Planning Services are provided by Global Business Service's Component Business Modeling (CBM) services which helps you methodically examine your business and identify the right set of business components and services for you. Service Oriented Modeling and Architecture (SOMA) services and tools help you identify the right services for our needs. Rational Unified Process (RUP) for SOMA provides best practice offering accelerates this process, especially for modernizing legacy systems. In addition, IBM Rational sells Rational Systems Architect and Rational Focal Point as tools for enterprise architects which provide decision support system for market-driven product and portfolio management. Rational RequisitePro traces business requirements to goals and steps in the service development lifecycle.
  • Business Services and Events help business analysts capture your business design for documentation, compliance, simulation, and optimization. WebSphere Business Monitor helps you create dashboards for visualizing performance of your business which helps you understand how your business design achieves your business objectives and recommends optimizations. Cognos Business Intelligence provides business reporting, analysis and dashboards on your SOA. WebSphere Operational Decision Management enhances BPM and SOA infrastructures with business insight and awareness around event driven business conditions.
  • Development Services are provided by Rational via Rational Software Architect which provides you a development environment for your business services on Windows, Linux, i, and z systems. Rational Team Concert enables collaborative development in these environments. Rational ClearCase and ClearQuest automate and enforce development processes for better insight, predictability, management, and control of the software development lifecycle. To complement this, IBM Integration Designer helps you create business process flows, state machines, and business rules.
  • Asset and Registry Services are provided by Rational Asset Manager which helps create, modify, govern, find and reuse any type of development assets including those for your SOA solution. WebSphere Service Registry and Repository provides the tools to provide registration and location of services to support late binding to services.
  • Service Integration Services are essentially the Enterprise Service Bus capability and is supported by the WebSphere Enterprise Service Bus which provides a basic fabric for transparent interconnection of services across an enterprise distributed network. It is extended by WebSphere Message Broker which provides message transformations for non-XML data types and provides message based integration. WebSphere Message Queue enables scalable, reliable information exchange across different platforms. WebSphere DataPower SOA appliances augment and accelerate your SOA application, specifically, WebSphere DataPower Integration Appliance XI52 and WebSphere DataPower XML Accelerator XA35 Appliance off loads Web service processing and XML processing respectively.
  • Business Application Services are hosted in WebSphere Application Server, a highly available hosting environment for basic SOA business services and a platform for WebSphere Portal, IBM Business Process Management (BPM) and WebSphere ESB. Standards based programming models for SOA, SCA, SIP, Web 2.0, and JPA are supported. WebSphere Application Server is augmented for scale with WebSphere eXtended Deployment (XD) and WebSphere Network Deployment expands the programming model for common high end computing requirements. WebSphere eXtended Deployment Compute Grid enables sharing business logic across transaction and batch paradigms. WebSphere eXtreme Scale provides distributed caching essential for elastic scalability and next-generation SOA and cloud environments. Business applications are enabled by performant data management systems: CICS, an application and transaction server, and IMS, a transaction and hierarchical database management system. Both CICS and IMS have been enabled for an SOA exploitation.
  • Process Services are supported fully by IBM Business Process Management which is a primary hosting environment for business processing – both flows and business state machines. WebSphere Operation and Decision Management delivers a business rules management system to control and manage business policy and processes. WebSphere Business Events helps businesses detect, evaluate, and respond to the impact of business events based on the discovery of actionable event patterns.
  • Interaction Services are supported by WebSphere Portal which is a hosting environment for the user interaction logic for your SOA application and allows interfaces to be aggregated into a single user page. Lotus Sametime, a unified communications platform, enables invocation of services and engagement of people in business processes. IBM Mashup Center enables you to use dynamic situational applications to connect users with business services.
  • Information Services are provided by data warehousing and information integration products. InfoSphere Master Data Management centrally manages business critical master data across customer, product and account domains in contrast to IBM Information Server which is a data integration platform for complex, heterogeneous, distributed information. Cognos Business Integrator enables you to explore and interact with any data, in any combination and spanning the entire spectrum of time.
  • Partner Services are supported through Sterling B2B Integration and WebSphere DataPower Appliance which enables business to business integration with trading partners via a centralized and consolidated trading partner and transaction management platform for process and data integration.
  • Access Services are supported via WebSphere Adapters which provides adapters to a variety of legacy information systems.
  • Infrastructure Services are supported by WebSphere Virtual Enterprise provides application virtualization to lower cost and increase flexibility, agility, availability and reliability. Virtualization software manages the utilization of middleware and hardware from IBM and other vendors. IBM is a trusted provider of systems, servers and storage for your business, this includes leading edge Power Systems running AIX or Linux, and BladeCenter integrated platforms with built in scalability and manageability. IBM is famous for the unmatched processing power and high availability of our System z Series.
  • Management Services include both security and runtime management. Security is provided by Tivoli Identity Manager, Tivoli Federated Identity Manager, Tivoli Security Policy Manager and Tivoli Access Manager provides a uniform point of administration of users, federation of user information, and privilege management Tivoli Compliance Insight Manager provides a automated user monitoring for security compliance. WebSphere DataPower XML Security Gateway XS40 and XG45 integrates Tivoli's federated identity, security, and directory services into your SOA network processing. Monitoring, provisioning, and automation are supported by Tivoli Composite Application Manager (ITCAM), an integrated product set (including ITCAM for SOA) which enables IT services management across all layers of the SOA RA, Tivoli Intelligent Orchestrator (TIO) which provides support managing and automating your administrative and management workflows, and initiating the workflows in response to events in the information system, and Tivoli Provisioning Manager which extends TIO with workflows for automating the deployment environment for provisioning hardware and software. Tivoli Change and Configuration Management DataBase (CCMDB) is the foundation for automating and supporting change and configuration management processes as described by ITIL, Tivoli Application Dependency Discovery (TADDM) delivers automated discovery and configuration tracking capabilities to build application maps that provide real-time visibility into application complexity. Tivoli Usage and Accounting Manager assesses usage and costs of shared computing resources. Tivoli Business Service Manager (TBSM) provides real-time service availability visibility and intelligence on dashboards, as well as visualizes the health of critical business services and associated SLAs. IBM Systems Director provides platform management of physical and virtual systems across multi-system environments which simplify virtualization.
  • Lifecycle Services are supported by Rational Method Composer is a flexible software development process platform with a best practice library that will help you deliver customized yet consistent process guidance to your project team. Rational Requirements Composer provides visual and textual techniques for capture of business objectives and elaboration of requirements in a collaborative environment. Rational Build Forge automates and accelerates the build and release process.

How SOA lays the foundation for Cloud

The SOA RA, as standardized by The Open Group, applies to Cloud architectures and is the underlying architecture for the IBM Cloud Computing Reference Architecture and has been submitted to The Open Group (IBM CCRA). This section will explain where there are new considerations for cloud architectures and show how they are supported by the SOA RA.

The functional concerns: operational systems, service components, services, business processes and consumer interfaces; all exist in and are relevant to Cloud.

Figure 6. Cloud foundation architecture
Cloud Foundation architecture

For the Cloud architecture, special focus is required for the:

  • Operational Layer: Infrastructure is part of the operational systems layer, but is often highlighted in Cloud architectures because Cloud imposes new requirements on infrastructure to enable broad network access, resource pooling, rapid elasticity, virtualization and scalability.
  • Service Layer: The common cloud service types, *aaS, are located in the services layer. These cloud service types, like other services, use and sometimes expose assets in the Operational systems layer. For cloud services, the type of asset exposed is often the focus of the service type, ie within operational systems, hardware infrastructure is exposed as IaaS, and middleware is exposed as PaaS, and business process as BPaaS.
  • Business Process: Business processes participate in a Cloud solution much like they do in SOA solutions, they can be provided as a service (BPaaS) or be the consumer of services (whether they are cloud services or not). Additionally, business processes within a cloud provider organization need to be restructured and streamlined in novel ways to meet much faster time-to-deliver, time-to-change and cost objectives.
  • Consumer Layer: The consumer layer is more strictly and carefully separated from the services and service provider to allow pooling and substitution of cloud services or providers.

The cross cutting concerns in the SOA RA: integration, quality of service, information and governance: are important concerns for all cloud architectures and solutions, just like they are for SOA. The fact that they are cross cutting means that each of the functional layers may have interactions with capabilities in the cross cutting layers.

For the Cloud architecture, there must be special focus on the:

  • Quality of Service (QOS) layer: The Quality of Service cross cutting concern has additional significant requirements for Cloud for management and security in order to enable on-demand self-service and measured service requirements as well as critical customer requirements for resiliency, security, performance, automated management, operational, and business support. The management support can be represented as a Common Cloud Management Platform in the SOA RA QOS layer, which includes support for operational and business support services, aka OSS and BSS. This is critical for driving economies-of-scale by delivering many cloud services based on the same foundation.
  • Governance for cloud solutions will also have some unique patterns of requirements needed to support governance across organizational boundaries. Providers and consumers will often need to negotiate with cloud providers on how to execute on an iterative governance process that ensures that the cloud solution and services are delivering appropriately and continue to be aligned with business requirements.

For the cloud ecosystem, cloud service consumers, providers and creators are the common high level roles identified in the cloud architectures.

It is important to look at Cloud in the context of SOA, and Cloud solutions in the context of the larger SOA solutions underpinning them.

The cross cutting concerns for integration and information are still important and must be considered in the development of any Cloud solution architecture. However, cloud does not introduce any new principles or concerns to these cross cutting layers.

To make it easier to focus on the Cloud concerns rather than the SOA concern, we can lift the Cloud concerns into its own diagram, as we show in figure 7.

Figure 7. IBM Cloud Computing Reference Architecture
IBM Cloud Computing Reference Architecture

The concepts and architectural elements not depicted in the CCRA are still implied and present via its SOA RA heritage.

Conclusion: Why IBM for building your SOA Solution

A recent Gartner article (Application and Integration Platforms Key Initiative Overview July 22, 2011) advises clients to, "make SOA a prerequisite architecture".

IBM is recognized as the SOA market share leader for 7 years and counting. Wintergreen's recently released their SOA software market, shares and forecasts paper ascribes 78% of the market to IBM, with our nearest competitor at a scant 4%.

IBM possesses the:

Importantly, IBM's SOA strategy is built on open standards – for interoperability and standardization. IBM's leadership in standardization of The SOA Reference Architecture, The SOA Ontology, OSIMM and SOA Governance Framework in The Open Group are examples of our commitment to standards for SOA architects.

Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=788032
ArticleTitle=The IBM advantage for SOA reference architecture standards
publish-date=01172012