SOA terminology overview, Part 1: Service, architecture, governance, and business terms

Level: Introductory

Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM

Learn some basic SOA terminology in this first part of a series. Bertrand Portier defines terms including service, architecture, Service-oriented architecture, governance, and business process -- and explains why they are fundamental to the success of SOA. He also introduces key graphics from the IBM SOA foundation.

Introduction

Semantics are essential in any domain and especially in Service-oriented architecture (SOA). Since SOA spans teams and organizations, agreement upon relevant terms is crucial. This series provides a tour of SOA by defining terms and the key concepts behind them. You will learn the vocabulary necessary to communicate in the SOA field. For each term, you will understand why it is important for SOA, what it means in this context, what the relevant standards are, and how the term differs from others.

A note about organization

The terms listed below are not organized alphabetically, nor are they shown in order of importance. Rather, they are organized in a building-block fashion. We begin with "service", as it is probably the most fundamental concept for an understanding of the SOA framework. We build upon service with definitions of "architecture", "governance", and "business" concepts. In many cases we've broken down the larger terms into their components.

Service

Services are obviously at the heart of Service-oriented architecture, and the term service is widely used. However, it means different things to different people and the question "What is a service?" often leads to long arguments. I have heard people talk about business tasks, business services, application functions, technology services, or infrastructure services. Let me give you a definition, based on the IBM Rational® Method Composer Plug-in for SOA Governance and the IBM Rational® Unified Process for Service-Oriented Architecture. Please see the Resources section for more information).

"A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

It is a difficult task to start this article by defining "service" because of the variety of definitions it elicits. For example, you may find the above definition too technical. Please bear in mind that it is important not to rely too much on a formal definition of a service, but rather focus on the key concepts behind services, including:

• Business alignment: Services are not based on IT capabilities, but on what the business needs. Services business alignment is supported by service analysis and design techniques.

• Specifications: Services are self-contained and described in terms of interfaces, operations, semantics, dynamic behaviors, policies, and qualities of service.

• Reusability: Services reusability is supported by services granularity design decisions.

• Agreements: Services agreements are between entities, namely services providers and consumers. These agreements are based on services specification and not implementation.

• Hosting and discoverability: As they go through their life cycle, services are hosted and discoverable, as supported by services metadata, registries and repositories.

• Aggregation: Loosely-coupled services are aggregated into intra- or inter-enterprise business processes or composite applications.

These combined characteristics show that SOA is not just about "technology", but also about business requirements and needs.

It is also important to note that not everything is a service. For example, there are IT functions that should not be exposed as services. Analysis techniques such as IBM's Service-Oriented Modeling and Architecture (SOMA) exist to identify the list of appropriate services based on the concepts listed above. We will cover these aspects (including all of the bold terms in this section) in detail in the course of this article.

Architecture

Like services, it is difficult to find an agreed-upon definition of architecture. However, unlike services, architecture is sometimes forgotten when people talk about SOA, and it clearly should not be! In fact, enterprise architecture and Service-Oriented Architecture share common goals around supporting the business with an integrated IT strategy. Enterprise architects, for example, are key to the success of SOA, as they look at the strategic evolution of an enterprise’s IT systems based on evolving business needs and demands.

The Open Group Architecture Forum (TOGAF) provides two definitions for architecture, based on context:

1. "A formal description of a system, or a detailed plan of the system at component level to guide its implementation.

2. The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time."

These two definitions are relevant to understanding the "A" of SOA. Breaking it down even further, we find that architecture is necessary to do the following:

• Design and model at different levels of abstractions

• Separate specification from implementation

• Build flexible systems

• Make sure business requirements are addressed

• Analyze the impact of a change in requirements

• Ensure principles are followed

Enterprise architecture

Here is the definition from Wikipedia:

"Enterprise architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction.

The primary purpose of creating an enterprise architecture is to ensure that business strategy and IT investments are aligned. As such, enterprise architecture allows traceability from the business strategy down to the underlying technology."

You may think of "architecture" at the project-level, and "enterprise architecture" at the organization level. Note the reference to processes, information systems, personnel, goals, strategy, and business IT alignment.

Service-Oriented Architecture

Service Orientation

As described in the IBM SOA foundation white paper, "... service orientation is a way of integrating a business as a set of linked services." Please see Resources to learn more about IBM’s SOA foundation.

A key word here is "business". For example, service orientation provides the flexibility of implementing business processes with services from one line of business (LOB), across LOBs, and with business partners.

SOA foundation reference model

The IBM SOA foundation includes an SOA reference model, as in in Figure 1, which shows the key capabilities equired to support Service-Oriented Architecture.

Because this model is itself based on service orientation, it allows for the incremental adoption of SOA as new business requirements arise, starting from small projects, and gradually broadening integration across the enterprise. Please refer to the Resources section for links to more information on the SOA foundation.

Figure 1. The SOA foundation reference model

Service-Oriented Architecture

SOA is defined by IBM's SOA foundation as follows:

"Service-Oriented Architecture (SOA) is an architectural style for creating an enterprise IT architecture that exploits the principles of service-orientation to achieve a tighter relationship between the business and the information systems that support the business."

SOA has the following characteristics:

• It enhances the relationship between enterprise architecture and the business.

• It allows the building of composite applications as a set of integrated services.

• It provides flexible business processes.

Service-Oriented Architecture implies new roles in the enterprise, new ways of collaborating, new supporting frameworks and new types of software artifacts in an evolutionary (as opposed to a "revolutionary") way.

SOA solution stack

The SOA solution stack, shown in Figure 2, is an SOA reference model depicting the conceptual (high level of abstraction) view of an SOA solution.

Sometimes referred to as "the SOA layered architecture", this model introduces layers and concepts such as business process, service, or service component, as well as the relationships between them.

It is independent of the technology used for implementation. This separation is important, as you will see in the Model-Driven Architecture (MDA) section in Part 2 of this series.

Figure 2. The SOA solution stack

The five functional layers are as follows (bottom to top):

• Operational systems: Represents existing IT assets, and shows that IT investments are valuable and should be leveraged in an SOA.

• Service components: Realize services, possibly by using one or more applications in the operational systems layer. As you can see on the model, consumers and business processes do not have direct access to components, but just services. Existing components can be internally reused, or leveraged in an SOA if appropriate.

• Services: Represents the services that have been deployed to the environment. These services are governed discoverable entities.

• Business Process: Represents the operational artifacts that implement business processes as choreographies of services.

• Consumers: Represents the channels that are used to access business processes, services, and applications.

The four nonfunctional layers are (left to right):

• Integration: Provides the capability to mediate, route, and transport service requests to the correct service provider.

• Quality of service: Provides the capability to address the nonfunctional requirements of an SOA (for example, reliability and availability).

• Information architecture: Provides the capability to support data, metadata, and business intelligence.

• Governance: Provides the capability to support business operational life cycle management in SOA.

Refer to the "Design an SOA solution using a reference architecture" article for a more detailed explanation of the SOA solution stack.

Governance

Governance is necessary for the successful adoption of SOA partly because of the cross-organizational nature of SOA where service funders, designers, implementers, maintainers, or consumers are not located in the same organization, business, IT department, LOB, division, or enterprise.

This section contains definitions from the IBM Rational Method Composer Plug-in for SOA Governance. It defines governance, IT governance, SOA governance, and the difference to management or compliance. It also describes the challenges addressed by SOA governance. Please see the Resources section for links to more information on Rational Method Composer.

Governance

"Governance is about:

• Establishing chains of responsibility, authority, and communication to empower people (decision rights)

• Establishing measurement, policy, and control mechanisms to enable people to carry out their roles and responsibilities

Governance looks at assigning the rights to make decisions, and deciding what measures to use and what policies to follow to make those decisions. The decision rights are assigned to roles, not to individuals. Management, on the other hand, includes assigning staff to the roles and monitoring the execution of policies.

Part of any governance solution is meeting the organization's compliance requirements. Compliance is documenting and proving that governance is in place and is being executed: decisions are documented and decision policies are followed."

IT governance

"IT governance refers to the aspects of governance that pertains to an organization's information technology processes and the way those processes support the goals of the business."

IT governance may be characterized by assigning decision rights and measures to IT processes.

SOA governance

"SOA governance is an extension of IT governance specifically focused on services and other SOA artifacts' lifecycle."

Specifically, SOA governance focuses on the methods and processes around service identification, funding, ownership, design, implementation, deployment, reuse, discovery, access, monitoring, management, and retirement.

"SOA governance addresses challenges such as:

• What new organizational roles and structures facilitate service identification, design, and sharing?

• What metrics support investment, maintenance, vitality, and sharing of services?

• How do businesses decide to invest in service creation and maintenance?

• What is an enterprise’s service-orientation maturity?

• What education, training, or mentoring is required?"

Life cycle

Service life cycle

Service life cycle comprises the states services may be in and the events that trigger transitions between these states.

Through their lives, services go through many stages or phases (like us ;-) ). Think of a service's life cycle as a business state machine with states (positions) in which services can exist, and transitions that make them evolve from one state to another.

SOA governance is about planning, defining, enabling, and measuring around the service life cycle. SOA governance defines what the service states are, what actions need to happen to move from state to state (transitions), how (processes and methods), and by whom (roles, guards).

For example, SOA governance can define that services states are identified, funded, specified, implemented, approved, operational, published, deprecated, and retired.

