March 2008 © 2008 IBM Corporation

IBM Software Group

SOMA, RUP and RMC: the right combination for Service Oriented Architecture

WebSphere User Group, Bedfont, 4th March, 2008

Keith MantellSenior Solution Architect

IBM Rationalkeith_mantell@uk.ibm.com

IBM Software Group

2

Agenda

What is SOA?

Rational Tool Support for SOA

Development Processes for SOA– Rational Unified Process – Rational Method Composer– RUP SOMA: variations

Examples

IBM Software Group

3

What is Service-Oriented Architecture (SOA) ?

SOA is different things to different people:

– a set of services that a business wants to expose to their customers and partners, or other portions of the organization

– an architectural style which requires a service provider, requestor and a service description

– a set of architectural principles, patterns and criteria which address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse, composability

– a programming model complete with standards, tools and technologies such as Web Services

– a middleware solution optimized for service assembly, orchestration, monitoring, an management

BusinessExecutive,

Analyst

Architect

Developer

ITArchitect

Software andSystem

Developer

IBM Software Group

4

Moving to Services-Oriented Solutions – Vision

Servicesatomic and composite

Operational Systems

Service Components

Consumers

Business ProcessComposition; choreography; business state machines

Service ProviderService C

onsumer

Integration (Enterprise Service Bus)

QoS Layer (Security, M

anagement &

Monitoring Infrastructure Services)

Data Architecture (m

eta-data) & B

usiness Intelligence

Governance

PackagedApplication

CustomApplication

OOApplication

Channel B2B

IBM Software Group

5

Moving to Services-Oriented Solutions – Challenges

Servicesatomic and composite

Operational Systems

Service Components

Consumers

Business ProcessComposition; choreography; business state machines

Service ProviderService C

onsumer

Integration (Enterprise Service Bus)

QoS Layer (Security, M

anagement &

Monitoring Infrastructure Services)

Data Architecture (m

eta-data) & B

usiness Intelligence

Governance

PackagedApplication

CustomApplication

OOApplication

Channel B2B

Hosting

Bind Resource

Mediation

Transformation

Orchestration

Transport

Reliability

Security

Identity

Permissions

Firewall

Policy Management

Contract Management

Registry

RepositoryReuse

QoS

Flexibility

IBM Software Group

6

Agenda

What is SOA?

Rational Tool Support for SOA

Development Processes for SOA– Rational Unified Process – Rational Method Composer– RUP SOMA: variations

Examples

IBM Software Group

7

SOA: the Larger Context

BusinessAnalyst

Rational RequisiteProDocument Business Strategy

Capture Business Goals, Objectives and Requirements

Trace Business

Objectives, Requirements

& Create Business Use Case Outlines

Trace Requirements & Architect System

Use Case Realizations

Create & Manage System

Requirements and Use Cases

Architect

Rational Software Architect

Model Services

ProjectManager

Rational Portfolio Manager

Business Strategist

Understand Risk, Project

Costs, and ROI

Identify and Manage

Projects and Resources

DatabaseDeveloper

Deploy/Run

Monitor

BusinessOperations Manager

RuntimeWebSphere Process ServerWebSphere Portal WebSphere Business Monitor

EAR

IBM Rational Team Unifying Platform

WebSphere Integration Developer

Choreograph services using

BPEL, WSDL, etc.

Configure Human Task Manager

(including Ad-Hoc) & Client

Use Business Rules, State Machines, Web Services,

Adapters, ESB, etc.

Integration Developer

EARTester Rational Functional Tester

Rational Performance Tester

EARVerify Quality

Implement Services, &

expose as Web Services

Rational Application Developer

Developer

Develop Portlets

(App UI and Monitor)

WebSphere Business Modeler

Create FinancialReports &

ROIEstimates

Create, Simulate & Analyze As-Is Business

Model

Create Observation Model with

KPIs & export to Monitor

Create, Simulate,

