understanding soa chappell

7/30/2019 Understanding SOA Chappell

1/135


2/135


3/135


4/135

The Evolution of Application Architecture

Clients

PCs

Web

Web Services

TMainframe

DBMSBusiness

Logic

GUIClient/Server DBMSBusiness

LogicBusiness

Logic

BrowserMulti-TierDBMS

Business

Logic

Service-Oriented DBMSBusiness

Logic BusinessLogic


5/135

Enterprises Today

PackagedApplication

Z

ERPApplication

PackagedApplication

Y

J2EEApplication

.NETApplication

PackagedApplication

X

CICSApplication

AS/400

Application


6/135

Enterprises with SOA:An Idealized View

BusinessService

BusinessService

BusinessService

SOAPBusinessService

BusinessService

BusinessService BusinessService BusinessService


7/135

What Exactly Is a Service?

There is debate about the meaning ofservice

Its analogous to the 90s argument aboutobject

In practice, a serviceis what isimplemented by dominant products:

Microsofts .NET Framework

IBMs WebSphere Application Server

BEAs WebLogic Application Server

Others


8/135

Defining Services: The Specs

SOAP, WSDL

WS-Addressing

WS-Policy

WS-Security, WS-SecureConversation,

WS-Trust, WS-ReliableMessaging

WS-Coordination, WS-AtomicTransaction

Other concerns, e.g., state management,are implementation issues

Referred to collectively as the WS-* specs

S i O i i


9/135

Service-Orientation:Clarifying Terms

Services:

Described using WSDL and accessed viaSOAP

Service-oriented applications:

Expose business logic through servicesService-oriented architecture (SOA):

Guidelines for creating and usingservice-oriented applications


10/135

Defining SOA

An approach to building applications in aservice-oriented world, including:

Guidelines for:

Defining and exposing business services

Defining and enforcing service levelagreements

Common technologies for:

Securing services Managing services

More

S ft Ab t ti i S i O i t d


11/135

Software Abstractions in a Service-OrientedWorld

Services

AccessData

Relations

Logic

Objects

Presentation

GUIs

Tables Object hierarchiesSQL types Java/CLR types

Object hierarchies Service interfacesJava/CLR types XML types

Service interfaces Widgets/controlsXML types Java/CLR/JavaScript types


12/135

Services and Messages

SOAP is a message-oriented protocol:


13/135

Communication Styles for Services:RPC and Messaging

Client Service

Synchronous RPC

Request

Response

Message

Message

Asynchronous Messaging

Message

Both made reliable by WS-ReliableMessaging

Communication Styles for Services:


14/135

Communication Styles for Services:Persistent Queuing?

Client Service

Message

Queue A

Message

Queue B

Not directly supported byWS-ReliableMessaging

Why SOA Makes Sense:


15/135

Why SOA Makes Sense:Technical Benefits

Applications can be exposed more easily todiverse clients

Because their logic can be accessed in astandard way by JSP, ASP.NET, mobiledevices, and others

Existing services can more easily be reused

Because apps expose their services in a

standard wayNew applications can be created or modifiedin less time and for less money

Because existing services are alreadyavailable

Why SOA Makes Sense:


16/135

Why SOA Makes Sense:Business Benefits

Business people understand services

So IT people can talk with them more

easilyApplication integration becomes cheaperand faster

Which makes implementing business

processes easier

Business processes can more easily bechanged or replaced

Because theyre built from autonomous

services with well-defined interfaces


17/135

Some Risks of SOA

Does it make sense to build most newapps in a service-oriented style?

Yes: there are exceptions, however

Can service-oriented apps perform?

Yes: perhaps 10-15% of people haveperformance problems today (typicallycaused by bad design or very high load

on a service)Can the organizational challenges beovercome?

Probably: more on this later


18/135

The Real Impact of SOA

The mechanics of creating a service aresimple

Designing a service-oriented application isa bigger challenge

Exposing the right services is hardHardest of all are SOAs organizationalchanges

The real challenges are human, nottechnical


19/135

Who Benefits Most From SOA?

Styles of IT Governance

Totalitarian,Centralized

Anarchic,

Decentralized

ERP-CentricOrganization