The underlying SOA framework then needs to support services through their life cycles and make sure the processes in place are followed. For example, service registries and repositories need to allow users to take action so that services evolve through their life cycle. Collaboration and portfolio management tools need to allow users (and just those who have the rights) to make decisions that will move services from one state to another, and notify users that need to take action.

SOA life cycle

The IBM SOA foundation uses four phases in its definition of the SOA life cycle:

• Model includes business analysis and design (requirements, processes, goals, key performance indicators) and IT analysis and design (service identification and specification).

• Assemble includes service implementation and the building of composite applications.

• Deploy includes application deployment and runtimes such as Enterprise Service Buses (ESB).

• Manage includes the maintenance of the operating environment, service performance monitoring, and service policy enforcement.

SOA governance and processes , as defined above, underpins these four phases. This is displayed in Figure 3.

Figure 3. The SOA life cycle

Business

Businesses nowadays need to be able to recognize change and react to it quickly while maintaining their ecosystem of employees, partners, customers. Technology needs to be fully leveraged in order to achieve this, as described by IBM On Demand Business . Please see the Resources section for information about IBM On Demand Business.

Because of external demands such as customers and regulatory compliance, and changes such as competition and markets, businesses have to be flexible and agile. Service-Oriented Architecture helps achieve this and allows businesses to quickly adapt to change.

Business alignment

Key to the success of SOA is the reuse of existing IT assets such as legacy applications. SOA, however, allows businesses to focus their technology efforts on services that will support their business capabilities or processes -- for example, service operations can correspond to business tasks -- as opposed to services based on siloed information systems. This business alignment provides better convergence and easier communication between business and IT. In a later part of this series we’ll cover top-down, bottom-up, and meet-in-the-middle approaches to SOA analysis and design to understand how business models can be refined into IT models, and how key existing functionality can be leveraged.

Being business aligned, however, doesn’t mean having business capabilities and IT implementations tightly coupled. One of the key SOA concepts is loose coupling and the separation between specification (business model, interface) and implementation (technology), which allows for the impact of a change, such as replacing a service provider, for example, to be minimized.

Business componentization

IBM Component Business Model® is a strategic method that allows businesses to focus on core competencies -- the parts of the business that differentiate them from their competitors, see how resources are consumed, and better align business and IT. Please see the Resources section for more information on the Component Business Model. The integration of these business components’ interaction as well as flexibility, such as outsourcing a component, is needed and achieved with service orientation: business components have a unique business purpose and collaborate through a set of business services they provide to or consume from other components. This can be seen as being part of the "business architecture".

Business modeling

Business Modeling is defined by IBM Rational Unified Process® as follows:

"The Rational Unified Process Business Modeling discipline provides specific guidance on how to describe the "as-is" or the "to-be" business using a number of approaches and techniques at different levels of formality."

Business modeling introduces concepts, deliverables, and roles; it describes and organizes tasks around business strategy, business vision, business objectives, business goals, business vocabulary, business architecture, business analysis and design, business rules, business value, business use cases, business entities, and business processes. The next section offers more details.

SOA is a long-term strategy about reorganizing business and IT systems in order to be able to quickly react to changes. The Resources section has a link to the IBM Systems journal, volume 44, number 4, on SOA, which offers a more detailed view on the business aspects of service-oriented thinking.

Business process

A business process consists of a sequence of activities that produces a valuable result.

A business process has related business items (data) that flow through it, including those used as the process’ input and output.

Business activities and tasks

Business activities and tasks are the elements that, when connected, make up a business processes.

You can associate duration, cost, revenue, resources, input and output to business activities. They are the elements used to decompose business processes. Service identification techniques include the decomposition of business processes into activities and tasks from which existing or to-be-developed services (and their operations) are identified. These services are sometimes referred to as "business" services.

Modeling business processes

An organization's business processes (current, "as-is") can be complex because they are often the result of a significant number of changes to the process that was originally defined. Understanding, formally defining, and documenting business processes is critical. Also, modeling and simulating "as-is" and "to-be" (future) business processes will allow for the identification of costs, delays, or areas for automation.

Modeling business processes not only provides a visual representation, but when done within a framework that provides underlying metadata, which we’ll cover in Part 2 of this series, it allows for elements of the business process model to later be refined into or linked to IT design elements.

Human tasks

Quite often, human interactions are needed in the course of a process (e.g., travel approval or loan approval). During business process modeling, a task is identified as manual, and different roles are assigned to each of these human tasks. When deployed, the SOA environment will then need to support human tasks as part of the execution of a process. For example, products like IBM WebSphere Process Server will provide users with a list of human tasks awaiting their action. Combined with this, collaboration products like IBM WebSphere Portal and Lotus Sametime will also allow users to collaborate with colleagues if needed, and notify the system of their decision so that execution of the process can carry on. This human aspect is critical to the success of SOA.

BPEL

IBM, Microsoft and others have contributed to the Business Process Execution Language (BPEL) for Web services specification as a means to formally specify business processes and interaction protocols.

Version 1.1 was published in May 2003, and an OASIS committed draft has been published for version 2.0, now called Web Services Business Process Execution Language WSBPEL. Please see the Resources section for a link.

Industries

Business processes can be specific to a domain or industry, such as an insurance claim process. Industry consortiums define industry business processes. For example, the TeleManagement Forum defines the enhanced Telecom Operations Map (eTOM) for the telecom industry. In addition to these, enterprises can differentiate themselves from their competitors by internally adopting proven business processes like the ones from the IBM Industry Models. Please see the Resources section for a link to the IBM Insurance Application Architecture (IAA), which is one of the IBM Industry Models.

Business Process Management

Business Process Management (BPM) looks at the full life cycle of business processes to improve their efficiency, flexibility and control.

BPM is about modeling, simulating, optimizing, deploying, running, managing and monitoring business processes before feeding the results back to improve the models and to follow a continuous improvement cycle. IBM WebSphere provides a variety of products needed around BPM.

Conclusion

In this article, Part 1 of the SOA terminology series, we defined the core SOA terms, namely Service, SOA, and how SOA relates to Architecture. We defined two terms, Service Life cycle, and SOA Governance, which are core elements of SOA. Finally,we talked about the relationship between SOA and the Business, and described Business Processes. This is just the beginning. Following parts of the series will define SOA terms related to IT design, development, runtime, and management. So stay tuned to developerWorks!

SOA terminology overview, Part 2: Development processes, models, and assets

Level: Introductory

Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM, Intel, Microsoft,HP

05 Apr 2007

Learn some basic SOA terminology. In this second part of the series, Bertrand Portier defines terms including development processes, models, and assets -- and explains why they are fundamental to the success of SOA. He also introduces key standards in this area.

Introduction

Semantics are essential in any domain and especially in Service-oriented architecture (SOA). Since SOA spans teams and organizations, agreement upon relevant terms is crucial. This series provides a tour of SOA by defining terms and the key concepts behind them. You will learn the vocabulary necessary to communicate in the SOA field. For each term, you will understand why it is important for SOA, what it means in this context, what the relevant standards are, and how the term differs from others.

Part 1 in the series has a business focus and sets the stage by defining terms such as service and SOA. This article presents the software engineering methods and processes needed for successful SOA adoption, as well as the artifacts needed to deliver SOA solutions, such as models and assets.

Development processes and methods

Successful software development requires:

• Principles to be understood and followed.

• Formally described methods and techniques based on proven best practices.

• Processes that can be tailored.

Method content

Method content describes what needs to be produced, how the work is performed, and by whom.

Method content artifacts include:

• Roles: Defined skills and work product responsibilities. Software Architect is an example of a role.

• Work products: Results of tasks, whether deliverables or not. Service Model is an example of a work product.

• Tasks: The sequence of steps that specific roles perform. Tasks use input work products to produce or modify output work products. Identify Services is an example of a task.

• Guidance: Documentation. Glossaries, templates, examples, and tool mentors are examples of guidance.

Process

A process is used to organize method contents into a development cycle and specify the sequence of the work to be done. The sequence of work to be done is independent of a development life cycle model (such as waterfall or iterative). Think of processes as workflows or breakdown structures. Processes enable project managers to see who is required and which work products are modified in each phase of the project. If you are familiar with the Rational Unified Process® (RUP), think of RUP disciplines such as analysis and design implementation as method content, and think of RUP phases such as elaboration and construction as process elements.

It is important to separate the two concepts of method and process and to have a framework that supports their independent modifications.

Rational Method Composer

IBM Rational® Method Composer (RMC) is an Eclipse-based method and process authoring platform used to integrate, tailor, codify, and publish processes. Out-of-the-box, RMC offers a catalog of processes that are ready to be used or customized, such as the Rational Unified Process (RUP). Project managers responsible for maintaining processes, project managers, and program managers typically use RMC, which supports the concepts described in this section.

The output of the work performed in RMC is a process that is published as HTML (usually in the form of a Web site). The organization meant to follow the process can then use the process site.

Software Process Engineering Metamodel

This section addresses the development processes. Software Process Engineering Metamodel (SPEM) is the standard specification that formally describes the software development processes. As an Object Management Group (OMG) standard, SPEM is vendor, method, and framework-agnostic. Version 1.1 was officially published in January 2005. Version 2.0, a major update, is currently being developed.

Rational Unified Process

Based on best practices adopted by thousands of projects worldwide, the Rational Unified Process (RUP) is a software development process that can easily be tailored for specific projects. RUP includes key principles around priority balancing, iterative development, visual modeling, software quality, and team

