Alix Cheema

1
Our Experiences in Delivering SOA with WebSphere
Process Server

• Alix Cheema
• Senior Architect, Capgemini

2
Agenda

• Background

• WebSphere Suite Process Server Overview

• Beta Programme

• Conclusions

• Lessons Learned

• Summary

• Q A

3
Background

• What
• Capgemini are focused on building specialist
  skills and knowledge for delivering SOA based
  initiatives and projects
• Why
• Help our customers to understand and better
  position SOA
• How does it help with current business drivers
  e.g. cost reduction, faster time to market etc
• Assist with strategic planning for future growth
• How a few examples
• Focus on the A in SOA
• e.g. Service Realisation, SOA delivery
  methodology
• Building strong partnerships with leading SOA
  product companies
• e.g. IBM
• Representation on 13 JSRs
• e.g. JBI, J2EE 5.0, J2SE 6.0
• Lead Chair for Open group
• Leadership of SOA committee in OASIS group (e.g.
  SOA notation)
• Only SI to participate in early WPS beta
  programme

Our goal is to be leading SOA practitioners,
focused on thought leadership and robust delivery
4
WebSphere Suite
WebSphere Integration Developer
WebSphere Process Server
Flexible deployment of business processes, making
plug-and-play of components a reality WebSphere
ESB Connectivity infrastructure for integrating
applications and services to power your SOA
Easy-to-use integration to simplify and speed the
assembly of composite applications
WebSphere Business Modeler
Simple to use process modeling for the business
analyst to help maximize process and business
resource re-use
WebSphere Adapters
Provide connectivity services to enterprise
applications, e.g. SAP, Oracle, Siebel
WebSphere Business Monitor
Real-time visibility into process performance
enabling process intervention and continuous
improvement
Complete tooling from modelling to deployment to
optimisation
5
WebSphere Suite Technical Overview

• 1. Process modeling
• Build and refine process model
• Simulate what if conditions
• Select processes for monitoring

• 2. Observation modeling
• Define metrics, KPIs, events
• Create metrics for capturing working duration and
  decision paths

Generate observation model
Communicate verify model
Modeler
Observation Model Editor
Export observation model runtime artifacts (XMI,
IGF)

• 2. Model preparation
• Further specify and prepare processes for
  deployment
• Leverage web services components

Buildtime Tools (WID RSA)

• 5. Continuous process improvement
• Feed working duration decision percentage data
  back into process model, and start cycle over
  again

WebSphere Process Server Runtime
WebSphere Monitor

• 3. Deployment to runtime
• Deploy process model
• Deploy observation model
• Monitor calculates working durations, decision
  paths, and other KPIs

• 4. Business monitoring
• Monitor the processes/operations real-time

Monitor Dashboard
Semantic continuum, Actor driven (who does what
and when), limited support for full
round-tripping, but heading in right direction
6
WebSphere Process Server Components
Compelling architecture, including support for
business processes, application integration and
human workflow, all encapsulated within a common
invocation, data model and event infrastructure
7
The Common Invocation Model Service Component
Architecture
Interface (export)How to callthis component
Reference(import) What thiscomponents calls
Everything is represented as a SCA and the export
is the business service.
8
The Common Invocation Model Service Component
Architecture

• Removes/abstracts incidental complexity to
  which developers are exposed when dealing
  directly with middleware APIs
• Focus on writing business logic
• Promotes loose coupling and service driven
  component models
• Enables two step process of implementation and
  assembly of heterogeneous service networks (e.g.
  coarse grained system and fine-grained module)
• SCA components connected by a number of different
  bindings e.g. WSDL/SOAP WS, JMS, Java and JCA
• An SCA component can have more than one type of
  export binding
• SCA components bindings configured with QoS
  attributes
• Wiring between components can be configured to be
  synchronous, asynchronous, transactional and
  secure

9
The Canonical Business Object Model Service Data
Objects

• Based on concept of disconnected data graphs
• Simplification of the J2EE data programming model
  
• Abstracts data from backend data store
• Unifies data application development
• Supports and integrates XML
• Business Object Framework consists of

Service Data Objects framework provides a unified
framework for data application development
10
SCA and SDO Together Conceptual View
OtherApplicationsandModules
Module Order Management
Reference
Interface
BO
OtherApplicationsandModules
Web
BO
BO
BO
BO
Web
BO
Component

• SCA components are assembled and wired together
• Export is the business service interface
  exposed to the outside world
• Multiple entry points can be added e.g. JMS
  Export and WS Export
• Module represents a logical domain
• Business Objects are the data flowing on wires
  between Components

SCA enables composition of heterogeneous service
networks and SDO acts as a vehicle for data flow
11
Common Event Infrastructure

• An event occurs when something significant
  happens in the IT system, called situations