Merger-CreatedOrganization

More immediate benefitfrom SOA

An Early SOA Example:


20/135

An Early SOA Example:Credit Suisse

IONAOrbix

IONAOrbix

IONAOrbix

Unix and WindowsServers

IBM Mainframes

IMSApplications

CICSApplications

Windows Desktops

Credit Suisse:


21/135

Credit Suisse:SOA Growth

Exposed businessservices

Front-endapplications

Users

1999

35

5

800

2000

173

21

9,000

2001

500

50+

100,000

2003

800

150+

100,000+

Credit Suisse:


22/135

Credit Suisse:What They Learned

Challenges:

An expensive project

ROI took time to materialize

Performance wasnt good initially

Security and management were custom Business units resisted sharing their

services; they were encouraged

Benefits:

Faster application development

75-80% of required services already available Savings of several million dollars a year

Another Example:


23/135

Another Example:SOA at Microsoft

.NET Framework

Alchemy

Siebel

Clarify

MS Sales

Worldwide

MarketingDatabase

ADO.NET

Siebel BusinessObjects

Sales

Portal

.NETEvangelism

Factory

AccountExplorer

Others

Defining SOA:


24/135

gSummary

The global agreement on web servicesmakes a service-oriented world practical

Services and SOA bring real benefits

Building service-oriented applications willbecome the default for most organizations


25/135

Moving to SOA

Getting Started


26/135

Getting Started

Creating a pure SOA environment willtake a long time

Making everything SOAP-accessiblemay never happen

The initial problem is to create service-oriented applications

Service-oriented architecture is built on

thisDifferent organizations move to SOA indifferent ways

Moving to SOA:


27/135

gThe Top-Down Approach

How it works:

Define a business architecture

Discover what services are required

Create service-oriented apps based on this

Pros: Its elegant, clean, and sensible

Cons:

Its very difficult in most organizations

Getting the up-front funding and business buy-

in is tough

Moving to SOA:


28/135

The Bottom-Up Approach

How it works:

Build a service-oriented app

Then build another one

Next, work on central SOA issues, e.g.,security and management

Then build another service-oriented app ...

Pros:

Its the only approach that works in mostorganizations

Cons: Its an inelegant, piecemeal approach

Think Services Not Objects


29/135

Think Services, Not Objects

Distributed object technology is over

CORBA, DCOM, Java RMI, etc. are

legacy technologies

The distributed future belongs to services Built on technologies such as Indigo

Some Characteristics of Services (1)


30/135


Services are defined by the contract theyexpose

Expressed in WSDL, XML schemas, andpolicies

Should contracts should be specifiedcode-firstor contract-first?

Service are as autonomous as possible

They have independent runtimeenvironments and failure modes

They are independent of any particulartype of client



31/135


Calls to services are generally expensive

So fine-grained interfaces are slow

Services are careful about participating inACID transactions

Once WS-AtomicTransaction isimplemented

A service and its client may not belong to

the same security domain

An object and its client typically do

Choosing Which Services to Expose


32/135

Choosing Which Services to Expose

Ask yourself:

What are the most important things this

application does? And what are the use cases for other apps

that might access it?

Can services be normalized across theenterprise?

Ideally, there should be just one way to dosomething

Think in terms of business services

Dont let developers decide what toexpose

Challenge:R


33/135

Reuse

How is service reuse different from objectreuse?

Services are the right granularity

Reusing a particular application and its

data might be requiredHow is information mapped between dataformats?

Applications have different definitions ofthe same information, e.g., customer

Why should different parts of anorganization share their applications?

Getting Into the Services Business


34/135

Getting Into the Services Business

Once a service-oriented application hasclients, those clients will have expectations

Youre in the services business

A service should always know who its

clients are The real goal is conversation-first

development

Developers need a way to learn whatservices are available

A UDDI registry? Google?

Challenge:S it


35/135

Security

Different applications use differentauthentication mechanisms

WS-Security, et al., should eventuallyhelp with this

HTTPS is sometimes sufficientDifferent applications require differentauthorization mechanisms

SOA is mostly intra-enterprise today

Cross-firewall web services can raise

difficult security questions

Challenge:G


36/135

Governance