collaboration. RUP defines disciplines (method contents) and phases (process), as shown in Figure 1.

Figure 1. The Rational Unified Process (RUP)

Rational Unified Process for Service-Oriented Modeling and Architecture

The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP Plug-In for SOMA) is built on top of RUP and provides guidance on developing service-oriented solutions. Version 2.4 (see Resources) provides a unified method that combines previous RUP for SOA content and the IBM Global Business Services (GBS) SOMA method. The RUP Plug-In for SOMA includes specific guidance for software architects and designers on the analysis, architecture, and design of service-oriented solutions.

Specialized Unified Modeling Language (UML) profiles exist for the modeling of domain-specific solutions, including SOA, and go hand-in-hand with specialized processes. For example, there is a UML 2.0 profile for Software Services that supports the RUP Plug-In for SOMA.

Note: Processes related to Management are addressed in subsequent articles in this series.

IBM techniques

As described in Part 1 of this series, Component Business Modeling, or CBM, helps organizations gain significant new insights into strategy, technology, operations, and investment alignment. CBM enables the identification of differentiating business components and the analysis of key business processes.

Service-Oriented Modeling and Architecture (SOMA) provides guidance on the analysis and design of SOA solutions. SOMA enables the identification, specification, and realization (at the design level) of business-aligned services. This topic is described in detail in a later section.

Models, UML, assets, and patterns

Metadata

Metadata literally means data about data. For example, metadata about a recorded song might include information about its artist, album, composer, length, or quality, whereas the data is the audio recording itself.

Depending on the context, the same data can be actual data, or metadata. Consider the example of development methods and processes, described in the previous section. When you codify a development method in RMC, you define content that is typed (backed-up by metadata). For example, you might define new instances of work products, tasks, and roles. At this level, work product, task, and role are metadata elements, and the metadata also defines what the relationship is between these types (tasks that are performed by roles). Now think about when designers defined the concepts around methods. Imagine that they were modeling the concepts of work product, role, and task using UML. At this level, work product, task, and role are the actual data, and UML is the metadata. This data will be later used as metadata in RMC. So, for this example, UML can be considered meta-metadata!

Model

RUP describes a model as an abstract representation or simulation of a system that provides a complete description of the system from a particular perspective. Models are often used to gain a better understanding of how the system works or to document design decisions for the actual implementation. Models are often made up of several different kinds of parts. These parts are categorized as model elements.

Models are targeted to a group of people who understand them. For example, system analysts and designers create and use analysis models, and database designers design and view data models. Models can be based on text or graphics or both. Because modeling is about being rigorous and complete while reducing complexity (such as describing at higher levels of abstraction), it is a good practice to use rich graphical design notations, such as the Unified Modeling Language (UML), described in RUP as visual modeling. A model is at a specific level of abstraction, and it can evolve into lower levels of abstraction. For example, analysis models typically evolve into design models.

Part 1 in the series explained that collaboration is even more important with SOA. For example, your company might have outsourced detailed design or implementation to another company. When you model, remember that it is for others to use. Also, your SOA design and development platform should be able to take a model and evolve it into another model.

Automations and transformations

An SOA design and development platform should allow for the semi-automatic transformation of models from higher to lower levels of abstraction, and eventually to code. For example, think of a UML-to-Java™ transformation that can generate Java code from a UML class diagram.

The underlying framework should also allow for traceability, which is basically going back to higher levels of abstraction. For example, imagine that you want to understand the impact that a change in a requirement would have on your design. You should be able to tell how the requirement was addressed in the design with the links (traces) that you added at the time you made design decisions to support that specific requirement. Then, during your impact analysis, you should be able to see all of the design decisions related (traced or linked) to that specific requirement, and you should start to understand what the impact of a change in this requirement is on your design.

A metamodel is a model about a model. It is the model of a specific domain, and it defines concepts and provides building elements to create models in that domain. For example, think of SPEM as the process engineering metamodel.

Eclipse Modeling Framework

As an open-source Eclipse project, the Eclipse Modeling Framework (EMF) includes a model metamodel (a metamodel in the modeling domain). Here is the definition from the EMF Web site:

"EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XML Metadata Interchange (XMI), EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor.

The core EMF framework includes a metamodel (Ecore) for describing models and runtime support for the models including change notification, persistence support with default XMI serialization, and a very efficient reflective Application Programming Interface (API) for manipulating EMF objects generically."

Unified Modeling Language (UML)

"The Unified Modeling Language (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It simplifies the complex process of software design, creating a 'blueprint' for construction." Source: Object Management Group (OMG)

The good thing about UML is that it has broad industry support. Originally submitted to the OMG in 1997, it is fully supported in many vendors' design and development environments, such as IBM Rational Software Modeler (RSM) or IBM Rational Software Architect (RSA).

An OMG standard, the current formal version of the specification is 2.1.1. It defines 13 groups of concepts and diagram types organized into two categories:

• Structure: Class, Object, Component, Composite Structure, Package, Deployment

• Behavior: Use Case, Activity, State Machine, Sequence, Communication, Timing, Interaction Overview

A generic modeling language, one of the key strengths of UML is that it can be extended for domain-specific modeling using UML profiles.

UML profile

UML profiles provide a simple extension mechanism to the domain-independent UML. Profiles enable the definition of domain-specific entities and rules. UML profiles pair well with development processes. For example, there is a UML Profile for Business Modeling that supports the Rational Unified Process (RUP) for Business Modeling Plug-In.

Profiles consist mainly of stereotypes. A stereotype defines which UML class (meta-class) is associated with it, properties on that class, and constraints on how stereotyped elements can be associated with other elements. For example, in the UML 2.0 Profile for Software Services, the Service Specification stereotype extends the Interface UML meta-class. It defines a property named published to indicate whether or not the service specification has been published to a service registry. Finally, one of its constraints is that all Service Specification operations should be marked public.

UML 2.0 Profile for Software Services

What is the difference between EMF and UML?

EMF is a modeling framework (that includes a metamodel), while UML is a specification. Consider the Eclipse UML2 project, which is an EMF-based implementation of the UML metamodel that supports the development of UML modeling tools for the Eclipse platform. From this perspective, you can see the EMF metamodel (Ecore) as the metamodel that is used to implement the UML model on the Eclipse platform.

The UML 2.0 Profile for Software Services is a UML profile that "allows for the modeling of services, service-oriented architecture (SOA), and service-oriented solutions. The profile (sometimes referred to as services profile) has been implemented in IBM Rational Software Architect (RSA), used successfully in developing models of complex customer scenarios, and used to help educate people about the concerns relevant to developing service-oriented solutions."

The profile defines stereotypes such as Message, Service Specification, or Service. It also provides distinctive graphical notations for these concepts. Figure 2 shows an example of UML diagram: a message design model in the insurance domain (from IBM Rational Software Architect). It is represented as a class diagram (a structural diagram) that uses the Message stereotype from the services profile.

Figure 2. A UML class diagram

Model-Driven Architecture

Model-Driven Architecture (MDA) provides an answer to having business and technology constantly changing by having independent models for both. Here is the definition from the OMG MDA user guide:

"OMG's MDA is a vendor-neutral approach to using models in software development. MDA provides an approach and enables tools to be provided for:

• Specifying a system independently of the platform that supports it

• Specifying platforms

• Choosing a particular platform for the system

• Transforming the system specification into one for a particular platform

The three primary goals of MDA are portability, interoperability, and reusability through architectural separation of concerns."

At the core of MDA are concepts such as system (as-is or to-be), platform (provides functionality such as J2EE or Web services), and viewpoint (an abstraction to focus on a particular concept).

MDA defines the following models:

• Computation-Independent Model (CIM): The domain model used to define the requirements for functionality.

• Platform-Independent Model (PIM): The business functionality and behavior model that is independent of (evolving) technologies on which it can be built.

• Platform-Specific Model (PSM): Combines specifications of the PIM and how a specific type of platform is used.

MDA defines a transformation as converting the model of a system to another model of the same system (such as PIM to PSM). Transformations of one model to another are described with mappings.

One of MDA's primary goals is to enable the provision of design and development tools that support it.

Model-Driven Development

The things described so far in this section, specifically models and transformations, form the basis for Model-Driven Development (MDD), sometimes referred to as Model-Driven Software Development (MDSD), which is the software engineering approach for which MDA is a prescriptive standard. Model-Driven Development (MDD) is a software development approach based on models and transformations. MDD supports the semi-automatic generation of code, starting from high-level business analysis models to using a set of model-to-model transformations and eventually to using model-to-code transformations. This is made possible through the definition of a set of models, the completeness of model instances, and the mappings between elements of different models used in transformations. Also, MDD enables the analysis of the impact of changes.

The IBM Rational Software Delivery Platform (SDP) supports team development of end-end enterprise solutions, following an MDD (or other) approach, such as Business-Driven Development. "Business-Driven Development (BDD) is an integrated, role-based approach to software development that aligns business and IT, enabling the dramatic improvement of business performance." BDD uses models as well, and it focuses on the coordination of business and IT models across the SOA lifecycle (see Part 1 of the series). The IBM BDD approach supports roles such as Business Analyst, IT Architect, J2EE Developer, or Integration Developer, with the IBM Software Delivery Platform.

