Documente Academic
Documente Profesional
Documente Cultură
Agenda
Defining SOA Moving to SOA Building Services: Indigo Implementing Business Processes: BizTalk Server 2004
Defining SOA
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
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
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
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
Service
Asynchronous Messaging
<s:Envelope> Message </s:Envelope> <s:Envelope> Message </s:Envelope> <s:Envelope> Message </s:Envelope>
Queue A
<s:Envelope> Message </s:Envelope>
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
Styles of IT Governance
Totalitarian, Centralized Anarchic, Decentralized
ERP-Centric Organization
IBM Mainframes
IONA Orbix
Windows Desktops
1999
Exposed business services Front-end applications Users
35 5 800
100,000 100,000+
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
Siebel
Clarify
Alchemy
ADO.NET
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 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?
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
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
Web Classes
GUI Classes
Service Classes
Transaction Classes
DBMS Classes
More
Applications
ASP. NET
Windows Forms
ASMX, etc.
Enterprise Services
ADO. NET
More
Applications
JSP
Swing
JAXRPC, etc.
JDBC
More
Standard Java Packages Java Virtual Machine (VM) Windows, Solaris, Linux, others
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
Illustrating Indigo
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
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
Indigo
Indigo
Indigo
Windows
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
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
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
C# access modifiers and Indigo attributes are completely independent from one another
Service Client
[OperationContract] private int Add() [OperationContract] public int Subtract() public int Multiply()
Object Client
Indigo
Duplex contracts Both client and service expose an endpoint Each can invoke operations in the other Message contracts Allow working directly with SOAP messages
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
Synchronous
Communication Style
Asynchronous
Asynchronous RPC
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 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
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
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
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
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)
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(); }
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
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
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
Indigo and .NET Remoting Interoperability No Portability Yes for most code
Will require some effort
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
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
Application
BPM Server
Application
Application
Orchestration Y
Composite Application 2
BPM Server
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,
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 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
BizTalk Server 2004 Engine MQSeries Adapter SAP Adapter ... Other Adapters Indigo Adapter
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
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
...
Purchase Order Invoice PO# 6013 PO# 6013 ...
ERP Application
...
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
BPM Technologies: Business Rules Services One approach: embed rules in an orchestration
Business Rule
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
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
Logic
Objects
Access
Services
Presentation
GUIs
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