Better application integration requiresbetter human integration

What manager wants to give up control?

Thorny governance issues arise:

Whos allowed to use which services? How is access controlled and audited?

Who pays for the additional use?

Service level agreements (SLAs) becomenecessary

SOA and Business Process Management


37/135

g

A key goal is better business processes

SOA is a means to this end

Business Process Management (BPM)

doesnt strictly require SOA But service-oriented applications can

make BPM significantly more effective

What Exactly Is BPM?


38/135

y

A business perspective:

Viewing a business as a set of processes

that can be explicitly defined, optimized,and managed

A technical (and SOA-oriented)perspective:

Development using software designedfor implementing, executing, andmonitoring process logic

Applying Services:Composite Applications


39/135

UserInterface

Process

Logic

ServiceService

Application A

ServiceService

Application B

ServiceService

Application C

Composite Applications

Moving to SOA:Summary


40/135

Summary

Different organizations adopt services indifferent ways

The benefits (and challenges) are similar,however

The key point: get started


41/135

Building Services:

Indigo

Supporting Service-Oriented Applications:Application Servers


42/135

Application Servers

DevelopmentTools

Applications

Standard Library

Operating System

Runtime Environment

GUIClasses

TransactionClasses

WebClasses

DBMSClasses

MoreServiceClasses

Example:The NET Framework


43/135

The .NET Framework

Applications

Visual Studio .NET

C#, VB.NET, Others

.NET Framework Class Library

Windows

Common Language Runtime (CLR)

WindowsForms

EnterpriseServices

ASP.NET

ADO.NET

MoreASMX,etc.

Example:J2EE Application Servers


44/135

J2EE Application Servers

Applications

Eclipse, Others

Java

Standard Java Packages

Windows, Solaris, Linux, others

Java Virtual Machine (VM)

Swing EnterpriseJava Beans

JSP JDBC MoreJAX-RPC, etc.

Application Servers:Some History


45/135

Some History

1996

Windows DNA

- MTS (COM+)- ASP

- ADO

Java

- Java VM- Java language

- J2SE

1998

J2EE 1.0

- EJB- JSP

- JDBC

2002

.NET Framework

- CLR- C#, VB.NET

- Enterprise services,

ASP.NET, ADO.NET

- Web servicessupport (ASMX, etc.)

J2EE 1.4

- Webservicessupport(JAX-RPC)

2004

Indigo

- Fullsupportfor WS-*specs

2006

Microsoft

Java

Illustrating Indigo


46/135

IndigoClient

Indigo

CLR

IndigoService

Indigo

CLR

SOAP

What Indigo Provides


47/135

Unificationof existing Microsofttechnologies for distributed applications

Interoperabilitywith applications built onplatforms other than the .NET Framework

Service-orientedapplication support

Unification:.NET Distributed Technologies and Indigo


48/135

st buted ec o og es a d d go

.NET

RemotingASMX

InteroperableWeb Services

x

.NET .NET

Communication

x

Support forWS-* Specs x

DistributedTransactions, etc.

x

xQueued

Messaging

Enterprise

ServicesWSE MSMQ Indigo

x

x

x

x

x

Interoperability:Indigo Communication


49/135

g

Process

Application

Indigo

Application

Domain

Windows

Process

Application

Indigo

Application

Domain

Windows

Process

Application

Indigo

Application

Domain

Process

Windows or Other System

Other WebServicesPlatform

Application

Interoperability:Indigo Protocols


50/135

g

All Indigo applications communicate via SOAP

Indigo-to-non-Indigo communication: standard

text XML SOAP messages Indigo-to-Indigo communication: optimized

binary SOAP messages

SOAP is supported over HTTP and other protocols

SOAP

HTTP TCP

TCP

SOAP

. . .

SOAP

Interoperability:Indigo and the WS-* Standards


51/135

g

Indigo implements:

WS-Addressing

WS-Policy

WS-ReliableMessaging

WS-Security, WS-SecureConversation,WS-Trust

WS-Coordination, WS-

AtomicTransaction

More

IBM, BEA, etc. will also implement these

Service-Orientation:Where Indigo Applies


52/135

g pp

Services:

Described using WSDL and accessed

