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
Packaged Application
Y
J2EE Application
.NET Application
Packaged 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>
<s:Envelope> … Message … </s:Envelope>
Asynchronous Messaging
<s:Envelope> … Message … </s:Envelope>
Both made reliable by WS-ReliableMessaging
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 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
using System.ServiceModel;
[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
using System.ServiceModel;
[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
Packaged Application
.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.