Analyze and Optimize To-Be Business

Model

Run-time Statistics

UMLBPEL

Details

IBM Software Group

8

Service Quality Management Functional and Performance Testing of Web Services from a common interface

Rational Tester for SOA Quality

Automated regression and functional testing for GUI-less Web services

Rational Performance Tester Extension for SOA Quality

Performance Testing for Web Service based applications

IBM Software Group

9

Asset Management – Solutions

Project repositories

Reusable Asset repository Portfolio data warehouse

Rational Portfolio Manager

ClearCase, ClearQuest, ReqPro

databases

Promote

Consume

Rational Asset Manager

Service Registry & Repository

WSRR

Analyze

Discover

IBM Software Group

10

Agenda

What is SOA?

Rational Tool Support for SOA

Development Processes for SOA– Rational Unified Process – Rational Method Composer– RUP SOMA: variations

Examples

IBM Software Group

11

Why Use the Rational Unified Process(RUP)? RUP provides a software development practitioner with a

standards-based yet configurable process environment. That process environment:

– Allows a tailored method to be published and made accessible to the entire project team

– Allows that method to be configured to suit the unique needs of each project

– Provides each user with customized filtering

RUP is a body of software engineering practices that are continually improved to reflect changes in industry practices.

IBM Software Group

12

Why Should I Use RUP? (cont.) For stakeholders

– RUP provides a glossary of terminology and an encyclopedia of knowledge to help you communicate your needs effectively with the software development team.

For software development practitioners– RUP provides a central, common process definition that team members

can share, helping to improve communication. – RUP provides a wealth of guidance on software development practices

For managers or team leaders– RUP provides you with a process by which you can communicate

effectively with your staff, and manage the planning and control of their work accordingly.

For process engineers– RUP provides you with an architectural foundation and wealth of

material from which you can construct your process definition.

IBM Software Group

13

History of the Rational Unified Process

200720032002200120001999199819971996

Objectory Process

Rational Approach

•OMT•Booch•UML 1.0

•Requirements •Test Process

•UI Design•Data Engineering•UML 1.1

•Performance Testing•Business Modeling•Configuration and Change Mgt

•Project Management•UML 1.3•RealTime

•Rational Process Workbench•Major addition of content

•Major addition of tool mentors

•Introduction of RUP Platform providing a configurable process framework 

Improved Process for independent testing

•Tree browser upgraded for enhanced capabilities of creating customized My RUP tree

•Terminology changes•Introduction of RUP Base Concepts•Key Principles for Business- Driven Development•Delivery processes

IBM Software Group

14

Key Principles for Business-Driven Development The tried-and-true best practices of the Rational Unified Process have been the

basis for the evolution of our tools and processes for more than a decade. Today, as software development is becoming a key business capability, our

best practices are maturing within the larger context of business-driven development.

The following six principles re-articulate our best practices for the broader lifecycle of continuously evolving systems, in which the primary evolving element is software:

Adapt The Process

Balance Competing Stakeholder Priorities

Collaborate Across Teams

Demonstrate Value Iteratively

Elevate Level Of Abstraction

Focus Continuously On Quality F E

D C

B A

IBM Software Group

15

Major Milestones: Business Decision Points

Architecture baselined

Lifecycle Architecture

Milestone

Scope and Business Case agreement

Lifecycle Objective Milestone

Product sufficiently mature for customers

Initial Operational Capability Milestone

Customer acceptanceor end of life

Product Release

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

time

IBM Software Group

16

What is Rational Unified Process(RUP)?

IBM Software Group

17

More detail!

IBM Software Group

18

Agenda

What is SOA?

Rational Tool Support for SOA

Development Processes for SOA– Rational Unified Process – Rational Method Composer– RUP SOMA: variations

Examples

IBM Software Group

19

Structuring Process Content

Project plantemplates

Lessons learnt from previous project and

iterationContent onmanaging

iterative development Corporate guidelines