via SOAPService-oriented applications:

Expose business logic through servicesService-oriented architecture (SOA):

Defines guidelines for creating and using

service-oriented applications

Indigo is focused

on these


53/135

Indigo 1:Services and Clients

Requirements for Creating an IndigoService


54/135

Implementing a service class: the methodsthis service provides

Each service class exposes one or moreservice contracts

Each service class may optionallyimplement one or more explicit datacontracts

Selecting a host: the app domain andprocess this service runs in

Specifying one or more endpoints: how the

service can be accessed

Illustrating an Indigo Service


55/135

HostProcess

ApplicationDomain

Indigo

Methods Service

Class

Endpoints

Implementing a Service Class:Two Approaches


56/135

Class-based: Mark a classwith theServiceContract attribute

Allows only one service contract perservice class

Interface-based: Mark an interfacewith theServiceContract attribute, then create a

class that implements that interface

A single service class can implementone or more interfaces

This allows one or more servicecontracts per service class

An Indigo Service Class:The Class-Based Approach


57/135

using System.ServiceModel;[ServiceContract]

class Calculator

{

[OperationContract]private int Add(int a, int b)

{

return a + b;

}[OperationContract]

public int Subtract(int a, int b)

{

return a - b;}

public int Multiply(int a, int b)

{

return a * b;}

}

C# access modifiers andIndigo attributes are

completely independentfrom one another

IllustratingService Contracts and Object Contracts


58/135

Indigo

Application Domain

[ServiceContract]

class Calculator

public int Multiply()

[OperationContract]

private int Add()

[OperationContract]

public int Subtract()

Service Contract

Object Contract

ServiceClient

ObjectClient

An Indigo Service Class:Interface-Based (1)


59/135

using System.ServiceModel;

[ServiceContract]

interface ICalculator

{

[OperationContract]

int Add(int a, int b);

[OperationContract]

int Subtract(int a, int b);

}

An Indigo Service Class:Interface-Based (2)


60/135

class Calculator : ICalculator

{

public int Add(int a, int b) // private methods arent

{ // allowed in interfaces

return a + b;

}

public int Subtract(int a, int b)

{

return a - b;

}

public int Multiply(int a, int b)

{

return a * b;

}}

More Options


61/135

One-way calls[ServiceContract]

interface IOneWayExample

{

[OperationContract(IsOneWay=true)]

void MethodX(int a);

}

Duplex contracts

Both client and service expose an endpoint

Each can invoke operations in the other

Message contracts

Allow working directly with SOAP messages

No return value allowed

Indigo and Event-Driven Architectures


62/135

An eventis a one-way communication

It can be initiated by any party in an

interaction

Indigo can support events using: One-way calls

Duplex contracts

Perhaps containing one-way calls

An Aside: CategorizingCommunication Styles


63/135

Parameter Style

Typed List Message

SynchronousTraditional

RPC

Traditionalmessagepassing

RPC withmessages asparameters

Asynchronous AsynchronousRPC

CommunicationStyle

Indigo supportsall four options

Defining Data Contracts


64/135

Service contracts implicitly define the dataexchanged

Such as parameters to methodsPassing more complex data types, e.g., structs,requires defining an explicit data contract

Example:[DataContract]

struct Customer {

[DataMember]public string Name;

int public age;

[DataMember]private int CreditRating;

}

Selecting a Host for an Indigo Service Class


65/135

A host provides a Windows process andapp domain for a service class

Two main options:

Host a service in an arbitrary process Host a service in the Windows Activation

Service (WAS)

Hosting in an Arbitrary Process


66/135


[ServiceContract]

class Calculator

{} //as defined earlier

public class CalculatorHost

{

public static void Main()

{

ServiceHost s1 =

new ServiceHost();

s1.Open();

Console.Writeline("Press ENTER to end service");

Console.Readline();

}

}

A generic type that can

host any service class

Hosting with WAS


67/135

WAS provides a standard process for hosting

Much like ASMX hosting

Requires putting the service class and a .svc fileinto a virtual directory

Example:

Filename: calc.svc

File contents:

An instance of the service class will be createdwhen a client request arrives

Specifying Endpoints


68/135

