Understanding ServiceOriented Architecture

David Chappell Chappell & Associates www.davidchappell.com

Copyright 2005 David Chappell

Agenda

Defining SOA Moving to SOA Building Services: Indigo Implementing Business Processes: BizTalk Server 2004

Defining SOA

The Evolution of Application Architecture Mainframe

PCs

DBMS

Business Logic

Client/Server
Web

DBMS

Business Logic

Business Logic

GUI

Multi-Tier

DBMS

Business Logic

Browser

Web Services
Clients

ServiceOriented

DBMS

Business Logic

Business Logic

Enterprises Today

ERP Application

.NET Application

Packaged Application X

J2EE Application

Packaged Application Y

CICS Application

Packaged Application Z

AS/400 Application

Enterprises with SOA: An Idealized View

Business Service Business Service Business Service

Business Service

SOAP

Business Service

Business Service

Business Service

Business Service

What Exactly Is a Service? There is debate about the meaning of service Its analogous to the 90s argument about object In practice, a service is what is implemented by dominant products: Microsofts .NET Framework IBMs WebSphere Application Server BEAs WebLogic Application Server Others

Defining Services: The Specs SOAP, WSDL WS-Addressing WS-Policy WS-Security, WS-SecureConversation, WS-Trust, WS-ReliableMessaging WS-Coordination, WS-AtomicTransaction
Referred to collectively as the WS-* specs

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

Service-Orientation: Clarifying Terms Services: Described using WSDL and accessed via SOAP Service-oriented applications: Expose business logic through services Service-oriented architecture (SOA): Guidelines for creating and using service-oriented applications

Defining SOA An approach to building applications in a service-oriented world, including: Guidelines for:
Defining and exposing business services Defining and enforcing service level agreements

Common technologies for:

Securing services Managing services More

Software Abstractions in a Service-Oriented World

Data Logic
Objects Relations

Access

Presentation

Services

GUIs

Tables <=> Object hierarchies SQL types <=> Java/CLR types Object hierarchies <=> Service interfaces Java/CLR types <=> XML types Service interfaces <=> Widgets/controls XML types <=> Java/CLR/JavaScript types

Services and Messages SOAP is a message-oriented protocol:

<s:Envelope <s:Header> . . . </s:Header> <s:Body> . . . </s:Body> </s:Envelope>

But this implies nothing about how a developer uses it

Communication Styles for Services: RPC and Messaging Client

Synchronous RPC
<s:Envelope> Request </s:Envelope> <s:Envelope> Response </s:Envelope>

Service

Asynchronous Messaging
<s:Envelope> Message </s:Envelope> <s:Envelope> Message </s:Envelope> <s:Envelope> Message </s:Envelope>

Both made reliable by WSReliableMessaging

Communication Styles for Services: Persistent Queuing? Client Service

<s:Envelope> Message </s:Envelope>

Queue A
<s:Envelope> Message </s:Envelope>

Queue B Not directly supported by WS-ReliableMessaging

Why SOA Makes Sense: Technical Benefits Applications can be exposed more easily to diverse clients Because their logic can be accessed in a standard way by JSP, ASP.NET, mobile devices, and others Existing services can more easily be reused Because apps expose their services in a standard way New applications can be created or modified in less time and for less money Because existing services are already available

Why SOA Makes Sense: Business Benefits Business people understand services So IT people can talk with them more easily Application integration becomes cheaper and faster Which makes implementing business processes easier Business processes can more easily be changed or replaced Because theyre built from autonomous services with well-defined interfaces

Some Risks of SOA Does it make sense to build most new apps in a service-oriented style? Yes: there are exceptions, however Can service-oriented apps perform? Yes: perhaps 10-15% of people have performance problems today (typically caused by bad design or very high load on a service) Can the organizational challenges be overcome? Probably: more on this later

The Real Impact of SOA The mechanics of creating a service are simple Designing a service-oriented application is a bigger challenge Exposing the right services is hard Hardest of all are SOAs organizational changes The real challenges are human, not technical

Who Benefits Most From SOA?

Styles of IT Governance
Totalitarian, Centralized Anarchic, Decentralized

