Understanding Service- Oriented Architecture · Service-oriented architecture (SOA): – Defines guidelines for creating and using service-oriented applications Indigo is focused

Understanding Service-Oriented Architecture

David ChappellChappell & 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

Clients

PCs

Web

Web Services

TMainframeDBMS

Business Logic

GUIClient/Server DBMSBusiness

LogicBusiness

Logic

BrowserMulti-Tier DBMSBusiness

Logic

Service-Oriented DBMS

Business Logic Business

Logic

Enterprises Today

Packaged Application

Z

ERP Application


Y

J2EE Application

.NET Application


X

CICS Application

AS/400 Application

Enterprises with SOA: An Idealized View

Business Service

Business Service

Business Service

SOAPBusiness Service

Business Service

Business Service

Business Service

Business Service

What Exactly Is a Service?

There is debate about the meaning of service– It’s analogous to the 90’s argument about

objectIn practice, a service is what is implemented by dominant products:– Microsoft’s .NET Framework – IBM’s WebSphere Application Server– BEA’s WebLogic Application Server– Others

Defining Services: The Specs

SOAP, WSDLWS-AddressingWS-PolicyWS-Security, WS-SecureConversation, WS-Trust, …WS-ReliableMessagingWS-Coordination, WS-AtomicTransaction…

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

Referred to collectively as the WS-* specs

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

Services

AccessData

Relations

Logic

Objects

Presentation

GUIs

Tables <=> Object hierarchies SQL types <=> Java/CLR types

Object hierarchies <=> Service interfacesJava/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 Service

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

<s:Envelope> … Response … </s:Envelope>

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


Asynchronous Messaging


Both made reliable by WS-ReliableMessaging

Communication Styles for Services: Persistent Queuing?

Client Service


Queue A


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 wayNew 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 easierBusiness processes can more easily be changed or replaced – Because they’re 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 simpleDesigning a service-oriented application is a bigger challenge– Exposing the right services is hard

Hardest of all are SOA’s 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

IONAOrbix

IONAOrbix

IONAOrbix

Unix and Windows Servers

IBM Mainframes

IMS Applications

CICS Applications

Windows Desktops

Credit Suisse: SOA Growth

Exposed business services

Front-end applications

Users

1999

35

5

800

2000

173

21

9,000

2001

500

50+

100,000

2003

800

150+

100,000+

Credit Suisse: What They Learned

Challenges:– An expensive project

• ROI took time to materialize– Performance wasn’t 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

.NET Framework

Alchemy

Siebel

Clarify

MS Sales

Worldwide Marketing Database

ADO.NET

Siebel Business Objects

Sales Portal

.NET Evangelism

Factory

Account Explorer

Others

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 happenThe initial problem is to create service-oriented applications– Service-oriented architecture is built on

thisDifferent 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:– It’s elegant, clean, and sensible

Cons:– It’s very difficult in most organizations

• Getting the up-front funding and business buy-in 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:– It’s the only approach that works in most

organizationsCons:– It’s 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

implementedA 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

somethingThink in terms of business services– Don’t 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 requiredHow is information mapped between data formats?– Applications have different definitions of

the same information, e.g., customerWhy 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– You’re in the services business

A service should always know who its clients are– The real goal is conversation-first

developmentDevelopers 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 mechanismsSOA 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:– Who’s 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) doesn’t 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

UserInterface

Process Logic

Service Service

Application A

Service Service

Application B

Service Service

Application C

Applying Services: Composite Applications

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

DevelopmentTools

Applications

Standard Library

Operating System

Runtime Environment

GUI Classes

Transaction Classes

Web Classes

DBMSClasses

MoreService Classes

Example: The .NET Framework

Applications

Visual Studio .NETC#, VB.NET, Others

.NET Framework Class Library

Windows

Common Language Runtime (CLR)

WindowsForms

EnterpriseServices

ASP.NET

ADO.NET

MoreASMX, etc.

Example: J2EE Application Servers