Refer to Resources for an IBM Systems Journal article containing an in-depth look at Model-Driven Software Development by IBM thought leaders.

Asset

Assets and patterns are key to the success of SOA, because they enable reuse. In fact, enterprises that adopt an asset-based business model have tremendous growth capabilities. They are no longer limited by the productivity or number of their staff, as in the traditional labor-based business model. The proper use of assets can dramatically change software investments. However, anyone who adopts this model can tell you that it is not straightforward, and it requires proper governance and infrastructure support.

Creativity can be counter-productive with SOA. Having architects, designers, and developers reinvent the wheel with each new project is undesirable. Similar requirements should lead to consistent architectures and designs. Assets and patterns allow the proper level or creativity, which enables you to reuse proven solutions wherever possible and then focus all of your time and effort on what needs to be invented, such as the business logic that is particular to the project.

Asset or service?

Assets and services share common characteristics around the need for a description, their reuse potential, and their granularity (fine-grained or coarse-grained). A service can be a kind of asset, which might require many assets to be represented. Some elements of the service assets are used more during development time, such as business process models or test cases, while other elements of the service assets are more applicable to the run-time, such as Web Services Description Language (WSDL), XML Schema Descriptor (XSD), or Enterprise Archive (EAR). SOA Governance defines the rules dictating the lifecycle of such services and assets.

An asset is a collection of artifacts that provide a solution to a problem in context. In this context, artifacts can be anything, such as a requirement, a design model, implementation code, or a test case. Think of an artifact as a file on the file system. Critical to their success, assets include instructions on how to use, customize, and extend the assets. See Reusable Asset Specification for more information about what makes an asset.

Pattern

A pattern is a solution to a recurring problem in a given context. A pattern is a specific type of reusable asset. You can make the distinction between the specification of a pattern (a description of the problem, context, forces, and solution), and its implementation, such as a Java bean. There can be many implementations of a single pattern specification.

Patterns fall into different categories, depending which phase in the development process they fit into. For example, the IBM Patterns for e-business classifies patterns into the following categories: business, integration, composite, application, and runtime. The Gang of Four (GoF) design patterns are also well-known.

When you use patterns, you can be sure that the solution they provide or codify is correct, useful, and has been validated. However, as with any type of reusable assets, adoption is possible only if a context and method are given on when, why, and how to use the patterns. Many patterns exist, and that context is necessary to get started. The patterns for e-business, for example, are presented with a process that, based on skills and environment, helps you identify the relevant patterns that address your business problem.

Finally, one of the goals of patterns is to provide consistency so that you end up with the same architecture based on the same set of requirements because you used patterns in your design.

Reusable Asset Specification

Adopted in 2005, the Reusable Asset Specification (RAS) is an OMG standard used to describe the structure, content, and description of reusable software assets. The goal of RAS is to provide best practices on how to package assets in a consistent and standard way. As defined in the specification, core characteristics of a RAS asset include:

• Classification: The context in which the asset is relevant.

• Solution: The artifacts contained in the asset.

• Usage: The rules for installing, using, and customizing the asset.

• Related assets: How this asset relates to other assets.

Artifacts can have a type determined by their file name suffixes, such as .xml, .txt, .doc, or .java; or by their purposes, such as use case model or analysis model. Because a software asset is a broad term, RAS also provides profiles used to describe specific types of assets. This is the same concept as UML profiles. There are UML profiles used to extend the domain-independent UML. Similarly, there are domain-specific (such as Web services) RAS profiles used to extend the domain-independent RAS.

RAS assets have a .ras file extension, and they are packaged like .zip files, meaning that they have a manifest and that you can open them using WinZip. Figure 3, from the RAS specification, illustrates the major sections of a core RAS asset.

Asset or pattern?

Assets and patterns both provide a proven solution to a problem in context. So, what are the subtle differences? An asset can contain artifacts of any type, such as a movie, but also includes patterns. A pattern is a special type of asset. Assets are backed up with a standardized model (RAS) on how to describe and structure them: a model that can be extended with profiles. Think of a pattern as its specification and its implementation.

Figure 2. The major sections of a core RAS asset

Conclusion

This article defines the terms around software engineering processes and methods. It defines software artifacts used to build SOA solutions, such as models, assets, and patterns. Key standards are introduced, such as SPEM, UML, or RAS.

Future articles will define SOA terms related to analysis, design, implementation, runtime, and management. So, stay tuned to developerWorks!

SOA terminology overview, Part 3: Analysis and design

Level: Intermediate

Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM

16 May 2007

Building on the previous articles in this series, Part 3 continues the Service-Oriented Architecture (SOA) terminology journey. Learn a few new terms, including service identification, specification, realization, and design principles, and find out why they are fundamental to the success of SOA.

Introduction

Semantics are essential in any domain, especially SOA. SOA spans teams and organizations, so agreement upon relevant terms is crucial. This series provides a tour of SOA by defining terms and the key concepts behind them. You'll learn the vocabulary necessary to understand and communicate in the SOA field. For each term, you'll learn its importance, what it means in this context, what the relevant standards are, and how the term differs from others in the SOA field.

Part 1 had a business focus and set the stage by defining terms like service and SOA. Part 2 covered development processes, models, and assets. In this part, the third installment in the series, you explore the terms and techniques associated with designing an SOA at a high level of abstraction (analysis) and how to move forward to a lower level of abstraction (design) that's just above the code level.

A note about organization

The terms listed below are not organized alphabetically, nor are they shown in order of importance. Rather, they are organized in a building-block fashion. Part 1 began with service, because it's probably the most important concept to understand the SOA framework. The next parts of this series build on the service concept and define other terms by grouping concepts that relate to specific disciplines, such as analysis and design in this part.

Analysis and design

The IBM® Rational® Unified Process® (RUP®), described in Part 2 of the series, defines a discipline called analysis and design, which sits between requirements and implementation. Analysis and design includes activities that specify the initial IT architecture based on a set of functional and nonfunctional requirements. It's also based on other activities that further detail this initial architecture from an analysis level of abstraction to a design level that's detailed enough for developers to generate and write the implementation code.

SOA analysis and design is also referred to as one or more of the following terms:

• Service modeling

• Service-oriented analysis and design

• Service-Oriented Modeling and Architecture (SOMA)

• Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)

Analysis involves describing what the system to be built is at a high (conceptual) level of abstraction. The input of analysis is a set of requirements and existing assets (or applications or systems). The output is a

description of what is to be built. Analysis is critical for SOA, because it's where IT meets the business during service identification. The result of analysis is used as input for design.

Design involves describing what the system to be built is and, more importantly, how to build it.

Most of the architecture (described in Part 1) work is performed during the analysis and design workflow, in the elaboration phase of a project.

Service-oriented analysis and design leverages existing analysis and design principles, such as the ones in object-oriented or component-based development. For example, you may remember that there's something called Object-Oriented Analysis and Design (OOAD). It’s important to note, however, that SOA efforts are always centered on services (as opposed to objects or components).

Note: Analysis-level models often evolve into design-level models, so there's only one RUP discipline for analysis and design.

The main output of a service-oriented analysis and design effort is a service model (previously referred to as service specification) that documents all of the architecturally significant parts of the service-oriented system and a design model that further details how the service model should be realized (implemented). These two models fully specify the SOA design and are enough for developers to unambiguously perform implementation.

In the following sections, you get an introduction to the terms associated with service-oriented analysis and design with descriptions of the associated tasks.

Note: The terms identification and specification were used in component-based development, and the terms specification and realization are defined by the Unified Modeling Language (UML). These three terms form the core activities of RUP SOMA (with the same meaning).

Service identification

Service identification is the core service-oriented analysis activity. The goal of service identification is to identify groups of conceptual services and their operations.

These identified services are needed by and meaningful for the business. In fact, business analysts help software architects perform this exercise. In the next section about service design principles, you learn about the need for logical groupings of services and business-relevant names for services and their operations. These are decided during service identification, using techniques like the ones described in RUP SOMA.

In Part 1, you learned about the SOA solution stack reference model, with its functional layers — consumers and business processes at the top, services in the center, and operational systems and components at the bottom. Based on this model, you can take different approaches to identify services (depending on whether you start from the top or the bottom of the diagram). Let’s take a closer look at these:

Top-down approach

Starting from a set of business objectives and goals, it's typical in SOA projects that the business architecture effort has identified one or more business processes to focus on. As a result of the business modeling effort, there may be designed business processes (the to-be processes) that can be seen as the functional requirements for the system under design.

The top-down approach is about decomposing business elements (mainly business processes and use cases) and refining them into a granularity that makes sense for services. During a top-down approach, you typically identify service operations from business tasks. The advantage of this is that you can be assured that the identified services are business aligned!

Bottom-up approach

The bottom-up approach is about analyzing existing IT assets (such as legacy applications and systems) and finding functionality that could be exposed as services, to be reused by many.

Reuse is an important part of SOA and critical to its success. As you probably know, your legacy applications (that is those that have already been deployed) are your company’s most valuable assets and should be leveraged. For example, the bottom-up approach analyzes existing Information Management System (IMS) transactions or COBOL programs.

A word of caution about bottom-up analysis: You have to be careful not to blindly expose existing IT capabilities. For example, Create Read Update Delete (CRUD) data services may be too fine-grained and not business aligned.

Note also that the use of existing asset-analysis tools, such as IBM WebSphere® Studio Asset Analyzer, is critical because often nobody knows exactly what is deployed and running!