on compliance

Content on agile development

JUnit user guidance

Content on J2EE

Configure a cohesive process frameworkcustomized for my project needs

Create project plan templates for Enactment of process in the context of my project

Standardize representation and manage libraries of reusable Method

Content

Develop and manage Processesfor performing projects

Process assetspatterns

Standard or reference processes

Guidance on serialized java beans

Configuration mgmtguidelines

IBM Software Group

20

Method Content Example

IC / Best Practices

Books / Publications

Standards / Regulations

Homegrown Methods

IBM Software Group

21

ProcessExample

IBM Software Group

22

Tools - Authoring, configuring and viewing capabilities

IBM Software Group

23

Agenda

What is SOA?

Rational Tool Support for SOA

Development Processes for SOA– Rational Unified Process – Rational Method Composer– RUP SOMA: variations

Examples

IBM Software Group

24

What we do?

How we do it?

RealizationDecisions

Specification of Services, Components, and Flows

Identification of Candidate Services and Flows

Domain Decomposition

SubsystemAnalysis

ServiceSpecification

message & event

specification

component flowspecification

service flowspecification

Realization Decisions

Goal-ServiceModeling

Existing AssetAnalysis

Component Specificationinformation

specification

service allocation

to componentscomponent

layeringtechnical feasibility exploration

SOMA activities are grouped into three major steps: Identification, Specification, and Realization Decisions.

At the heart of SOMA is the identification and specification of services, components, and flows.

Each step is carried out by applying one or more complementary techniques.

SOMA activities are grouped into three major steps

IBM Software Group

25

Service Identification

Identification

Specification

RealizationDomain

decompositionGoal Service

ModelingExisting Asset

Analysis

Top-down Analysis

Bottom-up Analysis

Align Serviceswith Business Goals

Functional Area Analysis

Process Decomposition

Variation-Oriented Analysis

CBM Maps aligned with

industry models

Industry process models

Business classification /

externalization of rules

Business directions, metrics, KPIs

Industry models as common framework for

mapping legacy systems functionality

IBM Software Group

26

Process decomposition helps identify candidate services

A sub-process is a convenient construct used to denote further levels of refinement to a process into its constituent parts (sub-processes), recursively.

Sub-processes are used to identify candidate services. The list of use cases provides the initial scope for system design (“business as usual”).

Process

Sub-process Sub-process

Process Process Process

In this top-down approach of the service identification approach, leaf-level sub-processes are good candidates for services.Rule of thumb: 3 levels of decomposition.

Use CaseUse CaseUse Case

Leaf-level Sub-process

Leaf-level Sub-process

Leaf-level Sub-process

Process Decomposition

IBM Software Group

27

Process Decomposition work productsProcess Decomposition

Process Definition Use Case Model Service Model

IBM Software Group

28

Detailed process analysis

Customize Control Flow

Assign RolesIdentify Automated Activities

Define Business Concepts And Information Flows

Analysis Process Model (APM)

Process models Process Definition

IBM Software Group

29

Service Analysis with RSM/RSAExtend the Class model based on the information requirements of the use caseDefine boundary of type class diagram

Analysis Process Model (APM)

Request for benefit to be provided by an insurer to the insured or entitled beneficiaries, under the terms and conditions of a policy.The Claim includes the following information:- Claim description- Claim open date- Claim reference number- Claim type- Claimant name- Claimee name- Claim status- Claim underlying insurance policy - Claim related Loss event

Business Object Model (BOM) – Boundary of type ClaimFolder

IBM Software Group

30

■ Service Specification- Elaborates the Service Model,

for example, service dependencies, composition, non-functional requirements, service message specifications, design decisions, and so on- Includes Service Litmus Test

that “gate” service exposure decisions

■ Subsystem Analysis- Partitioning into service

components that will be responsible for service realization

■ Component Specification- Detailed component modeling,

flow, information architecture, and messages

SOMA Specification Specifies Services, Service Components, and Flows

