View
219
Download
0
Embed Size (px)
Citation preview
Business Process Management Technologies
• BPM Servers and BizTalk (orchestration)
• BPEL4WS (modelling & execution)
• ebXML & RosettaNet (discovery & integration)
Communication Services
• allow an orchestration to interact with the various business services a composite application uses.
• Eventually, the dominant way to do this will be via SOAP-based web services, and so the communication services built into a BPM server today must include support for web services.
Orchestration Runtime Services
• Executing an Orchestration• Managing an Orchestration’s State• Handling Transactions• Correlating Requests and Responses• Exposing an Orchestration as a Web Service
Orchestration Runtime Services Executing an Orchestration
• orchestrations are typically defined graphically rather than by code.
• Diagrams aren’t directly executable so a BPM server must provide some way to translate an orchestration’s graphical depiction into an executable form.
• One approach is to translate an orchestration diagram into a low-level form, such as Java bytecode or the .NET Framework’s Intermediate Language (IL), then execute it like any other program.
• Another possibility is to transform the logic represented in the diagram into a process oriented language, then execute the resulting program on a specialized process engine.
• So as to define web services-based interactions between orchestrations that can be executed on any vendor’s BPM server, a group of vendors including Microsoft, IBM, and others have defined the Business Process Execution Language (BPEL4WS). Now being standardized under the auspices of OASIS, BPEL4WS is an XML-based language for defining interactions via web services. - More Later
Orchestration Runtime Services Managing an Orchestration’s State
• The long-running nature of a process orchestration affects how an orchestration manages the in-memory information it maintains—the state—about a running process. An orchestration may be blocked for a significant period of time.
• BPM servers provide a way for an orchestration’s state to be automatically written to disk, then restored again when the business process resumes, even if it’s days or weeks later.
Orchestration Runtime Services Handling (all or nothing) Transactions
• An orchestration driving a business process might need to invoke two business services and ensure that either both requests succeed or both fail. (Commit & Rollback)
• Atomic transactions require locking data for the life of the transaction, something that isn’t a problem when the transaction is short. Orchestrations rarely are.
• BPM servers support long-running transactions, which handle errors not by rolling back all updates, but by executing some kind of compensating logic when an error occurs. An imperfect solution!
Orchestration Runtime Services Correlating Requests and Responses
• Two orchestrations have sent some information into a service, such as a purchase order, and each is waiting for the same response, such as an invoice. How can the correct response, ‘the matching invoice,’ be delivered to the right orchestration?
• The request and response messages themselves can contain information that is used to correlate them e.g. a purchase order and its matching invoice, will contain identical purchase order numbers.
• The creator of an orchestration can indicate which values in the request and response should be used to correlate requests and responses, then automatically route responses to the orchestration instance that made the request.
Orchestration Runtime Services Exposing an Orchestration as a Web Service
• An orchestration acts as a client of services. By providing the central logic for a business process, it drives the operations that make the process go.
• Also, an orchestration may be used as a service itself. A BPM server can allow an orchestration to ‘expose itself’ as a web service.
Development Tools
• Are used to define the orchestration logic that drives a composite application, specifying mappings between data used by various business services, and other purposes.
• Virtually all of today’s BPM platforms provide graphical tools for creating orchestrations.
Orchestration Designer for Business Analysts.
Runs inside Microsoft Visio. Diagrams can be imported & exported from & to OD in Visual Studio
The BizTalk Editor provides agraphical approach for creating XML schemas,
BizTalk Mapper (shown here) creates definitions of mappings and transformations between fields in the messages defined by those schemas.
Management Tools
• are used for managing an orchestration, its communications, and other aspects of the BPM server.
Health and Activity Tracking (HAT) tool.
Provides a range of management functions, including the ability to display current and historicalinformation about executing orchestrations.
Business Rules Services
• Rules tend to change more frequently than processes
• so the business rules an orchestration uses are created and managed separately from the process flow.
• Business rules are stored in a single place, • organized into well defined groups, • making reuse of rules easier.
• Less technical people, such as business analysts, can create and modify rules.
Workflow Services
• allow people to participate in the business process.
• On its own, an orchestration typically implements the controlling logic for a business process that executes without human intervention - straight-through processing.
• A BPM server must support workflow, generally now used to mean human involvement in a business process.
• some BPM servers have roots in this area, others grew from integration-oriented products and add workflow support on top of their existing technologies.
Process monitoring services
• including both monitoring at a technical level and business activity monitoring (BAM) that provides real-time information about a running process.
A developer can configure an orchestration to make specific informationavailable to the BAM component.
Exposed via a web service, this component can beaccessed by Excel or other clients.
Web Services
• are self-contained, modular business process applications that are based on the industry standard technologies of
• WSDL (to describe), • UDDI (to advertise and syndicate), and • SOAP (to communicate).
• They enable users to connect different components even across organizational boundaries in a platform- and language-independent manner.
• However, none of these standards allow defining the business semantics of Web services.
BPEL4WS
• Business Process Execution Language For Web Services (BPEL4WS or BPEL, for short) specifies business processes and how they relate to Web services.
• BPEL supports the specification of business protocols between partners.
• A BPEL business process interoperates with the Web services of its partners, whether or not these Web services are implemented based on BPEL.
Business Processes and Web Services
• A BPEL business process specifies the potential execution order of operations from a collection of Web services,
• the data shared between these Web services, • which partners are involved, • how they are involved in the business process and• joint exception handling for collections of Web services.
• BPEL combines (and superceeds) IBM's Web Services Flow Language and Microsoft's XLANG specifications.
Partners
Containers
Receive an Itinerary from a Customer
Request tickets from Airline
Receive tickets from Airline
What Makes Web Services Possible?
• A fundamental requirement for Web Services is interoperability & consistency across platforms, applications & programming languages requiring:
– A common framework for Web service interactions based on open standards.
– An agreed set of vocabularies and interactions for specific industries and common functions.
What Makes Web Services Possible?
• Reliable & Transparent Interconnectivity– Web Protocols
• Structured Information– XML Schemas & validation
• Application Interface Standards– UDDI, WSDL, SOAP
• Business Process Interface Standards– ebXML, RosettaNet
ebXML (electronic business XML)
• Provides an open framework for global e-commerce• Replaces (but is compatible with) EDI• Is based on XML and other open standards
• Specifications:– Business Process– Registry Model and Services– Trading Partner Collaboration– Messaging Services
ebXML Architecture Concepts
• Business Processes and associated Core Components (in XML)
• A mechanism for registering and storing them (Registry)• A mechanism for describing a Trading Partners
capabilities (TPP). • A mechanism for describing a Trading Partner
Agreement (TPA). • A standardized messaging service (ebXML MS)• A standardized methodology/process for modeling the
real world business and translating it into XML.
Functional Service View (FSV) Architecture
Registry Service Interface
Payload
Business ServiceInterface
Business ServiceInterface
InternalBusiness App
Shrink-wrappedApplication
Registry
Implementers
Business Process and Information Models
Build
Registration
TPA
UML to XML conversion
Retrieval of ebXML Specifications & Models
Build
Retrieval of Profiles & new or updated ebXML Models
Retrieval of Profiles & new or updated ebXML Models
Registration RegistrationTPP
ebXML metamodel XML content
TPP
Registration
TPA Governs
TPP Derives
eb X M L co mp lian tso f tw are system
Bus ines s P rof iles
S c enar ios
e bX M LR e g is try
INDUSTRY
XM L S pec if ic ations
R eq u est In d u stry Pro cess D eta ils
1
B u ild L o cal S ystemImp lemen tat io n
R eg ister Imp lemen tat io n D eta ilsR eg ister C O M PA N Y A Pro f ile
3
2
5A g ree o n T rad in g A rran g emen t4
Q uery ab o u t C O M PA NY A p ro f ile
D ow n lo ad ebX M L compon en ts
DO BUSINESS TRANSACT IO
NS
6
COMPANY A
COMPANY B
ebXML Architecture in Practice
RosettaNet
• Is a non-profit consortium of more than 500 industry-recognized organizations which works to create, promote and implement open e-business standards and services that improve efficiencies across the global supply chain.
• RosettaNet standards prescribe how networked applications interoperate to execute collaborative business process.
• e.g. RosettaNet Partner Interface Processes (PIPs) are specialized system-to-system XML-based dialogs that define business processes between trading partners. Each PIP specification includes a business document with the vocabulary, and a business process with the choreography of the message dialog.