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 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.
Top Related