Domain Decomposition

SubsystemAnalysis

ServiceSpecification

message & event

specification

component flowspecification

service flowspecification

Realization Decisions

Goal-ServiceModeling

Existing AssetAnalysis

Component Specification

informationspecification

service allocation

to componentscomponent

layeringtechnical feasibility exploration

Identification

Specification

Realization

IBM Software Group

31

Service Specification Steps

Service Specification defines the dependencies, composition, exposure decisions, messages, quality of service constraints and decisions regarding the management of state within a service.

Identify Non-Functional Requirements

Use non-functional requirements to specify the desired quality of service.

Identify Services Composition andFlow

Review of functional areas and business processes will elaborate the composition of services from other services and their flow to enable the business function. (Service) Flow Specification describes the choreography between services.

Apply Service Litmus Test to Make Exposure Decisions

Use Service Litmus Test to make service exposure decisions – “From my candidate services, which ones should be exposed?”

Specify Service Messages

Identify and specify the format and content of input and output messages of a service.

Document State Management Decisions

Sometimes, the composition of services requires management of state. Document these decisions such as the answer to “What kind of persistence will be used and how will it be enabled?”

Identify ServiceDependencies

Detailed review of the service may expose service dependencies on other services or applications that will be used to realize the functionality of the service.

Service Specification

Service Model

IBM Software Group

32

Service Litmus Test

During the Service Specification, we make service exposure decisions: “From all the candidate services, which ones should we expose?”

S0S1

S2S3

Business Goals Candidate Services

SLT 1-1 : Does the service provide a required unit of business functionality that supports business processes and goals?

Not all candidate services should be exposed.

Every implemented service has costs and risks.

SOMA “Service Litmus Test” helps make exposure decisions.

Candidate Services

Business Alignment Composability

Externalized Service Description Redundancy Elimination

SLT

Services (Exposed)

IBM Software Group

33

Apply service Litmus test

Operation parameters based on Use Case Inputs and Outputs

Define services within IDM based on BOM use cases

Business Object Model (BOM)Interface Design Model (IDM)

Apply Service Litmus test

Service Model

IBM Software Group

34

Specify services messages

Interface Design Model (IDM)

Specify service messagesService Model

IBM Software Group

35

Service Realization:Services May be Implemented in Many Ways

Transform Integrate

Subscribe

Build Buy

Outsource

Integrate: Wrapping a legacy system’s function

Build New Component Functionality (“Roll your own”)

Transform legacy to enable functionality exposure for this service to reuse

Buy: Integrate with third party product

Subscribe

IBM Software Group

36

Service generationExport WSDL/XSD definitions of these IDM services using the generator plug-inWSDL includes Request/Response TypesXSD built based on aggregations and stereotypes

WSDL Interface and XSD (WID)

IBM Software Group

37

RUP SOMA – Service Infrastructure definition

Business Transformation AnalysisBusiness Models including Business

Processes IdentificationIdentify services by analysing business

modelsConfirm viable Services

SpecificationDetailed definition of service interfaces

and data RealizationDecide on approach to implement

services, including make/buy/subscribe decision

Make: How to design a service is not in the scope of this methodEmphasis is on development of services (in a large project or an enterprise)

- Not on services in a wider project context

IBM Software Group

38

Classic RUP with SOMA

Classic RUP Phases, Iterations and ActivitiesNow with added SOMA!!

Thus SOA is integrated into a complete software project development process

We chose this version as the basis of our work

IBM Software Group

39

RUP for SOA The Rational Unified Process (RUP)

describes many useful service specification and design techniques

A good place to start understanding RUP for SOA is the Developing Service-Oriented Solutions conceptual road map

RUP for SOA concentrates on the Analysis and Design discipline

IBM Software Group

40

© Copyright IBM Corporation 2007. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. This information is based on current IBM product plans and strategy, which are subject to change by IBM without notice. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way.IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.