ERP-Centric Organization

Merger-Created Organization More immediate benefit from SOA

An Early SOA Example: Credit Suisse

IBM Mainframes

Unix and Windows Servers

IONA Orbix

IMS Applications IONA Orbix CICS Applications

IONA Orbix

Windows Desktops

Credit Suisse: SOA Growth

1999
Exposed business services Front-end applications Users

2000 173 21 9,000

2001 500 50+

2003 800 150+

35 5 800

100,000 100,000+

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: SOA at Microsoft

Siebel Business Objects

Siebel

Sales Portal .NET Evangelism Factory Account Explorer

Clarify

Alchemy
ADO.NET

MS Sales .NET Framework

Others

Worldwide Marketing Database

Defining SOA: Summary The global agreement on web services makes a service-oriented world practical Services and SOA bring real benefits Building service-oriented applications will become the default for most organizations

Moving to SOA

Getting Started Creating a pure SOA environment will take a long time Making everything SOAP-accessible may never happen The initial problem is to create serviceoriented applications Service-oriented architecture is built on this Different organizations move to SOA in different ways

Moving to SOA: The 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 buyin is tough

Moving to SOA: 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 most organizations Cons: Its an inelegant, piecemeal approach

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) Services are defined by the contract they expose Expressed in WSDL, XML schemas, and policies Should contracts should be specified code-first or contract-first? Service are as autonomous as possible They have independent runtime environments and failure modes They are independent of any particular type of client

Some Characteristics of Services (2) Calls to services are generally expensive So fine-grained interfaces are slow Services are careful about participating in ACID transactions Once WS-AtomicTransaction is implemented 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 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 the enterprise?

Ideally, there should be just one way to do something

Think in terms of business services Dont let developers decide what to expose

Challenge: Reuse How is service reuse different from object reuse? Services are the right granularity Reusing a particular application and its data might be required How is information mapped between data formats? Applications have different definitions of the same information, e.g., customer Why should different parts of an organization share their applications?

Getting Into the Services Business Once a service-oriented application has clients, 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 what services are available A UDDI registry? Google?

Challenge: Security Different applications use different authentication mechanisms WS-Security, et al., should eventually help with this HTTPS is sometimes sufficient Different applications require different authorization mechanisms SOA is mostly intra-enterprise today Cross-firewall web services can raise difficult security questions

Challenge: Governance Better application integration requires better 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) become necessary

SOA and Business Process Management 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? 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 designed for implementing, executing, and monitoring process logic

Applying Services: Composite Applications

User Interface

Process Logic

Service Service

Service Service

Service Service

Application A

Application B

Application C

Moving to SOA: Summary Different organizations adopt services in different ways The benefits (and challenges) are similar, however The key point: get started

Building Services: Indigo

Supporting Service-Oriented Applications: Application Servers

Development Tools Applications

Web Classes

GUI Classes

Service Classes

Transaction Classes

DBMS Classes

More

Standard Library Runtime Environment Operating System

Example: The .NET Framework

Visual Studio .NET C#, VB.NET, Others

Applications

ASP. NET

Windows Forms

ASMX, etc.

Enterprise Services

ADO. NET

More

.NET Framework Class Library Common Language Runtime (CLR) Windows

Example: J2EE Application Servers

Eclipse, Others Java

Applications

JSP

Swing

JAXRPC, etc.

Enterprise Java Beans

JDBC

More

Standard Java Packages Java Virtual Machine (VM) Windows, Solaris, Linux, others

Application Servers: Some History

1996
Windows DNA - MTS (COM+) - ASP - ADO

1998

2002
.NET Framework - CLR - C#, VB.NET - Enterprise services, ASP.NET, ADO.NET - Web services support (ASMX, etc.)

2004

2006
Indigo - Full support for WS-* specs

Microsoft

Java

Java - Java VM - Java language - J2SE

J2EE 1.0 - EJB - JSP - JDBC

J2EE 1.4 - Web services support (JAX-RPC)

Illustrating Indigo

Indigo Client Indigo CLR

SOAP

Indigo Service Indigo CLR