Meet-in-the-middle approach

The meet-in-the-middle approach is about reconciling needs (the services identified by the top-down analysis) and what's already provided by existing IT assets.

The meet-in-the-middle approach requires collaboration between business analysts, software architects, and specialists for the legacy applications. Note that although it's valuable to perform bottom-up analysis outside of the context of a specific project (for example, an enterprise architecture team doing inventory of candidate services), in practice, however, efforts usually start with the top-down approach and the decomposition of one or more business process as part of a project. Then, in this context, bottom-up analysis occurs to try and find matches for the required services (meet-in-the-middle approach).

Based on the three described approaches, a set of services and their operations are identified, validated (for example, validation makes sure that services don't already exist or are business aligned), and grouped into logical categories (such as business components or business functional areas). Business items (such as, policy or claim) are also identified, mainly from existing data legacy applications. The next step is to fully specify what these services and their operations are in terms of structure and behavior.

Service specification

Service specification and realization are the core service-oriented design activities. Service specification is about designing the structure and behavior of the service elements that are architecturally significant.

Service model

The main output of service specification is the RUP SOMA work product called service model, which includes artifacts like service specifications (interfaces), service providers, and service collaborations. A service model should be complete enough so that service providers and consumers unambiguously know what the service is.

Specifying services includes designing the following:

Service specification

From the service model, a service specification artifact is an interface that describes the operations offered by a service.

Optionally, service messages can be designed to act as operation input, output, or fault parameters.

You may recognize the interface and operation concepts from the object-orientated paradigm. The emphasis on messages, collaborations, and policies (described later in this article) can be seen as the evolution provided by service orientation.

A service specification is used as the contract between a service provider and a service consumer. It defines the structure and behavior of a service.

Service provider

From the service model, a service provider artifact groups a set of related services together.

A service provider includes:

• Required service specifications (when the service is a composite one and part of a collaboration, as described in the following section).

• Provided service specifications.

• Provided services.

For example, there may be a coarse-grained service provider called Sales Management, which supports the sales management functional area. This service provider may provide two services called Account Activation and Application Inquiry, with the Account Activation service typed as the Account Activation service specification.

Service provider design is where principles from component-based development should be leveraged. Service providers are typically represented at UML components and then services as UML ports on these components. Note: The services (ports) are typed with service specifications.

Service collaboration

From the service model, a service collaboration artifact represents the communication between two or more services. Service collaboration specifies the dynamic behavior of services within an environment with other services.

Terms related and somewhat synonymous to collaboration are choreography, orchestration, or composition.

Atomic services are fine-grained services that don't require other services. Composite services are larger-grained services that require other services to provide their services. Therefore, composite services act as service consumers and always need to have associated service collaboration.

In Part 1, you saw that the Business Process Execution Language (BPEL) can be used to specify an executable version of a business process flow. It also plays an important role in the area of service collaboration as it can be used to implement a composite service as a collaboration of atomic services.

Note that, although this article doesn't go into it because it’s too detailed, service consumers and service partitions (the structure of the SOA) also need to be addressed by the design.

Quality-of-service approach

As with traditional (non-SOA) approaches, the design needs to address both functional (such as use cases and business processes) and nonfunctional (such as quality of service, or QoS) requirements.

A QoS description should be part of the service specification. Also, you should use proven design patterns to address them. (Design patterns are typically heavily used during service realization.)

The policies regarding usage of services need to be tackled at the design level, too. Policy is covered in a later part of this series.

Model-driven development (MDD) approach

For the design to be explicit, complete, and unambiguous, you need to rely on modeling languages, such as UML (see Part 2) to design services. For example, remember that service providers are typically represented by UML components with UML ports. Also, UML collaborations or sequence diagrams support the modeling of service collaborations. More specifically, you should use UML profiles for service-oriented design, such as the UML 2.0 profile for Software Services, introduced in Part 2.

MDD lets you model and specify elements at different levels of abstractions. You've probably noticed that this series goes into lower levels of abstractions as it progresses. It started at the business level, moved to analysis, and now design. In following installments of this series, you'll learn about implementation (at the code level). MDD provides semiautomated transformations from one level of abstraction to another. For example, you'll see that you can generate the Web Services Definition Language (WSDL) files from the service model work product. Also, you can eventually generate the code (usually from the design model) that will be used as the base for your SOA implementation.

The MDD approach also allows traceability, which is basically going from lower to higher levels of abstraction. For example, you can link a design decision to the requirement(s) that it's addressing. This allows rapid analysis of the impact on your design of a change in requirements.

Support

In this domain, I strongly recommend that you look at the following terms, which are described in previous parts of this series. You can also find more information about them in the Resources section at the end of this article:

• The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA) process

• The IBM Rational Software Modeler (RSM) Rational Software Architect (RSA) tools

• The UML 2 Profile for Software Services

• The SOA design assets and patterns available on the developerWorks RAS repository

• Business services modeling, which provides a mapping between business process modeling elements and UML elements

Service realization

Service realization is about designing how services will be implemented. It's the most detailed design, just before the code level. It's not about implementing (constructing) services, as Part 3 will describe, but about describing at the design level how the services should be implemented. Service realization is performed by the software architect and the designer.

There's a fine line between specification and realization. Here's an easy way to look at it the difference between them: If service specification is about what, then service realization is about how.

Design model

The design model, as defined by RUP SOMA, is the core output work product from service realization. It describes the realization of the SOA and acts as an abstraction of the implementation (including code). The output of service realization, it's used as input for service implementation.

Service component

The main design model artifact you should focus on is the service component — which represents how one or more service specification is realized — and how all of the functional and nonfunctional requirements and structural and behavior specifications are addressed.

A lot of new classes are also created during service realization to refine the service components and services. The definition of the structure and behavior of these classes is thus performed as well.

As previously stated, service realization should make heavy use of design patterns (for example delegation, singleton, and factory), which are typically applied to the classes designed during service realization.

WSDL and XML Schema

During realization, you make decisions about a variety of technologies. Web services have proven to be a reliable platform of choice for SOA. From the service model, MDD tools like IBM Rational Software Architect can generate the Web Service Definition Language (WSDL) for the service providers and specifications as well as the associated XML schema files (.xsd) that define the messages that flow between service providers and consumers. WSDL and XML Schema can arguably be an output of service realization or one of the initial outputs of service implementation.

QoS and service partitions

Making technology choices has a huge impact on quality of service. Some technologies don't support the requirements you may have. An example can be illustrated in terms of reliable message delivery or performance (such as throughput). It's a good practice to map technology choices to partitions, as with traditional (non-service-oriented) design. In the case of SOA, the service partitions that were defined during service specification may need to be revised during realization to have associated service policies (access channels, security, performance, and so on) addressed by specific technologies. Think, for example, of performance requirements that would imply in-memory transactions, or interoperability requirements that would imply the use of SOAP and Web services, or when to use local invocations instead.

After you're done with service design, the next step is to implement (construct) services based on this design, as will be described in the next part of this series.

Service design principles

This section lists four service design principles that you should have in mind when designing SOA solutions. Note, however, that this isn't an official or comprehensive list and that some of the concepts originate in other paradigms, such as object orientation. These principles are important in the design of service-oriented solutions.

Reuse

Always have reuse in mind when designing services. Usually, you have specific requirements from specific service consumers at design time. However, if you want to reap the benefits of SOA, you want the services you design to be reused by other consumers with slightly different requirements. You don't know these consumers and what their requirements are at the time you create the design, so it's not an easy task!

Some of the things you can consider are:

• Providing a meaningful and descriptive name for services and their operations based on business domain, not technology.

• Making services discoverable by providing complete human and machine-readable specifications published to a service registry (see the following parts of this series for more information).

• Quality of service for usage scenarios that are different from the initial one, for example, plan for increased demands and workloads when the service becomes popular.

• The possibility of extending the initial functionality provided by the service (based on the initial set of requirements) to make the service complete.

• The possibility of implementing a service specification on a number of different platforms.

Loose coupling

Coupling refers to how much entities or systems depend on one another. Within the SOA context, you can think of coupling between a service specification and its provider or implementation, or coupling between a service provider and a service consumer. To support the agility promised by SOA, coupling should be loose.

A service provider shouldn't have to know about a specific instance of a service consumer, and vice-versa. Replacing a service provider or the implementation of a service should have only minimal or no disruptive effects on consumers.

To help achieve loose coupling, consider the following:

• Separate service specification (the service and design model described in this article) from service implementation. As described in the MDD section in Part 2, it's important to have full specifications for services, which are independent of a particular implementation. Also, the service contract should be at the specification level (not at the implementation level).

• Using tools, formally describe a service specification in both human-readable and standard machine-readable format (for example, WSDL and WS-Policy) so that code generators can help with the implementation of services (Part 4 of this series will have more information about this).

• When developing service consumer code, keep in mind that there may be service intermediaries or other providers, and don't hardcode any information about an instance of a provider.

Statelessness

Transactional state means that a service needs to have information about things that happened as part of a long-running transaction between a specific instance of a service provider and a specific instance of a service consumer. For example, the result of invoking a service operation is different if the operation has already been invoked, or another operation needs to be invoked before an operation can be invoked. Although it can be found in component-based development, transactional state should be avoided with SOA.