• Data about the event is captured in an event
  object.
• The event (object) has a standardized format
  called the Common Base Event (CBE)
• Events can be configured declaratively,
  programmatically and dynamically (through admin
  console)
• Events can be correlated using sessionID
• Supports instance tracking
• All event objects are passed to the event
  infrastructure to enable
• Tracking the progress of a business process
• Audit trails
• Coordinating work between independent business
  processes
• Monitoring for exceptions in a business process
• Events are managed using WebSphere Event Browser

Common end-to-end event capture, correlation and
monitoring
12
WebSphere Process Server Components
13
WebSphere Process Server Components
14
Business Process

• WS-BPEL compliant business process engine
• WS-BPEL 2.0 (currently draft)
• Optionally, generated from WebSphere Business
  Modeler
• Generic Business Process
• Operations / Parameters
• Service Implementation Details hidden
• Transactions / Compensation
• Cannot be specified in Modeler
• Full XPath 1.0 Support
• Visual Debugger

Business Process Execution Language used for
business service orchestration
15
Human Task Manager

• Invoke humans as services
• Human participate in an otherwise automated
  business process
• Human interface to services
• Allows humans initiate a service such as a
  business process or Web Service using a common
  User Interface
• Ad-hoc usage of To-Do list
• Implement a pure-human task (such as a managed
  query) to a colleague or customer
• Forward a workitem to another human

Human interaction can be peer-to-peer, human to
machine or machine to human
16
Human Task Features

• Powerful Staff Resolution
• Integrate with existing enterprise people
  repository (e.g. LDAP, Local OS, custom registry)
• Specify different levels of authority (e.g.
  Readers, Administrators and Potential Owners)
• Included Clients
• Web Client
• Portal Client (JSR 168)
• Transfer and suspend tasks
• Enable expiration, escalation (single or
  chained), notification, sub-tasks and follow-on
  tasks
• Supports four eyes principle
• Notification supports for e-Mail, event, work
  item creation and custom

WebSphere Application Server (J2EE Runtime)
Competitive features for human workflow automation
17
Business State Machines

• Another way to model a process
• Manage transitions
• State Machine Implementation
• Based on UML 2.0State Machine
• Event driven business processes
• Creates WS-BPELunder the cover
• Simple/Complex States
• Entry/Exit
• Transitions
• Guards
• Actions (invokes, e.g. SCA)
• Timeout

Only BPM product to offer state machine
execution, extremely valuable for event driven
systems
18
Business Rules

• Externalize Business Logic from an application
  (business process)
• Easy change of logic that may change
• Dynamically Update Rules in Runtime on the fly
  through Web Interface
• Most-requested Business Rule functionality
• Decision Tables
• Rule Sets (If/Then Rules)
• Rule Templates
• Ease of Use
• Rule Group all artifacts needed for business
  rule developer are contained within one component
• Enables rules to be displayed in the web based
  tooling with a more natural language view
• if invoice.purchase() gt 100.00 then discount
  .05
• When the customer purchase is 100 or more then
  give the customer a discount of 5 percent.
• Implemented by the application developer, defined
  by the business analyst

Rules engine offers basic functionality, does not
compete with specialised rule products
19
Beta Programme

• Objectives
• Solution
• Conclusions

20
Objectives

• Address a real-world scenario to prove the
  practicality of delivering customer solutions
  using the WPS v6.0 Suite
• Create a working demonstration of how the WPS
  v6.0 Suite can address business problems
  Capgeminis customers are facing, taking a full
  development life-cycle approach
• Use the demonstration as a reference site for
  Capgemini IBM to illustrate the strength of the
  alliance and highlight best practice experience
  gained through the beta programme
• Ensure the appropriate training education plan
  is in place to aid in longer term project
  delivery based on WPS v6.0 Suite
• Ensure that the Capgemini-IBM partnership is able
  to demonstrate clear differentiation in the
  marketplace

21
Solution

• Modelled 10 use-cases (3 simple, 5 medium and 2
  complex) based on an on-line product sales
  business
• 6 key domains were architected
• Product
• Payment
• Order Fulfilment (State Machine)
• Inventory (BPEL process)
• Delivery
• Customer Relationship Management
• Designed macro (level 0, level 1) business
  processes using BPEL and state machine
• Incorporated mixture of implementation
  approaches, JMS, EJB and WebServices
• Made use of transactions, however, no security
  was implemented
• Utilised SCA compliant JCA adaptors for
  integration with files and database
• Linux (Redhat) based deployment architecture

22
Conclusions

• Capgemini beta team created gt 150 PMRs,
  representing over 60 of all PMRs raised, key
  summary areas being

• Interchangeable implementations with SCA
• Support for Human Workflow with automated
  processes