What Indigo Provides Unification of existing Microsoft technologies for distributed applications Interoperability with applications built on platforms other than the .NET Framework Service-oriented application support

Unification: .NET Distributed Technologies and Indigo

.NET Enterprise WSE MSMQ Remoting Services

ASMX
Interoperable Web Services .NET .NET Communication Distributed Transactions, etc. Support for WS-* Specs Queued Messaging

Indigo

x
x

x x x x x x x x

Interoperability: Indigo Communication

Windows
Process Application Domain Application Process Application Domain Application

Indigo

Indigo

Process Application Domain Application

Process Application Other Web Services Platform

Indigo

Windows

Windows or Other System

Interoperability: Indigo Protocols 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 SOAP TCP SOAP ...

Interoperability: Indigo and the WS-* Standards Indigo implements: WS-Addressing WS-Policy WS-ReliableMessaging WS-Security, WS-SecureConversation, WS-Trust WS-Coordination, WSAtomicTransaction More IBM, BEA, etc. will also implement these

Service-Orientation: Where Indigo Applies Services: Described using WSDL and accessed via SOAP Service-oriented applications: Expose business logic through services Service-oriented architecture (SOA): Defines guidelines for creating and using service-oriented applications
Indigo is focused on these

Indigo 1: Services and Clients

Requirements for Creating an Indigo Service Implementing a service class: the methods this service provides Each service class exposes one or more service contracts Each service class may optionally implement one or more explicit data contracts Selecting a host: the app domain and process this service runs in Specifying one or more endpoints: how the service can be accessed

Illustrating an Indigo Service

Process Application Domain Methods

Host

Service Class

Indigo
Endpoints

Implementing a Service Class: Two Approaches Class-based: Mark a class with the ServiceContract attribute Allows only one service contract per service class Interface-based: Mark an interface with the ServiceContract attribute, then create a class that implements that interface A single service class can implement one or more interfaces This allows one or more service contracts per service class

An Indigo Service Class: The Class-Based Approach

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 and Indigo attributes are completely independent from one another

Illustrating Service Contracts and Object Contracts

Application Domain
[ServiceContract] class Calculator

Service Client

[OperationContract] private int Add() [OperationContract] public int Subtract() public int Multiply()

Object Client

Indigo

Service Contract Object Contract

An Indigo Service Class: Interface-Based (1)

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)