Every Indigo service exposes one or moreendpoints

A client connects to a specific endpointEvery endpoint has three things:

Address: whereto find this endpoint

Binding: howto communicate with thisendpoint

Contract: whatoperations this endpointexposes

The ABCs of

endpoints

Illustrating an Endpoint


69/135

BasicProfileHttpBinding

Binding

http://www.qwickbank.com/calculator/calc.svc

Address

Calculator

Contract

Indigo

Process

ApplicationDomain

Methods

Endpoints: Addresses


70/135

URIs that indicate where an endpoint canbe found

Can be explicitly specified Required for Indigo services hosted in

an arbitrary process

Can be generated automatically

For WAS-hosted Indigo services only

Example:

http://www.qwickbank.com/calculator/calc.svcProtocol

MachineDNS Name Virtual Directory.svc Filename

Endpoints: Bindings


71/135

A simple way to wrap together manyaspects of communication with an

endpoint, such as: Protocol for conveying SOAP messages:

HTTP, TCP, etc.

Security options

Support for WS-* specs

Other thingsSeveral predefined bindings ship withIndigo

Custom bindings can also be created

Some Example Bindings


72/135

BasicProfileHttpBinding

Conforms to WS-I Basic Profile 1.0

WsHttpBinding Supports WS-ReliableMessaging, WS-

Security, WS-AtomicTransaction, andother WS-* specs

NetTcpBinding

Sends binary-encoded SOAP withsupport for reliable messaging, security,and transactions directly over TCP

(Indigo-Indigo only)

Endpoints: Contracts


73/135

Identify the service contract this endpointexposes

For class-basedservice classes: The contracts name is the name of the

service class

For interface-basedservice classes:

The contracts name is the name of

some interface marked withServiceContract that this class

implements

Defining Endpoints:Two Options


74/135

Endpoints can be defined programmatically

By calling theAddEndpoint method on

a ServiceHost, for exampleEndpoints can be defined in a config file

For WAS-hosted services, the file isweb.config

For services hosted in an arbitrary

process, the file is app.config

Likely to be the mostcommon approach

Example: Defining an Endpoint in aweb.config File


75/135

Would beICalculator for the

interface-based service class

Address omitted because WAS-

hosted services have onegenerated automaticallyService class thisendpoint applies to


76/135

Illustrating a Client and an Indigo Service


77/135

Process

ApplicationDomain

Indigo

Client

Proxy

Indigo

Process

ApplicationDomain

MethodsChannel

Service

An Example Client


78/135


using Indigo.Example; // namespace for proxy class

public class CalculatorClient{

public static void Main()

{CalculatorProxy p = new CalculatorProxy();

Console.WriteLine("7 + 2 = {0}", p.Add(7, 2));

Console.WriteLine("7 - 2 = {0}", p.Subtract(7, 2));

p.Close();

}

}

Indigo Basics:Summary


79/135

Creating an Indigo service requires:

Implementing a service class

Selecting a host Specifying one or more endpoints

Creating an Indigo client requires:

Creating a proxy(typically)

Specifying an endpoint to connect to(which might be created automatically)


80/135

Indigo 2:Other Features

Reliable Messaging in Indigo


81/135

Raw SOAP doesnt guarantee reliablemessage transfer

Especially through SOAP intermediariesSome Indigo bindings, such asWsHttpBinding, support WS-

ReliableMessaging

It adds TCP-like features to SOAP

WS-ReliableMessaging doesnt directlysupport message queuing, however

How Indigo does this is described later

Controlling a Service Classs Local Behavior:The ServiceBehavior Attribute


82/135

ServiceBehavior allows setting purely local

behaviors for a service class as a whole

Such as threading and instance managementExample:using System.ServiceModel;

[ServiceContract][ServiceBehavior(

ConcurrencyMode=Multiple,

InstanceMode=PerCall)]class Calculator { ... }

Indicates that the serviceis multi-threaded

Indicates that a new instance of the

service should be created for each call,then destroyed when that call returns

Controlling a Methods Local Behavior:The OperationBehavior Attribute


83/135

OperationBehavior allows setting purely local

behaviors for individual methods in a service class

