All rights reserved by SMU & John M. Medellin 1 Business Process Management and Services Oriented Architecture Presentation OOAD Class Curriculum John.

All rights reserved by SMU & John M. Medellin 1

Business Process Management and Services Oriented Architecture Presentation

OOAD Class Curriculum

John M. Medellin

March 2, 2015

All rights reserved by SMU & John M. Medellin

2

Speaker’s CV Sketch

John M. Medellin

Retired IBM Vice President and PricewaterhouseCoopers Partner30 Years Experience in IT Domain and IT Management

Currently Candidate to PhD Degree at SMU LyleDissertation Defended October 10, 2014Professor Steve Szygenda, PhD, C. Green Chair in Engineering, AdviserProfessor LiGuo Huang, PhD, Member of the Committee“Using Special Purpose Heuristics in Software Configuration Management Audits” Plan to graduate on May 16, 2015

Prior roles in this domain include:2007: Global Leader IBM SOA Center of Excellence2010: Financial Services; largest SOA Project at IBM (800+ staff)2012: Strategic Services Executive; Largest Projects in Latin American Region


3

Business Process Management Domains

Process Modeling and Analysis

Invoke

Invoke

Invoke

Invoke Invoke

Process Orchestration and Choreography

ENTERPRISE SERVICE BUS

Process Monitoring and Management

112

2

3

45

678

9

10

11


4

Business Process Modeling Tools

Import Formats Export Formats

WBI Modeler 5.1 projectWBI Modeler 4.2.4 - .ORGDelimited TextXML Schema - .XSDVisio - . VDX

WBI Modeler 5.1 projectFDLDelimited textUML – Rational XDEWBI-SF: BPEL, WSDL, XSD

Note: FDL/BPEL exportsrequire further development beforedeploying to appropriateruntime.


5

Business Process Choreography

-Eclipse based-Eclipse plug-ins for ClearCase, etc.-Develop BPEL, XSD, WSDL, JSP, etc.-Integrated Test Environment

WebSphere Studio Application Developer – Integration Edition


6All rights reserved by SMU & John M. Medellin

6

A SOA Is Composed of Multiple Layers that Decouple the Provider and Consumer Views

Composite ServiceAtomic Service

Registry

Da

ta A

rchite

cture

an

d B

usin

ess In

tellig

en

ce

Qo

S, S

ecu

rity, Ma

na

ge

me

nt, a

nd

Mo

nito

ring

Infra

structu

re S

ervice

Inte

gra

tion

(En

terp

rise S

ervice

Bu

s Ap

pro

ach

)

consumers

business processesprocess choreography

servicesatomic and composite

service components

operational systems

Se

rvice C

on

sum

er

Se

rvice P

rovid

er

JService Portlet WSRP B2B Other

OOApplication

CustomApplication

PackagedApplication

Go

vern

an

ce

Service M

odeling

These are not layers, they addressed in the appendix


7

Layer 1: Operational Systems (Leverage Existing Investment)

Recognizes the value of existing IT investment

Some SOA Related Activities: Asset Inventory Refactor existing applications to unlock business value

May have a valuable asset hidden in side an application, e.g. a portfolio valuation algorithm buried inside a COBOL application.

SAP CustomApplication

OOApplicationISV

Custom Apps

Supporting Middleware

Broker DBMS

Outlook

Operational Systems(Applications & Data)

Examples for illustration: specifics are not in the scope of the Reference Architecture.




8

Layer 2: Service Components (Service aligned implementation façades )

Service Components

The Service Component Layer: Enables IT flexibility by strengthening the decoupling in the system. Decoupling is

achieved by hiding volatile implementation details from consumers. Often employs container based technologies like EJBs

Each Service Component: Provides an enforcement point for service realization Offers a facade behind which IT is free to do what they want/need to do

ApplicationY

ServiceComponent

A

PackageX

Service A

Application B

XML via HTTP.

WSClient




9

Layer 3: Services (Decouple Business and IT)

The Services Layer forms the basis for the decoupling of Business and IT. Captures the functional contract (incl. QoS) for each standalone business function or each

task in a business process

The assumption is that (within an SOA) IT responsibility is to realize/manage service implementations that faithfully conform to the set of services in the service model.

The Service Model is a governed asset

The service layer is not an operational layer, it is a semantic layer

Servicesatomic and composite




10

Services Layer cont’d

• This layer contains all the exposed services in the SOA• They can be “discovered” and invoked, or possibly choreographed into a

composition. • Services are abstract “functions” that are accessible across a network according

to specifications captured in the service description.• Services and their contracts are defined by Senior Architects and form the heart

of the design.• Each service is a contract between the consumer(s) and the provider(s). In a

value chain, a service is a contract among all participants.– consists of: service descriptions, policies, service versions, SOA

management descriptions as well as attachments that categorize or show service dependencies.




11

Not all Services are created equal

registry

Services orientation is a tool, tools are used for many things SOA is about business/IT alignment and represents one use of services,

not all uses. Exposed Services are key to SOA and are subject to stringent

governance/management Each service represents a governed business operation, potentially consumed by several business

processes and/or partners – breaking the contract is potentially costly Some services do not need exposure because they support other services or are not invoked

directly from the registry (they however should be registered as such) Principle of encapsulation and information hiding (as well as private interface)

Servicesatomic and composite