class Calculator : ICalculator { public int Add(int a, int b) // private methods arent { return a + b; } public int Subtract(int a, int b) { return a - b; } public int Multiply(int a, int b) { return a * b; } } // allowed in interfaces

More Options 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 An event is 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: Categorizing Communication Styles

Parameter Style
Typed List Traditional RPC Message RPC with messages as parameters Traditional message passing

Synchronous

Communication Style
Asynchronous

Asynchronous RPC

Indigo supports all four options

Defining Data Contracts Service contracts implicitly define the data exchanged Such as parameters to methods Passing 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 A host provides a Windows process and app 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

using System.ServiceModel; [ServiceContract] class Calculator {} //as defined earlier public class CalculatorHost A generic type that can { host any service class public static void Main() { ServiceHost<Calculator> s1 = new ServiceHost<Calculator>(); s1.Open(); Console.Writeline("Press ENTER to end service"); Console.Readline(); } }

Hosting with WAS WAS provides a standard process for hosting Much like ASMX hosting Requires putting the service class and a .svc file into a virtual directory Example: Filename: calc.svc File contents:
<% @Service language=c# class="Calculator" %>

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

Specifying Endpoints Every Indigo service exposes one or more endpoints A client connects to a specific endpoint Every endpoint has three things: Address: where to find this endpoint Binding: how to communicate with this endpoint Contract: what operations this endpoint exposes
The ABCs of endpoints

Illustrating an Endpoint

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

Process

Binding
BasicProfileHttpBinding

Application Domain Methods

Calculator

Indigo

Contract

Endpoints: Addresses URIs that indicate where an endpoint can be 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:
Protocol
http://www.qwickbank.com/calculator/calc.svc

Machine DNS Name

Virtual Directory

.svc Filename

Endpoints: Bindings A simple way to wrap together many aspects of communication with an endpoint, such as: Protocol for conveying SOAP messages: HTTP, TCP, etc. Security options Support for WS-* specs Other things Several predefined bindings ship with Indigo Custom bindings can also be created

Some Example Bindings BasicProfileHttpBinding Conforms to WS-I Basic Profile 1.0 WsHttpBinding Supports WS-ReliableMessaging, WSSecurity, WS-AtomicTransaction, and other WS-* specs NetTcpBinding Sends binary-encoded SOAP with support for reliable messaging, security, and transactions directly over TCP (Indigo-Indigo only)

Endpoints: Contracts Identify the service contract this endpoint exposes For class-based service classes: The contracts name is the name of the service class For interface-based service classes: The contracts name is the name of some interface marked with ServiceContract that this class implements

Defining Endpoints: Two Options Endpoints can be defined programmatically By calling the AddEndpoint method on a ServiceHost, for example Endpoints can be defined in a config file For WAS-hosted services, the file is web.config For services hosted in an arbitrary process, the file is app.config
Likely to be the most common approach

Example: Defining an Endpoint in a web.config File

<configuration> Would be ICalculator for the <system.serviceModel> interface-based service class <services> <service serviceType="Calculator"> <endpoint contractType="Calculator" bindingType=basicProfileHttpBinding /> </service> </services> </system.serviceModel> </configuration>

Service class this endpoint applies to

Address omitted because WAShosted services have one generated automatically

Requirements for Creating an Indigo Client Creating a channel to a service This is typically hidden inside a proxy Proxies are created:
Today: with a tool called svcutil Soon: with Visual Studio

Specifying a specific endpoint on the service to communicate with This is typically done in a config file

Illustrating a Client and an Indigo Service

Process Application Domain

Process Application Domain Methods

Proxy

Channel

Indigo Client

Indigo Service

An Example Client
using System.ServiceModel; 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 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)

Indigo 2: Other Features

Reliable Messaging in Indigo Raw SOAP doesnt guarantee reliable message transfer Especially through SOAP intermediaries Some Indigo bindings, such as WsHttpBinding, support WSReliableMessaging It adds TCP-like features to SOAP WS-ReliableMessaging doesnt directly support message queuing, however How Indigo does this is described later

Controlling a Service Classs Local Behavior: The ServiceBehavior Attribute ServiceBehavior allows setting purely local behaviors for a service class as a whole Such as threading and instance management Example: Indicates that the service
using System.ServiceModel; [ServiceContract] [ServiceBehavior( ConcurrencyMode=Multiple, InstanceMode=PerCall)] class Calculator { ... }

is 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 OperationBehavior allows setting purely local behaviors for individual methods in a service class Such as transactions and impersonation Example:
Indicates that this using System.ServiceModel; operation requires a [ServiceContract] transaction class Example { [OperationContract] [OperationBehavior(RequireTransaction=true)] int Update(int value1, int value2){} }

Security in Indigo Indigo provides authentication, message integrity, and message confidentiality Largely controlled via bindings Indigo also provides authorization Controlled through standard .NET mechanisms, e.g., the PrincipalPermission attribute

Binding Choices for Authentication, Integrity, and Confidentiality Choose a standard binding that supports security Choose a standard binding that supports security, then customize it E.g., change the authentication mechanism Create a custom binding that provides exactly the security features an application requires Choose a standard binding that provides no support for security, such as BasicProfileHttpBinding

Transactions in Indigo 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 The simplest approach is to create and use a TransactionScope 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 include RequiresNew, Supported, and NotSupported

Transaction Options for Indigo Applications 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 the OperationBehavior Attribute