Such as transactions and impersonationExample:using System.ServiceModel;

[ServiceContract]class Example {

[OperationContract]

[OperationBehavior(RequireTransaction=true)]int Update(int value1, int value2){}

}

Indicates that this

operation requires atransaction

Security in Indigo


84/135

Indigo provides authentication, messageintegrity, and message confidentiality

Largely controlled via bindings

Indigo also provides authorization

Controlled through standard .NETmechanisms, e.g., the

PrincipalPermission attribute

Binding Choices for Authentication,Integrity, and Confidentiality


85/135

Choose a standard binding that supportssecurity

Choose a standard binding that supportssecurity, then customize it

E.g., change the authentication

mechanism

Create a custom binding that provides

exactly the security features an applicationrequires

Choose a standard binding that provides no

support for security, such asBasicProfileHtt Bindin

Transactions in Indigo


86/135

Built on System.Transactions

New with .NET Framework 2.0 (aka

Whidbey)

Separates transactions from other things,e.g., state management

This is different from Enterprise

Services, COM+, and MTS

Using System.Transactions


87/135

The simplest approach is to create and use aTransactionScope object

Example:using System.Transactions;

using (TransactionScope ts = new

TransactionScope(TransactionScopeOption.Required))

{

// Do work, e.g., update different DBMSs

ts.Complete();

}

Indicates a vote to commit

Other options includeRequiresNew, Supported,

and NotSupported

Transaction Options for Indigo Applications

C S


88/135

Can use System.Transactions explicitly

By creating a TransactionScope, for

example

Can use Indigos OperationBehavior

attribute

Which uses System.Transactions under

the covers

Controlling Transactions using theOperationBehavior Attribute

i S t S i M d l


89/135


[ServiceContract]

class XactOperations{

[OperationContract]

[OperationBehavior(RequireTransaction=true,AutoCompleteTransaction=true)]

int Update(int value1, int value2)

{

// Insert value1 and value2 into

// two different databases

}

}

Indicates that exiting the method with

no exceptions will automaticallygenerate a vote to commit

Indicates that this method

requires a transaction

Queuing in Indigo

I di t i


90/135

Indigo supports message queuing

With Microsoft Message Queuing

(MSMQ) as the transportStandard service contracts are used

With only one-way operations

Binding choices include:

NetMsmqBinding: for communication

between two queued Indigo apps MsmqIntegrationBinding: for

communication between a queuedIndigo app and a native MSMQ app

An Aside: Is Indigo an ESB?

Th t E t i S i B (ESB) i


91/135

The term Enterprise Service Bus (ESB) isnot well-defined

For every ESB vendor, ESB = Myproduct

And the products are quite different

Theyre often based on proprietarycommunication

The result: ESBis a marketing term

Its not a useful way to think aboutservices and SOA today

Other Aspects of Indigo:Summary

S i b ilt I di b


92/135

Services built on Indigo can be:

Reliable

Secure Transactional

Queued

All but queuing are directly interoperable

with non-Microsoft web services platforms


93/135

Indigo 3:Coexistence and Migration

Coexistence and Migration

Indigo doesnt force migration


94/135

Indigo doesn t force migration

All current technologies will continue to

workBig issues:

Interoperability between Indigo-basedapps and apps built using existingtechnologies

Portability to Indigo of apps built usingexisting technologies

Indigo and ASMX

Interoperability ASMX applications will


95/135

Interoperability

Yes

Portability

Yes for most code

Will require some mostly mechanical effort,e.g., changing attribute names

No for SOAP Extensions

ASMX applications willhave the smoothest

migration path to Indigo

Indigo and .NET Remoting

Interoperability


96/135

Interoperability

No

Portability

Yes for most code

Will require some effort

No for .NET Remoting extensions such

as channels and sinks

Indigo and Enterprise Services

Interoperability


97/135

Interoperability

Yes for ES interfaces wrapped using an

Indigo-supplied tool Yes for clients using an Indigo moniker

Portability

Yes

Will require some mostly mechanical effort,e.g., changing attribute names

Indigo and WSE

Interoperability


98/135

Interoperability

Yes for apps built on WSE 3.0

No for apps built on WSE 1.0 and WSE2.0