Data (information) state means that the state of data instances needs to be managed. Some services typically need to manage data state. Take the example of a Claim service in the insurance industry. This service has to manage the state of Claim instances, especially because these instances are accessed by many different consumers over distinct business transactions. Note that services that hold state are typically atomic (fine-grained). To address state requirements, you rely on the underlying technology used for implementation, such as Java™ Platform, Enterprise Edition (Java EE) with stateful session beans.

Granularity

For service-oriented design, you can think of granularity at the service provider level (how many services are provided) or at the service specification level, for example. A service specification is a logical grouping of service operations. Here, logical means that it makes sense as far as the business is concerned. For example, a Claim Processing interface in the insurance domain provides all of the operations needed in claim processing usage scenarios. It also makes sense as far as IT implementation is concerned. For example, all of the service’s identified operations are implemented in the same development iteration.

When designing services operations, consider collaborations, usage scenarios, and the messages (number and size of them) that will flow between service providers and consumers. Coarse-grained operations

provide more business value and allow for easier modifications of implementation. Coarse-grained operation parameters (using messages for input, output, and fault) are less error prone. Using fine-grained parameters instead of messages, however, is usually more descriptive. For example, if a service operation signature is determineEligibility(application: ApplicationMessage), then you need to look at the definition of ApplicationMessage. If the signature is determineEligibility(customer : Customer, product : Product, date : Date, amount : Amount), it's more descriptive. Also, the Customer or Product parameter types, for example, can be reused in other operations, unlike the ApplicationMessage.

For service granularity, always keep in mind that services should be composable. This is related to reuse and the ability to provide new functionality based on existing functionality. A set of services at a certain granularity level can be choreographed, and the result would be another more coarse-grained service. Think, for example, of having business tasks provided by services and then having a sequence of these business tasks (a business process) provided as a service as well.

At the end, making a design decision on service granularity is always a tradeoff between performance (for example, size and number of messages being exchanged and efficient implementation) and potential for reuse. Also, a typical SOA contains both fine-grained (atomic) and coarse-grained (composite) services.

Conclusion

This article covered the terms that relate to the IT architecture and design of SOA solutions. You saw where IT meets the business needs during service-oriented analysis and moved down the abstraction level path to further detail the design. Starting with a set of requirements, you learned about the activities that take place (and their associated terminology) to design an SOA that meets the requirements. The result is a design that's detailed and unambiguous enough to be used for implementation, which will be the topic of Part 4 of this series. Stay tuned to developerWorks for more (and use the RSS feed link in the Resources section to access the next installment as soon as it's available)!

Service Oriented Architecture (SOA) Entry Points Learn about the SOA Entry Points

People: enables efficiency through interaction and collaboration Process: offers tools and services to help streamline business process management Information: enables access to complex, heterogeneous data sources Connectivity: links people, processes and information for your business Reuse: extends the value of your previous asset investments

People:

What is the people entry point?

Are your employees, partners, and customers enabled to take advantage of SOA to drive greater productivity and collaboration? People can interact with SOA-based business services and composite applications through an enabling framework of tools, and practices. The people entry point is a starting point for SOA, enabling people to interact with application and information services that support business processes. As a complement to the other entry points — process, information, reuse and connectivity—the people entry point can facilitate real time decision making and dynamic collaboration, and immediate execution. Overall, the people entry point approach to SOA drives business and operational flexibility and improves end-user productivity and collaboration.

The value of people

Employee productivity, operational efficiency and the ability to innovate on the fly are paramount to competitiveness and growth. Companies frequently struggle with siloed applications and information that prevent customers, employees, and partners from working together effectively. Empowering people through SOA solutions can bridge these challenges and provide a foundation for greater productivity and collaboration. Because people drive the interaction with the SOA services that execute business results, focusing on people is critical to the success of SOA implementations. The people entry strategy to SOA can help:

• Accelerate productivity

• Reduce costs for access to multiple applications and information sources.

• Reduce time to deployment for new services.

• Increase access to process flexibility and orchestration.

• Enable collaboration inside and outside the enterprise.

Process:

What is the process entry point?

The process entry point is a business-centric starting point for service oriented architecture (SOA) that provides specific tools and services to help streamline and improve processes across the enterprise. By entering SOA from process vantage, you can establish the foundation for IBM's business process management with SOA. Improve the efficiency, flexibility, and control of key business processes.

The value of process

Do your processes allow you to quickly respond to changing market conditions? By streamlining your processes you can align your business and IT goals — reducing the complexity of building processes. Leveraging SOA with a focus on process can help your business:

• Improve employee productivity.

• Increased collaboration.

• Accelerate speed to market.

• Respond quickly to business challenges.

• Implement new processes in less time.

• Maximize return on investment.

Reuse:

What is service creation and reuse?

Service creation and reuse is an IT-centric entry point to service oriented architecture (SOA) that focuses on deriving continued value from previous asset investments, identifying services to be outsourced and designing new services to fill portfolio gaps. By entering SOA from a service creation and reuse vantage, you may expand access to proven systems and achieve greater value from your existing technology investments. In fact, a study by Software Productivity Research found that it can be up to five times less expensive to reuse existing services and applications than to rewrite them. Extend, enhance or create new processes enabling you to substantially increase business flexibility and responsiveness through reduced development time and elimination of duplicate processes.

The value of service creation and reuse

Improve efficiency. Reduce risk. Cut cost. The IBM entry strategy to SOA through service creation and reuse can help:

• Reduce the amount of new code that must be created for business initiatives.

• Lower maintenance cost by eliminating redundant systems.

• Expedite the roll-out of new business functions by creating composite function from within your applications.

• Integrate tasks performed by your legacy applications into broader business functions to establish a simple and effective means to enhance usefulness of mainframe-based systems.

Information

What is information as a service?

Information as a service is an entry point to service oriented architecture (SOA) that offers information access to complex, heterogeneous data sources within your company as reusable services. These services may be available both within the enterprise and across your value chain. By entering SOA from an information vantage, you may improve the availability and consistency of information, while simultaneously removing traditional barriers to information sharing. Drive innovation by better understanding your organization’s operational, transactional, analytical, and unstructured information and making it available in new ways through SOA.

The value of information as a service

Establish information as a service to ensure consistent definitions, packaging, and governance of key business data. Provide information services that can be easily reused across processes and independently maintained to enable more business flexibility and increase IT resource productivity. The IBM entry strategy to SOA through information can help:

• Collect, clean and make your data accessible: o Develop a unified view of their business with inline access to analytical data for improved

transparency and business insight. o Generate and govern authoritative master data records with shared metadata and data

quality services for master data management.

• Reduce cost and risk: o Reduce costs associated with infrastructure rationalization and migration by decoupling

information from siloed information sources. o Reduce risk exposure through in line analytics and auditable data quality for risk and

compliance initiatives.

• Increase your organizations agility: o Increase the agility for business transformation by providing reusable information services,

spanning structured and unstructured information that can be plugged into applications, business processes, and portals. At the same time lower development costs associated with accessing and transforming data.

Connectivity

What is service connectivity?

Service connectivity is an IT-centric entry point to service oriented architecture (SOA) designed to help simplify your IT environment with a more secure, reliable and scaleable way to connect within and beyond your business. Link people, processes and information in your business with a seamless flow of messages and information from virtually anywhere at anytime using anything — that's true connectivity. SOA brings new levels of flexibility to such linkages. Delivering real business value on its own, connectivity is also a core building block for future SOA initiatives.

The value of service connectivity

Open your doors to customers by providing a variety of ways for them to interact with your company. Enabling exceptional connectivity through your SOA you can deliver a consistent user experience regardless

of what business channel they choose. Also, by linking your business units or divisions across the multiple parts of your company and your partners, you can build a foundation for success. IBM entry strategy to SOA through service connectivity can help:

• Ensure seamless flow of information from anywhere at anytime using anything.

• Execute broad business processes that span your company and business partners.

• Build trusted relationships with your partners.

• Scale your business to grow smoothly.

• Deliver a consistent user experience regardless of channel or device.

When not to use an SOA

You'd think that with ZapThink's laserlike focus on the benefits of service-oriented architectures (SOAs), we'd be of the opinion that SOAs were good for all users, systems, and situations. As a matter of fact, SOAs are particularly valuable in certain circumstances -- namely, in heterogeneous IT environments that are subject to frequent change. However, in many situations, for example, if your IT environment isn't heterogeneous, or isn't expecting much in the way of change, then maybe an SOA isn't right for you. In these cases, the advantages and benefits received by building and running an SOA -- greater business agility, empowering business users, squeezing more value out of IT, reducing the cost of integration -- may actually be outweighed by the cons of SOA, including its greater performance overhead, the increased need for architectural discipline, and the requirement that companies change how they consume and produce IT assets. Here, then, are four situations where you might not want to use an SOA.

1. ...when you have a homogeneous IT environment If you are an organization that uses the technologies of a single vendor, then it's possible that the additional overhead of an SOA would not be cost-effective for you. This situation is particularly true if your IT infrastructure has a narrow purpose, say, running a Web site. If you have an application server, a database, and two Web servers, then an SOA may not add sufficient value to your IT investment. Most small companies, for example, have a small, homogeneous network behind their own firewall. For these companies as well as larger companies who have staked their claim in a single-vendor technology implementation, an SOA is frequently an impractical addition to an otherwise simple infrastructure.