using System.ServiceModel; [ServiceContract] Indicates that this method class XactOperations requires a transaction { [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 automatically }

generate a vote to commit

Queuing in Indigo Indigo supports message queuing With Microsoft Message Queuing (MSMQ) as the transport Standard 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 queued Indigo app and a native MSMQ app

An Aside: Is Indigo an ESB? The term Enterprise Service Bus (ESB) is not well-defined For every ESB vendor, ESB = My product And the products are quite different
Theyre often based on proprietary communication

The result: ESB is a marketing term Its not a useful way to think about services and SOA today

Other Aspects of Indigo: Summary Services built on Indigo can be: Reliable Secure Transactional Queued All but queuing are directly interoperable with non-Microsoft web services platforms

Indigo 3: Coexistence and Migration

Coexistence and Migration Indigo doesnt force migration All current technologies will continue to work Big issues: Interoperability between Indigo-based apps and apps built using existing technologies Portability to Indigo of apps built using existing technologies

Indigo and ASMX Interoperability Yes Portability Yes for most code
Will require some mostly mechanical effort, e.g., changing attribute names ASMX applications will have the smoothest migration path to Indigo

No for SOAP Extensions

Indigo and .NET Remoting 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 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 Yes for apps built on WSE 3.0 No for apps built on WSE 1.0 and WSE 2.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 Yes using MsmqIntegrationBinding Portability Yes with some effort
System.Messaging is quite different from the Indigo programming model

Building Services: Summary Indigo provides: Unification of .NETs distributed technologies Interoperability with non-Microsoft platforms Explicit support for service-oriented applications Indigo will be a mainstream technology in a service-oriented world

Implementing Business Processes: BizTalk Server 2004

Composite Applications (Again)

User Interface

Process Logic

Service Service

Service Service

Service Service

Application A

Application B

Application C

Implementing Process Logic: Orchestrations The most commonly used term for process logic today is orchestration Although not all vendors use it Orchestrations can benefit from a platform expressly designed to support them An application server isnt enough The goal: Business Process Management (BPM) Supported by a BPM server

BPM in a Service-Oriented World Composite Application 1

Application
Orchestration X

Application

BPM Server

Application

Application
Orchestration Y

Composite Application 2

BPM Server

Supporting Orchestrations: BPM Servers

Development Tools Workflow Services Business Rules Services
Orchestrations

Management Tools Process Monitoring Services Other Services

Orchestration Runtime Services Communication Services Application Server Operating System

Some Example BPM Servers Microsoft BizTalk Server 2004 IBM WebSphere Business Integration Server Foundation BEA WebLogic Process Edition Arguably, many small-vendor BPM systems: FileNet, Staffware, Pegasystems, Metastorm, Ultimus, Savvion, Intalio, Chordiant,

Illustrating BizTalk Server 2004

Visual Studio .NET Orchestration Designer Health and Activity Tracking (HAT)

Human Workflow Services Business Rules Engine

Orchestrations

Business Activity Monitoring (BAM) More

BizTalk Server 2004 Engine

.NET Framework Windows

BPM Technologies: Communications Services Adapters 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 data formats Standards: XML, XSLT

BTS 2004: Adapters Standard adapters from Microsoft include: 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

BTS 2004 and Indigo BizTalk Server 2004 and Indigo address different problems But theyre complementary technologies Use Indigo to create apps that expose and consume (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

Human Workflow Services Business Rules Engine

Orchestrations

Business Activity Monitoring (BAM) More

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 operations that drive a process BPM servers all provide graphical tools for defining orchestrations Adding some code is usually possible, too Standard: Business Process Execution Language (BPEL) Now owned by OASIS Supported by many vendors

BTS 2004: Creating Orchestrations Define the operations in a business process using shapes Compile into standard .NET assemblies Example shapes: Decide: an if-then-else statement Loop: performs an action repeatedly Send: sends a message Receive: receives a message Expression: executes an arbitrary expression Parallel Actions: performs multiple operations in parallel

BTS 2004: Orchestration Designer

BTS 2004: Orchestration Designer for Business Analysts

Orchestration Runtime Services: Illustrating BPEL

BPEL Definition Generated
Web Services

BPM Server X

BPM Server Y

Orchestration Runtime Services: State Management Orchestrations can implement long-running processes Especially when people are involved An orchestrations state is typically automatically stored and reloaded as needed

State

Persistent Store

Orchestration Runtime Services: Transaction Support Operations can commonly be grouped (scoped) into two kinds of transaction: Atomic (ACID): recovery via rollback Long-running: recovery via compensation
Scope X: Atomic
1) Update and commit J2EE Application CICS Application 3) Compensate BPM Server 2) Attempt update, fail