• Common tooling support across all components
• Programming model enforces higher-level
  abstraction, entry point is SCA not J2EE
• Common Event Infrastructure
• Integrated Enterprise Service Bus, SCA driven
  (Mediation)
• Built-on WAS
• High-productivity

• Limited refactoring support, e.g. changing a
  module name
• Sometimes difficult to debug errors
• Good understanding of generation policies
  required
• Experienced problems with version control in
  highly distributed development environment
• Specialised integration may require use of
  Advanced ESB product (Message Broker)
• Lack of best practice and design techniques, this
  is improving (e.g. redbooks, whitepapers)

IBM announced Capgemini involvement in beta
programme was best-ever. WPS is ready for
production and we are engaged in a number of WPS
projects.
23
Lessons Learned

• Adoption
• Architecture
• Development
• Deployment

24
Adoption

• Dont attempt to sell SOA to the business, lead
  with BPM and position SOA as an enabler
• Selling SOA is difficult due to difficulties in
  measuring ROI and TCO
• Successful adoption of a business process
  platform requires significant involvement from
  business stakeholders
• Defining all major business processes is a major
  undertaking, adopt an incremental approach
• Approach must be driven from the business down
• Clear line of sight from business to IT
• Value Chain
• Business Strategy/Drivers/KPIs
• Business Services
• Business Processes
• Remember process flexibility is constrained by
  packaged products and bespoke applications
• Service enable packages/applications when and
  where possible
• Dont be forced by vendors to select vertical
  packaged solutions
• Dont try to automate everything
• Some processes are better handled by people,
  consider cost/benefit
• Automation should facilitate collaboration
  between employees, not hinder!

25
Architecture

• Dont approach the design of SCA as you would
  with the design of Java Objects
• Modules should be used to represent a logical
  business domains
• Design coarse grained business orientated
  interfaces for exports
• Minimise Modules and group components sensibly
• Understand generation policies
• Authored versus generated
• Inter communication between SCA components
  generates LocalEJB
• External communication between Modules generates
  RemoteEJB
• Synchronous versus Asynchronous reference
• Synchronous uses RMI based invocations
• Asynchronous uses request/reply patterns via JMS
  queues
• Use the State Machine to model event driven
  interactions
• Difficult to code using BPEL
• Use BPEL to model sequence based service
  interactions
• Long running processes should be marked as
  asynchronous and are persisted
• Ensure appropriate correlationID(s) are
  identified, better to use alias
• Use Compensation Handlers inside to BPEL to
  rollback operations

26
Development

• Consider disabling Auto-Publish and Auto-Build
• Cache results of Service.Manager.locateService()
• Avoid overuse of WPS components
• Use coarse-grained exports to minimise
  invocations
• Use the simplest component kind for required
  function
• Utilise multi-threaded SCA clients to achieve
  concurrency
• Test components using WID, e.g. BPC to start
  processes
• Team-based component wiring can be risky,
  especially at earlier stages of development,
  instead consider using stubs.
• Error handling is an iterative process, design
  for the maximum error handling and tweak over
  time
• Fault handlers around Invokes, Scopes, entire
  Processes
• Involve Human Tasks in fault handlers to help
  manage exceptions
• Available for interruptible processes only
• Implement a comprehensive source control
  environment with backup
• Understand derived v non-derived files
• Always synchronise before committing or updating
• Export modules between workspaces as Interchange
  files

27
Deployment

• Reduce the number of SCA Modules, when
  appropriate
• Place local modules in same server JVM
• Use Asynchrony judiciously
• Avoid unnecessary cross-component async
  invocations in a module
• Avoid unnecessary cross-module Asynchronous
  invocations
• Use async SCA instead of JMS bindings when
  possible
• Configure the required level of MDB concurrency
  for asynchronous components
• Use Object Data Representation for JMS
• Security should be enabled so not everyone can
  modify business data in Failed Event Manager
• Use Common Event Infrastructure (CEI) to track
  all events in a business transaction

28
Summary
29
Summary

• Product offers BPM, human workflow and
  integration in a common architecture
• WebSphere Process Server offers a compelling
  architecture for designing and building highly
  pluggable service based systems
• Service Component Architecture (SCA) is a
  powerful abstraction model that separates the
  what from the how
• True round tripping between modeller, WID,
  monitor is heading in the right direction a
  single meta model is key
• Improvement areas robust distributed
  development, SCA repository, improved debugging,
  tuning ,best practice and refactoring support
• Business involvement from the start is key,
  preferably starting from Modeller
• Organisations must consider the wider
  implications on architecture and governance if
  they are to be successful with SOA and BPM
• Current systems incorporate large amounts of
  batch processing, as systems become more
  real-time, business models will have to evolve

30
Questions Answers