Homogeneity, however, works on different levels -- hardware, software infrastructure, applications, and data. Heterogeneous hardware environments may not benefit from an SOA unless you also have a heterogeneous software infrastructure -- i.e., different operating systems or middleware. And even if you have a homogeneous software infrastructure, a heterogeneous mix of applications may necessitate a service-oriented (SO) approach to exposing application functionality.

Counterpoint: when you would like to expose external services Yet, even when you buy all your hardware, software infrastructure, and applications from individual vendors, you may still find an SOA to be a cost-effective architecture if offering software functionality as services to external parties is a part of your business. In such cases, the SOA resolves issues of flexibility and visibility across multiple firms, even when individual companies have homogeneous IT environments.

2. ...when true real-time performance is critical I don't know about you, but I'm glad the antilock braking system in my car isn't an SOA. In fact, embedded systems like those found in cars, specialty equipment, etc., often require responses in the millisecond range or faster. As SOAs rely upon asynchronous communication to provide loose coupling between service consumers and producers, SOAs are not well-suited to situations that require strictly enforced response times. When a life depends on speed, I'd rather go with a tightly coupled architecture any day.

Counterpoint: there's "real-time" and then there's "right-time" However, "real-time" means something quite different when you're talking about an embedded system vs. a real-time enterprise. If an enterprise can get some critical business intelligence in 30 seconds rather than having to wait overnight, that's real-time enough for most companies. And if an occasional query takes an hour, that's usually OK, too. In fact, SOA is an excellent approach for companies looking for ways to speed up onerous batch processing without having to throw away their legacy applications. In these cases, we're not talking about real-time as much as right time, and when SOAs can provide business value at the right time, they are the most valuable.

3. ...when things don't change This is the "if it works, don't mess with it" situation. If your requirements for that dusty old legacy system in the corner aren't expected to change, then why bother messing with it? In fact, this principle applies to companies and networks of all sizes. How many of you have a perfectly good computer that's more than five years old? Maybe running Windows 98 or Mac OS 8 or Solaris 1.x? Even the relative newcomer Windows 2000 is hitting its fourth anniversary.

These systems are likely just as good now at doing what it did five years ago -- as long as you don't mess with them. We're not just talking about the systems themselves here, but also the applications running on those systems. If there are few reasons to change the business logic, presentation, data flow, process, or any other aspect of the application, converting these dinosaurs to an SOA might not return sufficient value to make the effort worthwhile.

Counterpoint: SOAs can unlock business value in even the most crotchety old systems This counterpoint probably won't apply to that ancient Macintosh, but many companies can benefit by service-enabling enterprise legacy systems. In some cases, service enablement means installing new software on the old box, but not necessarily. Today's next generation screen scrapers and other legacy enablement solutions can turn that dinosaur's interface or print output into XML with little muss or fuss.

4. ...when tight coupling is a pro, not a con Loose coupling is great for enabling communications between applications in a distributed computing environment, and making it easier to change the elements of such an environment. After all, if you don't have to know anything about the system at the other end of the line, then communication and change are simple and straightforward. When building an application that will reside on a single computer, however, loosely coupling the components of that application from each other introduces needless overhead. Indeed, the developer controls all those components at once, so what does it matter that one component needs to have an intimate understanding of the workings of another?

It's also important to remember that coupling of software is a spectrum, with degrees of looseness or tightness. Object-oriented (OO) development, after all, does offer a certain looseness, because of the encapsulation of individual objects. Objects are known by the methods they expose, not their inner workings. In fact, OO and SO development are two sides of the same coin: as developers and their tools get up to speed on SO development, it will become second nature to decide whether a particular bit of software should be OO or SO, depending on how tightly our loosely coupled it should be from the other software it will interact with.

Counterpoint: won't Moore's Law take care of the performance hit? So, why not use SO development approaches for all your applications if performance is the only issue? If the overhead of service interfaces is the problem (since XML is far more verbose than the binary protocols that OO uses), then maybe we should just throw more hardware at the problem. It's true that there are many hardware products in a variety of form factors coming to market that accelerate XML processing, and there's also every indication that computers will keep getting faster and hard drives will keep getting bigger. So, in the cases where you require tight coupling for high-performance communications among components of your application, and you don't require loose coupling anyway, an SOA might not be appropriate.

Model and build ESB SOA frameworks Adapt service-oriented architectures for easy application integration

Application integration is the biggest challenge today for many enterprises. Building an Enterprise Service Bus

(ESB) is probably the quickest and most cost-effective way to address this challenge. In this article, you gain

insight on ESBs, and how to model and construct ESB service-oriented architecture frameworks.

Service-Oriented Architecture (SOA) is an approach to defining integration architectures based on the concept of

a service.

The key components of a SOA include services, dynamic discovery, and messages.

• A service is a callable routine that is made available over a network. A service exposes an interface

contract, which defines the behavior of the service and the messages it accepts and returns. The term

service is often used interchangeably with the term provider, which specifically denotes the entity that

provides the service.

• Interfaces are often published in public registries or directories where they are categorized based on

different services offered, just as businesses and their phone numbers are listed in a phone book's Yellow

Pages. Clients (service consumers) can look up a particular service by dynamically querying for services

based on various categorization features. This process is referred to as the dynamic discovery of

services.

• Service consumers or clients consume services through messages. Because interface contracts are

platform- and language-independent, messages are typically constructed using XML documents that

conform to an XML schema.

Figure 1 illustrates the various roles in a SOA.

Figure 1. The roles in a SOA

Web services as a SOA Web services are built on top of open standards and platform-independent protocols. A Web service uses the

XML-based Simple Object Access Protocol (SOAP) over HTTP for communication between service providers and

consumers. Services are exposed as interfaces defined by Web Service Definition Language (WSDL), whose

semantics are defined in XML. Universal Description, Discovery and Integration (UDDI), a language-independent

protocol, is used to interact with registries and look for services. All of these features make Web services an

excellent choice for developing SOA applications.

ESB: An Introduction When you enable or add Web service interactions that use existing Internet and intranet infrastructure between

systems in an architecture, you can create many individual point-to-point integrations, which are difficult to

maintain. As organizations move towards service-oriented architectures, which host various deployed services,

they require infrastructure service that provides robust communication, intelligent routing, and sophisticated

translation and transformation of services.

Application servers provide features like life connection pooling, transaction management, and life cycle

management that free the programmer from writing new code for each application. Similarly, an ESB provides

common communication and integration services. Because ESBs also use industry standards for most of the

services they provide, they facilitate cross-platform interoperability and become the logical choice for companies

looking to implement SOA.

The ESB is not a new software product, but a new way to integrate applications, coordinate resources, and

manipulate information. Unlike many previous approaches for connecting distributed applications (such as RPC or

distributed objects), the ESB pattern enables the connection of software that runs parallel on different platforms,

is written in different programming languages, and uses different programming models.

Capabilities of the Enterprise Service Bus An Enterprise Service Bus exhibits these minimum, or mandatory, capabilities:

• Communication

Supports routing and addressing for at least one messaging style (such as request/response, or

publish/subscribe), and at least one transport protocol that is or can be made widely available. This

enables location transparency and service substitution, which enables the decoupling of the consumer

view of services from their implementation.

• Integration

Supports several integration styles or adapters. It enables the provision of services based on these

integration capabilities, and decouples technical aspects of service interactions and the integration of

services in the enterprise.

• Service interaction

Supports an interface definition format and associated messaging model (such as WSDL and SOAP) to

allow the decoupling of technical aspects of service interactions.

• Management and autonomic

Provides a consistent administration model across a potentially distributed infrastructure, including

control over naming, routing, addressing, and transformation capabilities. This enables the management

of services in the enterprise.

More advanced ESBs typically offer a number of additional value-added features, including:

• Adapters, to enable connectivity to packaged and custom enterprise applications, as well as to leading

technologies.

• Service orchestration engines, to support both long-running (stateful) and short-running (stateless)

processes.

• Quality of service and service-level capabilities.

• Presentation services, to enable the creation of personalized portals that aggregate services from

multiple sources.

Typical architecture of an Enterprise Service Bus The architecture of an ESB is centered on a bus. The bus provides message delivery services based on standards

such as SOAP, HTTP, and Java™ Messaging Service (JMS). It is typically designed for high-throughput,

guaranteed message delivery to a variety of service producers and consumers. The ESB enables the use of

multiple protocols (such as synchronous and asynchronous) and performs transformation and routing of service

requests. The ESB enables services to interact with each other based on the quality of service requirements of

the individual transactions. It also supports different standards such as SOAP, XML, WSDL, JMS, J2EE, JAX-RPC,

and so on.

Figure 2 illustrates component types that can connect to an ESB:

• Custom applications, based on standards like J2EE and Struts, which plug into the ESB to provide a user

interface to enterprise services.

• Service orchestration engine, which hosts long running business processes, based on standards like

Business Process Execution Language (BPEL).

• Adapters, typically built to the Java Connector Architecture (JCA) specification, enable integration with a

wide variety of enterprise applications.

• Presentation and portals enable the creation of personalized portals that aggregate services from

multiple sources.

• Data services which provides real time view of data from heterogeneous data sources.

• Web services provides a standard means of connectivity to legacy and proprietary integration

technologies.

Figure 2. ESB architecture

ESB use case scenario In this section, I go through a use case scenario for a loan processing system and show how, by adapting an ESB

approach using a series of IBM® products as an example, you can deliver loosely coupled independent systems,

which interact through consuming messages independently.