ERP Application

Scope Y: Long-running

Orchestration Runtime Services: Correlating Messages Messages can be routed to the correct orchestration instance based on their contents An orchestration need not block waiting for a response message
Purchase Order

1 2
BPM Server

Invoice PO# 5978

PO# 5978 ...

...
Purchase Order Invoice PO# 6013 PO# 6013 ...

ERP Application

...

Orchestration Runtime Services: Exposing an Orchestration as a Web Service

BPM Server Web Services Clients

J2EE Application

.NET Application

CICS Application

Packaged Application

AS/400 Application

BPM Technologies: Management Tools Tools must be provided to manage: Orchestrations Other aspects of the BPM server Typical features include: Configuration support Monitoring of messages, execution, etc. Report creation More

BTS 2004: Health and Activity Tracking (HAT) Tool

BPM Technologies: Business Rules Services One approach: embed rules in an orchestration
Business Rule

Orchestration with Embedded Rules

Another option: implement rules in a separate Business Rules Engine (BRE) invoked by an orchestration
Business Rules Engine Orchestration with External Rules Business Rules

Implementing Business Rules: The Traditional Approach Rules are embedded directly in code or orchestration
... 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 is invoked from code or orchestration
... Call BRE ...

BRE
If CreditScore = High Then MaximumOrder = 10000 If CreditScore = Medium Then MaximumOrder = 4500 If CreditScore = Low Then MaximumOrder = 1000 If OrderQuantity > MaximumOrder) Then RejectOrder = True

BTS 2004: Business Rules Engine (BRE) Can be invoked from an orchestration or any .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

An Aside: The Rise of Business Analysts Many organizations have people in a business analyst (BA) role In a service-oriented world, they can do more than just define requirements BAs can potentially: Define services Create and update orchestrations Define and modify business rules Will BAs be the successor to Visual Basic developers?

BPM Technologies: Workflow Services Many business processes involve people BPM servers must support human interaction with processes BTS 2004: Human Workflow Services Allows creating orchestrations that can interact with people A framework only
Requires third-party tools or developers to use effectively

BPM Technologies: Process Monitoring Services Technical monitoring Tools for IT people, e.g., BTS 2004 HAT tool Business Activity Monitoring (BAM) Tools for business people Allows examining business aspects of a running 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

Implementing Business Processes: Conclusions A service-oriented world implies BPM 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 for Windows BPM And more

Summing Up: Software Abstractions in a Service-Oriented World

Data
Relations

Logic
Objects

Access
Services

Presentation
GUIs

Stored Procedures XML Documents

<X></X> <Y></Y> <Z></Z>

SELECT FROM

Orchestrations

Business Rules
If Then If Then If Then

Understanding SOA: Summary Were headed for a service-oriented world Web services finally make SOA practical This change brings new technical approaches Indigo for building services on Windows BizTalk Server 2004 for BPM The benefits are real Weve waited a long time for this

About the Speaker

David Chappell is Principal of Chappell & Associates in San Francisco, California. Through his speaking, writing, and consulting, he helps information technology professionals understand, use, market, and make better decisions about enterprise software. David has been the keynote speaker for conferences in the U.S., Europe, Latin America, and the Middle East, and hes also delivered keynotes at many in-house events. His seminars have been attended by tens of thousands of developers and decision makers in thirty-five countries. Davids books on enterprise software technologies have been published in ten languages and used regularly in courses at MIT and other universities. He is Series Editor for Addison-Wesleys Independent Technology Guides, and more than 100 of his articles have appeared in various publications. Davids consulting clients have included HP, IBM, Microsoft, Target Corporation, Stanford University, and others. He has also advised a range of global organizations, including Deutsche Bank, Singapore Airlines, and the Industrial and Commercial Bank of China. David holds a B.S. in Economics and an M.S. in Computer Science, both from the University of Wisconsin-Madison. He has also participated in Executive Education at the Wharton School of Business.