Applications

Eclipse, OthersJava

Standard Java Packages

Windows, Solaris, Linux, others

Java Virtual Machine (VM)

Swing EnterpriseJava Beans

JSP JDBC MoreJAX-RPC, etc.

Application Servers: 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 services

support (ASMX, etc.)

J2EE 1.4- Web services support (JAX-RPC)

2004

Indigo- Full support for WS-* specs

2006

Microsoft

Java

Illustrating Indigo

Indigo Client

Indigo

CLR

Indigo Service

Indigo

CLR

SOAP

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

.NETRemotingASMX

Interoperable Web Services

x.NET –.NET

Communicationx

Support for WS-* Specs

x

Distributed Transactions, etc.

x

xQueued Messaging

EnterpriseServices

WSE MSMQ Indigo

x

x

x

x

x

Interoperability: Indigo Communication

Process

Application

Indigo

Application Domain

Windows

Process

Application

Indigo

Application Domain

Windows

Process

Application

Indigo

Application Domain

Process

Windows or Other System

Other Web Services Platform

Application

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 messagesSOAP is supported over HTTP and other protocols

SOAP

HTTP TCP

TCP

SOAP

. . .

SOAP

Interoperability: Indigo and the WS-* Standards

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

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 inSpecifying one or more endpoints: how the service can be accessed

HostProcess

Application Domain

Indigo

Methods Service Class

Endpoints

Illustrating an Indigo Service

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

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)

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 aren’t

{ // allowed in interfacesreturn a + b;

}

public int Subtract(int a, int b){

return a - b;}

public int Multiply(int a, int b){

return a * b;}

}

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 Message

Synchronous Traditional RPC

Traditional message passing

RPC with messages as parameters

Asynchronous Asynchronous RPC

Communication Style

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 contractExample:[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


[ServiceContract]class Calculator{…} //as defined earlier

public class CalculatorHost{public static void Main(){

ServiceHost<Calculator> s1 = new ServiceHost<Calculator>();

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

}}

A generic type that can host any service class

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 directoryExample:– 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

exposesThe ABCs of

endpoints

BasicProfileHttpBindingBinding

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

Calculator

ContractIndigo

Process

Application Domain

Methods

Illustrating an Endpoint

Endpoints: Addresses

URIs that indicate where an endpoint can be foundCan be explicitly specified– Required for Indigo services hosted in

an arbitrary processCan be generated automatically– For WAS-hosted Indigo services only– Example:

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

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, WS-

Security, 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 exposesFor class-based service classes:– The contract’s name is the name of the

service classFor interface-based service classes:– The contract’s 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 exampleEndpoints 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><system.serviceModel><services><service serviceType="Calculator"><endpoint contractType="Calculator"bindingType=”basicProfileHttpBinding />

</service></services>

</system.serviceModel></configuration>

Would be ICalculator for the interface-based service class

Address omitted because WAS-hosted services have one generated automatically

Service class this endpoint applies to

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

Process

Application Domain

Indigo

Client

Proxy

Indigo

Process

Application Domain

Methods

Illustrating a Client and an Indigo Service

Channel

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 doesn’t guarantee reliable message transfer– Especially through SOAP intermediaries

Some Indigo bindings, such as WsHttpBinding, support WS-ReliableMessaging– It adds TCP-like features to SOAP

WS-ReliableMessaging doesn’t directly support message queuing, however– How Indigo does this is described later

Controlling a Service Class’s 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:using System.ServiceModel;[ServiceContract] [ServiceBehavior(ConcurrencyMode=Multiple, InstanceMode=PerCall)]

class Calculator { ... }

Indicates that the service 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 Method’s Local Behavior:The OperationBehavior Attribute

OperationBehavior allows setting purely local behaviors for individual methods in a service class– Such as transactions and impersonation

Example:using System.ServiceModel;[ServiceContract] class Example { [OperationContract] [OperationBehavior(RequireTransaction=true)]int Update(int value1, int value2){…}}

Indicates that this operation requires a

transaction

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 securityChoose a standard binding that supports security, then customize it – E.g., change the authentication

mechanismCreate a custom binding that provides exactly the security features an application requiresChoose 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 objectExample:using System.Transactions;using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required))