Look at an example of a loan processing system with these requirements:

• The user can submit a request for the loan from a Web-based application.

• The loan processing information is submitted through a Web service.

• Based on some predefined rules, such as the type of customer, a workflow system is required to take

further actions for approving the loan.

• During the approval process, the loan approver interacts with various server providers to check the credit

history of the loan requestor and act accordingly. I assume that server providers provide Web services to

access credit history information.

• Once the loan information is approved, the loan information is updated to the legacy system.

With this information, you can provide a high-level framework design of an Enterprise System Bus using various

products. Figure 3 breaks down the architecture of your ESB.

Figure 3. Build ESB architecture with IBM products

As shown in Figure 3, you will use WebSphere® Business Integration Message Broker with Rules and Formatter

Extension and WebSphere MQ to deliver enterprise bus messaging facilities. The flow of your loan processing

application and the corresponding product implementations are:

• Use WebSphere Portal to build the Web-based application with various presentation rules.

• The portal submits Web service requests containing loan and customer information to the Enterprise

Services Bus layer.

• Configure appropriate rules and formatter extensions using the Rules and Formatter Extension options

provided with WebSphere Business Integration Message Broker to route soap requests to appropriate

WebSphere MQ Queues. With rules such as type of customer (high risk/low risk), your application can

extract information from the headers and routed appropriately.

• Model business processes for loan processing, which require human intervention, using MQSeries

workflow and then expose them as Web services. Set up the users required for human intervention in

LDAP or any user directory. In this scenario, the arrival of a message (based on appropriate WebSphere

queues using JMS protocol) triggers the appropriate business workflow.

• The loan approver interacts with various service providers to check the loan requestor credit history. To

implement this, route SOAP requests to multiple service providers using WebSphere Business Integration

Message Broker. Then consolidate multiple SOAP responses and provide the results to loan approver.

• Once the loan is approved, route the loan information to the appropriate WebSphere queue. The

WebSphere Business Integration Adapter listening on the queues picks up the message from the queue,

maps a message to the business object, which in turn is used to create the loan record in the legacy

system.

Benefits of ESB

Today's fast-paced business world demands the ability to change and adapt rapidly. With an Enterprise Service

Bus, you can integrate your business applications and processes quickly and easily as you respond to business

challenges and opportunities when they arise.

The ESB pattern can improve operational performance and reduce costs while it simplifies the task of connecting

dissimilar applications across a network of different operating systems using open standards such as SOAP, XML,

WSDL, JMS, J2EE, JAX-RPC, and others.

New to WebSphere and SOA How WebSphere products fit into a service-oriented architecture solution

Service-oriented architecture. SOA. It's all the buzz! But what is it exactly and how can it help your company?

How does WebSphere® fit into an SOA solution? And where can you learn more? This page is a starting point for

you to learn more about SOA and WebSphere and how you can use them in an SOA solution.

What is SOA?

It seems, lately, that SOA is everywhere. But what exactly does it mean and why does it matter to your

business? As the name implies, SOA is an architecture--a business-centric IT architecture. The building blocks of

SOA are services, which represent discreet, repeatable, reusable business tasks. You can combine and re-

combine these tasks in many ways to build applications that integrate function from many sources to support

different business needs.

SOA can help your business:

• Reduce development cycles and costs

• Consolidate legacy parts into composite business processes

• Improve flexibility and make it easier to respond to and implement changes

• Automate business processes

• Respond to customers more quickly

• Link business processes to improve interaction

How do I get started with SOA and WebSphere?

Based on extensive field experience, IBM has defined five entry points for businesses getting started with SOA.

The entry points are divided into two categories: business-centric and IT-centric, and there are WebSphere

products to help you with each entry point.

The business-centric entry points are:

People

SOA helps you improve productivity by enabling you to collect and consolidate information into views that deliver

information and facilitate interaction in the context of a business process.

The following WebSphere products support the SOA People entry point:

• WebSphere Portal

• WebSphere Portlet Factory

• WebSphere Everyplace Deployment

• WebSphere Everyplace Connection Manager

Process

With SOA you can quickly deploy innovative business models with re-usable processes, which means you can

react fast to changing business needs.

The following WebSphere products support the SOA Process entry point:

• WebSphere Business Modeler

• WebSphere Business Monitor

• WebSphere Process Server

• WebSphere Integration Developer

Information

By delivering information as a service, SOA helps you improve business insight and reduce risk with trusted

information services delivered in-line and in-context.

The following WebSphere products support the SOA Information entry point:

• WebSphere Federation Server

• WebSphere Product Center

The IT-centric entry points are:

Connectivity

When we talk about SOA connectivity, we're talking about the underlying connectivity that supports business-

centric SOA. Connectivity provides the ability to integrate service providers and consumers, and allows for the re-

use of services across multiple channels. WebSphere allows you to connect everything inside and outside your

company, which enables your SOA to deliver reliability and security with high performance and availability that

spans newly developed Web services and complex heterogeneous environments.

The following WebSphere products support the SOA Connectivity entry point:

• WebSphere Enterprise Service Bus (WebSphere ESB)

• WebSphere Message Broker and WebSphere Transformation Extender (WebSphere TX) for Message

Broker

• WebSphere DataPower SOA Appliances

• WebSphere MQ and MQ Extended Security Edition

• WebSphere Adapters

Re-use

With SOA, you can cut costs, reduce cycle times, and expand access to core applications through re-use of

services in various business applications. Use portfolio management to consider which assets you need to run

your company. Identify high-value existing IT assets and service-enable them for re-use. Satisfy remaining

business needs by creating new services. Finally, create a registry or repository to provide centralized access to

and control of these reusable services.

Some of the WebSphere products that support the SOA Re-use entry point are:

• WebSphere Application Server and WebSphere Application Server Community Edition

• WebSphere Service Registry and Repository

• WebSphere IP Multimedia Subsystem Connector (WebSphere IMS Connector)

• WebSphere Extended Deployment

• WebSphere Commerce

There is no "right" place to start with SOA. Where you start depends on your specific business needs. You can

use any one, or any combination of, these entry points to approach SOA incrementally. The IBM SOA Self-

Assessment can help you determine which entry points makes sense for you.

How does WebSphere support the SOA lifecycle?

Now that you understand the various SOA entry points you might choose, let's talk about how to start with your

own SOA project. IBM has defined four phases in the lifecycle of an SOA project. These phases make up the SOA

Foundation, which is a set of best practices, software, and patterns for implementing SOA in your business.

WebSphere products can help you with each phase of implementing an SOA project from model to deploy. The

phases of an SOA project are:

Model

During the model phase, you'll collect and assess your business needs and define your business processes. You'll

then design the services to support these processes. During this phase, you can use WebSphere Business

Modeler to build a model of your business and IT processes and goals. The model help you see whether the

resulting application meets your company's needs and can provide you with a benchmark for measuring business

performance.

Assemble

During the assemble phase, you create services out of existing assets, such as enterprise resource planning

(ERP) and financial systems, CICS applications and other solutions that run your business. If the necessary

function to support a business process doesn't exist, you can create and test a new service to deliver it. Once you

have the required services, you can combine them to create a business process. You can use the following

WebSphere products to help you with the assemble phase of an SOA project:

• WebSphere Portlet Factory helps you quickly and easily create and deploy portlets.

• WebSphere Integration Developer helps you assemble complex services into business processes.

• WebSphere Service Registry and Repository enables you to store, access, and manage metadata to

support your SOA project.

Deploy

During the deploy phase, you configure your run-time environment to meet the service levels required by your

business processes. Then you can deploy it into a scalable, secure services environment. The services

environment is optimized to run critical business processes while having the flexibility to make dynamic updates

in response to changing business requirements. This service-oriented approach reduces the cost and complexity

associated with maintaining numerous point-to-point integrations. WebSphere provides many products to help

you with the deploy phase:

• WebSphere DataPower SOA Appliances are easy-to-deploy network devices that simplify, help secure,

and accelerate your XML and Web services deployments while extending your SOA infrastructure.

• WebSphere Process Server securely and consistently executes your critical business processes.

• WebSphere ESB provides standards-based Web Services connectivity and service-oriented integration.

• WebSphere Message Broker provides an advanced ESB that offers universal connectivity and any-to-any

data transformation, which allows for applications that do not conform to standards to connect to an

ESB.

• WebSphere Partner Gateway

• WebSphere Adapters provide predefined adapters and a build-your-own toolkit to help you quickly

integrate business applications into your SOA. The adapters service-enable your applications by

connecting them to the ESB, which powers your SOA.

• WebSphere Portal links people to information so they can execute tasks quickly and accurately, and

helps you quickly deploy content and applications in an SOA.

• WebSphere Everyplace Deployment extends SOA applications to the edge of your network.

• WebSphere Federation Server gives you access to disparate data sources and helps you build unified

business views.

• WebSphere Application Server and WebSphere Extended Deployment delivers the secure, reliable

application infrastructure you need for your SOA.

Manage

During the manage phase, you're concerned with establishing and maintaining service availability and response

times, as well as managing underlying services. By monitoring key performance indicators in real time, you can

get the information you need to help you prevent, isolate, diagnose and fix problems. Once you understand the

performance of your business processes, you can provide feedback to improve the business-process model as

needed. During th management phase, you also manage version control of the services that make up your

business processes.

One of the key products you can use to continuously monitor and improve your business processes is WebSphere

Business Monitor.