Exposedservices

allservices

Governance




12

Layer 4: Business Processes (Business process alignment of IT)

This layer contains operational IT artifacts that implement business processes as a choreography of services

The set of services that are choreographed/composed is restricted to those services that are defined in Layer 3

While BPEL is often used in this layer it is not a requirement… e.g. A Java Bean could be used to choreograph a set of services. The choice of technology depends on a set of realization decisions that must be made

when establishing a physical Reference Architecture for a given SOA. Those decisions are typically made based on requirements and the capabilities of the

available alternatives.

The granularity & binding decisions at this level are critical to performance and many times must be prototyped in advance of the services being coded themselves.

Business ProcessComposition; choreography; business state machines



13

Layer 5: The Consumer Layer (Channel independent access to business processes )

This layer exists to recognize that the technology chosen to expose Business Processes/Services must permit access from a wide set of interaction channels.

When establishing a Physical Reference Architecture for a given situation, it is important to populate this layer with the set of channels types that are required in a solution.

Each channel type is typically accompanied limitation/capabilities that will shape the way the Physical Reference Architecture supports communication with Business Processes and Services.

In particular the portal aspect of this is crucial. The framework for assembly and presentation is governed by choreography and the presentation itself mutates as users discover different areas of the business process (specially during error correction and in exception conditions in the BPEL).

ConsumersPortal Ajax B2BWSRP <other>


14

Cross-cutting concerns/capabilities

Several concerns are not restricted to a single layer in the Reference Architecture, these concerns are captured in ‘Layers’ 6-9

These are not really layers but treating them as such gives us the ability focus discussions/decisions, for example “What is found where Governance intersects Services? i.e. what are the Governance concerns specific to Services?”

Clearly there is interaction among these ‘layers’ also. For example, it is likely that most data architectures will be subject to governance

Integ

ratio

n (En

terp

rise Se

rvice B

us)

Qua

lity of S

ervice

(Secu

rity, Ma

na

gem

en

t & M

on

itoring

Infra

structu

re S

ervice

s)

Data

Arch

itecture

(me

ta-da

ta &

services) &

Busin

ess In

tellig

ence

Gove

rnan

ce

1

2

3

4

5 6 7 8 9

for illustration: this is not saying that SOA requires an ESB.


15

Module View

Infrastructure Services

Enterprise Service Bus

PartnerServices

BusinessApplicationServices

ProcessServices

InformationServices

InteractionServices

Application and Data Access Services

Business Performance Management Services

Development Platform

Business Application and Data Services

Enterprise Applications and Data


16

Actual Implementation Example

The purpose of Service Integration Pattern is to:

1.Provide an standard way to integrate components distributed in same subsystems, different subsystems or different systems (outside of SOA System)

2.Decouple integration logic from business logic

The above is an illustration of additional patterns that are implemented within the SOA Architecture, it is for a real client.

ESB

EXTERNAL SYSTEMS

SOA SYSTEM

Subsystem A

Integration Layer

Business Layer

Access Layer

Integration Layer

Business Layer

Access Layer

Subsystem B

Integration Layer

Business Layer

Access Layer

Access to components in same subsystem (e.g. in same package) must be done by using business component mediators. No need to use integration mediators

Access to any external system or web service must be done through the ESB using integration mediators described in Service Integration pattern

Access to components in different subsystems (e.g. different packages) must be done by using routers and adapters described in Service Integration pattern e.g. Common Services

Access to global components e.g. DB, Process Server, Business Fabric, etc . must be done by using integration mediators described in Service Integration pattern.

A service component is divided into three layers for access, business logic and integration


17

Architecture Patterns and Tradeoff Decisions

• Modifiability vs Performance: The ability to trace changes from business scenarios to the services themselves has proven to be more efficient in maintaining SOA architectures– Impact: Performance hit very probable due to the increased number of components involved in

service invocation, choreography, assembly and presentation. Instantiated services also remain in the environment until the business process has executed causing more resource usage.

– Tactics: Balance service atomicity and weight by achieving a balance of 5-7 operations per service, only expose services that are consumed in real time, hide services that are atomic and do not provide dialogue or direct impact to a business process. Protoype early and often, enable tradeoff analysis by pre-negotiating response times for each step in the business process scenario.

• Interoperability vs Testability: The ability to provide services that have syntactic as well as semantic properties is critical to SOA objectives.– Impact: because of so many layers and moving parts within the architecture, testing is more

complex than traditional architectures (states, re-creation, service independence)– Tactics: embed verbose output and report methods in the code that can be invoked through

switches and variants, use state machines to capture memmory behavior, trace output received back to artifacts (classes etc.) within the sdk environment to step through test scenarios.

• Usability vs Security: Services can typically be invoked in a variety of ways because they can be exposed in internal, external or published areas.– Impact: attack surface is greater in SOA design patterns because of the dependence on multiple

parts being active in networks (internal/external etc.). – Tactics: Special care in service design to minimize attack surface & access, consider including

embedded security in the service itself (depending on criticality), definitely service monitors required.


18

Thanks !!!!

All rights reserved by SMU & John M. Medellin 1 Business Process Management and Services Oriented Architecture Presentation OOAD Class Curriculum John.

Documents

smu john

service components service

management slide

process orchestration

business value

cobol application

appendix slide

smu lyle dissertation