{// Do work, e.g., update different DBMSsts.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 Indigo’s OperationBehaviorattribute– Which uses System.Transactions under

the covers

Controlling Transactions using the OperationBehavior Attribute


[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 automatically

generate a vote to commit

Indicates that this method requires a transaction

Queuing in Indigo

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 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

• They’re often based on proprietary communication

The result: ESB is a marketing term– It’s 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 doesn’t force migration– All current technologies will continue to

workBig 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

– No for SOAP Extensions

ASMX applications will have the smoothest

migration path to Indigo

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 .NET’s 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

UserInterface

Process Logic

Service Service

Application A

Service Service

Application B

Service Service

Application C

Composite Applications (Again)

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 isn’t enough

The goal: Business Process Management (BPM)– Supported by a BPM server

BPM in a Service-Oriented World

Application

Application

Application

Application

Composite Application 1

Orchestration X

BPM Server

Composite Application 2

Orchestration Y

BPM Server

Supporting Orchestrations:BPM Servers

Orchestration Runtime Services

Communication Services

Business Rules Services

WorkflowServices

Other Services

Process Monitoring Services

Orchestrations

Development Tools

Management Tools

Application Server

Operating System

Some Example BPM Servers

Microsoft BizTalk Server 2004IBM WebSphere Business Integration Server FoundationBEA WebLogic Process EditionArguably, many small-vendor BPM systems:– FileNet, Staffware, Pegasystems, Metastorm,

Ultimus, Savvion, Intalio, Chordiant, …

IllustratingBizTalk Server 2004

Business Rules Engine

Human Workflow Services

More

Business Activity Monitoring (BAM)

Orchestrations

BizTalk Server 2004 Engine

Visual Studio .NETOrchestration Designer

Health and Activity Tracking (HAT)

.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-* specsData 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 they’re complementary technologies

Use Indigo to create apps that expose and consume (web) servicesUse 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

Business Rules Engine

Human Workflow Services

More

Business Activity Monitoring (BAM)

Orchestrations

BizTalk Server 2004 Engine

MQSeriesAdapter

SAP Adapter

Other Adapters

. . . Indigo Adapter

.NET Framework

Windows

BPM Technologies: Creating and Supporting Orchestrations

An orchestration defines the operations that drive a processBPM 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 orchestration’s state is typically automatically stored and reloaded as needed

Persistent Store

State

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

BPM Server

Scope Y: Long-running

ERP Applicationx

2) Attempt update, fail

Scope X: Atomic

CICS Application

J2EE Application

1) Update and commit

3) Compensate

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

BPM Server

1

2

. . .PO# 5978

Purchase Order

. . .PO# 6013

Purchase Order

. . .PO# 5978

Invoice

. . .PO# 6013

Invoice

ERP Application

Orchestration Runtime Services: Exposing an Orchestration as a Web Service

BPM Server


.NET Application

J2EE Application

CICS Application

AS/400 Application

Web Services Clients

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

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

Orchestration with Embedded Rules

Business Rule

Orchestration withExternal Rules

Business Rules

Business RulesEngine

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 = HighThen MaximumOrder = 10000If CreditScore = MediumThen 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

Includes a Business Rule Composer– Allows a process’s 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 requirementsBAs 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 processesBTS 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

toolBusiness 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 BPMBut 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

XML Documents

<Y>…</Y> <Z>…</Z>

<X>…</X>

If … Then …

If … Then …

If … Then …

Business Rules

Orchestrations

Services GUIsObjectsRelations

AccessData Logic Presentation

Stored ProceduresSELECT … FROM …

Understanding SOA:Summary

We’re 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– We’ve waited a long time for this

About the Speaker

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

http://www.davidchappell.com/