The WS-* specs have changed

Portability

Yes for apps built on WSE 3.0 Not without non-trivial effort for apps

built on WSE 1.0 and WSE 2.0

Indigo and MSMQ

Interoperability


99/135

Interoperability

Yes using MsmqIntegrationBinding

Portability

Yes with some effort

System.Messaging is quite different from theIndigo programming model

Building Services:Summary

Indigo provides:


100/135

Indigo provides:

Unification of .NETs distributed

technologies Interoperability with non-Microsoft

platforms

Explicit support for service-orientedapplications

Indigo will be a mainstream technology in aservice-oriented world


101/135

ImplementingBusiness Processes:

BizTalk Server 2004

User

Composite Applications (Again)


102/135

Interface

Process

Logic

ServiceService

Application A

ServiceService

Application B

ServiceService

Application C


103/135

BPM in a Service-Oriented World

Composite Application 1


104/135

Application

Application

Application

Application


Orchestration X

BPM Server


Orchestration Y

BPM Server

Supporting Orchestrations:BPM Servers

DevelopmentTools ManagementTools


105/135

Orchestration Runtime Services

Communication Services

Business Rules

Services

WorkflowServices

Other

Services

Process MonitoringServices

Orchestrations

Tools Tools

Application Server

Operating System

Some Example BPM Servers

Microsoft BizTalk Server 2004


106/135

IBM WebSphere Business Integration Server

FoundationBEA WebLogic Process Edition

Arguably, many small-vendor BPM systems:

FileNet, Staffware, Pegasystems, Metastorm,Ultimus, Savvion, Intalio, Chordiant,

IllustratingBizTalk Server 2004

Visual Studio .NETOrchestration Designer

Health and ActivityTracking (HAT)


107/135

Business

Rules Engine

Human WorkflowServices

More

Business ActivityMonitoring (BAM)

Orchestrations

BizTalk Server 2004 Engine

Orchestration Designer Tracking (HAT)

.NET Framework

Windows

BPM Technologies:Communications Services

Adapters


108/135

p

Allow connections to diverse

technologies, e.g., IBM WebSphere MQ,SAP R/3, EDI, etc.

Standards: SOAP, WSDL, WS-* specs

Data mapping tools

Allow creating mappings and

transformations between different dataformats

Standards: XML, XSLT

BTS 2004:Adapters

Standard adapters from Microsoft include:


109/135

p

Web Services adapter

MQSeries adapter SAP adapter

More

Many third-party adapters are available,including:

EDI adapter PeopleSoft adapter

Lots more

BTS 2004:Data Mapping


110/135

BTS 2004 and Indigo

BizTalk Server 2004 and Indigo address


111/135

different problems

But theyre complementary technologiesUse Indigo to create apps that expose andconsume (web) services

Use BTS 2004 to:

Support orchestrations, business rules,

BAM, etc. Connect to diverse software, including

protocols other than SOAP

Map between different data formats

Illustrating BizTalk Server 2004 and Indigo

H man Workflo B siness Acti it


112/135

BusinessRules Engine

Human WorkflowServices

More

Business ActivityMonitoring (BAM)

Orchestrations

BizTalk Server 2004 Engine

MQSeries

Adapter

SAP

Adapter

Other

Adapters. . .

Indigo

Adapter

.NET Framework

Windows

BPM Technologies:Creating and Supporting Orchestrations

An orchestration defines the operationsh d i


113/135

that drive a process

BPM servers all provide graphical tools fordefining orchestrations

Adding some code is usually possible,

tooStandard: Business Process ExecutionLanguage (BPEL)

Now owned by OASIS

Supported by many vendors


114/135


115/135

BTS 2004:Orchestration Designer for Business Analysts


116/135

Orchestration Runtime Services:Illustrating BPEL

BPELDefinition


117/135

Generated

WebServices

BPM Server X BPM Server Y

Orchestration Runtime Services:State Management

Orchestrations can implement long-runningprocesses


118/135

processes

Especially when people are involvedAn orchestrations state is typically automaticallystored and reloaded as needed

Persistent Store

State

Orchestration Runtime Services:Transaction Support

Operations can commonly be grouped (scoped) intotwo kinds of transaction:


119/135

two kinds of transaction:

Atomic (ACID): recovery via rollback Long-running: recovery via compensation

BPM Server

Scope Y: Long-running

ERPApplicationx

2) Attempt update, fail

Scope X: Atomic

CICS

Application

J2EEApplication

1) Update and commit

3) Compensate

Orchestration Runtime Services:Correlating Messages

Messages can be routed to the correctorchestration instance based on their contents


120/135

orchestration instance based on their contents

An orchestration need not block waiting for aresponse message

BPM Server

1

2

. . .

PO# 5978

Purchase Order

. . .

PO# 6013

Purchase Order

. . .

PO# 5978

Invoice

. . .PO# 6013

Invoice

ERPApplication

Orchestration Runtime Services:Exposing an Orchestration as a Web Service

BPM ServerWeb Services


121/135

Packaged

Application

.NETApplicationJ2EEApplication

CICS

Application

AS/400

Application

Clients

BPM Technologies:Management Tools

Tools must be provided to manage:

Orchestrations


122/135

Orchestrations

Other aspects of the BPM serverTypical features include:

Configuration support

Monitoring of messages, execution, etc.

Report creation

More

BTS 2004:Health and Activity Tracking (HAT) Tool


123/135

BPM Technologies:Business Rules Services

One approach: embed rules in an orchestrationBusiness


124/135

Another option: implement rules in a separateBusiness Rules Engine (BRE) invoked by an

orchestration

Orchestration with

Embedded Rules

Rule

Orchestration withExternal Rules BusinessRules

Business RulesEngine

Implementing Business Rules:The Traditional Approach

Rules are embedded directly in code ororchestration


125/135

...

if (creditScore == HIGH){

maxOrder = 10000; }

else if (creditScore == MEDIUM) {

maxOrder = 4500; }else {

maxOrder = 1000; }

...

if (orderQty > maxOrder) {

reject = TRUE; }

...

Implementing Business Rules:Using a Business Rules Engine (BRE)

Business rules are evaluated by a BRE, which isinvoked from code or orchestration


126/135

...

Call BRE

...BRE

If CreditScore = HighThen MaximumOrder = 10000If CreditScore = Medium

Then MaximumOrder = 4500If CreditScore = LowThen MaximumOrder = 1000

If OrderQuantity > MaximumOrder)Then RejectOrder = True

BTS 2004:Business Rules Engine (BRE)

Can be invoked from an orchestration or any.NET assembly


127/135

.NET assembly

Includes a Business Rule Composer

Allows a processs rules to be expressed

in a more natural way Can be used by business analysts or

developers


128/135

BPM Technologies:Workflow Services

Many business processes involve people BPM servers must support human


129/135

BPM servers must support humaninteraction with processes

BTS 2004: Human Workflow Services

Allows creating orchestrations that can

interact with people A framework only

Requires third-party tools or developers touse effectively

BPM Technologies:Process Monitoring Services

Technical monitoring Tools for IT people e g BTS 2004 HAT


130/135

Tools for IT people, e.g., BTS 2004 HATtool

Business Activity Monitoring (BAM)

Tools for business people

Allows examining business aspects of arunning process (and more)

Broader than just BPM May link into business intelligence

technologies, other applications, and more

BTS 2004:An Example BAM View in Excel


131/135

Implementing Business Processes:Conclusions

A service-oriented world implies BPMBut BPM requires:


132/135

But BPM requires:

Support for creating, executing,monitoring, and managing process logic

Connections to non-SOAP services

Data mapping

More

BizTalk Server 2004 is a foundation forWindows BPM

And more

Summing Up: Software Abstractions in aService-Oriented World

Services GUIsObjectsRelations

AccessData Logic Presentation


133/135

XMLDocuments

I f Then

I f Then

I f Then

Business Rules

Orchestrations

Stored Procedures

SELECT FROM

Understanding SOA:Summary

Were headed for a service-oriented world Web services finally make SOA practical


134/135

y p

This change brings new technicalapproaches

Indigo for building services on Windows

BizTalk Server 2004 for BPM

The benefits are real

Weve waited a long time for this
http://www.davidchappell.com/


135/135