WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7

WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7 Define, model, implement, and monitor real-world BPEL 2.0 business processes with SOA-powered BPM

Matjaz B. Juric with Swami Chandrasekaran Ales Frece Matej Hertis Gregor Srdic

professional expertise distilled

P U B L I S H I N G BIRMINGHAM - MUMBAI

WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7 Copyright © 2010 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

First published: October 2010

Production Reference: 1071010

Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK. ISBN 978-1-849680-46-2 www.packtpub.com

Cover Image by Tina Negus ([email protected])

Credits Author Matjaz B. Juric Co-Authors Swami Chandrasekaran

Editorial Team Leader Gagandeep Singh Project Team Leader Priya Mukherji

Ales Frece Matej Hertis Gregor Srdic Reviewers Krishna Mandepudi Anirudh Pucha Acquisition Editor James Lumsden Development Editor Dhwani Devater Technical Editors Erika Fernandes Aditi Suvarna Copy Editors Sanchari Mukherjee Janki Mathuria

Project Coordinator Prasad Rai Proofreader Sandra Hopper Indexer Rekha Nair Graphics Nilesh Mohite Production Coordinator Alwin Roy Cover Work Alwin Roy

Foreword I am quite honored that the authors of this book asked me if I could write the foreword. They have a long and concrete experience in implementing business processes, and we have interacted together in the context of telecommunication operators, where they delivered successful business process implementation. What I would like to share here is some practices I came to after driving many business process management and service-oriented architecture projects. Many of my customers are still trying to find how to implement processes and what technology they should use. In fact, the answer is a palette of techniques that need to be applied in the best combination. So let me try to give some clues about ways that succeed. To BPEL or not to BPEL, that is the question. There have been long debates about whether agile enterprises could drive the way they do business in an orchestrated fashion, where a maestro drives all of the interactions, or if the enterprise should act as a choreographed dancing team, where each dancer implements their part of the choreography. As such, the partition of the orchestra was used as an analogy for describing the purpose of language that described processes such as the Business Process Execution Language (BPEL). What has been missed in the orchestration analogy is that BPEL only orchestrates business service requests, but does not preclude the way the services will be executed. In a sense, BPEL is like musicians in an orchestra deciding what they could use to play their part, such as using a recorded musical part. We can easily say that the orchestration analogy does not really fit with services and neither does choreography.

So why use business processes. Agile enterprises delegate business focus to business owners, such as the owner of the customer relationship management or of the supply chain of a given country or market. In agile enterprises, the business owners establish a contract between themselves, where a party defines what services it needs for the other party, with the appropriate service-level agreements. If these services can be automated, they may end up being programmatic services. Within its domain, the business owner can be the maestro or service requests, requiring services from his own teams or from the next business owner. The end-to-end process ends up being a chain of explicit processes, each with a specific business owner, requesting services from other explicit processes. The overall effect is implicit, where the implicit process is like a train where each wagon has an explicit controller, and connects to the next wagon in a flexible way to build the train. Wagons can be changed based on the business requirements, and the technology that is used within each wagon is left to the choice of the business owner. There are many ways to implement explicit processes and these can reside in packaged applications, ERPs, or legacy applications. But in most of these examples, the flows are hidden in the application logic and are costly to manage. This is where BPEL helps in separating the flow of explicit processes from the delivery of services, which are finer-grained actions. A question still remains on how to control the end-to-end process. This is where there has been confusion between explicit process monitoring and implicit process monitoring. The monitoring of an end-to-end process that cuts across different business owners requires the creation of an abstract process view, as defined by the Business Process Modeling Notation (BPMN) categorization of processes. This monitored process never exists as a single executable component in an application or middleware, but is just the representation of a high-level chain. It is just like viewing a train from the outside, where explicit monitoring looks at what happens in a particular wagon. The implicit process monitoring requires an event strategy to capture interactions between the explicit processes so that the monitoring engine can give a high-level image of the chain. The final question that remains is what is a good size for an explicit process? Industry process standards can give clues in finding explicit process boundaries. There is a process classification framework defined by APQC (http://www. apqc.org). This classification framework models the business of industries in an enterprise decomposition and organizes the enterprise in business categories and then process groups. At level three of the decomposition, it has the processes. Similarly, the supply chain organization (http://supply-chain.org) defines that processes are at the third level of decomposition. Another example is the enhanced Telecommunication Operation Map (eTOM) standard from the TeleManagement Forum organization (http://www.tmforum.org). Again, here the explicit processes are at the third level of decomposition.

So it seems there is a common industry agreement that explicit processes need to be identified by performing a business decomposition of the enterprise, and that they need to be commonly located at a third level of this decomposition. BPEL then applies for these explicit process and services are the way these processes communicate and interact together. We should also not forget that processes carry information that is exchanged by services. I have been in projects where changes in the information models are propagated to the service interfaces and then to the business processes, leading to an important test effort. It is essential to create an ecosystem including information, services, and processes where the information model has a natural flexibility so that it can carry different content without requiring a message structural change. If you want to make your processes more agile, it becomes important to think about introducing variability patterns in the information model. In conclusion, it is important to understand how to implement BPEL for private processes with a definite business owner. This book gives you a complete view of this language and of best practices to use it efficiently with the appropriate performance, and more importantly, value to the business.

Marc Fiammante, Distinguished Engineer, Office of the IBM Software Group CTO for Europe, Member of the IBM Academy of Technology

About the Authors Matjaz B. Juric holds a Ph.D. in Computer and Information Science. He is a full-time Professor at the university and head of the Cloud Computing and SOA Competence Centre. He is a Java Champion and Oracle ACE Director. He has more than 15 years of work experience. He has authored/coauthored Business Process Driven SOA using BPMN and BPEL (Business Process Execution Language) for Web Services (English and French editions), BPEL Cookbook: Best Practices for SOA-based integration and composite applications development (award for the best SOA book in 2007 by SOA World Journal), SOA Approach to Integration, Professional J2EE EAI, Professional EJB, J2EE Design Patterns Applied, and .NET Serialization Handbook. He has published chapters in More Java Gems (Cambridge University Press) and in Technology Supporting Business Solutions (Nova Science Publishers). He has also published journals and magazines, such as SOA World Journal, Web Services Journal, Java Developer's Journal, Java Report, Java World, EAI Journal, TheServerSide.com, OTN, ACM journals, and presented at conferences such as OOPSLA, Java Development, XML Europe, OOW, SCI, and others. He is a reviewer, program committee member, and conference organizer. He has been involved in several large-scale projects. In cooperation with IBM Java Technology Centre, he worked on performance analysis and optimization of RMI-IIOP, an integral part of the Java platform. He is also a member of the BPEL Advisory Board. My efforts in this book are dedicated to my family. Thanks to my friends at SOA and Cloud Computing Centre, and Packt Publishing.

Swami Chandrasekaran works for IBM as an Industry Executive Architect for its Software Group—Industry Solutions. He provides architectural leadership for IBM tooling/product suite and works with its global customers in delivery of best-in-class solutions. His expertise includes next-generation networks, OSS/ BSS, SOA, Dynamic BPM, and modern web-based architectures, and TM Forum Frameworx (NGOSS). He has travelled to almost 24 countries and is constantly sought after within the company for his technical leadership and client skills. His credits include technical and strategic interface with various senior executives and institutions, including Fortune 100/500 companies and international clients. He is the SME and co-lead Architect for the WebSphere Telecom Content Pack. He has presented at several conferences, authored articles within IBM, articles featured in BearingPoint Institute for Thought Leadership and also holds several patent disclosures. He previously worked for BearingPoint and also for Ericsson Wireless Research. He lives with his wife Ramya and daughter Harshitha in Dallas, Texas. He is an avid video gamer and during his free time he likes to write at http://www. nirvacana.com. He holds a Master's in Electrical Engineering from the University of Texas, Arlington. There are many people whom I would like to thank. I thank my IBM management team for encouraging me and allowing me the time needed to write this book. I'd like to thank all my mentors and my family members including my in-laws who have helped and guided me over the last several years. Finally, and most importantly, I thank my wife Ramya and daughter Harshitha, for encouraging me to take this immensely challenging journey and for all the weekends and time they have sacrificed so that this book could become a reality. I dedicate this book to my parents, my gurus, and Ramya.

Ales Frece ([email protected], [email protected]) is a researcher at a university, where he is preparing his doctoral dissertation. He has participated in several SOA projects as a consultant and solution designer at the SOA Competence Centre and Cloud Computing Centre. He is involved in several research and applicative projects. He has published articles and attended conferences where he has presented his extensive knowledge on BPM, SOA, and IBM WebSphere platform. He holds several IBM SOA Technology certificates and has cooperated in launching the first cloud in Slovenia. I would like to thank Matjaz for giving me the opportunity to contribute to this book. I would also like to thank my dear wife Darja for all her love and support.

Matej Hertis ([email protected], [email protected]) is a researcher at a university. He graduated in computer and information sciences and is now working on his doctoral thesis. His main research areas are SOA, BPM, and Cloud Computing. He has published several articles and presented in conferences. He has been involved in several IT projects as a consultant and is a vice-head project manager at SOA Competence Centre and Cloud Computing Centre. His main expertise includes BPM, SOA, and Cloud Computing, especially on IBM WebSphere platform. He holds IBM SOA Technology certificates. I would like to thank Matjaz B. Juric for the opportunity to be a part of this book and his guidance throughout the writing process.

Gregor Srdic ([email protected]) is a researcher at a university. He has been involved in several research and applicative projects as consultant and solution designer. He is also participating at the SOA Competency Centre and Cloud Computing Centre in the fields of SOA, BPM, and Cloud Computing. His main expertise includes business process design and business monitoring with IBM WebSphere platform and cloud management with IBM WebSphere CloudBurst Appliance. I'd like to thank Matjaz B. Juric for his mentorship and for the opportunity to be a part of this book.

About the Reviewers Krishna Mandepudi has more than five years of experience in Java Technologies, including three years on Oracle SOA Suite. He has worked in India and is currently working in South Africa. He has worked with major clients such as Media24, South African Reserve Bank, University Of Pretoria, and ABSA.

Anirudh Pucha is a SOA and Cloud Computing Strategist working on Fusion Middleware Integration products in Oracle Corporation. He has been working in the SOA Integration space for over five years, focusing on .NET, J2EE, Oracle SOA Suite, BPEL, ESB, Adapters, BAM, Business Rules, and BPM. He is a certified webMethods Developer and Oracle Certified Professional. He is an ex-Microsoft Student Ambassador and Platform Evangelist appointed by Microsoft Corporation. He is the Assistant Manager of DNUGHS (DotNet Users Group of Hyd, supported by Microsoft Corp). He is a INETA (International .NET Association)—APAC Volunteer and Culminis Member. He is a speaker at various conferences and a guest lecturer for several universities and colleges. He is a native of Hyderabad (India), certified Latin American dancer, professional singer, dubbing artist, cricketer, cartoonist, sculptor, and a fashion model. He can be contacted on LinkedIn at http://in.linkedin.com/in/anirudhpucha and his website at http://www. anirudhpucha.tk/. I dedicate this book to God, my mother—Smt. Pucha Annapurna, father—Shri. Pucha Hanumanth Rao, and my cute nephew—Karthik Achintya.

Table of Contents Preface Chapter 1: Introduction to BPEL and SOA Why business processes matter Business and IT alignment Service-Oriented Architecture BPEL Services How to develop services

SOA concepts

Services Interfaces Messages Synchronicity Loose coupling Reusability Registries and repositories Quality of Service Composition of services into business processes

SOA building blocks BPEL for process automation Web services

How web services differ from their predecessors Web services technology stack

1 7

8 10 11 13 13 14

15 15 16 16 16 16 17 17 17 17

18 20 23 23 24

Enterprise Service Bus

25

Registry and repository Human task support and identity management Process monitoring or business activity monitoring Business Rules Management Systems (BRMS) or Rule Engine Adapters Service Component Architecture

28 30 31 33 33 34

ESB features

26

Table of Contents

SOA governance Understanding BPEL BPEL features Orchestration and choreography Executable and abstract processes Relation of BPEL to other languages XLANG WSFL BPML ebXML BPSS YAWL WSCL WSCI WS-CDL BPMN BPEL servers overview The future of BPEL Summary

Chapter 2: Service Composition with BPEL

Developing business processes with BPEL Core concepts Invoking services Invoking asynchronous services Synchronous/asynchronous business processes Understanding links to partners Partner link types Defining partner links BPEL process tag Variables Providing the interface to BPEL processes—, , and

Assignments Validating variables Accessing variables in expressions XSLT transformations Conditions Activity names Documentation [ ii ]

36 37 38 39 40 42 43 43 43 44 45 46 46 47 47 49 51 52

53 54 55 59 60 62 63 65 67 68 69 71 71 72 73

73 77 77 80 81 82 82

Table of Contents

BPEL business process example Involved services

83 86

Employee Travel Status service Airline service

86 88

WSDL for the BPEL process Partner link types Business process definition

91 92 95

BPEL process outline Partner links Variables BPEL process main body

Asynchronous BPEL example Modify the BPEL process WSDL Modify partner link types Modify the BPEL process definition Summary

Chapter 3: Advanced BPEL Advanced activities Loops

96 97 98 99

104 105 105 106 107

109

110 110

While Repeat Until For Each

111 112 113

Delays

115

Deadline and duration expressions

115

Empty activities Ending a process Fault handling and signaling WSDL faults Signaling faults

Signaling faults to clients in synchronous replies Signaling faults to clients in asynchronous scenarios

Handling faults

Selection of a fault handler Synchronous example Asynchronous example Propagating faults Default fault handler Inline fault handling

117 117 118 118 119 120 122

123

125 126 128 130 130 130

Scopes Example

132 134

First scope Second scope Third scope

137 139 141

Isolated scopes

142 [ iii ]

Table of Contents

Compensation Compensation handlers

143 144

Invoking compensation handlers Termination handler Default termination handler Managing events Pick activity

147 149 149 150 150

Example Default compensation handler

146 147

Message events Alarm events Example

151 152 153

Event handlers

154



Business process lifecycle Correlation and message properties Message properties Mapping properties to messages Extracting properties Properties and assignments

Correlation sets

155 157

158 160 161

162 164 164

165

Using correlation sets

166

Concurrent activities and links Sources and targets

168 169

Transition conditions Join conditions and link status Join failures

177 179 180

Example

170

Suppressing join failures

181

Dynamic partner links Message exchanges From-parts and To-parts

182 185 186

Abstract business processes Generating BPEL from BPMN diagrams Summary

188 190 191



Chapter 4: BPEL Processes with IBM WebSphere BPEL support in WebSphere Long-running processes and microflows Overview of BPEL activities BPEL extensions [ iv ]

186 187

193 194 194 197 200

Table of Contents

Assembly diagram

202

Imports and exports Import and export bindings

203 204

Steps for developing a BPEL process in WID Business objects WSDL interface Assembly diagram and bindings BPEL process implementation Deploying and running the example Using exports and imports Transaction boundaries Using forEach and dynamic partner references Dynamic partner references BPEL process with Parallel

207 208 209 210 214 218 223 225 227 227 228 232

Asynchronous calls, callbacks, and correlation Business objects Interfaces Assembly diagram Implementing the TravelApproval BPEL process Correlation Fault handling Compensation handling

235 236 236 239 240 241 244 245

Transaction boundaries in BPEL Setting transaction boundaries in BPEL

Adding a compensation handler to the process Calling the compensation handler from the fault handler

Event handling Data maps The XML map The BO map

233 233

247 248

250 252

255 256

Qualifiers Reliability qualifiers Activity session qualifiers Security qualifiers Other asynchronous qualifiers Miscellaneous qualifiers Summary

Chapter 5: Human Interactions in BPEL

Human interactions in business processes Human tasks in BPEL Human task integration with BPEL [v]

257 259 261 262 262 262 263

265 266 267 269

Table of Contents

Human tasks in WebSphere Process Server Defining human tasks Types of human tasks Interacting with human tasks

To-do human task Inline human task

Creating an inline human task Deploying and testing an inline human task

Global human tasks

Creating a global human task Invoking a global to-do human task from a BPEL process Deploying and testing the human task

270 271

271 272

273 274

275 280

283

284 288 292

Invocation human tasks Creating an invocation human task Testing and deploying an invocation human task Human task escalations Defining escalations Parallel escalations Chained escalations Collaboration human tasks Creating a collaboration human task Managing BPEL processes and human tasks in runtime Using the Human Task Manager API to claim to-do human tasks

294 295 298 299 300 303 304 305 305 308 309

BPEL4People A brief look at WS-HumanTask

312 312

A brief look at BPEL4People

316

Creating a human task Querying human tasks Accessing the API from a web application

Overall structure Human tasks Escalations Notifications Programming interface

310 310 311

312 313 314 315 316

Overall structure People assignments People activities

317 318 318

Summary

Chapter 6: Securing BPEL Processes

Core concepts Securing a BPEL process Exposing a BPEL process as web service Creating a WS-Policy set for WS-Security authentication Securing a BPEL process web service export with a WS-policy set [ vi ]

319

321 321 323 324 329 336

Table of Contents

Testing a secured BPEL process

339

Propagating user identity to a BPEL process

345

Testing user identity propagation to BPEL process Restricting access to a BPEL process

356 356

Calling a BPEL process without credentials Calling a BPEL process with credentials

Extracting user identity from UsernameToken Propagating an extracted user identity to a BPEL process

Setting a security permission qualifier Testing the authorization mechanism Adding users to an authorized role Testing the authorization mechanism with an authenticated and authorized user

Summary

Chapter 7: Iterative Process Development from BPMN to BPEL Iterative process lifecycle Process modeling in WebSphere Business Modeler Modeling TravelApproval process Creating a new Business Modeling Project Importing business services Creating a business process

341 342 346 351

357 359 359 362

363

365 366 368 368

369 370 374

Business process building blocks Palette

375 376

Process modeling Exporting a business process model to WebSphere Integration Developer Exporting a process model from WebSphere Business Modeler Importing a process model in WebSphere Integration Developer Implementing a process in WebSphere Integration Developer Specifying service references Deploying a process Testing a process Process change synchronization Synchronizing implemented changes

380

Activities Gateways Data Events Compensations

Changing a process in WID Technical synchronization from WID to WBM Importing a change report to WBM Reviewing changes Applying changes Resynchronizing with WID

Synchronization of modeling changes

[ vii ]

376 377 378 379 379

389 390 394 397 397 398 399 402 403

403 404 409 412 412 414

419

Table of Contents Modifying process Synchronizing changes

420 421

Round-trip synchronization

424

Exporting a new version from WBM Synchronizing with WID Resolving errors Creating a new process version

424 426 427 428

Summary

Chapter 8: Monitoring Business Processes

Motivation for Business Monitoring Business Monitoring in WebSphere Monitor model Dashboard Developing a monitor model in WebSphere Business Modeler Business measures Specifying a metric Adding an instance metric Specifying Key Performance Indicators Creating dimensions Adding additional metrics and KPIs Defining an instance metric Specifying KPIs

Exporting a monitor model to WebSphere Integration Developer Developing and refining a monitor model in WebSphere Integration Developer Importing into WID The Business Monitoring perspective Resolving warnings

Monitor model overview Adding business measures in WID Defining events Importing events Defining triggers Specifying instance metrics Creating KPIs Defining a dimension

Building and publishing a monitor application Preparing a dashboard in Business Space Configuring Business Space Defining an alert Preparing a widget for dimensional analysis Testing the dashboard Summary [ viii ]

431

433 433 436 436 437 438 439 440 442 444 446 448

448 450

453 456 456 458

460

462 466

466 467 471 473 474 476

480 482 483 485 486 488 491

Table of Contents

Chapter 9: IBM BPM Enabled by SOA: Overview

Achieving success through BPM enabled by SOA Business Process Management Building blocks of a BPM enabled by SOA framework Business process modeling Business process execution (including choreography) Enterprise Service Bus Business policies and rules Business process monitoring Information model

IBM SOA reference architecture Key elements of an IBM SOA Reference Architecture IBM SOA programming model Service Component Architecture Service data objects Common business process implementation types IBM's BPM enabled by SOA platform WebSphere Business Modeler WebSphere Integration Developer Getting around with WID Project types Creating and visualizing interfaces Business objects and business graph

493 494 495 496

497 497 497 498 498 499

501 502 505 505 511 512 515 515 516 518 520 520 521

Where does WID/WPS fit in with WS-BPEL?

524

WebSphere Process Server

527

IBM WebSphere Enterprise Service Bus

532

Working with a business process (WS-BPEL) Role of WPS in SOA Platform architecture Common BPM adoption scenarios Role of WESB in SOA Common WESB usage scenarios

WebSphere Business Monitor Business Space Creating your first BPEL solution WebSphere Industry Content Pack Summary

Chapter 10: IBM BPM Enabled by SOA—BPM in the Cloud, Dynamic Processes, and Advanced Topics Employee On-Boarding automation IBM's BPM BlueWorks Organization chart Strategy maps

[ ix ]

526 527 528 530 533 535

537 537 538 545 546

549 550 551 553 553

Table of Contents

Capability maps Process maps Business vocabulary Long-running process and Microflow Exception handling in business processes SCA exception types Compensation Catch, Catch All, Throw, Rethrow, and Terminate Exception handling suggested practices Failed event manager Testing modules and components Test configurations

554 556 559 561 563 564 564 565 566 568 568 569

WebSphere Business Services Fabric What are business services? How does it complement the BPM platform? WebSphere Business Services Fabric Dynamic Assembler Dynamic Employee On-Boarding business process with Fabric Business vocabulary Business policies WebSphere Industry Content Pack IBM WebSphere Telecom Content Pack (WTCP) IBM BPM deployment topologies WebSphere Application Server Network Deployment fundamentals

571 571 573 574 575 577 578 578 578 581 581

Application deployment topology Management, monitoring, and security topics Using the administrative console Installing SCA modules using admin console Troubleshooting and problem determination Monitoring solution components with business space

584 588 588 589 590 592

Words of wisdom—tips, tricks, suggestions, and pitfalls What are the various tools and the associated URLs that I should be aware of and bookmark?

595

Emulators Monitors Events

Cells Nodes Deployment manager Profiles Clusters Bus

Tools and capabilities provided Service monitoring with Business Space

[x]

570 570 571

581 582 582 582 582 583

592 594

595

Table of Contents

How to turn off an IBM-specific BPEL extension Any suggested method to back up WID? How to restore a profile from a backup How to increase WID heap size How to change the type of your business process How to create versioned modules and libraries Use of global variables in a ForEach within a BPEL process Summary

Index

[ xi ]

596 597 597 598 598 599 600 601

603

Preface Business Process Execution Language (BPEL, aka WS-BPEL) has become the de facto standard for orchestrating services in SOA composite applications. BPEL reduces the gap between business requirements and applications and allows better alignment between business processes and underlying IT architecture. BPEL is for SOA what SQL is for databases. Therefore, learning BPEL is essential for successful adoption of SOA or development of composite applications. Although BPEL looks easy at first sight, it hides large potential and has many interesting advanced features that you should get familiar with in order to maximize the value of SOA. This book provides a comprehensive and detailed coverage of BPEL, one of the center pieces of SOA. It covers basic and advanced features of BPEL 2.0 and provides several real-world examples. In addition to the BPEL specification, the book provides comprehensive coverage of BPEL support in the IBM WebSphere SOA platform including security, transactions, human workflow, process monitoring, automatic generation of BPEL from process models, dynamic processes, and many more.

What this book covers

Chapter 1, Introduction to BPEL and SOA, introduces BPEL, defining its role with regard to SOA (Service-Oriented Architecture), and explaining the process-oriented approach to SOA and the role of BPEL. It also provides short descriptions of the most important BPEL servers and compares BPEL to other business process languages. Chapter 2, Service Composition with BPEL, describes how to define a BPEL process and makes you familiar with the basic concepts of service composition with BPEL. It also defines two example BPEL processes for business travels and shows how to develop a synchronous and then an asynchronous process.

Preface

Chapter 3, Advanced BPEL, makes you familiar with the advanced concepts of BPEL, such as loops, process termination, delays, and deadline and duration expressions and also addresses fault handling, which is a very important aspect of each business process. Chapter 4, BPEL Processes with IBM WebSphere, illustrates how to develop BPEL processes in IBM WebSphere Integration Developer and deploy and run the BPEL processes on the IBM WebSphere Process Server. Chapter 5, Human Interactions in BPEL, describes the different approaches to human workflow support in BPEL and analyzes their relevance in practical scenarios, and discusses real-world scenarios in which BPEL and human workflow services are used. It also describes two specifications, BPEL4People and WS-HumanTask. Chapter 6, Securing BPEL Processes, describes how to get familiar with basic security concepts on WebSphere Application Server regarding protection of BPEL processes and looks at how to secure BPEL processes, so that they can be accessed only by authenticated users. Chapter 7, Iterative Process Development from BPMN to BPEL, describes how to achieve synchronization between a business process model and process implementation. It models the Travel Approval process and uses this process for different synchronization scenarios such as initial, technical, business, and round-trip synchronization. Chapter 8, Monitoring Business Processes, covers the basic concepts of Business Monitoring also known as Business Activity Monitoring (BAM). It also explains how to use IBM WebSphere to monitor BPEL processes and shows how to develop a monitor model and a dashboard in WebSphere. Chapter 9, IBM BPM Enabled by SOA: Overview, discusses the core capabilities needed for a process integration approach, IBM's SOA reference architecture, and IBM's Business Process Management platform including WebSphere Process Server and WebSphere Enterprise Service Bus. It then looks at the fundamental SOA programming model concepts and explains how these concepts apply in the context of WID/WPS/WESB. Chapter 10, IBM BPM Enabled By SOA—BPM in the Cloud, Dynamic Processes, and Advanced Topics, discusses several topics ranging from strategy maps creation to deployment and management of solutions on top of WebSphere BPM using the various tools provided. Appendix A, BPEL 2.0 Syntax Reference, provides a syntax reference for WS-BPEL (Web Services Business Process Execution Language). This can be downloaded from http:// www.packtpub.com/sites/default/files/downloads/0462_Appendix.zip.

[2]

Preface

What you need for this book

In the course of this book, you will need the following software utilities to try out the various code examples listed: •

IBM WebSphere Process Server 7.0

•

IBM WebSphere Application Server 7.0

•

IBM WebSphere Integration Developer 7.0

•

IBM WebSphere Business Modeler Advanced 7.0

•

IBM WebSphere Business Monitor 7.0

•

IBM WebSphere Business Space 7.0

Who this book is for

This book is aimed at SOA architects and developers involved in the design, implementation, and integration of composite applications and end-to-end business processes. The book provides comprehensive coverage of WS-BPEL 2.0 for implementing business processes and developing SCA composite applications, dealing with the issues of composition, orchestration, transactions, coordination, and security. This book uses IBM WebSphere SOA platform version 7.0. To follow this book, you need to have a basic knowledge of XML, web services, and Java EE.

Conventions

In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning. Code words in text are shown as follows: "The role of the BPEL process (myRole) is described as insurance requester and the partner role is described as insurance service." A block of code is set as follows:

[3]

Preface

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold: /> /> />

Any command-line input or output is written as follows: $variableName.messagePart/ns:node/ns:node…

New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "Select packtpub.com module, fill out Target file to which the change report will be saved, and click on Finish."

Warnings or important notes appear in a box like this.

Tips and tricks appear like this.

Reader feedback

Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of. To send us general feedback, simply send an e-mail to [email protected], and mention the book title via the subject of your message. If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail suggest@ packtpub.com. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.

[4]

Preface

Customer support

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase. Downloading the example code for this book You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub. com/support and register to have the files e-mailed directly to you.

Errata

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub. com/support, selecting your book, clicking on the errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.

Piracy

Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at [email protected] with a link to the suspected pirated material. We appreciate your help in protecting our authors, and our ability to bring you valuable content.

Questions

You can contact us at [email protected] if you are having a problem with any aspect of the book, and we will do our best to address it. [5]

Introduction to BPEL and SOA BPEL (Business Process Execution Language) for web services, also WS-BPEL, (BPEL4WS) is a language used for the composition, orchestration, and coordination of web services. It provides a rich vocabulary for expressing the behavior of business processes. In this chapter, we introduce BPEL, define its role with regard to SOA (Service Oriented Architecture), and explain the process-oriented approach to SOA and the role of BPEL. We will also provide short descriptions of the most important BPEL servers—the runâ•‚time environments for the execution of business processes specified in BPEL and compare BPEL with other business process languages. In this chapter, we will: •

Discuss the role of business processes and their automation

•

Discuss business and IT alignment

•

Examine SOA, its concepts, and BPEL

•

Look at the SOA building blocks, such as services, Enterprise Service Bus, registry and repository, human task support, process monitoring, Rule Engine, and adapters

•

Mention SOA governance

•

Look at BPEL features

•

Distinguish orchestration and choreography

•

Examine the relationship of BPEL with other languages

•

Overview BPEL servers and SOA platforms

•

Discuss the future of BPEL

Introduction to BPEL and SOA

Why business processes matter

Enterprise applications and information systems have become fundamental assets to companies. Companies rely on them to be able to perform business operations. Enterprise information systems can improve the efficiency of businesses through the automation of business processes. The objective of almost every company is that the applications it uses, should provide comprehensive support for business processes. This means that applications should align with business processes closely. A business process is a collection of coordinated service invocations and related activities that produce a business result, either within a single organization or across several organizations.

Although this requirement does not sound very difficult to fulfill, real-world situations show us a different picture. Business processes are usually dynamic in nature. Companies have to improve and modify, act in an agile manner, optimize and adapt business processes to their customers, and thus improve the responsiveness of the whole company. Every change and improvement in a business process has to be reflected in the applications that provide support for them. It is most likely that companies have to live with very complex information system architectures consisting of a heterogeneous mix of different applications that have been developed over time using different technologies and architectures. These existing applications (often called legacy applications) are a vital asset in each company and core business usually depends on them. Replacing them with newly developed applications would be very costly and time consuming and usually would not justify the investment. On the other hand, existing applications have several limitations. Probably the most important fact is that the majority of older applications have been developed from the functional perspective and have addressed the requirements of a single domain. Therefore, such applications typically do not provide support for the whole business process. Rather they support one or a few activities in a process. Such applications provide support for certain functions or tasks only. For an information system to provide complete support for business processes, it has to be able to use the functionalities of several existing applications in a coordinated and integrated way. The consequence is that users need to switch between different applications to fulfill tasks and also perform some tasks manually. The flow of the tasks is in the heads of users, not in the information system and this has several disadvantages, such as limited insight into the way business activities are performed, difficulties in tracing current status and progress, difficulties in monitoring key performance indicators, and so on. [8]

Chapter 1

Existing applications have often been developed using older technologies, languages, and architectures, which are by definition less flexible to change. Tightly coupled applications, constructed of interrelated modules, which cannot be differentiated, upgraded, or refactored with a reasonable amount of effort, place important limitations on the flexibility of such applications. This is why such applications are sometimes called stovepipe applications. Let us summarize—on one side we have the business system, which consists of business processes. Business processes define the order of activities and tasks that produce a specific business result. Business processes have to be flexible in order to adapt to customer requirements, to market demand, and to optimize operations. On the other side, we have the information system with multiple existing applications. Existing applications have important business logic implemented, which a company relies upon to perform business operations. Existing applications are also difficult to modify and adapt, because they have not been developed in a flexible way that would allow modifying application parts quickly and efficiently. This is shown in the following figure:

[9]

Introduction to BPEL and SOA

Business and IT alignment

The business system usually evolves with a different pace as compared to that of the information system. Over time, this has resulted in an important loss of alignment between the business system and the information system. This has resulted in applications that do not fully support business tasks and which have again hindered the evolution of business processes. The consequence has been less flexible and adaptable organizations with less competitive power in the market. Only companies where applications can be quickly and efficiently adapted to changing business needs can stay competitive in the global market. The loss of alignment between the business and IT has a name—IT gap. An IT gap is a common occurrence in almost every company. It is mainly a consequence of the inability of application developers to modify and adapt the applications to business requirements quickly and efficiently. The main reason probably lies in the fact that in the past neither programming languages and technologies nor architectural design have anticipated changes. Existing applications have been designed to last. They have been developed in a tightly coupled fashion, which make changes to specific parts of applications very difficult. Because of dependencies, such changes usually often have several unpredictable consequences. In addition to the complexity and size of the modification, an important factor is also the state of the application being modified. If an application has a well-defined architecture and has been constructed keeping in mind future modifications, then it will be easier to modify. However, each modification to the application makes its architecture less robust with respect to future changes. Applications that have been maintained for several years and have gone through many modifications usually do not provide robust architecture anymore (unless they have been refactored constantly). Modifying them is difficult, time consuming, and often results in unexpected errors. Therefore, modifying existing applications requires time. This means that an information system cannot react instantly to changes in business processes. Rather it requires time to implement, test, and deploy the modifications. This is sometimes referred to as the IT gap time. It is obvious that the gap time should be as short as possible. However, in the real world, this is (once again) not always the case. We have seen that there are at least three important forces that have to be considered: •

Alignment between business and IT, which is today seen as one of the most important priorities.

•

Complexity of existing applications and the overall IT architecture: Modifying them is a complex, difficult, error-prone, and time-consuming task. [ 10 ]

Chapter 1

•

Indispensability of existing applications: Companies rely upon existing applications and very often their core business operations would be jeopardized if existing applications fail.

This makes the primary objective of information systems to provide timely, complete, and easy-to-modify support for business processes even more difficult to achieve.

Service-Oriented Architecture

We have seen that the lack of alignment between the business and IT is a common occurrence in almost every company. Achieving the alignment by modifying existing applications is in most cases, not successful for two reasons: •

Complexity of the IT architecture, which makes modifying existing applications difficult and time consuming

•

Existing applications must not fail, because companies rely on them for everyday business

The alignment of business and IT is very difficult to achieve using traditional approaches. However, if a mediation layer between the business and the information system is introduced, the alignment between business and IT becomes more realistic—meet the SOA. To manage problems related to changing requirements, technology developments, and integration, different methods have been proposed and used over time. A Service Oriented Architecture is the latest architectural approach related to the integration, development, and maintenance of complex enterprise information systems. SOA is not a radically new architecture, but rather the evolution of well-known distributed architectures and integration methods. Integration between applications has evolved from early days into well-defined integration methods and principles, often referred to as EAI (Enterprise Application Integration). EAI initially focused on the integration of applications within enterprises (intra-EAI). With the increasing need for integration between companies (B2B, business-to-business), the focus of EAI has been extended to inter-EAI. SOA improves and extends the flexibility of earlier integration methods (EAI) and distributed architectures and focuses on the reusability of existing applications and systems, efficient interoperabilities and application integrations, and the composition of business processes out of services (functionalities) provided by applications. An important objective of SOA is also the ability to apply changes in the future in a relatively easy and straightforward way.

[ 11 ]

Introduction to BPEL and SOA

SOA defines the concepts, architecture, and process framework, to enable the cost-efficient development, integration, and maintenance of information systems by reducing complexity and stimulation of integration and reuse. Let us look at the definition of SOA, as provided by Bernhard Borges, Kerrie Holley, and Ali Arsanjani (http://searchsoa.techtarget.com/news/article/0,289142,sid26_ gci1006206,00.html): SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions. The following figure shows SOA as a mediator that aligns business and IT more closely. The end-to-end automation of business processes with BPEL fills the gap towards the business system. The services fill the gap towards the information system.

[ 12 ]

Chapter 1

A Service-Oriented Architecture has several goals, but the two most important goals are to: •

•

Provide end-to-end automation of business processes. To achieve end-to-end automation of business processes, SOA introduces a special language, that is, BPEL. Provide a flexible, adaptable IT architecture, where applications are modularized, consolidated, decoupled, and where business logic is contained in autonomous, encapsulated, loosely-coupled, and reusable components, called services.

Let's look at these two goals more closely.

BPEL

From the perspective of business systems, it is important that IT provides applications that support business processes from the beginning to the end (or endto-end). However, such support has to be flexible so that business processes can be modified quickly. In SOA, this is achieved by introducing a specialized language for business process execution—BPEL. BPEL is the most popular, commonly accepted specialized language for business process automation and the main topic of this book. BPEL is a special language, designed to execute business processes using a special server—the process server. BPEL promises to achieve the holy grail of enterprise information systems, to provide an environment where business processes can be developed in an easy and efficient manner, directly executed, monitored, and quickly adapted to the changing needs of enterprises without too much effort.

Services

Achieving adaptable and flexible IT architecture is another important objective of SOA. SOA enables us to develop a modular, loosely coupled architecture, which can overcome the difficulties of existing architectures. The end-to-end automation of business processes can only be successful if sound, robust, and reliable applications are available underneath. This goal can only be achieved by developing a flexible architecture, where applications consist of modules. In SOA, modules are called services. Services should be autonomous and should be able to work in different contexts. They should be reusable and loosely coupled. They should be encapsulated and should expose the operations through interfaces. Finally, the application architecture should be consolidated, which means that for a specific functionality, only one service should exist. [ 13 ]

Introduction to BPEL and SOA

In SOA, services become the main building blocks of the overall IT architecture. Services guide us into good development practices and away from monolithic, tightly coupled applications. Services enable better and more efficient integration. They enable us to modify and adapt the applications faster, with less effort and with less negative consequences. Services are also the main building blocks of BPEL processes. They are the executable artifacts. Those services that expose high-level, coarse-grained operations are called business services. The operations in business services usually represent distinct business activities. They are used in business processes—more exactly, BPEL uses business services to execute process activities. In other words, BPEL processes are compositions of business services. Business services provide the functionality, while BPEL processes contain the process flow. Business services should be designed in a reusable manner, which means that a single business service can be used by more than one BPEL process. It also means that only one business service with the same functionality should exist in the system, which leads to consolidation. Although services in SOA are one of the most important building blocks, we should not forget about the architecture. Services will fulfill the promises only if they adhere to the architecture. Architectural design should therefore be the key priority.

How to develop services

There are several possibilities in which we can develop services. They are: •

Developing services from scratch. This is appropriate for functionalities that are new and not yet covered by existing applications.

•

Exposing the functionality of existing applications through services. It is particularly important to reuse the logic in existing applications and to integrate new solutions with existing applications. Today, several possibilities exist for exposing existing applications through services, such as facades, adapters, mediators, and so on.

•

Using services provided by a third party.

The ability to expose existing applications is particularly important, because it enables those who will adapt SOA to reuse their existing IT assets. Existing applications have an enormous amount of business logic, which should be exposed and reused. SOA provides a standardized way to expose and access the functionalities (business logic) of existing applications through services. [ 14 ]

Chapter 1

From the technical perspective, services can be developed using a variety of distributed architectures. The requirement to expose the functionalities of applications and access them remotely has resulted in several distributed architectures and middleware products over time. The latest distributed architecture is web services. Web services are the most suitable distributed architecture for exposing the functionality of applications as services.

SOA concepts

SOA is more than just a set of technologies. SOA is not directly related to any technology, although it is most often implemented with web services. Web services are the most appropriate technology for SOA realization. However, using web services is not adequate to build SOA. We have to use web services according to the concepts that SOA defines. The most important SOA concepts are: •

Services and service abstraction

•

Self-describing, standardized interfaces with coarse granulation

•

Exchange of messages

•

Support for synchronous and asynchronous communication

•

Loose coupling

•

Reusability

•

Service registries and repositories

•

Quality of service

•

Composition of services into business processes

Services

Services provide business functionalities, such as an application for business travel, an application for a loan, and so on. This differs considerably from technologyoriented functionalities, such as retrieving or updating a table in a database. Services in SOA must provide business values, hide implementation details, and be autonomous. Services should be abstracted and autonomous. Service consumers are software entities, which call the service and use its functionality.

[ 15 ]

Introduction to BPEL and SOA

Interfaces

Service consumers access the service through its interface. The interface of a service defines a set of public operation signatures. It is a contract between the service provider and a service consumer. The interface is separated from the implementation, is self-describing, and is platform-independent. Interface description provides a basis for the implementation of the service by the service provider and a basis for the implementation of the service consumers. Each interface defines a set of operations. In order to define business services, we need to focus on the correct granulation of operations and we should standardize interfaces. SOA services are best modeled with coarse granulation.

Messages

Operations are defined as a set of messages. Messages specify the data to be exchanged and describe it in a platform-and-language-independent way using schemas. Services exchange only data, which differs considerably from objectoriented and component approaches, where behavior (implementation code) can also be exchanged. Operations should be idempotent (an operation is idempotent if repeated invocations have the same effect as one invocation). WSDL is a service description language that meets SOA criteria.

Synchronicity

Service consumers access services through the service bus. This can be either a transport protocol, such as SOAP or an ESB. Service consumers can use synchronous or asynchronous communication modes to invoke the operations of services. In synchronous mode, a service operation returns a response to the service consumer after the processing is complete. The service consumer has to wait for the completion. Usually, we use the synchronous mode with operations in order to complete processing in a short time. In an asynchronous mode, a service operation does not return a response to the consumer, although it may return an acknowledgement so that the consumer knows that the operation has been invoked successfully. If a response is needed, usually a callback from the service to the consumer is used. In such a scenario, a correlation between messages is needed.

Loose coupling

Through the self-describing interfaces, coarse granulation, exchange of data structures, and support for synchronous and asynchronous communication modes, a loose coupling of services is achieved. Loosely coupled services are services that expose only the necessary dependencies and reduce all kinds of artificial dependencies. This is particularly important when services are subject to frequent changes.

[ 16 ]

Chapter 1

Minimal dependencies assure us that there will be a minimal number of changes required by other services when one service is modified. Such an approach improves robustness, makes systems more resilient to change, and promotes the reuse of services.

Reusability

SOA is about the consolidation of functionalities. Therefore, the common goal is to have a single service for each business functionality. In other words, we should not have more than one service with equal or similar functionalities. It is essential to achieve this in order to reuse services in different contexts. Reuse is not easy to achieve. First, we have to develop services that are general enough to be useful in different scenarios. Second, developers should first look at existing services, before developing a new one. If an existing service fulfills the need, they should reuse it. Reuse is fostered by registries and repositories.

Registries and repositories

To simplify and automate searching for the appropriate service, services are maintained in service registries, which act as directory listings. Service providers publish services in registries; service consumers look up the services in the registries. Lookup can be done by name, service functionality, or business process properties. UDDI is an example of a service registry. Service registries can improve reuse. In addition to registries, repositories are becoming important for storing artifacts, such as WSDL interfaces, XML schemas, and so on. Registries and repositories play an important role in SOA governance.

Quality of Service

Services usually have associated Quality of Service(QoS) attributes. Such attributes include security, reliable messaging, transaction, correlation, management, policy, and other requirements. The infrastructure must provide support for these attributes. Quality of Service attributes are often important in large information systems. In web services, Quality of Service attributes are covered by WS-* specifications, such as WS-Security, WS-Addressing, WS-Coordination, and so on. Quality of Service is also provided by the ESB.

Composition of services into business processes

The final and probably the most important SOA concept is the composition of services into business processes. Services are composed in a particular order and they follow a set of rules to provide support for business processes. The composition of services allows us to provide support for business processes in a flexible and relatively easy way. It also enables us to modify business processes quickly and, therefore, to provide support to change requirements faster and with less effort. [ 17 ]

Introduction to BPEL and SOA

For composition, we will use a dedicated language, BPEL, and an engine on which business process definitions will be executed. Only when we reach the level of service composition, can we realize all the benefits of SOA.

SOA building blocks

Let us now have a closer look at the SOA building blocks that enable us to realize the above-mentioned concepts: •

BPEL for business process automation with service composition.

•

Services for achieving modular and flexible architecture. For service development web services technology is usually used.

•

Enterprise Service Bus (ESB) provides a means for services and processes to communicate and enables management and control over the communication. ESB is the backbone of SOA.

•

Registries and repositories are central directories of services and useful for locating and reusing services, as well as SOA governance.

•

Human task support—business processes often involve human interaction. SOA supports human interactions in different ways, such as WS-HumanTask and BPEL4People. Human task support is related to Identity Management.

•

Process monitoring or Business Activity Monitoring (BAM) allows the monitoring of the execution of processes, such as total execution time, average execution time, execution time of certain activities, and so on. It also allows us to monitor the Key Performance Indicators (KPIs), which is particularly interesting for management, as it allows them to understand better how the business operations perform.

•

Business Rules Management Systems (BRMS) or Rule Engine, which is a central place for managing business rules. With BRMS we can put business rules into a central location instead of hard coding them.

•

Adapters, which provide easy access to external systems, such as ERP, CRM, SCM, but also DBMS systems.

A very important aspect of SOA is SOA governance. SOA is a complex architecture, which has to be governed in order to be consistent. SOA governance is a set of activities related to control over services and processes in SOA. Typical activities are related to managing service portfolios and lifecycles, ensuring service consistency, and monitoring service performance. The full architecture of SOA is shown in the following figure:

[ 18 ]

Chapter 1

The following figure shows the technology view of SOA and positions the above-mentioned concepts:

[ 19 ]

Introduction to BPEL and SOA

Let us now add the technologies into the previous picture to understand the connection between SOA concepts and the technologies that provide a means for their realization. Notice that the mere use of a specific technology does not guarantee that we are building an SOA-compliant architecture. For example, with web services we can develop business services (for example, a loan application), but we can also develop technologyâ•‚focused services (updating the database, for example). So, it is essential that technologies are used according to the guidelines provided by SOA concepts:

For this picture, we can have two views. The bottom-up view of SOA sees different applications exposing their functionalities through business services. This enables access to functionalities (services) of different existing and newly developed applications in a standard way. Access to services is important because a typical enterprise has a large number of applications, which have to be integrated. Developing business services, either through reuse of existing applications or by new development, is not sufficient. We also need to compose services into business processes—this is the second top-down, or process-oriented approach to SOA. We would obviously prefer a relatively simple and straightforward way to compose and modify business processes. This is where BPEL becomes important.

BPEL for process automation

Services in SOA are composed into aggregate services. We compose services until the aggregate services provide support for the whole business processes. Business processes are thus defined as a collection of activities through which services are invoked. For the outside world, that is, for the clients, a business process looks like any other service. In real-world scenarios, we will usually create two kinds of business processes—those that will contain services from within the enterprise only and those that will consume services provided by several companies. With service composition we can use services provided by business partners in our processes and business partners can use our services in their processes. [ 20 ]

Chapter 1

For example, a business process for booking business travel will invoke several services. In an oversimplified scenario, the business process will require us to specify the employee name, destination, dates, and other travel details. Then the process will invoke a service to check the employee's status. Based on the employee status, it will select the appropriate travel class. Then it will invoke the services of several airline companies (such as American Airlines, Delta Airlines, and so on) to check the airfare price and buy the one with the lowest price. The structure of services composed in the business process is shown in the following figure. In Chapter 2, Service Composition with BPEL, we will discuss this example in detail and show how to define this process using BPEL.

From the perspective of our business process, we do not care whether the service for checking the employee status accesses a legacy system, a database directly, or retrieves the status in any other way. We also do not care whether the services of airline companies are composed of other low-level services. From the perspective of the client (for our business process) the client monitors the process as any other service and does not care whether the process is implemented through composition of other services or some other way. This stimulates reuse and further composition. Real-world business processes will usually be much more complicated than our example. Usually they will contain several services and invoke their operations either in sequence or in parallel. They will also contain flow logic, handle faults, take care of transactions and message correlation, and so on.

[ 21 ]

Introduction to BPEL and SOA

The composition of services into business processes requires the definition of collaboration activities and dataâ•‚exchange messages between involved web services. WSDL provides the basic technical description and specifications for messages that are exchanged. However, the description provided by WSDL does not go beyond simple interactions between the client (sender) and the web service (receiver). These interactions may be stateless, synchronous, or asynchronous. These relations are inadequate to express, model, and describe the complex compositions of multiple web services in business activities, which usually consist of several messages exchanged in a well-defined order. In such complex compositions, synchronous and asynchronous messages can be combined, and interactions are usually long running, often involving state information that has to be preserved. An important aspect is also the ability to describe how to handle faults and other exceptional situations. Given the limitations of WSDL, we need a mechanism to describe the composition of web services into more complex processes. The composition of services into business processes could be realized using one of the well-known programming languages (Java, C#, and so on), but it turns out that the composition of services differs somehow from traditional programming. With composition, we merge functionalities (services) into larger services and processes. In other words, we do programming in large, which differs from traditional programming in small. Programming in large refers to the representation of the high-level state transition logic of a system. Using programming languages, such as Java, C#, and so on, for composition often results in inflexible solutions, particularly, because there is no clear separation between the process flow and the business logic, which should not be tightly coupled. In addition to these facts, the composition of business processes has other specific requirements, such as support for many process instances, long-running processes, compensation, and so on. All this makes the use of dedicated solutions reasonable. This is why over the years several proprietary BPM (Business Process Management) products have been developed, such as Dralasoft Workflow and Tibco Business Process Management. The disadvantage of using proprietary BPMs is that these are traditionally niche products, sold from a top-down perspective to large business users. Such products usually are expensive and bound to a certain provider. This is why we need BPEL.

BPEL is equally important for SOA as SQL is for databases.

[ 22 ]

Chapter 1

Web services

Web services are the latest distributed technology and, as we will see, they are the most suitable technology for the realization of SOA. They have become the commonly used technology for interoperability and the integration of applications and information systems. Web services provide the technological foundation for achieving interoperability between applications using different software platforms, operating systems, and programming languages. They are built on XML. While XML is the de facto standard for data-level integration, web services are becoming the de facto standard for service-level integrations between and within enterprises. From the technological perspective, web services are a distributed architecture. The distributed computing paradigm started with DCE (Distributed Computing Environment), RPC (Remote Procedure Call), and messaging systems, also called messageâ•‚oriented middleware (products such as MQ Series, MSMQ, and so on.). Then distributed objects and ORBs (Object Request Brokers), such as CORBAORBs (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model), and RMI (Remote Method Invocation), emerged. Based on these, component models, such as EJB (Enterprise Java Beans), COM+ (Component Object Model), .NET Enterprise Services, and CCM (CORBA Component Model) have been developed. RPC, ORBs, and component models share a similar communication model, which is based on a synchronous operation invocation. Messaging systems are based on an asynchronous communication model.

How web services differ from their predecessors

Web services are similar to their predecessors, but also differ from them in several aspects. Web services are the first distributed technology to be supported by all major software vendors. Therefore, they are the first technology that fulfills the promise of universal interoperability between applications running on disparate platforms. The fundamental specifications that web services are based on are SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration). SOAP, WSDL, and UDDI are XML-based, making web services protocol messages and descriptions human readable. From the architectural perspective, web services introduce several important changes compared to earlier distributed architectures: •

Web services support loose coupling through operations that exchange data only. This differs from component and distributed object models, where behavior can also be exchanged.

[ 23 ]

Introduction to BPEL and SOA

•

Operations in web services are based on the exchange of XMLâ•‚formatted payloads. They are a collection of input, output, and fault messages. The combination of messages defines the type of operation (one-way, request/ response, solicit response, or notification). This differs from previous distributed technologies. For more information, please refer to WSDL and XML Schema specifications.

•

Web services provide support for asynchronous as well as synchronous interactions.

•

Web services introduce the notion of endpoints and intermediaries. This allows new approaches to message processing.

•

Web services are stateless. They do not follow the object paradigm.

•

Web services utilize standard Internet protocols such as HTTP (Hyper Text Transfer Protocol), SMTP, (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), and MIME (Multipurpose Internet Mail Extensions). So, connectivity through standard Internet connections, even those secured with firewalls, is less problematic.

Web services technology stack

In addition to several advantages, web services also have a couple of disadvantages. One of them is performance, which is not as good as that of distributed architectures that use binary protocols for communication. The other is that plain web services do not offer infrastructure and Quality of Service features, such as security, transactions, and others, which have been provided by component models for several years. Web services fill this important gap by introducing additional specifications: • • •

• • •

WS-Security: Addresses authentication and message-level security, and enables secure communication with web services. WS-Coordination: Defines a coordination framework for web services and is the foundation for WS-AtomicTransaction and WS-BusinessActivity. Transactions specifications (WS-AtomicTransaction and WS-BusinessActivity): Specify support for distributed transactions with web services. AtomicTransaction specifies short duration, ACID transactions, and BusinessActivity specifies longer-running business transactions, also called compensating transactions. WS-Reliable Messaging: Provides support for reliable communication and message delivery between web services over various transport protocols. WS-Addressing: Specifies message coordination and routing. WS-Inspection: Provides support for the dynamic introspection of web service descriptions. [ 24 ]

Chapter 1

•

WS-Policy: Specifies how policies are declared and exchanged between collaborating web services.

•

WS-Eventing: Defines an event model for asynchronous notification of interested parties for web services.

Because of their flexibility, interoperability, and other features, web services are regarded as the most appropriate technology for exposing the functionalities of applications as services and are therefore the most appropriate technology for realization of SOA. Because of their wide support by all major software vendors, web services provide the possibility to use the same technology to expose services implemented in a variety of different applications ranging from mainframe-based legacy applications to the modern multitier applications.

Enterprise Service Bus

While web services are an appropriate technology for SOA, some other aspects need to be considered: •

In most enterprises, web services are not the only middleware solution used. Usually enterprises already have one or more middleware products, such as messaging systems and ORBs. Enterprises cannot afford to replace them overnight with web services. Therefore, there is a need to integrate different middleware products and provide interoperability with web services.

•

In order to provide connectivity between services, the use of SOAP in complex environments is not adequate. In such environments, we need ways to connect, mediate, manage, and control the services and particularly the communication between them.

•

SOAP over HTTP might not be robust enough for heavy enterprise use. Enterprise information systems require dependable, robust, and secure service infrastructure.

The Enterprise Service Bus (ESB) is the software infrastructure, acting as an intermediary layer of middleware that addresses the above-mentioned requirements. An ESB adds flexibility to the communication between services and simplifies the integration and reuse of services. An ESB makes it possible to connect services implemented in different technologies (such as EJBs, messaging systems, CORBA components, and legacy applications) in an easy way. It can act as a mediator between different, often incompatible protocols and middleware products.

[ 25 ]

Introduction to BPEL and SOA

The ESB provides a robust, dependable, secure, and scalable communication infrastructure between services. It also provides control over the communication and control over the use of services, including: Message interception capabilities: This allows us to intercept requests to services and responses from services and apply additional processing to them. In this manner, the ESB acts as an intermediary. • Routing capabilities: This allows us to route the messages to different services based on their content, origin, or other attributes. • Transformation capabilities: These allow us to transform messages before they are delivered to services. For XML-formatted messages, such transformations are usually done using XSLT (Extensible Stylesheet Language for Transformations) or XQuery engines. • Control over the deployment, usage, and maintenance of services: This allows logging, profiling, load balancing, performance tuning, charging for use of services, distributed deployment, on-the-fly reconfiguration, and so on. • Other important management features include the definition of correlation between messages, definition of reliable communication paths, definition of security constraints related to messages and services, and so on. •

ESB features

The Enterprise Service Bus enables the communication and management of services and provides answers related to the usage of services in complex enterprise information systems. In such environments support for the centralized, declarative, and well-coordinated management of services and their communications is required. Because of existing middleware, the integration of different middleware products and interoperability with other services is required. The Enterprise Service Bus is important, because it represents the communication backbone for services. Using ESB for communication, we can get rid of point-topoint connections between services and processes. ESB also simplifies the transition between development, test, and production environments. The most important features of ESB are service routing, transformation, and enhancement, protocol transformation, service mapping, security, and Quality of Service: •

Message routing enables us to route messages to a specific service provider in a declarative manner based on the message content, user type, channel, or other rules.

•

Message transformation enables us to transform the input and output messages. Usually this is related to XML transformation using XSLT. [ 26 ]

Chapter 1

•

Message enhancement enables us to add or remove data to the message, so that they conform to the requirements of the service provider and service consumer.

•

Protocol transformation is the ability to automatically transform the protocol based on the service provider and service consumer preferences. For example, a service consumer might use SOAP, while the service uses JMS. Protocol transformation can also optimize performance and switch to an optimized protocol for collocated services.

•

Service mapping enables us to map a service to a specific service implementation. This is usually an extension of WSDL bindings.

•

Security enables us to secure services and the transportation layer used for the exchange of messages. For securing services, authentication and authorization are important; for securing the exchange of messages, encryption is usually applied.

•

Quality of Service allows us to define specific parameters of service communication, such as reliability, bandwidth, availability, and so on. Quality of Service assurance is the baseline for the definition of Service Level Agreements (SLA).

Currently, there are several products in the market that claim to provide ESB functionality. A good ESB should provide at least Quality of Service support at enterprise level, including reliability, fault-tolerance, and security. If provided by an ESB, services can depend on these features and do not need to implement them themselves. The ESB should also allow the configuration of any combination of these Quality of Service features and provide flexibility. An ESB should provide support for a variety of technologies on which services are implemented. In addition to web services, an ESB should provide connectors for a broad range of technologies, such as Java EE and .NET components, messaging middleware, legacy applications, and TP monitors. The ESB needs to provide flexibility to bind any combination of services without technological constraints. It should also support a combination of different interaction models, such as queuing, routing, and so on, without changing the services or requiring to write code. An ESB should make services broadly available. This means that it should be easy to find, connect, and use a service irrespective of the technology it is implemented in. With a broad availability of services, an ESB can increase the reuse and can make the composition of services easier. Finally, an ESB should provide management capabilities, such as message routing, interaction, and transformation, which we have already described.

[ 27 ]

Introduction to BPEL and SOA

An ESB that provides these features becomes an essential part of the SOA. It provides several benefits, including increased flexibility, reduced deployment, development, and maintenance costs, and increased reliability and manageability. The following figure shows the relation between BPEL, ESB, and services:

Registry and repository

We have already seen that SOA consists of services and processes. The more applications that we implement following SOA concepts, the more services we will have. Managing the services becomes a challenging task. This includes aspects such as: •

How many services do we have?

•

Does a service with a specific functionality already exist?

•

Where is the service deployed?

•

Which versions of the service exist?

•

Who are the consumers (clients) of a specific service?

•

What is the interface definition (WSDL) of a service?

[ 28 ]

Chapter 1

Registries and repositories help to answer these and similar questions. They have become an essential part of each SOA architecture. Registries and repositories are used to register services in a central location. Once registered, we can search and locate appropriate services. The more metadata about a service we include, the better search capabilities a registry and repository can provide. A rule of thumb is that once we have more than 50 services we will desperately start needing the registry and repository. However, sometimes it might be wise to introduce it from the beginning, because once developers get used to a certain development process, it will be very difficult to change their behavior. In addition to the above-mentioned questions, registries and repositories play an important role in service reuse. Simplifying things somewhat, reuse on a service level means that we compose executable processes (in BPEL) and reuse as many services as possible instead of developing them from scratch. Registries and repositories also play an important role in the deployment process. In professional development it is usual to have three environments: development, test, and production. When an application is ready for production use, this requires that it is deployed into the production environment. The controlled deployment of processes requires that a process starts to use a production version of services instead of development or test versions. If links to services are hard coded into the BPEL processes, such migrations can be very painful, as it might (in a worst-case scenario) require the manual change of URL addresses. When deploying a service we might want to know which processes use this service, because we might want to retest those processes. The understanding of the role of registries and repositories in SOA has changed over the years considerably. A few years ago, we believed that a relatively simple registry—UDDI, would cover all the needs. Today, we have identified that a registry alone is not powerful enough for SOA, because in many cases it makes sense to store service metadata as well (WSDL interfaces, XSD schemas, and so on).Therefore, today we talk about registries and repositories. A powerful registry and repository should have the following features: •

Classification capabilities to categorize and classify services and processes based on one or more classification schemas. This simplifies queries and enables easier locations for the most appropriate services for reuse.

•

Governance functions, which should enable the definition of proprietary service/process lifecycles, together with the conditions to go from one stage of the lifecycle to another. Stage transitions can trigger automatic actions, such as validators.

[ 29 ]

Introduction to BPEL and SOA

•

Access control, which defines who can do which operations on the registry and repository, and on the registered services/processes. Such access control could be based on XACML (eXtensible Access Control Markup Language).

•

User, programming, and administration interfaces.

Registries and repositories also play an important role in SOA governance.

Human task support and identity management Business processes often involve human interaction. Therefore, SOA has to provide support for human tasks. Human tasks are sometimes called user interactions. Human tasks in business processes can be simple, such as approving certain tasks or decisions, or complex, such as delegation, renewal, escalation, nomination, or chained execution. Task approval is the simplest and probably the most common human task. If the situation is more complex, a business process might require several users to make approvals, either in sequence or in parallel. In sequential scenarios, the next user often wants to see the decision made by the previous user. Sometimes, (particularly in parallel human tasks) users are not allowed to see the decisions taken by other users. This improves the decision potential. Sometimes one user doesn't even know which other users are involved—or whether any other users are involved at all. A common scenario for involving more than one user is escalation. Escalation is typically used in situations where an activity doesn't fulfill a time constraint. In such a case, a notification is sent to one or more users. They can be chained, going first to the first-line employees and advancing to senior staff if the activity is not fulfilled. Sometimes it's difficult or impossible to define in advance, which user should perform an interaction. In this case, a supervisor might manually nominate the task to other employees; the nomination can also be made by a group of users or by a decision-support system. In other scenarios, a business process may require a single user to perform several steps that can be defined in advance or during the execution of the process instance. Even more-complex processes might require that one workflow is continued with another workflow. Human tasks can include data entries or process management issues, such as process initiation, suspension, and exception management. This is particularly true for long-running business processes, where, for example, user exception handling can prevent costly process termination and related compensation for those activities that have already been successfully completed. [ 30 ]

Chapter 1

As a best practice for human tasks, it's usually not wise to associate human tasks directly with specific users; it's better to connect tasks to roles and then associate those roles with individual users. This gives business processes greater flexibility, allowing any user with a certain role to interact with the process and enabling changes to users and roles to be made dynamically. To be able to do this, we need to have an Identity Management system where users, roles, and groups are managed. This can be a simple LDAP or a more sophisticated system. To interleave human tasks with BPEL processes we can use a workflow service, which interacts with BPEL processes using standard WSDL interfaces, as any other service. This way, the BPEL process can assign user tasks and wait for responses by invoking the workflow service using the same syntax as for any other service. The BPEL process can also perform more complex operations such as updating, completing, renewing, routing, and escalating tasks. To standardize the explicit inclusion of human tasks in BPEL processes the BPEL4People (WS-BPEL Extension for People) specification has been proposed. BPEL4People introduces people activities and people links into BPEL. People activity is a new BPEL activity used to define user interactions, in other words, tasks that a user has to perform. For each people activity, the BPEL server must create work items and distribute them to users who are eligible to execute them. To specify human tasks the WS-Human Task specification has been proposed.

Process monitoring or business activity monitoring

One of the key elements for process control is process monitoring or BAM. The key objective of BAM is to provide a complete insight into business process execution. BAM allows for the monitoring of Key Performance Indicators, such as total execution time, average execution time, the execution time of certain activities, and so on. This allows us to understand better how the business processes perform. Business activity monitoring is the real-time observation of key performance indicators.

The most important component of BAM is time. Time is crucial, because BAM shows the actual near real-time information on process execution. This way, a company can react quickly and efficiently to changes reflected through process execution. BAM solutions can provide other useful information. They can show us how many process instances are active at a specific time, how long on average it takes to complete a process, which users (employees) have started how many process instances, and so on. [ 31 ]

Introduction to BPEL and SOA

Note that BAM is not related to automatic activities (those implemented by services) only. It can be used with human activities as well. In such a case, we can use BAM to observe the productivity of employees. BAM is not only a system that displays interesting information about processes, but also consolidates data gathered from different independent sources. Connecting these data with past data enables BAM to identify critical situations in process execution or even automatically or semi-automatically solves some frequent critical problems. The ultimate goal of each BAM user is to optimize the process execution, to improve the process efficiency, and to sense important events and react. The BAM user interface (dashboard) should be simple and present information and data in an easy and understandable way. It should hide all the complexity behind the scenes. Usually a typical BAM user interface uses graphical elements, graphs, and colors to present the data. The following screenshot shows an example BAM:

[ 32 ]

Chapter 1

In the previous figure, we can see the BAM dashboard showing different important information for decision makers. In addition to the dashboard, another important part of the BAM is the decision-support module. A module such as this can use decision methods, business intelligence, or simulations for support and can help decision makers take the right decision at the right time, which can improve business efficiency.

Business Rules Management Systems (BRMS) or Rule Engine

Business rules are part of almost every business application. Experience has shown that business rules change sometimes or very often. Today, business rules are usually coded into different applications and are tightly coupled with the implementation of an application system. Changing business rules is therefore often very difficult and requires modifications to applications. Each modification requires that the developer changes the code. After that, testing and deployment has to be done. The same business rules are often implemented in several applications. Therefore, if a rule changes, the major challenge becomes to identify in which applications this business rule is coded and to modify each application where such a rule has been used. Business rules are also very common in business processes. BRMS or rule engines are meant to provide a central location for storing, executing, and managing business rules. Instead of hard-coding business rules into the executable code (whether BPEL, or Java, C#, and so on), we place business rules into the BRMS, where: •

Business rules can be reused from different processes, services, and applications

•

User friendly interfaces exist, which enable us to change and modify business rules

Adapters

Adapters in SOA are meant to simplify the integration with external systems, such as ERP, CRM, SCM, and others. Without adapters, we would need to manually expose functionality out of such systems, for example by developing corresponding web services. As such systems usually have rich functionalities, it would require a considerable amount of time and effort to develop the integration interfaces and services. Additionally, when such a system is upgraded, we would need to modify the integration services.

[ 33 ]

Introduction to BPEL and SOA

Adapters automate this procedure and provide tools to integrate with such systems in an easy way. Examples of adapters are adapters for SAP, Oracle, PeopleSoft, Salesforce, or some other popular system. Adapters are also useful for accessing database data directly. Such adapters automate the development of data services. Examples include adapters for Oracle, DB2, SQL Server, and so on. Adapters differ in the level of sophistication. The simplest adapters are just API wrappers, which expose the interfaces of the external systems as a service (usually a web service). More sophisticated adapters can have smart fault handling mechanisms, can capture events on both sides, allow synchronous and asynchronous interactions, take care of load balancing, performance, scalability, security, and so on. When deploying an SOA platform, it makes sense to check whether it provides adapters for the systems that we have deployed in our information system. With adapters, accessing the functionality of such systems will most likely be much simpler than without.

Service Component Architecture

So far we have seen that SOA applications are composite applications that consist of several components, such as services, BPEL processes, ESB mediation, rules, adapters, and so on. All these components have to work together and support one or more composite applications. Service Component Architecture (SCA) defines a programming model for composite SOA applications. SCA is based on the idea of service composition (orchestration). SCA provides a model for the composition of services and for the creation of service components, including the reuse of existing applications within SCA composites. The basic building blocks of SCA are components. Every SCA application is built from one or more components. Components can be implemented in a programming language such as Java, C++, C, or they can be implemented as BPEL processes. SCA provides a generalized definition of a component. Components offer their business function for use by other components as services. Implementations may depend on services provided by other components. Such dependencies are called references. Implementations can have properties through which the business function can be influenced. The component configures the implementation by providing values for the properties and by wiring the references to services provided by other components. An SCA component is represented like this:

[ 34 ]

Chapter 1

Service components are assembled into applications, called composites. Composites can contain components, services, references, properties, and wiring. Composites themselves can also be used as components and can provide services, they can depend on references and expose properties. Composites can be used within other composites. This allow a hierarchical construction of composite business applications, where high-level services are implemented by sets of lower-level services. The following example shows an SCA composite:

[ 35 ]

Introduction to BPEL and SOA

Composites are deployed within an SCA Domain. An SCA Domain represents an area of business functionality with the related services. The SCA Domain diagram is shown in the next figure:

We will use the SCA and composites in Chapter 4, BPEL Processes with IBM WebSphere, when we will start to develop composite applications.

SOA governance

SOA governance is a set of related activities for exercising control over services and processes in SOA. SOA is a distributed architecture where applications consist of services and processes. The objective of SOA governance is assurance that all services and processes within an information system will adhere to the overall architecture. SOA governance has to address many different aspects, among them: • • • • • • • • •

Services and processes must follow specific guidelines, best practices, and patterns Services should not be duplicated Services are reused and reusable The portfolio of services is managed, including the development of new services and modifications of existing services Versioning of services and processes is defined Service lifecycle is defined Deployment practices are defined Consistency of services is monitored Quality of Services is ensured [ 36 ]

Chapter 1

SOA governance is an essential element of a successful SOA implementation. Without governance, SOA will most likely fail to deliver its value to the stakeholders. To learn more about SOA governance, have a look at: SOA Governance by Todd Biske, Packt Publishing.

Understanding BPEL

The general adoption of business process automation solutions requires a standard foundation and a specialized language for composing services into business processes that provide the ability to express business processes in a standardized way, using a commonly accepted language. BPEL is such a language and is quickly becoming the dominant standard. The main goal of BPEL is to standardize the process of automation between web services. With BPEL, we can define business processes that make use of services and business processes that externalize their functionality as services.

Within enterprises, BPEL is used to standardize enterprise application integration and extend the integration to previously isolated systems. Between enterprises, BPEL enables easier and more effective integration with business partners. BPEL stimulates enterprises to further define their business processes, which in turn leads to business process optimization, re-engineering, and the selection of the most appropriate processes, thus further optimizing the organization. Definitions of business processes described in BPEL do not influence existing systems. BPEL is the key technology in environments where functionalities already are, or will be, exposed via web services. With increases in the use of web service technology, the importance of BPEL will rise further. IBM, BEA, and Microsoft developed the first version of BPEL in August 2002. Since then SAP and Siebel have joined, which has resulted in several modifications and improvements and the adoption of version 1.1 in March 2003. In April 2003, BPEL was submitted to OASIS (Organization for the Advancement of Structured Information Standards) for standardization purposes, where the WSBPEL TC (Web Services Business Process Execution Language Technical Committee) has been formed. Many vendors have joined the WSBPEL TC (http://www.oasis-open. org/committees/tc_home.php?wg_abbrev=wsbpel) since then. This has led to even broader acceptance in industry. In April 2007, BPEL version 2.0 was approved by OASIS after quite a long preparation period.

[ 37 ]

Introduction to BPEL and SOA

BPEL represents a convergence of two early workflow languages, WSFL (Web Services Flow Language) and XLANG. WSFL was designed by IBM and is based on the concept of directed graphs. XLANG was designed by Microsoft and is a block-structured language. BPEL combines both approaches and provides a rich vocabulary for the description of business processes. In this book, we shall use BPEL version 2.0.

BPEL uses an XML-based vocabulary to specify and describe business processes. BPEL version 2.0 utilizes the WSDL 1.1, XML Schema 1.0, XPath 1.0, and XSLT 1.0 specifications. Familiarity with them is helpful for learning BPEL.

BPEL features

With BPEL we can define simple and complex business processes. To a certain extent, BPEL is similar to traditional programming languages. It offers constructs such as loops, branches, variables, assignments, and so on that allow us to define business processes in an algorithmic way. BPEL is a specialized language focused on the definition of business processes. It is an execution language for business processes, not a modeling language. Therefore, on one hand it offers constructs, which makes the definition of processes relatively simple. On the other hand, it is less complex than traditional programming languages, which simplifies learning. The most important BPEL constructs are related to the invocation of services. BPEL makes it easy to invoke operations of services either synchronously or asynchronously. We can invoke operations either in sequence or in parallel. We can also wait for callbacks. BPEL provides a rich vocabulary for fault handling, which is very important, as robust business processes need to react to failures in a smart way. BPEL also provides support for long-running processes and compensation, which allows undoing partial work done by a process that has not finished successfully. Listed below are the most important features that BPEL provides. With BPEL we can: • • • • • •

Describe the logic of business processes through composition of services Compose larger business processes out of smaller processes and services Handle synchronous and asynchronous (often long-running) operation invocations on services and manage callbacks that occur at later times Invoke service operations in sequence or parallel Selectively compensate completed activities in case of failures Maintain multiple long-running transactional activities, which are also interruptible [ 38 ]

Chapter 1

•

Resume interrupted or failed activities to minimize work to be redone

•

Route incoming messages to the appropriate processes and activities

•

Correlate requests within and across business processes

•

Schedule activities based on the execution time and define their order of execution

•

Execute activities in parallel and define how parallel flows merge based on synchronization conditions

•

Structure business processes into several scopes

•

Handle message-related and time-related events

Orchestration and choreography

Depending on the requirements, the composition of services can address private or public processes, for which two terms are used: •

Orchestration

•

Choreography

In orchestration, a central process takes control over the involved services and coordinates the execution of different operations on the services involved in the operation. This is done as per the requirements of the orchestration. The involved services do not know (and do not need to know) that they are involved in a composition and that they are a part of a higher business process. Only the central coordinator of the orchestration knows this, so the orchestration is centralized with explicit definitions of operations and the order of invocation of services. Orchestration is usually used in private business processes and is schematically shown as follows:

[ 39 ]

Introduction to BPEL and SOA

Choreography, on the other hand, does not rely on a central coordinator. Rather, each service involved in the choreography knows exactly when to execute its operations and whom to interact with. Choreography is a collaborative effort focused on the exchange of messages in public business processes. All participants of the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges. Choreography in services composition is as shown in the following figure:

From the perspective of composing services to execute business processes, orchestration has an advantage over choreography. Orchestration is a more flexible paradigm, although the line between orchestration and choreography is vanishing. Orchestration has the following advantages: •

We know exactly who is responsible for the execution of the whole business process

•

We can incorporate services, even those that are not aware that they are a part of a business process

•

We can also provide alternative scenarios when faults occurs

BPEL provides support for orchestration and choreography through executable and abstract business processes.

Executable and abstract processes

With BPEL, we can describe business processes in two distinct ways: •

We can specify the exact details of business processes. Such processes are called executable business processes and follow the orchestration paradigm. They can be executed by an orchestration engine. [ 40 ]

Chapter 1

•

We can specify the public message exchange between parties only. Such processes are called abstract business processes. They do not include the internal details of process flows and are not executable. They follow the choreography paradigm.

Executable business processes are processes that comprise of a set of existing services and specify the exact algorithm of activities and input and output messages. Such processes are executable by BPEL engines. Executable processes are important because they are the direct answer to the problem of business process automation through IT that we have discussed earlier in this chapter. With BPEL executable processes, we are able to specify the exact algorithm of service composition in a relatively simple and straightforward way and execute it on a BPELâ•‚compliant engine. Executable processes fill the gap between the business process specifications and the code responsible for their execution. When we define an executable business process in BPEL, we actually define a new web service that is a composition of existing services. The interface of the new BPEL composite web service uses a set of port types, through which it provides operations like any other web service. To invoke an executable business process, we have to invoke the resulting composite web service. You can see that executable business processes are the most important way of using BPEL. In the majority of cases, BPEL is used to specify executable processes. Abstract business processes, on the other hand, are not executable. They specify public message exchange between parties only—the externally observable aspects of process behavior. The description of the externally observable behavior of a business process may be related to a single service or a set of services. It might also describe the behavior of a participant in a business process. Abstract processes will usually be defined for two scenarios: •

To describe the behavior of a service without knowing exactly in which business process it will take part

•

To define collaboration protocols among multiple parties and precisely describe the external behavior of each party

Abstract processes are rarely used. The most common scenario is to use them as a template to define executable processes. Abstract processes can be used to replace sets of rules usually expressed in natural language, which are often ambiguous. In this book, we will first focus on executable processes and come back to abstract processes in Chapter 3, Advanced BPEL.

[ 41 ]

Introduction to BPEL and SOA

Relation of BPEL to other languages

BPEL is not the only language for business process execution. Before we start discussing the technical aspects of BPEL, let us overview the relation of BPEL to other languages. Recently, several orchestration and choreography languages have been proposed. The most important orchestration languages include: •

XLANG and the new version XLANG/s from Microsoft

•

WSFL from IBM

•

BPML (Business Process Modeling Language) from BPMI.org

•

BPSS (Business Process Specification Schema), part of the ebXML framework

•

YAWL (Yet Another Workflow Language), an Open Source workflow language

The most important choreography languages include: •

WSCL (Web Services Conversation Language) from HP, submitted to W3C

•

WSCI (Web Services Choreography Interface), co-developed by Sun, SAP, BEA, and Intalio and submitted to W3C

•

WS-CDL (Web Services Choreography Description Language), at the time of writing: a W3C Candidate Recommendation

In addition to orchestration and choreography languages, which have primarily been designed to provide machine executable representations of business processes, we also have to mention the business process modeling notations. These are used to define business process models and are essential for BPM (Business Process Management). The most popular and well-known is the BPMN (Business Process Modeling Notation). BPMN is becoming an important part of SOA. The following figure shows a timeline of the mentioned languages, as they have been developed:

[ 42 ]

Chapter 1

We have already mentioned that BPEL represents a convergence of XLANG and WSFL and it shares and further develops the concepts of those languages. In the following sections we will briefly describe these languages.

XLANG

XLANG has been one of the early orchestration languages. It has been developed with the objective of achieving clear separation between processes and implementations. It is a Microsoft proprietary language and not fully documented. It has been used in Microsoft BizTalk. XLANG and its successor XLANG /s can be viewed as messaging languages with some of the expression capabilities of C#. However, code is not portable between XLANG /s and C#. XLANG/s specifies high-level constructs that are used to define and execute business processes. The semantics embodied in XLANG/s are a reflection of those defined in BPEL. Although XLANG is thought of as a predecessor of BPEL, Microsoft continues to use XLANG/s in their BizTalk Server. Instead of moving to BPEL in BizTalk, Microsoft provides a conversion between XLANG/s and BPEL.

WSFL

WSFL is also one of the early XML-based orchestration languages. It has been developed by IBM to be a part of the web services technology stack. WSFL supports two types of service compositions. First is the flow model, which specifies the exact interactions between services (a process). Such a flow model is executable. The second type is the global model, which specifies the overall interaction of services and is abstract. This is very similar to BPEL executable and abstract processes. As we have already mentioned, WSFL has, together with XLANG, provided a basis for BPEL. Unlike Microsoft, IBM has moved to BPEL as their main language for service composition and provides full support for BPEL in their various products, such as IBM WebSphere Process Server.

BPML

BPML has been developed by BPMI.org (Business Process Management Initiative). Intalio has played an important role and has been the initiator of BPML. BPML is a meta-language for modeling business processes and provides an abstract execution model for describing collaborations and transactions. It defines a formal model for expressing abstract and executable processes, and supports: •

Data management

•

Conformity [ 43 ]

Introduction to BPEL and SOA

•

Exception handling

•

Operation semantics

BPML can describe a process in a specific language, defined on top of the extensible BPML scheme. Business processes are defined as groups of flows (control flows, data flows, and event flows). Formatting features, security rules, and transactional contexts can also be defined. BPML offers support for synchronous and asynchronous distributed transactions and can be used for the process components of existing applications. Comparing BPML to BPEL shows that both share similar roots in web services and leverage other web services specifications, particularly WS-Security, WSCoordination, and WS-Transactions. However, BPML supports modeling more complex business processes through its support for advanced semantics such as nested processes and complex compensated transactions. BPML can therefore be regarded as a superset of BPEL. The extensions of BPEL with business rules, task management, human interactions, and so on are defined in BPXL (Business Process Extension Layers). The fact that both BPEL and BPML share the same idioms and have similar syntax has resulted in BPML being discontinued in favor of BPEL. BPEL has over the years gained much broader support by software vendors than BPML.

ebXML BPSS

ebXML (Electronic Business XML) is a framework that provides a set of technologies, BPSS (Business Process Specification Schema) being one of them. ebXML has been developed under the initiative of OASIS and UN/CEFACT and consists of the following technologies: •

Messaging: Uses SOAP with attachments for communication between partners

•

Registry and repository: Similar to UDDI registry, but offers additional functionality through the repository

•

Core Components: Used for construction of business documents

•

CPP (Collaboration Protocol Profile): Used to express a partner profile

•

CPA (Collaboration Protocol Agreement): Used to express an agreement between partners

•

BPSS: Used for the specification of business processes

[ 44 ]

Chapter 1

BPSS covers the same domain as BPEL. The BPSS approach to the process specification follows the choreography pattern and is therefore comparable to abstract BPEL processes. In addition to specifying the process logic, BPSS also specifies the communication protocol details. BPSS is designed around the concept of business transactions, which is, however, not fully conformant with the web services transactions specifications. A BPSS business transaction is used to describe the message exchange between two abstract roles: the sender and the responder. Each message consists of an XML document and optional attachments, which can be XML or binary. For each responding message, we specify whether it is a positive or negative message. Each message is associated with a business transaction protocol. Collaboration in BPSS can be bilateral or multi-party and is described by the business transaction protocol. We can see that BPSS is not a direct alternative to BPEL and is used in environments where ebXML is applied. For more information on ebXML, read the following books: •

ebXML: Concepts and Application by Brian Gibb and Suresh Damodaran, John Wiley & Sons, October 21, 2002, ISBN: 0-7645-4960-X

•

ebXML: The New Global Standard for Doing Business over the Internet by Alan Kotok and David RR Webber, SAMS, August 23, 2001, ISBN: 0-7357-1117-8

•

ebXML Simplified: A Guide to the New Standard for Global Eâ•‚Commerce by Eric Chiu, John Wiley & Sons, June 15, 2002; ISBN: 0-471-20475-7

YAWL

YAWL has been developed by Eindhoven University of Technology and Queensland University of Technology. Subsequently, several companies have contributed to the language. The objective of YAWL has been to develop a language that would support workflow patterns with a formal specification. YAWL is based on Petri nets. The formal semantics of YAWL enables the static analysis of the language, which is supported by a tool. The language itself is supported by software that is developed as an open source under an LGPL license. It includes the execution engine, graphical editor, and an application for human tasks. Similar to BPEL, YAWL is an executable language for processes (workflows). The main advantage of YAWL is its support for workflow patterns. The major difference is how both languages have been developed. BPEL has been driven by a standardization committee under OASIS and has gained large industry support. Today, most major vendors provide support for BPEL. YAWL, on the other hand, has only one implementation. More on YAWL can be found on http://www.yawl-system.com/.

[ 45 ]

Introduction to BPEL and SOA

WSCL

WSCL has been developed by HP. In contrast to previously mentioned languages, WSCL has focused on the choreography aspect rather than on the orchestration. It has been designed to describe business-level conversations or public processes, supported by corresponding services. WSCL specifies the XML documents being exchanged and the allowed sequencing of these document exchanges. WSCL is not a direct alternative to BPEL, as it does not support executable process orchestrations, as BPEL does. It is somehow similar to BPEL abstract processes. HP has submitted WSCL to W3C, where it has become a W3C Note in 2002. Since then it has not gained much support from software vendors and, therefore, WSCL does not play an important role in SOA. The WSCL specification is accessible at http://www.w3.org/TR/wscl10/.

WSCI

WSCI (Web Services Choreography Interface) version 1.0 has been developed by Sun, BEA, SAP, and Intalio. WSCI is a choreography language for describing the flow of messages exchanged by web services in the context of a process. It allows us to describe the observable behavior of a web service in a message exchange. WSCI also describes the collective message exchange among interacting web services, providing a global and message-oriented view of a process involving multiple web services. In WSCI, message exchange is described from the viewpoint of each web service. Each exchange can be qualified by message correlations, transaction descriptions, and location capabilities. WSCI, therefore, describes the observable behavior of web services. However, WSCI does not address the definition of the processes driving the message exchange. It also does not address the definition of the internal behavior of each web service. As WSCI follows the choreography pattern and does not address defining executable business processes, it is compared directly to BPEL abstract processes. WSCI has a cleaner interface, which makes it a little easier to learn than BPEL. The WSCI specification has also been submitted to W3C, which has published it as a W3C Note. Further, W3C has formed a WS-Choreography working group, which will address the choreography of web services, but has only released the requirements specification so far. WSCI has not gained industry support comparable to BPEL. The industry consensus seems to support BPEL. The WSCI specification is accessible at http://www.w3.org/ TR/wsci/.

[ 46 ]

Chapter 1

WS-CDL

WS-CDL is a language for specifying the choreography of collaborating services. It targets the composition of interoperable collaborations between services. With WS-CDL, we can specify the peer-to-peer collaboration of web services through the definition of their observable behavior. We can define sets of rules that define how, and in what order, different services should act together. Such specification provides a flexible systemic view of the process. Its authors position WS-CDL as a complementary language to BPEL (and other business process languages). While BPEL focuses on the behavior specification of a specific business partner, WS-CDL focuses on the description of message interchanges between business partners. WS-CDL provides the global model needed by BPEL processes to ensure that the behavior of endpoints is consistent across all cooperating services. A business partner can use the WS-CDL choreography specification to verify if their internal processes have their outside behavior defined in a way that will allow them to participate in choreography. WS-CDL choreography specifications can be used to generate public interfaces, for example, specified using BPEL abstract processes. WS-CDL specifications are also useful at runtime to verify the execution of message exchange between business partners. As WS-CDL is a complementary language to BPEL, we cannot make a direct comparison. However, WS-CDL differs considerably from BPEL. With WS-CDL, we define the message flows exchanged by all partners, while with BPEL we focus on message flow and the behavior of a specific partner, that is, on the internal behavior of a business process. The WS-CDL description of message flows is done from a general perspective, while BPEL specifies message exchange from the point of view of a specific partner. A BPEL process specifies activities that are executed. WS-CDL specifies reactive rules, which are used by all participants of a collaboration. At the time of writing, WS-CDL has been a W3C Candidate Recommendation, dated 9 November 2005. Since then, WS-CDL has not gained much industry support, as no major vendor supports it. At the time of writing, only two small vendors provided tools. The WS-CDL specification is accessible at http://www.w3.org/TR/ws-cdl-10/.

BPMN

Business Process Modeling Notation (BPMN) is a graphical notation for specifying business processes. It is the most comprehensive notation for process modeling so far. BPMN has initially been developed by the BPMI. In 2005, BPMI merged with OMG (Object Management Group) . The current version of BPMN is 1.2. BPMN version 2.0 is currently a work in progress. [ 47 ]

Introduction to BPEL and SOA

We use BPMN to draw business process diagrams. Such diagrams present the activities and tasks of a process and their relations. The diagram uses flowchart concepts to represent the logic of business processes. BPMN is a graphical-visual language and uses a set of graphical elements. Activities are represented as rectangles and decisions are represented as diamonds. BPMN successfully joins the simplicity of the diagrams with the expressive power, which allows BPMN to be used for complex processes and specification of details. To model the diagrams, BPMN defines four categories of elements: •

Flow objects, which are activities, events, and gateways. Activities can be tasks or subprocesses. Events can be triggers or results. Three types of events are supported: start, intermediate, and end. Gateways control the divergence of sequential flows into concurrent flows and their convergence back to sequential flow.

•

Connecting objects are used to connect together flow objects. Connectors are sequence flows, message flows, and associations.

•

Swim lanes are used to organize activities into visual categories in order to illustrate different responsibilities or functional capabilities. Pools and lanes can be used for swim lanes.

•

Artifacts are used to add specific context to the business processes that are modeled. Data objects are used to show how data is produced or required by the process. Groups are used to group together similar activities or other elements. Annotations are used to add text information to the diagram. We can also define custom artifacts.

BPMN can be used to model parts of processes or whole processes. Processes can be modeled at different levels of fidelity. BPMN is equally suitable for internal (private) business processes and for public (collaborative) business-to-business processes. The most important goals when designing BPMN have been: •

To develop a notation that will be useful and understandable at all levels of BPM. In business process modeling, different people are involved. From business users, business analysts, process owners, to the technical architects and developers. The goal of BPMN has been to provide a graphical notation that is simple to understand, but powerful enough to model business processes into the required details.

[ 48 ]

Chapter 1

•

The semantic gap between the business process models and the information technology (application software) has been quite large with existing technologies. There has been no clear definition of how one relates to the other. The goal of BPMN is to enable automatic transformation into the executable code, into BPEL and vice versa. Therefore, BPMN has been designed specifically to provide such transformation.

Particularly, because of the ability to automatically transform BPMN process models in executable BPEL processes, BPMN today plays an important role in SOA development. Modeling of a business process using BPMN is usually the first step. After the model is complete, such a process is transformed into BPEL to be executed on a process server. Today several tools for major vendors such as Oracle and IBM provide such automatic transformation, usually in both directions, which enables round-tripping between model (BPMN) and executable process representation (BPEL). For more information on BPMN read the following books: •

Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant, Packt Publishing, August 2008, ISBN: 1847191460.

•

BPMN Specification, http://www.bpmn.org/.

BPEL servers overview

BPEL servers provide a run-time environment for executing BPEL business processes. Today BPEL servers are usually part of the SOA platform, which in addition to the BPEL server includes other elements of a complete SOA environment: application server, ESB, registry and repository, human tasks support, process monitoring, BRMS (Rule Engine), and adapters. Often a development environment is also included and sometimes a process modeling tool is also available. Most advanced SOA platforms support the automatic translation of business models into executable BPEL processes. Most SOA platforms have been developed on top of modern software platforms, particularly Java Enterprise Edition and Microsoft .NET. BPEL servers leverage Java Enterprise Edition or .NET application server environments, where they can make use of the services provided by application servers, such as security, transactions, scalability, integration with databases, components such as EJBs (Enterprise Java Beans) and COM+ (Component Object Model), messaging systems such as JMS (Java Message Service) or MSMQ (Microsoft Message Queue), and so on. The most important commercial SOA platforms with BPEL servers are listed as follows: •

IBM WebSphere (WebSphere Process Server) (http://www.ibm.com/ software/solutions/soa/) [ 49 ]

Introduction to BPEL and SOA

• • • •

Oracle SOA Suite (BPEL Process Manager) (http://www.oracle. com/technologies/soa/soa-suite.html) Oracle Sun Java Composite Application Platform Suite (http://

developers.sun.com/javacaps/)

TIBCO ActiveMatrix (ActiveMatrix BusinessWorks) (http://www.tibco.

com/products/soa/default.jsp)

InterSystems Ensemble (http://www.intersystems.com/ensemble/index.

html)

•

Fujitsu Interstage (Business Process Manager) (http://www.fujitsu.com/ global/services/software/interstage/)

•

Hitachi uCosminexus Service Platform (http://www.hitachi.co.jp/Prod/ comp/soft1/global/prod/cosminexus/sol/sp/sp_view.html)

•

Software AG webMethods (http://www.softwareag.com/Corporate/ products/wm/default.asp)

•

Intalio BPM (http://www.intalio.com/products/bpm/)

•

Fiorano SOA Platform (http://www.fiorano.com/products/fsoa/ products_fioranosoa.php)

•

Active Endpoints ActiveVOS (http://www.activevos.com/)

•

OpenLink Virtuoso Universal Server (http://virtuoso.openlinksw.com/)

• •

Parasoft BPEL Maestro (http://www.parasoft.com/jsp/products/home.

jsp?product=BPEL)

PolarLake Integration Suite (http://www.polarlake.com/)

Microsoft also provides an SOA platform, although Microsoft does not use the acronym SOA as often as the other suppliers. Microsoft's SOA is built around Windows Workflow Foundation, Windows Communication Foundation, and Microsoft BizTalk (process server). In contrast to most of the other vendors, Microsoft does not support BPEL natively (yet). Microsoft BizTalk at the time of writing still uses XLANG/s, the Microsoft proprietary orchestration language. However, it allows the import and export of BPEL. An important supporter of SOA is SAP. SAP Enterprise Service-Oriented Architecture (Enterprise SOA) has been defined by SAP as an open architecture for adaptive business solutions. Enterprise SOA is enabled by the SAP NetWeaver platform. SAP has positioned Enterprise SOA to deliver the benefits offered by service-oriented architecture, including enabling both flexibility and business efficiency. Most of SAP products, such as mySAP ERP, mySAP CRM, and mySAP SRM, are built upon Enterprise SOA. [ 50 ]

Chapter 1

There are also a few open source implementations: •

JBoss Enterprise SOA Platform (Red Hat) (http://www.jboss.com/

products/platforms/soa/)

•

Open ESB (https://open-esb.dev.java.net/)

•

ActiveBPEL Engine (http://www.activebpel.org/)

•

bexee BPEL Execution Engine (http://sourceforge.net/projects/bexee)

•

Apache Agila (http://wiki.apache.org/agila/), formerly known as Twister

In the following chapters, we will use IBM WebSphere SOA platform, including WebSphere Process Server, WebSphere Integration Developer, and WebSphere Business Modeler. Please remember that BPEL is an open specification; therefore, it does not differ between the products. BPEL code is portable between different BPEL servers. This holds true as long as you are not using some vendor-specific extensions. Therefore, in the next chapters we will first look at standard BPEL. Then, we will look at how to use BPEL using IBM WebSphere.

The future of BPEL

OASIS has been responsible for the further development of BPEL since April 2003. An OASIS Technical Committee, called WSBPEL TC, has been formed for the development of a new BPEL version, called WS-BPEL 2.0. The technical committee, which supervises and influences further development of BPEL, has many new members. This ensures that BPEL will be extended with new features and also ensures continuity of development. The number of participants involved in BPEL shows that industry support is large and still increasing. More information on WSBPEL TC can be found at http://www.oasis-open.org/committees/tc_home. php?wg_abbrev=wsbpel.

[ 51 ]

Introduction to BPEL and SOA

Summary

In this chapter, we have become familiar with BPEL, its role in the SOA, and basic concepts related with service composition and the definition of business processes. BPEL provides a rich vocabulary for defining processes and has several features not found in programming languages. This makes BPEL the preferred choice for the composition of services. Major software vendors support BPEL and open source implementations exist. Based on the comparison with other technologies and languages, we have seen that BPEL plays an important role in service composition. BPEL fits very well into the SOA and with BPEL and we can define executable business processes and abstract business processes. Executable processes are the most important and allow us to define the exact order in which services are composed. In the next chapter, we will look at BPEL and learn how to define a BPEL process.

[ 52 ]

Service Composition with BPEL In this chapter, we will get familiar with BPEL concepts and discuss composing services with BPEL. We will look at how to develop executable business processes. In a nutshell, we will: •

Discuss service composition with BPEL

•

Explain how business processes are defined in BPEL

•

Get familiar with core concepts including:

•

°Â°

The structure of BPEL process definitions

°Â°

Invoking services

°Â°

Synchronous and asynchronous processes

°Â°

Partner links

°Â°

The role of WSDL

°Â°

Important activities and other constructs

Define an example BPEL process

Service Composition with BPEL

Developing business processes with BPEL

BPEL uses an XML-based vocabulary that allows us to specify and describe business processes. BPEL is a programming language. Most development environments that support BPEL, such as IBM WebSphere Integration Developer, Oracle JDeveloper, or Eclipse usually provide a visual editor, where we can compose BPEL processes by dragging and dropping the BPEL activities in a visual way. However, the majority of tools also allow a switch to the source view, where you can enter the BPEL code directly. A BPEL visual representation is generated out of BPEL code. In this chapter, we will look at the BPEL code. With BPEL, you can describe business processes in two distinct ways: •

Executable business processes: This specifies the exact details of business processes and can be executed by a BPEL process server. In the majority of cases, we will use BPEL to specify executable processes.

•

Abstract business processes: This specifies process templates or public message exchange between parties, without including the specific details of process flows. They are not executable and are rarely used.

This chapter focuses on executable business processes. Abstract business processes are covered in the next chapter. Executable business processes are processes that consist of a set of services. When we describe a business process in BPEL, we actually define a new service that is a composition of existing services. The interface (WSDL) of the new BPEL composite service uses a set of port types, through which it provides operations like any other service. To invoke a business process described in BPEL, we must invoke the resulting composite service. In a typical scenario, the BPEL business process receives a request. To fulfill it, the process then invokes the involved services and finally responds to the original caller. Because the BPEL process communicates with other services, it relies heavily on the WSDL description of the services invoked by the composite BPEL service. Anyone developing BPEL processes requires a good understanding of WSDL and other related technologies. BPEL introduces WSDL extensions, which enable us to accurately specify relations between several services in the business process. These relations are called partner links. The following figure shows a BPEL process and its relation to services (partner links):

[ 54 ]

Chapter 2

Any BPEL process specifies the exact order in which participating services should be invoked. This can be done sequentially or in parallel. With BPEL, we can express conditional behavior. For example, a service invocation can depend on the value of a previous invocation. We can also construct loops, declare variables, copy and assign values, define fault handlers, and so on. By combining all these constructs, we can define complex business processes in an algorithmic manner. We can describe deterministic as well as non-deterministic flows. Because business processes are essentially graphs of activities, it is sometimes useful to express them using a modeling notation, such as BPMN (Business Process Modeling Notation) or UML (Unified Modeling Language) activity diagrams. BPEL is not a modeling language for processes, but an execution language for processes and orchestration of services. To understand how business processes are defined in BPEL, we look at the core concepts in the next section.

Core concepts

A BPEL process consists of steps. Each step is called an activity. BPEL supports basic and structured activities. Basic activities represent basic constructs and are used for common tasks. The following shows the list of common tasks: •

Invoking other web services, using

•

Waiting for the client to invoke the business process through sending a message, using (receiving a request)

•

Generating a response for synchronous operations, using

•

Manipulating data variables, using [ 55 ]

Service Composition with BPEL

•

Indicating faults and exceptions, using

•

Waiting for some time, using

•

Terminating the entire process, using

We can then combine these and other basic activities and define complex flows that exactly specify the steps of a business process. To combine basic activities, BPEL supports several structured activities. The most important are: •

Sequence () for defining a set of activities that will be invoked in an ordered sequence

•

Flow () for defining a set of activities that will be invoked in parallel

•

Conditional construct () for implementing branches

•

While, repeat, and for each (, , and ) for defining loops

•

The ability to select one of a number of alternative paths, using

Each BPEL process will also define partner links, using and declare variables, using . To provide an idea of how a BPEL process looks, the following example shows a very simple BPEL process, which selects the best insurance offer from several. We first declare the partner links to the BPEL process client (called client) and two insurance services (called insuranceA and insuranceB): [ 56 ]

Chapter 2

Next, we declare variables for the insurance request (InsuranceRequest), insurance A and B responses (InsuranceAResponse, InsuranceBResponse), and for the final selection (InsuranceSelectionResponse):

Finally, we specify the process steps. First we wait for the initial request message from the client (). Then we invoke both insurance services () in parallel, using the activity. The insurance services return the insurance premium. Then we select the lower amount () and return the result to the client (the caller of the BPEL process) using the activity: [ 57 ]

Service Composition with BPEL $InsuranceAResponse.confirmationData/ins:Amount <= $InsuranceBResponse.confirmationData/ins:Amount

In the coming sections, we will explain the different parts of the BPEL process and the syntax of various BPEL activities. As BPEL processes are exposed as services, we need a WSDL for the BPEL process.

As each BPEL process is a service, each BPEL process needs a WSDL document too. This is more or less obvious. As mentioned, a client will usually invoke an operation on the BPEL process to start it. With the WSDL process of BPEL, we specify the interface for this operation. We also specify all message types, operations, and port types a BPEL process offers to other partners. We will show WSDL for the BPEL process later in this chapter. [ 58 ]

Chapter 2

Invoking services

A BPEL process definition is written as an XML document using the root element. Within the element, a BPEL process will usually have the toplevel element. Within the , the process will first wait for the incoming message to start the process. This wait is modeled with the construct. Then the process will invoke the related services, using the construct. Such invocations can be done sequentially or in parallel. If we want to make them sequential, we simply write an for each invocation and the services will be invoked in that order. This is shown in the following code excerpt: ... /> /> />

Here we have not shown the full syntax of , , and other activities, which require that we specify certain attributes. This is explained later in this chapter, after we have become familiar with the basic structure of BPEL documents. To invoke services concurrently, we can use the construct. In the following example, the three operations would perform concurrently: ... ...

[ 59 ]

Service Composition with BPEL

We can also combine and nest the and constructs, which allows us to define several sequences executing concurrently. In the following example, we have defined two sequences—one consisting of three invocations and one with two invocations. Both sequences would execute concurrently: ... ...

Invoking asynchronous services

We just explained how to invoke synchronous service operations. There are actually two major types of service operations: •

Synchronous request/reply service operations: Here we send a request and wait for the reply. Such operations usually do not require much time to process. Therefore, it is reasonable for the sender (client) to wait for the reply. They are shown in the following figure:

[ 60 ]

Chapter 2

•

Asynchronous service operations: Usually, such operations perform processing that requires a longer time to finish. Therefore, they do not block the sender for the duration of the operation. If such operations require that results are sent back to the client, they usually perform callbacks. This is shown in the following figure:

Callbacks usually need to be related to original requests. We call this message correlation. Message correlation can be achieved automatically with WS-Addressing, or with BPEL correlation sets, which will be explained in Chapter 3, Advanced BPEL. Using the construct, we can invoke both types of operations: synchronous and asynchronous. If we invoke a synchronous operation, the business process waits for the reply. We do not need to use an explicit construct to retrieve the reply. With asynchronous operations, only takes care of the first part—the operation invocation. To receive a result (if one is returned to the client), we need to use a separate construct—. With , the business process waits for the incoming message. Between the and , we could do some other processing instead of waiting for the reply, as is the case with synchronous operations. The following code excerpt shows how to invoke asynchronous operations: ...

[ 61 ]

Service Composition with BPEL

Just like synchronous operations, we can use asynchronous / pairs within to perform several concurrent invocations.

Synchronous/asynchronous business processes

We have already mentioned that the BPEL-modeled business process is exposed as a service. The BPEL process itself can be synchronous or asynchronous. A synchronous BPEL process returns a response to the client immediately after processing and the client is blocked for the whole duration of the BPEL process execution. An asynchronous BPEL process, on the other hand, does not block the client. To return a result to the client, an asynchronous process uses a callback, similar to any other service. However, it is not required that such a BPEL process returns a response. This brings us to the conclusion that the type of BPEL process we choose is very important. Most real-world processes are long running, so we model them as asynchronous. However, there may also be processes that execute in a relatively short time or processes where we want the client to wait for completion. We model such processes as synchronous. How do synchronous and asynchronous processes differ in the BPEL specification? We know that both first wait for the initial message, using a . Both also invoke other services, either synchronously or asynchronously. However, a synchronous BPEL process will return a result after the process has completed. Therefore, we use a construct at the end of the process, as shown in the following excerpt: ...

An asynchronous BPEL process does not use the clause. If such a process has to send a reply to the client, it uses the clause to invoke the callback operation on the client's port type. Remember that an asynchronous BPEL process does not need to return anything. [ 62 ]

Chapter 2 ...

We will come back to the , , and activities a little later to describe the whole syntax, including the necessary attributes. First, however, we have to introduce the concept of partner links and partner link types.

Understanding links to partners

From what we have discussed until now, we can see that BPEL processes interact with external services in two ways: •

The BPEL process invokes operations on other services.

•

The BPEL process receives invocations from clients. One of the clients is the user of the BPEL process, who makes the initial invocation. Other clients are services, for example, those that have been invoked by the BPEL process, but make callbacks to return replies.

Links to all parties BPEL interacts with are called partner links. Partner links can be links to services that are invoked by the BPEL process. These are sometimes called invoked partner links. Partner links can also be links to clients and can invoke the BPEL process. Such partner links are sometimes called client partner links. Note that each BPEL process has at least one client partner link, because there has to be a client that first invokes the BPEL process. Usually a BPEL process will have at least one invoked partner link, because it will be most likely to invoke at least one service. The process invokes other services using the activity, where it has to specify the operation name and the port type used for invocation, as we will see later. Invoked partner links may, however, become client partner links—this is usually the case with asynchronous services, where the process invokes an operation. Later the service (partner) invokes the callback operation on the process to return the requested data.

[ 63 ]

Service Composition with BPEL

BPEL treats clients as partner links for two reasons: •

The most obvious reason is support for asynchronous interactions. In asynchronous interactions, the process needs to invoke operations on its clients. This is used for modeling asynchronous BPEL processes. Such processes also invoke the callback on the initial caller, as mentioned in the previous section.

•

The second reason is based on the fact that the BPEL process can offer services. These services, offered through port types, can be used by more than one client. The process may wish to distinguish between different clients and offer them only the functionality they are authorized to use. For example, an insurance process might offer a different set of operations to car-insurance clients than to real-estate insurance clients.

To sum up, partner links describe links to partners, where partners might be: •

Services invoked by the process

•

Services that invoke the process

•

Services that have both roles—they are invoked by the process and they invoke the process

We have already described the first two scenarios. Let us now have a closer look at the third scenario—a typical asynchronous callback. Here a service offers a portType A, through which the BPEL process invokes the operations on that service. The BPEL process also has to provide a portType through which the service invokes the callback operation—let us call that portType B. This is shown in the following figure:

From the viewpoint of the BPEL process, the process requires portType A on the service and provides portType B to the service. From the perspective of the service, the service offers portType A to the BPEL process and requires portType B from the process.

[ 64 ]

Chapter 2

Partner link types

Describing situations where the service is invoked by the process, and vice versa, requires selecting a certain perspective. We can select the process perspective and describe the process as requiring the portType A on the service and providing the portType B to the service. Alternatively, we select the service perspective and describe the service as offering portType A to the BPEL process and requiring portType B from the process. To overcome this limitation, BPEL introduces partner link types. They allow us to model such relationships as a third party. We are not required to take a certain perspective; rather, we just define roles. A partner link type must have at least one role and can have at most two roles. The latter is the usual case. For each role, we must specify a portType that is used for interaction. A partner link type declares how two parties interact and what each party offers.

In the following example, we define a partnerLinkType called insuranceLT. It defines two roles, the insuranceService and the insuranceRequester. The insuranceService offers the ComputeInsurancePremiumPT port type from the namespace ins, qualified by the corresponding URI (the namespace declarations are not shown here). The insuranceRequester offers the ComputeInsurancePremiumCallbackPT port type from the com namespace. As the name implies, the latter port type is used for the callback operation. The following declaration specifies the service and the callback roles:

Sometimes, we may not need to specify two roles. A typical example is when we use synchronous request/response operations. If the operations in the ComputeInsurancePremiumPT port type returned results immediately, there would be no need for a callback. We would only need a single role:

[ 65 ]

Service Composition with BPEL

If we specify only one role, we express willingness to interact with the service, but do not place any additional requirements on the service. In the first example, however, where we have specified two roles, we require that the insurance service supports the ComputeInsurancePremiumCallbackPT port type. It is important to understand that the partner link types are not part of the BPEL process specification document. This is reasonable, because partner link types belong to the service specification and not the process specification. They can, therefore, be placed in the WSDL document that describes the partner service or the BPEL process. Partner link types use the WSDL extensibility mechanism, so they can be a part of a WSDL document. The following is a skeleton of the WSDL document with the partnerLinkType section. It specifies types, messages, port types, and partner link types. It does not, however, show the bindings and the service sections, because the BPEL execution environment usually automatically generates these: ... ... [ 66 ]

Chapter 2 ...

Sometimes, existing services will not define a partner link type. Then we can wrap the WSDL of the service and define partner link types ourselves.

Now that we have become familiar with the partner link types and know where to place their declarations, it is time to go back to the BPEL process definition, more specifically to the partner links.

Defining partner links

We have already described the role of partner links in BPEL process specifications. However, we have not yet explained how to define partner links, because we first have to get familiar with partner link types. Partner links are concrete references to services that a BPEL business process interacts with. They are specified near the beginning of the BPEL process definition document, just after the tag. Several definitions are nested within the element: ... ... [ 67 ]

Service Composition with BPEL

For each partner link, we have to specify: •

name: This serves as a reference for interactions through the partner link.

•

partnerLinkType: This defines the type of the partner link.

•

myRole: This indicates the role of the BPEL process itself.

•

partnerRole: This indicates the role of the partner.

•

initializePartnerRole: This indicates whether the BPEL engine should

initialize the partner link's partner role value. This is an optional attribute and should only be used with partner links that specify partner role.

We define both roles (myRole and partnerRole) only if the partnerLinkType specifies two roles. If the partnerLinkType specifies only one role, the partnerLink also has to specify only one role—we omit the one that is not needed. Let us go back to our previous example, where we have defined the insuranceLT partner link type. To define a partnerLink called insurance, characterized by the insuranceLT partnerLinkType, we need to specify both roles, because it is an asynchronous relation. The role of the BPEL process (myRole) is described as insurance requester and the partner role is described as insurance service. The definition is shown in the following code excerpt:

BPEL process tag

Now that we are more familiar with BPEL, let us focus on the tag. This delimits the root element of the BPEL document. The tag requires that we specify certain attributes. We have to specify at least the following: • • •

name: This specifies the name of the BPEL business process targetNamespace: This specifies the target namespace for the business

process definition

xmlns: The namespace used by BPEL is http://docs.oasis-open.org/ wsbpel/2.0/process/executable

[ 68 ]

Chapter 2

Usually, we also specify one or more additional namespaces to reference other involved namespaces, for example, those used by services. Here is a typical process declaration tag:

We can also specify additional attributes for the tag, including: •

queryLanguage: This specifies which query language is used for node

selection in assignments, properties, and other uses. The default is XPath 1.0 (urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0). However, another language can be specified, such as XPath 2.0 or XQuery. The available options are determined by what is supported by a given BPEL engine.

• expressionLanguage: This specifies which expression language is used in the process. The default is XPath 1.0 (urn:oasis:names:tc:wsbpel:2.0:su blang:xpath1.0). •

suppressJoinFailure: This determines whether to suppress join failures (yes or no). The default is no. Join failures are explained in Chapter 3.

•

exitOnStandardFault: This defines how the process should behave when a standard fault occurs. We can specify yes if we want the process to exit on a standard fault (other than bpel:joinFailure), or no if we want to handle the fault using a fault handler. The default is no.

Variables

BPEL business processes model the exchange of messages between involved services. Messages are exchanged as operations are invoked. When the business process invokes an operation and receives the result, we often want to store that result for subsequent invocations, use the result as it is, or extract certain data. BPEL provides variables to store and maintain the state. Variables are used to store messages that are exchanged between business process partners or to hold data that relates to the state of the process.

[ 69 ]

Service Composition with BPEL

Variables can also hold data that relates to the state of the process, but will never be exchanged with partners. Specifically, variables can store WSDL messages, XML Schema elements, or XML Schema simple types. Each variable has to be declared before it can be used. When we declare a variable, we must specify the variable name and type. To specify type, we have to specify one of the following attributes: •

messageType: A variable that can hold a WSDL message

•

element: A variable that can hold an XML Schema element

•

type: A variable that can hold an XML Schema simple type

The declaration of variables is gathered within the element. The following example shows three variable declarations. The first one declares a variable with the name InsuranceRequest, which holds WSDL messages of type ins:InsuranceRequestMessage. The second declaration defines a variable PartialInsuranceDescription that can hold XML elements of type ins:InsuranceDescription. The last variable declaration is for variable LastName, which can hold XML Schema string type data. The first two declarations assume that the corresponding messageType and element have been declared in the WSDL (these declarations are not shown here):

You can declare variables globally at the beginning of a BPEL process declaration document or within scopes. Here we focus on globally declared variables and discuss scopes in the next chapter. The following example shows the structure of a BPEL process that uses variables: ... ... [ 70 ]

Chapter 2 ...

Providing the interface to BPEL processes—, , and

At the beginning of this section, we became familiar with the , , and activities. With , the BPEL process invokes operations on other services, while with , it waits for incoming messages (that is, operation invocations). With , the business process usually waits for the initial message to start the process. Another typical use of is to wait for callbacks. With , a BPEL process can send a response, if the process is modeled as synchronous. All three activities use the same three basic attributes: •

partnerLink: This specifies which partner link will be used.

•

portType: This specifies the used port type.

•

operation: This specifies the name of the operation to invoke (), to wait to be invoked (), or the name of the operation which has been invoked but is synchronous and requires a reply (). For each BPEL activity, we can specify a name attribute. We use the name attribute to provide names for activities. In most BPEL activities, the name attribute is optional, but we can add it to improve the readability of the code.



The operation supports two other important attributes. When the business process invokes an operation on the service, it sends a set of parameters. These parameters are modeled as input messages with services. To specify the input message for the invocation, we use the inputVariable attribute and specify a variable of the corresponding type. If we invoke a synchronous request/response operation, it returns a result. This result is again a message, modeled as an output message. To store it in a variable, provides another attribute, called the outputVariable.

[ 71 ]

Service Composition with BPEL

The following code excerpt shows an example of the clause. We specify that the BPEL process should invoke the synchronous operation ComputeInsurancePremium on port type ins:ComputeInsurancePremiumPT using the insuranceA partner link, providing the input from variable InsuranceRequest and storing output in the InsuranceAResponse variable.



Let us now take a closer look at the activity. We have said that waits for the incoming message (operation invocation), either for the initial activity to start the BPEL process, or for a callback. Usually, the business process needs to store the incoming message and it can use the variable attribute to specify a suitable variable. Another attribute for activity is the createInstance attribute, which is related to the business process lifecycle and instructs the BPEL engine to create a new instance of the process. Usually, we specify the createInstance="yes" attribute with the initial activity of the process to create a new process instance for each client. We will discuss this attribute in more detail in the next chapter. Another optional attribute for activity is messageExchange, which is used to disambiguate the relationship between inbound message activities and activities. We will discuss message exchange in Chapter 3. The following example shows a activity that waits for the SelectInsurance operation on port type com:InsuranceSelectionPT using the client partner link. Because this is the initial activity, the createInstance attribute is used. The client request is stored in the InsuranceRequest variable:

[ 72 ]

Chapter 2



Finally, let us look at the clause. As we already know, is used to return the response for synchronous BPEL processes. is always related to the initial activity through which the BPEL process started. Using , we can return the answer, which is the normal usage, or we can return a fault message. Returning a fault message using is discussed in Chapter 3. We can also specify a message exchange. When we use to return a response for a synchronous process, we have to define only one additional attribute—the name of the variable where the response is stored. The following example shows a reply on an initial receive operation. It uses the client partner link and provides a response for the SelectInsurance operation on ins:InsuranceSelectionPT port type. The return result is stored in the InsuranceSelectionResponse variable. Please notice that the same partnerLink, portType, and operation name have been used in the initial clause:

The three activities, , , and support additional functionality. They all support correlations and also supports fault handlers and compensation handlers. We will discuss these in Chapter 3.

Assignments

The variables in the business process hold and maintain the data. We used variables in , , and to specify the input and output messages for invoking operations on partner services. In this section, we get familiar with how to copy data between variables. To copy data between variables, expressions, and partner link endpoint references, BPEL provides the activity. Within it, we can perform one or more commands. For each command, we have to specify the source () and the destination (). The following is the syntax of an assignment: [ 73 ]

Service Composition with BPEL ...

There are several choices for the and clauses. To copy values from one variable to the other, we have to specify the variable attribute in the and elements. This is shown in the following example, where we have copied a value from the InsuranceAResponse variable to the InsuranceSelectionResponse variable:

This copy can be performed only if both variables are of same type, as in our example ins:InsuranceResponseMessage, or if the source type is a subtype of the destination type. Variables can be of three types: •

WSDL message types

•

XML Schema elements

•

XML Schema primitive types

If a variable holds a WSDL message, which is common, we can further refine the copy by specifying the part of the message we would like to copy. WSDL messages consist of parts (more on WSDL can be found at http://www.w3.org/TR/wsdl). The following presents a simple message (defined in the WSDL document) that consists of two parts—the insuredPersonData part and the insuranceDetails part. Both parts are specified with the corresponding XML Schema complex types (not shown here):

Now suppose that we get a variable of type ins:InsuredPersonDataType from invoking another service, which has the following message declaration in its WSDL and uses the same namespace:

[ 74 ]

Chapter 2

Our BPEL process would declare two variables, InsuranceRequest and InsuredPersonRequest, with the following declaration:

Now, we could perform a copy from the InsuredPersonRequest variable to the insuredPersonData part of the InsuranceRequest variable, using the following assignment:

We could also perform a copy in the opposite direction. In addition to specifying the part, we can also specify the exact path to the element we require. To specify the path, we have to write a query, using the selected query language specified within the tag.

The default query language is XPath 1.0.

In our previous example, suppose the ins:InsuredPersonData is defined as follows: [ 75 ]

Service Composition with BPEL

We could perform a copy from the LastName variable to the InsuranceRequest variable, to the message part insuredPersonData, to the last name: ins:LastName

The location path must select exactly one node. We can also use the activity to copy expressions to variables. Expressions are written in the selected expression language. We specify the expression within the element. The following example shows how to copy a constant string to the LastName variable: string('Juric')

We are not restricted to such simple expressions. We can use any valid XPath 1.0 expressions (or the expressions of the selected expression language). For more information, refer to the XPath 1.0 specification: http://www.w3.org/TR/xpath. Another possibility is to copy a literal XML complex element to the InsuredPersonRequest variable. In this case, we can specify the source XML directly: Matjaz B. Juric Ptuj 30 [ 76 ]

Chapter 2

We can specify two optional attributes for the activity: •

•

keepSrcElementName: This specifies whether the element name of the

destination will be replaced by the element name of the source. The default is no. ignoreMissingFromData: This specifies whether the BPEL engine should ignore missing data in the part of the copy assignment (and not raise a fault). The default is no.

We can also specify an optional attribute for the activity: validate: If set to yes, the assign activity will validate all variables being modified by the . The default is no.

Validating variables

Sometimes, particularly after assignments (if we did not use validation in assignments), it makes sense to validate the variables against their associated XML Schemas and WSDL definitions. We can validate the variables explicitly using the activity. It is very simple to validate variables. We just have to list all variable names that we would like to validate. We separate the variable names with a space. The syntax is as follows:

For example, if we would like to validate variables InsuredPersonRequest, InsuranceRequest, and PartialInsuranceDescription, we would write the following:

Accessing variables in expressions

We can access BPEL variables from XPath expressions. This is particularly useful in assignments, where we would like to access specific nested elements. We access BPEL variables in XPath using the $ operator. We will look at the three types of variables (variables can be of a messageType, element, or type). [ 77 ]

Service Composition with BPEL

Let us first look at messageType variables. Let us assume that we have the following definition of a variable:

Where the WSDL message and the corresponding XML Schema will look like the following:

We can access such a variable from XPath in the following way: $variableName.messagePart/ns:node/ns:node…

For example, if we would like to access the LastName from the InsuredPersonRequest variable, we would need to write: $InsuredPersonRequest.insuredPersonData/ins:LastName

Let us now look at an example, where the variable contains an XML element. Let us assume that we have the following definition of a variable:

Where the XML Schema looks like the following: [ 78 ]

Chapter 2

We can access such variables from XPath in the following way: $variableName/ns:node/ns:node…

For example, if we would like to access the Description from the PartialInsuranceDescription variable, we would need to write: $PartialInsuranceDescription/ins:Description

Finally, let us look at an example where the variable contains an XML type. Let us assume that we have the following definition of a variable:

Where the XML Schema looks like the following:

We can access such a variable from Xpath in the following way: $variableName/ns:node/ns:node…

For example, if we would like to access the Street from the Address variable, we would write: $Address/ins:Street

[ 79 ]

Service Composition with BPEL

XSLT transformations

Using the assignments to copy data from one variable to another is useful. However, if we deal with complex XML Schemas and have to perform transformations between different schemas, using the construct alone would be very time consuming. A much better approach would be to use XSLT transformations. The activity provides support for XSLT transformations. We can invoke an XSLT transformation from an assignment using the bpel:doXslTransform() function. The bpel:doXslTransform() is an XPath extension function. The following is the syntax: bpel:doXslTransform('style-sheet-URI', node-set, ('xslt-parameter', value)*)

The first parameter is the URI that points to the XSLT stylesheet. We have to provide a string literal and cannot use a variable here, because the BPEL server has to statically analyze the XSLT stylesheet. The second parameter is the node set on which the XSLT transformation should be performed. Here, we provide an XPath expression. In most cases, we will provide a variable (as described in the previous section). Optionally, we can specify XSLT parameters (if our XSLT stylesheet requires parameters). We always specify parameters in pairs, first the name of the parameter, then the value. The value can be an XPath expression (for example a BPEL variable). We can specify several pairs of parameters. For example, we can use an XSLT transformation to transform the data stored in the PersonData variable and copy the result of the transformation to the InsuredPersonRequest variable: bpel:doXslTransform("http://packtpub.com/xslt/person.xsl", $PersonData)

[ 80 ]

Chapter 2

Conditions

We have to get familiar with one more construct before we are ready to start developing our BPEL processes. In a business process specification, we usually have to make choices based on conditions. In BPEL, conditional branches are defined with the activity. The activity can have several branches and one branch. The following example shows the structure of the activity: boolean-expression boolean-expression boolean-expression ...

The Boolean expressions for elements are expressed in the selected query language. Since the default query language is XPath 1.0, we can use any valid XPath expression that returns a Boolean value. Variables are usually used in conditions. We access variables in conditions in the same way as in assignments. We have described it in the previous section. Let us define a conditional branch, based on the age of the insured person. Suppose we want to make three different activities, based on the ages from [0, 25], [26, 50], and [51 and above]. The BPEL would look like this: $InsuranceRequest.insuredPersonData/ins:Age > 50 $InsuranceRequest.insuredPersonData/ins:Age > 25 [ 81 ]

Service Composition with BPEL

Activity names

For each BPEL activity, such as , , , , and so on, we can specify a name by using the name attribute. This attribute is optional and can be used with all basic and structured activities. For instance, the Employee Travel Status web service invocation activity could be named EmployeeTravelStatusSyncInv. This is shown in the following code excerpt. We will see that naming activities is useful on several occasions; for example, when invoking inline compensation handlers or when synchronizing activities:

Activity names also improve the readability of BPEL processes.

Documentation

To include documentation in the BPEL code, we can use the construct. We can add this construct to any BPEL activity. For example, we could add: [ 82 ]

Chapter 2

Now, we know enough to start writing BPEL business process definitions. In the next section, we will write a sample BPEL business process to get familiar with using the core concepts.

BPEL business process example

To demonstrate how business processes are described with BPEL, we will define a simple business process for business travels. Let us consider the business travel process. We describe an oversimplified scenario, where the client invokes the business process, specifying the name of the employee, the destination, the departure date, and the return date. The BPEL business process first checks the employee travel status. We will assume that a service exists through which such a check can be made. Then the BPEL process will check the price for the flight ticket with two airlines: American Airlines and Delta Airlines. Again, we will suppose that both airline companies provide a service through which such checks can be made. Finally, the BPEL process will select the lower price and return the travel plan to the client. For the purpose of this example, we first build a synchronous BPEL process, to maintain simplicity. This means that the client will wait for the response. Later in this chapter, we modify the example and make the BPEL process asynchronous. We will assume that the service for checking the employee travel status is synchronous. This is reasonable, because such data can be obtained immediately and returned to the caller. To acquire the plane ticket prices, we use asynchronous invocations. Again, this is reasonable, because it might take a little longer to confirm the plane travel schedule. We assume that both airlines offer a service and that both web services are identical (provide equal port types and operations). This assumption simplifies our example. In real-world scenarios, you will usually not have the choice about the services, but will have to use whatever services are provided by your partners. If you have the luxury of designing the web services along with the BPEL process, consider which is the best interface. Usually, we use asynchronous services for long-lasting operations and synchronous services for operations that return a result in a relatively short time. If we use asynchronous services, the BPEL process is usually asynchronous as well.

[ 83 ]

Service Composition with BPEL

In our example, we first develop a synchronous BPEL process that invokes two asynchronous airline web services. This is legal, but not recommended in real-world scenarios as the client may have to wait for an arbitrarily long time. In the real world, the solution would be to develop an asynchronous BPEL process, which we will cover later in this chapter.

We invoke both the Airlines' web services concurrently and asynchronously. This means that our BPEL process will have to implement the callback operation (and a port type), through which the airlines will return the flight ticket confirmation. Finally, the BPEL process returns the best airline ticket to the client. In this example, to maintain simplicity, we will not implement any fault handling, which is crucial in real-world scenarios. This topic is discussed in the next chapter. Let's start by presenting the BPEL process activities using a UML activity diagram. In each activity, we have used the stereotype to indicate the BPEL operation used:

[ 84 ]

Chapter 2

Although the presented process might seem very simple, it will offer a good start for learning BPEL. To develop the BPEL process, we will go through the following steps: •

Get familiar with the involved services

•

Define the WSDL for the BPEL process

•

Define partner link types

•

Define partner links

•

Declare variables

•

Write the process logic definition

[ 85 ]

Service Composition with BPEL

Involved services

Before we can start writing the BPEL process definition, we have to get familiar with all services invoked from our business process. These services are sometimes called partner services. In our example, three services are involved: •

The Employee Travel Status service

•

The American Airlines service

•

The Delta Airlines service The two airline services (namely, the American Airlines service and the Delta Airlines service) share equal WSDL descriptions.

The services used in this example are not real, so we will have to write WSDLs and even implement them to run the example. In real-world scenarios, we would obviously use real web services exposed by partners involved in the business process. The services and the BPEL process example can be downloaded from http://www.packtpub.com. The example runs on the IBM WebSphere Process Server.

Web services' descriptions are available through WSDL. WSDL specifies the operations and port types that web services offer, the messages they accept, and the types they define. We will now look at both web services.

Employee Travel Status service

Understanding the services that a business process interacts with is crucial to writing the BPEL process definition. Let's look into the details of our Employee Travel Status service. It provides the EmployeeTravelStatusPT port type through which the employee travel status can be checked using the EmployeeTravelStatus operation. The operation will return the travel class an employee can use: economy, business, or first. This is shown in the following figure:

[ 86 ]

Chapter 2

The operation is a synchronous request/response operation as we can see from the WSDL: ...

The EmployeeTravelStatus operation consists of an input and an output message. To maintain simplicity, the fault is not declared. The definitions of input and output messages are also a part of the WSDL:

The EmployeeTravelStatusRequestMessage message has a single part, employee, of element Employee, type EmployeeType, while the EmployeeTravelStatusResponseMessage has a part called travelClass, of element TravelClass, and type TravelClassType. The EmployeeType and the TravelClassType types are defined within the WSDL under the element: [ 87 ]

Service Composition with BPEL

EmployeeType is a complex type and has three elements: first name, last name, and department name. TravelClassType is a simple type that uses the enumeration to

list the possible classes:



Now let us look at the airline service.

Airline service

The Airline service is an asynchronous web service. Therefore, it specifies two port types. The first, FlightAvailabilityPT, is used to check the flight availability using the FlightAvailability operation. To return the result, the service specifies the second port type, FlightCallbackPT. This port type specifies the FlightTicketCallback operation. Although the Airline service defines two port types, it only implements the FlightAvailabilityPT. FlightCallbackPT is implemented by the BPEL process, which is the client of the web service. The architecture of the service is schematically shown as follows:

[ 88 ]

Chapter 2

Flight Availability port type

FlightAvailability is an asynchronous operation, containing only the

input message:

...

The following shows the definition of the input message. It consists of two parts, the flightData part and the travelClass part:

The travelClass part is the same as that used in the Employee Travel Status service. The flightData part is of element FlightRequest, which is defined as follows:

[ 89 ]

Service Composition with BPEL

FlightRequestType is a complex type and has four elements, through which we

specify the flight origin and destination, the desired departure date, and the desired return date.

Flight Callback port type

The Airline service needs to specify another port type for the callback operation, through which the BPEL process receives the flight ticket response messages. Note that the service will only specify this port type, which is implemented by the BPEL process. We define the FlightCallbackPT port type with the FlightTicketCallback operation, which has the TravelResponseMessage input message as follows:

TravelResponseMessage consists of a single part called confirmationData

as follows:



FlightConfirmation is of type FlightConfirmationType, which is a complex

type used for returning the result. It includes the flight number, travel class, price, departure and arrival date and time, and the approved flag. It is declared as follows:

[ 90 ]

Chapter 2

Now that we are familiar with both the services, we can define the BPEL process. Remember that our BPEL process is an actual web service. Therefore, we first have to write the WSDL for the BPEL process.

WSDL for the BPEL process

The business travel BPEL process is exposed as a service. We need to define the WSDL for it. The process will have to receive messages from its clients and return results. So, it has to expose a port type that will be used by the client to start the process and get the reply. We define the TravelApprovalPT port type with the TravelApproval operation:

We have already said that the BPEL process is synchronous. The TravelApproval operation will be of synchronous request/response type: ...

[ 91 ]

Service Composition with BPEL

We also have to define messages. The TravelRequestMessage consists of two parts: •

employee: The employee data, which we reuse from the Employee Travel Status service definition.

•

flightData: The flight data, which we reuse from the Airline service

definition.

...

For the output message, we use the same message used to return the flight information from the Airline service—the TravelResponseMessage defined in the aln namespace. This is reasonable, because the BPEL process will get the TravelResponseMessage from both airlines, select the most appropriate (the cheapest) and return the same message to the client. As we have already imported the Airline WSDL, we are done. When writing the WSDL for the BPEL process, we usually do not define the binding () and the service () sections. These are usually generated by the BPEL execution environment (BPEL server). Before we can start writing the BPEL process, we still need to define partner link types.

Partner link types

Partner link types represent the interaction between a BPEL process and the involved parties, which includes the services the BPEL process invokes and the client that invokes the BPEL process. In our example, there are three different partners—the client, the Employee Travel Status service, and the Airline service. Ideally, each service should define the corresponding partner link types (in the WSDL). In real-world scenarios, this may not be the case. Then we can wrap the partner web service with a WSDL that imports the WSDL of the service and defines the partner link types. We define three partner link types, each in the corresponding WSDL of the service: •

travelLT: This is used to describe the interaction between the BPEL process client and the BPEL process itself. This interaction is synchronous. This partner link type is defined in the WSDL of the BPEL process. [ 92 ]

Chapter 2

•

employeeLT: This is used to describe the interaction between the BPEL

•

flightLT: This describes the interaction between the BPEL process and

process and the Employee Travel Status service. This interaction is synchronous too. This partner link type is defined in the WSDL of the Employee service.

the Airline service. This interaction is asynchronous and the Airline service invokes a callback on the BPEL process. This partner link type is defined in the WSDL of the Airline service.

We already know that each partner link type can have one or two roles and for each role we must specify the portType it uses. For synchronous operations, there is a single role for each partner link type, because the operation is only invoked in a single direction. For example, the client invokes the TravelApproval operation on the BPEL process. Because it is a synchronous operation, the client waits for completion and gets a response only after the operation is completed. Note that if TravelApproval were an asynchronous callback operation, we would have to specify two roles. The first role would describe the invocation of the TravelApproval operation by the client. The second role would describe the invocation of a callback operation. This callback operation would be invoked by the BPEL process and would call the client to return the result. We will make our example process asynchronous later in this chapter. Please remember that there is an asynchronous relation between the BPEL process and the Airline service. As we have already figured out, we need three partner link types. In the first two, we have to specify a single role, because they deal with synchronous operations. In the third, we need to specify both the roles, because it is asynchronous. Partner link types are defined within a special namespace: http://docs.oasis-open. org/wsbpel/2.0/plnktype. The reference to this namespace has to be included first:

[ 93 ]

Service Composition with BPEL

Now we can add the definitions for the partner link types. First, we define the travelLT link type in the BPEL process WSDL. This is used by clients to invoke the BPEL process. The only role required is the role of the travel service (our BPEL process). The client uses the TravelApprovalPT port type to communicate with the BPEL service:

The second link type is employeeLT. It is used to describe the communication between the BPEL process and the Employee Travel Status service, and is defined in the WSDL of the Employee service. The interaction is synchronous, so we need a single role, called employeeTravelStatusService. The BPEL process uses the EmployeeTravelStatusPT on the Employee service:

The last partner link type is flightLT, used to describe the communication between the BPEL process and the Airline service. This communication is asynchronous. The BPEL process invokes an asynchronous operation on the Airline service. The web service, after it has completed the request, invokes a callback on the BPEL process. Therefore, we need two roles: •

The first role describes the role of the Airline service to the BPEL process, which is the airline service (airlineService). The BPEL process uses the FlightAvailabilityPT port type to make the asynchronous invocation.

•

The second role describes the role of the BPEL process to the Airline services. For the Airline service, the BPEL process is an airline customer, thus the role name is airlineCustomer. The Airline service uses the FlightCallbackPT port type to make the callback.

This partner link type is defined in the WSDL of the Airline service:

[ 94 ]

Chapter 2

Understanding partner link types is crucial for developing a BPEL process specification. Sometimes it helps to make a diagram of all the interactions. Once the partner link types are defined, we have finished the preparation phase and are ready to start writing the business process definition.

Business process definition

The BPEL business process definition specifies the order of activities that have to be performed within a business process. Typically, a BPEL process waits for an incoming message, which starts the execution of the business process. This incoming message is usually the client request. Then a series of activities occur, either sequentially or in parallel. These activities include: •

Invoking operations on other services

•

Receiving results from other services

•

Conditional branching, which influences the flow of the business process

•

Looping

•

Fault handling

•

Waiting for certain events to occur

In our example process, we do not cover all these aspects. We will leave loops, faults, and waits for the next chapter. Before we start defining our business process, let us have a quick look at the sequence diagram. It shows the messages exchanged between the involved parties. The following parties are involved: •

The client that will invoke the BPEL process

•

The BPEL process itself

•

The Employee Travel Status service

•

Two airline web services: American and Delta

The client initiates the BPEL process by sending an input message: TravelRequest. This is a synchronous call. Then the BPEL process invokes the Employee Travel Status service, sending the EmployeeTravelStatusRequest message. Because this is a synchronous invocation, it waits for the EmployeeTravelStatusResponse message. Then the BPEL process makes concurrent asynchronous invocations of both the Airline web services by sending them the FlightTicketRequest message. Both the Airline web services make a callback, sending the TravelReponse message.

[ 95 ]

Service Composition with BPEL

The BPEL process then selects the more appropriate airline and returns the reply message, TravelResponse, to the initial client. See the following sequence diagram:

In real-world scenarios, we do not define synchronous BPEL processes that use asynchronous web services as the client may have to wait for an arbitrarily long time. We would rather select an asynchronous BPEL process. In this example, we use the synchronous example to maintain simplicity. The next section shows how to define an asynchronous BPEL process. Understanding and knowing the exact details of a business process is crucial. Otherwise, we will not be able to specify it using BPEL.

Now, we are ready to start writing the BPEL process definition. Each BPEL definition contains at least four main parts: • The initial root element with the declaration of namespaces • The definition of partner links, using the element • The declaration of variables, using the element • The main body, where the actual business process is defined; this is usually a element that specifies the flow of the process

BPEL process outline

We start with an empty BPEL process outline that presents the basic structure of each BPEL process definition document: [ 96 ]

Chapter 2

Let us first add the required namespaces. Here we have to define the target namespace and the namespaces to access the Employee and Airline WSDLs, and the BPEL process WSDL. We also have to declare the namespace for all the BPEL activity tags (here the default namespace; so, we do not have to qualify each BPEL tag name). The BPEL activity namespace must be http://docs.oasis-open.org/wsbpel/2.0/ process/executable:

Partner links

Next, we have to define the partner links. Partner links define different parties that interact with the BPEL process. Each partner link is related to a specific partnerLinkType that characterizes it. Each partner link also specifies up to two attributes: •

myRole: This indicates the role of the business process itself

•

partnerRole: This indicates the role of the partner

The partner link can specify a single role, which is usually the case with synchronous request/response operations. In our example, we define four roles. The first partner link is called client and is characterized by the travelLT partner link type. The client invokes the business process. We need to specify the myRole attribute to describe the role of the BPEL process. In our case, this is the travelService:

The second partner link is called employeeTravelStatus and is characterized by the employeeLT partner link type. It is a synchronous request/response relation between the BPEL process and the service; we again specify only one role. This time it is the partnerRole, because we describe the role of the service, which is a partner of the BPEL process:

The last two partner links correspond to the Airline services. Because they use the same type of service, we specify two partner links based on a single partner link type—flightLT. Here we have asynchronous callback communication; therefore, we need two roles. The role of the BPEL process (myRole) to the Airline web service is airlineCustomer, while the role of the airline (partnerRole) is airlineService:

Variables

Variables are used to store messages, and to reformat and transform them. We usually need a variable for every message sent to the partners and received from the partners. Looking at the sequence diagram, this would mean eight variables for our example. However, notice that the messages are sent to both Airline services are identical. So, we only need seven variables. Let's call them TravelRequest, EmployeeTravelStatusRequest, EmployeeTravelStatusResponse, FlightDetails, FlightResponseAA, FlightResponseDA, and TravelResponse. For each variable we have to specify the type. We can use a WSDL message type, an XML Schema simple type, or an XML Schema element. In our example, we use WSDL message types for all variables: [ 98 ]

Chapter 2

BPEL process main body

The process main body may contain only one top-level activity. Usually this is a element that allows us to define several activities that will be performed sequentially. Other possibilities for this activity include , through which several activities can be performed concurrently. We can also specify to indicate loops, or to define nested activities. However, we usually use and nest other activities within the sequence. Within the sequence, we first specify the input message that starts the business process. We do this with the construct, which waits for the matching message. In our case, it is the TravelRequest message. Within the construct, we do not specify the message directly. Rather, we specify the partner link, the port type, the operation name, and optionally, the variable that holds the received message for consequent operations. We link the message reception with the client partner, and wait for the TravelApproval operation to be invoked on port type TravelApprovalPT. We store the received message in the TravelRequest variable: [ 99 ]

Service Composition with BPEL

As already mentioned, waits for the client to invoke the TravelApproval operation and stores the incoming message and parameters about the business trip in the TravelRequest variable. Here, the variable name is the same as the message name, but this is not necessary. Next, we need to invoke the Employee Travel Status service. Before this, we have to prepare the input for this service. Looking at the WSDL of the Employee service, we can see that we have to send a message consisting of the employee part. We can construct such a message by copying the employee part of the message that the client sent. We write the corresponding assignment:

Now we can invoke the Employee Travel Status service. We make a synchronous invocation, for which we use the activity. We use the employeeTravelStatus partner link and invoke the EmployeeTravelStatus operation on the EmployeeTravelStatusPT port type. We have prepared the input message in the EmployeeTravelStatusRequest variable. Because it is a synchronous invocation, the call waits for the reply and stores it in the EmployeeTravelStatusResponse variable:

The next step is to invoke both the Airline web services. Again, we first prepare the required input message (which is equal for both the web services). The FlightTicketRequest message consists of two parts:

[ 100 ]

Chapter 2

•

flightData: This is retrieved from the client message (TravelRequest)

•

travelClass: This is retrieved from the EmployeeTravelStatusResponse

variable

Therefore, we write an assignment with two copy elements:

The input data includes the data that needs to be passed to the Airline web services. As it is in the same format, we can pass it directly (using a simple copy). In the real world, we usually need to perform a transformation. We could do that using XPath expressions with , use a transformation service (such as an XSLT engine), or use the transformation capabilities provided by specific BPEL servers. Now we are ready to invoke both the Airline web services. We will make concurrent asynchronous invocations. To express concurrency, BPEL provides the activity. The invocation to each web service will consist of two steps: •

The activity is used for the asynchronous invocation.

•

The activity is used to wait for the callback.

We use to group both activities. The two invocations differ only in the partner link name. We use AmericanAirlines for one and DeltaAirlines for the other. Both invoke the FlightAvailability operation on the FlightAvailabilityPT port type, sending the message from the FlightDetails variable. The callback is received using the activity. Again, we use both partner link names. waits for the FlightTicketCallback operation to be invoked on the FlightCallbackPT port type. We store the result message in the FlightResponseAA and the FlightResponseDA variables respectively:

[ 101 ]

Service Composition with BPEL

At this stage of the process, we have two ticket offers. In the next step, we have to select one. For this, we use the activity. $FlightResponseAA.confirmationData/aln:Price <= $FlightResponseDA.confirmationData/aln:Price [ 102 ]

Chapter 2

In the element, we check whether the offer from American Airlines (FlightResponseAA) is equal or better than the offer from Delta (FlightResponseDA). For this, we access the BPEL variable from XPath using the $ operator. The price is located inside the confirmationData message part, which is the only message part, but we still have to specify it. We also have to specify the node to locate the price element. Here, this is a simple XPath 1.0 expression. If the American Airlines offer is better than Delta (or equal), we copy the FlightResponseAA variable to the TravelResponse variable (which we finally return to the client). Otherwise, we copy the FlightResponseDA variable. We have come to the final step of the BPEL business process—to return a reply to the client, using the activity. Here we specify the same partner link as in the initial receive client. We also specify the same port type and operation name. The variable that holds the reply message is TravelResponse:

With this, we have concluded our first business process specification in BPEL. You can see that BPEL is not very complicated and allows a relatively easy and natural specification of business processes. The consumption of other services is also relatively easy if you are familiar with WSDL. In the next section, we will modify our BPEL process to make it asynchronous. [ 103 ]

Service Composition with BPEL

Asynchronous BPEL example

Our first BPEL business process example was synchronous, because this was the easiest case. However, in the real world, we will mostly use asynchronous processes. Most business processes are long running. It makes no sense for a client to wait (and be blocked) for the entire duration of the process. A much better alternative is to model the BPEL process as asynchronous. This means that the client invokes the process, and when the process completes, it performs a callback to the client. This has a few consequences: •

• •

For the BPEL process to be able to perform a callback to the client, the client must be a service and implement a certain port type (usually defined by the BPEL process WSDL). The partner link type for the client will have to specify two roles. The BPEL process will not to the client. Rather it will the callback.

Let us now focus on our business process and modify it for asynchronous invocation, presented in the next sequence diagram. We have to perform the following steps: 1. Modify the BPEL process WSDL, where the operation invoked by the client will now have only the input message. 2. Define the client port type and the operation, which the BPEL process will invoke for the callback. We will do this in the WSDL of the BPEL process. 3. Modify the partner link type, where we will add the second role. 4. Modify the BPEL process specification. We have to modify the partner link and replace the activity with an . The following shows the modified sequence diagram. It is very similar to the previous example, except that the initial travel request is asynchronous and the final answer is delivered as a callback:

[ 104 ]

Chapter 2

Modify the BPEL process WSDL

The modified WSDL for the BPEL process will have to specify the TravelApprovalPT port type, which will now specify an input message only. It will also have to declare the ClientCallbackPT port type, used to return the result to the client (asynchronously, using a callback). This is shown in the following figure:

Let us first modify the TravelApprovalPT port type used for client interaction, which will now define only the input message:

Next we define the client callback port type (ClientCallbackPT) with the ClientCallback operation. The response message is TravelResponseMessage. Notice that the WSDL only specifies this port type, which is implemented by the client:

Modify partner link types

We need to modify the partner link type for the interaction with the BPEL process, called the travelLT link type. We have to add the second role, travelServiceCustomer, which characterizes the client to which the BPEL process will perform a callback on the ClientCallbackPT port type. This is done in the WSDL of the BPEL process: [ 105 ]

Service Composition with BPEL

Modify the BPEL process definition

Finally, we modify the BPEL process definition. Here we first have to modify the client partner link, where we have to specify the second role—the partnerRole. Here, this is travelServiceCustomer, which characterizes the BPEL process client:

Next, we change the last activity of the BPEL process. We replace the activity with the callback. For the callback, we use the client partner link and invoke the ClientCallback operation on the ClientCallbackPT port type. The message signature has not changed, so we use the same variable as before, TravelResponse.

Our BPEL process is now asynchronous! To execute a BPEL process we need a runtime environment. In Chapter 1, Introduction to BPEL and SOA, we provided an overview of BPEL servers. Later chapters give a detailed description of the IBM Websphere Process Server. You can download both the synchronous and asynchronous BPEL process examples with the corresponding services from http:// www.packtpub.com. They can be deployed to the IBM WebSphere Process Server using the IBM WebSphere Integration Developer. For more information on IBM WebSphere Process Server and Integration Developer, refer to Chapter 4, BPEL Processes with IBM WebSphere.

[ 106 ]

Chapter 2

Summary

In this chapter, you have become familiar with the basic concepts of service composition with BPEL. BPEL is an XML-based language for business process definition. Each process has a set of activities and interacts with partner services. The BPEL process is also a service. With BPEL, we can define executable and abstract business processes. In this chapter, we have focused on executable processes. They exactly define the activities of the processes and can be executed on a BPEL-compliant server. We have overviewed the basic concepts of BPEL, described how to invoke services synchronously and asynchronously, and discussed the role of WSDL. BPEL processes can be synchronous or asynchronous and we have overviewed both options. Web services with which a BPEL process interacts are called partner services. Therefore, we have explained the concepts of partner link types and partner links. We have overviewed the most important activities for invoking operations, receiving messages, and returning replies to clients. We have also become familiar with variables and assignments. With this theoretical knowledge, we defined two example BPEL processes for business travels. We developed a synchronous and then an asynchronous process.

[ 107 ]

Advanced BPEL In the previous chapter, we covered the basics of BPEL and provided an introduction to the structure of business processes. We are now familiar with defining business processes, invoking web service operations sequentially and in parallel, defining partner links, defining variables, and assigning values. However, using BPEL for complex real-world business processes requires additional functionality. Sometimes, the activities of a business process need to be performed in loops. Often activities might have links that would affect the execution order. This is usually the case with concurrent flows. Sometimes we will have to wait either for a message event or an alarm event to occur. One very important aspect of business process modeling is fault handling. Particularly in business processes that span multiple enterprises and use web services over the Internet, we can assume that faults will occur quite often for various reasons, including broken connections, unreachable web services, unavailability of services, and so on. If business processes do not finish successfully, we might need a way to undo the partial work. This is called compensation and is one of the features of BPEL. In this chapter, we will look at these and other advanced BPEL features including: •

BPEL activities not covered in the previous chapter, such as loops, delays, and process termination

•

Fault handling

•

Scopes and isolation

•

Compensation

•

Events and event handlers

•

Concurrent activities and links

•

The business process lifecycle

•

Correlations and message properties

Advanced BPEL

•

Dynamic partner links

•

Abstract business processes

•

Generating BPEL from BPMN diagrams

Advanced activities

In the previous chapter, we familiarized ourselves with important BPEL activities, including invoking web service operations (), receiving messages from partners (), returning results to process clients (), declaring variables (), updating variable contents (), sequential and concurrent structured activities ( and ), and conditional behavior (). However, these activities are not sufficient for complex real-world business processes. Therefore, in the first part of this chapter we will become familiar with the other important activities offered by BPEL, particularly activity names, loops, delays, empty activities, and process termination. We will not discuss concrete use cases where these activities can be used, because they are well known to developers. We will, however, use these activities later in the chapter, where we will present some examples. Let us first look at loops.

Loops

When defining business processes, we will sometimes want to perform a certain activity or a set of activities in a loop; for example, perform a calculation or invoke a partner web service operation several times, and so on. BPEL supports three types of loops: • • •

loops loops loops

The and loops are very similar to other programming languages. The loop, on the other hand, provides the ability to start the loop instances in parallel. Loops are helpful when dealing with arrays. In BPEL, arrays can be simulated using XML complex types where one or more elements can occur more than once (using the maxOccurs attribute in the XML Schema definition). To iterate through multiple occurrences of the same element, we can use XPath expressions. Let us now look at the loop. [ 110 ]

Chapter 3

While

The loop repeats the enclosed activities until the Boolean condition no longer holds true. The Boolean condition is expressed through the condition element, using the selected expression language (the default is XPath 1.0). The syntax of the activity is shown in the following code excerpt: boolean-expression

Let us consider a scenario where we need to check flight availability for more than one person. Let us also assume that we need to invoke a web service operation for each person, similar to the example in Chapter 2, Service Composition with BPEL. In addition to the variables already present in the example, we would need two more NoOfPassengers to hold the number of passengers and Counter to use in the loop. The code excerpt with variable declarations is as follows:

We also need to assign values to the variables. The NoOfPassengers can be obtained from the Employee Travel web service. In the following code, we initialize both variables with static values: number(5) number(0)

The loop to perform the web service invocation is shown in the following code excerpt. Please remember that this excerpt is not complete: $Counter < $NoOfPassengers [ 111 ]

Advanced BPEL ... ... ... $Counter + 1

Repeat Until

The loop repeats the enclosed activities until the Boolean condition becomes true. The Boolean condition is expressed through the condition element, the same way as in the loop. The syntax of the activity is shown in the following code excerpt: boolean-expression

A similar example of a loop as mentioned in the previous section, but using , is as follows: ... [ 112 ]

Chapter 3 ... ... $Counter + 1 $Counter >= $NoOfPassengers

For Each

The loop is a for type loop, with an important distinction. In BPEL the loop can execute the loop branches in parallel or serially. The serial is very similar to the for loops from various programming languages, such as Java. The parallel executes the loop branches in parallel (similar to ), which opens new possibilities in relatively simple parallel execution (for example, invocation of services). The loop requires us to specify the BPEL variable for the counter (counterName), the startCounterValue, and the finalCounterValue. The loop will execute (finalCounterValue – startCounterValue + 1) times. The requires that we put all activities, which should be executed within the branch, into a . The allows us to perform group-related activities. We will discuss in detail later in this chapter. The syntax of is shown in the following: unsigned-integer-expression unsigned-integer-expression [ 113 ]

Advanced BPEL

Such a loop will complete when all branches () have completed. A similar example of a loop as in the previous section is as follows: number(1) $NoOfPassengers ... ... ...

Sometimes it would be useful if the loop would not have to wait for all branches to complete. Rather, it would wait until at least some branches complete. In we can specify that the loop will complete after at least N branches have completed. We do this using the . We specify the number N of . The will complete after at least N branches have completed. We can specify if we would like to count only successful branches or all branches. We do this using the successfulBranchesOnly attribute. If set to yes, only successful branches will count. If set to no (default), successful and failed branches will count. The syntax is as shown in the following: unsigned-integer-expression unsigned-integer-expression unsigned-integer-expression

[ 114 ]

Chapter 3

Delays

Sometimes a business process may need to specify a certain delay. In BPEL, we can specify delays either for a specified period of time or until a certain deadline is reached, by using the activity. Typically, we could specify delays to invoke an operation at a specific time, or wait for some time and then invoke an operation; for example, we could choose to wait before we pool the results of a previously initiated operation or wait between iterations of a loop. The activity can be: •

for: We can specify duration, that is, we specify a period of time. duration-expression

•

until: We can specify a deadline; we specify a certain date and time. deadline-expression

Deadline and duration expressions

To specify deadline and duration expressions, BPEL uses lexical representations of corresponding XML Schema data types. For deadlines, these data types are either dateTime or date. For duration, we use the duration data type. The lexical representation of expressions should conform to the XPath 1.0 (or the selected query language) expressions. The evaluation of such expressions should result in values that are of corresponding XML Schema types: dateTime and date for deadline and duration for duration expressions.

[ 115 ]

Advanced BPEL

All three data types use lexical representation inspired by the ISO 8601 standard, which can be obtained from the ISO web page http://www.iso.ch. ISO 8601 lexical format uses characters within the date and time information. Characters are appended to the numbers and have the following meaning: •

C represents centuries.

•

Y represents years.

•

M represents months.

•

D represents days.

•

h represents hours.

•

m represents minutes.

•

s represents seconds. Seconds can be represented in the format ss.sss to

increase precision.

• Z is used to designate Coordinated Universal Time (UTC). It should immediately follow the time of day element. For the dateTime expressions there is another designator: T is used as time designator to indicate the start of the representation of the time.

Examples of deadline expressions are shown in the following code excerpts: '2004-03-18T21:00:00+01:00' '18:05:30Z'

For duration expressions, the following characters can also be used: •

P is used as the time duration designator. Duration expressions always start with P.

•

Y follows the number of years.

•

M follows the number of months or minutes.

•

D follows the number of days.

•

H follows the number of hours.

•

S follows the number of seconds.

[ 116 ]

Chapter 3

To specify a duration of 4 hours and 10 minutes, we use the following expression: 'PT4H10M'

To specify the duration of 1 month, 3 days, 4 hours, and 10 minutes, we need to use the following expression: 'P1M3DT4H10M'

The following expression specifies the duration of 1 year, 11 months, 14 days, 4 hours, 10 minutes, and 30 seconds: 'P1Y11M14DT4H10M30S'

Empty activities

When developing BPEL processes, you may come across instances where you need to specify an activity as per rules, but you do not really want to perform the activity. For example, in activities, we need to specify an activity for each branch. However, if we do not want to perform any activity for a particular case, we can specify an activity. Not specifying any activity in this case would result in an error, because the BPEL process would not correspond to the BPEL schema. Empty activities are also useful in fault handling, when we need to suppress a fault. The syntax for the element is rather straightforward:

Ending a process

BPEL provides the activity to immediately end a business process, before it has finished. We can use it to immediately terminate processes that are in execution. Often we use in conditional branches, where we need to exit a process when certain conditions are not met. The activity ends the current business process instance and no fault and compensation handling is performed. Process instances, faults, and compensations are discussed later in this chapter.

[ 117 ]

Advanced BPEL

The syntax is very simple and is as follows:

Now that we have become familiar with loops, delays, empty activities, and process termination (which we will use in examples in the rest of this chapter), we will go on to fault handling.

Fault handling and signaling

Business processes specified using BPEL will interact with their partners through operation invocations of web services. Web services are based on loosely coupled Service Oriented Architecture (SOA) . The communication between web services is done over Internet connections that may or may not be highly reliable. Web services could also raise faults due to logical errors and execution errors arising from defects in the infrastructure. Therefore, BPEL business processes will need to handle faults appropriately. BPEL processes may also need to signal faults themselves. Fault handling and signaling is an important aspect of business processes designed using BPEL. Faults in BPEL can arise in various situations: •

When a BPEL process invokes a synchronous web service operation, the operation might return a WSDL fault message, which results in a BPEL fault.

•

A BPEL process can explicitly signal (throw) a fault.

•

A fault can be thrown automatically, for example, when a join failure has occurred. We will discuss join failures later in this chapter.

•

The BPEL server might encounter error conditions in the runtime environment, network communications, or any other such area. BPEL defines several standard faults; these are listed in Appendix A.

WSDL faults

WSDL faults occur due to synchronous operation invocations on partner web services. In WSDL, such faults are denoted with the element within the declaration. In BPEL, WSDL faults are identified by the qualified name of the fault and the target namespace of the corresponding port type used in the operation declaration. In the Synchronous Business Travel Process example in the previous chapter, we have used the TravelApproval operation on the TravelApprovalPT port type with input and output messages. This is shown in the following WSDL excerpt: [ 118 ]

Chapter 3

To add fault information to the operation, we first need to define a corresponding message. For simplicity, this message will be of the xs:string type:

Now we will add the fault declaration to the operation signature shown previously:

WSDL does not require that we use unique fault names within the namespace used to define the operation. This implies that faults that have the same name and are defined within the same namespace will be considered as the same fault in BPEL. Keep this in mind when designing services that can potentially become partners of BPEL business processes, because this can lead to conflicts in fault handling during execution.

Signaling faults

A business process may sometimes need to explicitly signal a fault. For such a situation, BPEL provides the activity. It has the following syntax:

BPEL does not require that we define fault names in advance, prior to their use in the activity. This flexible approach can also be error-prone, because there is no compile-time checking of fault names. Therefore, a typo could result in a situation where a misspelled fault might not be handled by the designated fault handler. Faults can also have an associated variable that usually contains data related to the fault. If such a variable is associated with the fault, we need to specify it when throwing the fault. This is done by using the optional faultVariable attribute as shown here: [ 119 ]

Advanced BPEL

The following example shows the most straightforward use of the activity; where a WrongEmployeeName fault is thrown, no variable is needed. Remember that fault names are not declared in advance:

The faults raised with the activity have to be handled in the BPEL process. Fault handling is covered later in this chapter. Faults that are not handled will not be automatically propagated to the client as is the case in modern programming languages (Java for example). Rather, the BPEL process will terminate abnormally. Sometimes, however, we may want to signal faults to clients.

Signaling faults to clients in synchronous replies

A BPEL process offers operations to its clients through the activity. If the process wants to provide a synchronous request/response operation, it sends a activity in response to the initial . Remember that the type of the operation is defined in the WSDL document of the BPEL process. A synchronous request/response operation is defined as an operation that has an input and an output message, and an optional fault message. If such an operation has the fault part specified, we can use the activity to return a fault instead of the output message. The syntax of the activity in this case is: [ 120 ]

Chapter 3 ...

Then we return the fault to the BPEL process client. We will need to check if something went wrong in the travel process. For the purpose of this example, we will check whether the selected flight ticket has been approved. This information is stored in the confirmationData part of the TravelResponse variable in the Approved element (see the previous chapter for the complete schema definition). Note that this is an oversimplification, but it demonstrates how to return faults. We can use an activity to determine whether the ticket is approved; then we construct the fault variable and use the activity to return it to the client. This is shown in the following code: $TravelResponse.confirmationData/aln:Approved='true' string('Ticket not approved')

If the ticket is not approved, the following fault is signaled to the client: Ticket not approved [ 121 ]

Advanced BPEL

We have seen that signaling faults in synchronous replies is easy. Let us now discuss signaling faults in asynchronous scenarios.

Signaling faults to clients in asynchronous scenarios

If an asynchronous BPEL process needs to notify the client about a fault, it cannot use the activity. Remember that in asynchronous scenarios the client does not wait for the reply; rather, the process uses a callback. To return a fault in callback scenarios, we usually define additional callback operations on the same port type. Through these callback operations, we can signal that an exceptional situation has prevented normal completion of the process. To demonstrate how faults can be propagated to the client using a callback operation, we will use the asynchronous travel process example. First, we need to modify the travel BPEL process WSDL and introduce another operation called ClientCallbackFault. This operation consists of an input message called tns:TravelFaultMessage. The message is of the string type (similar to the synchronous example). The declaration of the operation and the message is shown in the following code excerpt:

We can use the activity to determine whether the ticket has been approved, as in the synchronous example. If the ticket is not approved, however, we the ClientCallbackFault operation instead of using the activity to signal the fault to the client. This is shown in the following code excerpt: $TravelResponse.confirmationData/aln:Approved='true' [ 122 ]

Chapter 3 string('Ticket not approved')

In the next section, we will look at how to handle faults thrown in BPEL processes.

Handling faults

Now that we are familiar with how faults are signaled, let us consider how the business process handles faults. When a fault occurs within a business process (this can be a WSDL fault, a fault thrown by the BPEL process, or any other type of fault), it means that the process may not complete successfully. The process can complete successfully only if the fault is handled within a scope. Scopes are discussed in the next section.

Business processes handle faults through fault handlers.

A business process can handle a fault through one or more fault handlers. Within a fault handler, the business process defines custom activities that are used to recover from the fault and recover the partial (unsuccessful) work of the activity in which the fault has occurred. [ 123 ]

Advanced BPEL

The fault handlers are specified before the first activity of the BPEL process, after the partner links and variables. The overall structure is shown in the following code excerpt: ... ... ...

We can see that within the fault handlers, we specify several activities where we indicate the fault that we would like to catch and handle. Within a fault handler, we have to specify at least one or a activity. Of course, the activity can be specified only once within a fault handler. Usually we will specify several activities to handle specific faults and use the to handle all other faults. The activity has two attributes, of which we have to specify at least one: •

faultName: Specifies the name of the fault to be handled.

•

faultVariable: Specifies the variable type used for fault data. Additionally,

we can specify one of the following attributes (both are optional, but we may specify one, not both): °Â°

faultMessageType: Specifies the WSDL message type of the

fault to be handled.

[ 124 ]

Chapter 3

°Â°

faultElement: Specifies the XML element type of the fault to

be handled.

The flexibility of activities is high and several variations are permissible. Listed ahead are the most common:

We can see that fault handlers in BPEL are very similar to try/catch clauses found in modern programming languages.

Selection of a fault handler

Let us consider the fault handlers listed earlier and discuss the scenarios for which the activities will be selected: •

The first will be selected if the trv:TicketNotApproved fault has been thrown and the fault carries no fault data.

•

The second will be selected if the trv:TicketNotApproved fault has been thrown and carries data of a type matching that of the TravelFault variable.

•

The third will be selected if a fault has been thrown whose fault variable type matches the TravelFault variable type, and whose name is not trv:TicketNotApproved.

•

In all other cases the will be selected.

[ 125 ]

Advanced BPEL

We can see that the selection of the activity within fault handlers is quite complicated. It may even happen that a fault matches several activities. Therefore, BPEL specifies exact rules to select the fault handler that will process a fault: •

For faults without associated fault data, the fault name will be matched. The activity with a matching faultName will be selected, if present; otherwise, the default handler will be used, if present.

•

For faults with associated fault data, a activity specifying a matching faultName value and faultVariable value will be selected, if present. Otherwise, a activity with no specified faultName and a matching faultVariable will be selected, if present. If not, the default handler will be used, if present. The activity will execute only if no other activity has been selected.

If no is selected and is not present, the fault will be rethrown to the immediately enclosing scope, if present. Otherwise, the process will terminate abnormally. This situation is similar to explicitly terminating the process using the activity.

Synchronous example

Let's go back to the synchronous BPEL travel process example to add a fault handlers section. We need to define a fault handler that will simply signal the fault to the client. In real-world scenarios, a fault handler can perform additional work to try to recover the work done by an activity or retry the activity itself. To signal the fault to the client, we use the same TravelFaultMessage message that we defined in the previous section. Here is an excerpt from the WSDL: [ 126 ]

Chapter 3

We define a fault handler and add a section immediately after the definition and before the activity, as shown ahead. The fault handler for the trv:TicketNotApproved fault is defined with the associated TravelFault variable. This handler will use the activity to signal the fault to the BPEL client. We will also provide a default handler, which will first create a variable and then use the activity to signal the fault to the client: ... string('Other fault')

We also have to modify the process itself. Instead of replying to the client () in the activity, if the ticket has not been approved, we will simply throw a fault, which will be caught by the corresponding fault handler. The fault handler will also catch other possible faults: ... $TravelResponse.confirmationData/aln:Approved='true' string('Ticket not approved')

Faults that are not handled by the BPEL process result in abnormal termination of the process and are not propagated to the client. In other words, unhandled faults do not cross service boundaries unless explicitly specified using a activity as we did in our example. This differentiates BPEL from Java and other languages, where unhandled exceptions are propagated to the client.

Asynchronous example

In asynchronous BPEL processes, faults are handled in the same way as in synchronous processes by using . We need to define a fault handler that, in our example, will simply forward the fault to the client. We cannot, however, use the activity to signal the fault to the client. Instead, we need to define an additional callback operation and use the activity, as we did in our previous example. In this example, we will use the same fault callback operation as in the previous asynchronous example: [ 128 ]

Chapter 3

Now we will define the section. The difference compared to the synchronous example will be that we will use the activity to invoke the newly defined operation instead of the activity to propagate the fault to the client: string('Other fault')

Another important question related to fault handling is how the BPEL process can be notified of faults that occurred in asynchronously invoked partner web service operations. A typical example is the invocation of the American and Delta Airlines web services in our example. To invoke the operation, we used the activity and then a activity to wait for the callback. BPEL provides a way to wait for more than just one message (operation call) using the activity, which is described later in this chapter in the Managing events section. By using instead of , our BPEL process can wait for several incoming messages. One of these can be a message for regular callback and others can be messages that signal fault conditions. With , we can even specify a time-out for receiving a callback. For further information on these issues, please see the Managing events section. [ 129 ]

Advanced BPEL

Propagating faults

In fault handlers we might want to propagate a fault that we have caught to the higher-level fault handler. For example, a fault handler of a nested scope catches a fault. However, it is a type of fault that it will not handle. Rather, it will propagate it to the fault handler of the higher-level scope. To achieve this, we can use the activity. is used to rethrow the fault caught by the fault handler. can be used only within a fault handler ( and ). The syntax is simple:

Default fault handler

If a fault handler for any fault is not defined for any given , the BPEL engine implicitly creates a default fault handler. The default fault handler will compensate all inner scopes (compensation is covered later in this chapter) and rethrow the fault to the upper scope. The default implicit fault handler looks like this:

Inline fault handling

The loosely coupled model of web services and the use of Internet connections for accessing them make the invocation of operations on web services particularly error prone. Numerous situations can prevent a BPEL process from successfully invoking a partner web service operation, such as broken connections, unavailability of web services, changes in the WSDL, and so on. Such faults can be handled in the general sections. However, a more efficient way is to handle faults related to the activity directly and not rely on the general fault handlers. The activity provides a shortcut to achieve this, that is, inline fault handlers. Inline fault handlers can catch WSDL faults for synchronous operations and also other faults related to the runtime environment, communications, and so on. [ 130 ]

Chapter 3

The syntax for inline fault handlers in the activity is similar to the syntax of the section. As shown in the following code excerpt, we can specify zero or more activities and we can also specify a handler. The only difference is that in inline activities, we have to specify a fault name. Optionally, we may specify the fault variable: ... ... ...

The following code excerpt shows an inline fault handler for invoking the Employee Travel Status web service from our BPEL travel process example. Please notice that this also requires modifying the Employee Travel Status WSDL and declaring an additional fault message for the operation. Because this code is similar to what we did in previous examples, it is not repeated here again. The following code excerpt demonstrates inline fault handling. The rules, as to which catch activity will be selected, are the same as for standalone fault handlers and have been discussed in the previous section: [ 131 ]

Advanced BPEL

This brings us to the thought that it would be useful if we could specify more than one section in a BPEL process. It would be great if we could specify different fault handlers sections for different parts of the process, particularly for complex processes. This is possible if we use scopes, described in the next section. We will see that inline fault handling of the activity is equal to enclosing the activity in a local scope.

Scopes

Scopes provide a way to divide a complex business process into hierarchically organized parts—scopes. Scopes provide behavioral contexts for activities. In other words scopes address the problem that we identified in the previous section and allow us to define different fault handlers for different activities (or sets of activities gathered under a common structured activity, such as or ). In addition to fault handlers, scopes also provide a way to declare variables and partner links that are visible only within the scope. Scopes also allow us to define local correlation sets, compensation handlers, event handlers, termination handler, and message exchanges. We will discuss these topics later in this chapter. The following code excerpt shows how scopes are defined in BPEL. We can specify , , , , , , , and locally for the scope. All are optional: [ 132 ]

Chapter 3 activity

Each scope has a primary activity. This is similar to the overall process structure, where we have said that a BPEL process also has a primary activity. The primary activity, which is often a or , defines the behavior of a scope for normal execution. Fault handlers and other handlers define the behavior for abnormal execution scenarios. The primary activity of a scope can be a basic activity such as , or it can be a structured activity such as or . Enclosing the activity with a scope and defining the fault handlers is equivalent to using inline fault handlers. The inline fault handler shown in the previous section is equal to the following scope:

If the primary activity of a scope is a structured activity, it can have many nested activities where the nesting depth is arbitrary. The scope is shared by all nested activities. A scope can also have nested scopes with arbitrary depth. The variables defined within a scope are only visible within that scope. Fault handlers attached to a scope handle faults of all nested activities of a scope. By default behavior, faults not caught in a scope are rethrown to the enclosing scope. Scopes in which faults have occurred are considered to have ended abnormally, even if a fault handler has caught the fault and not rethrown it. Similarly as for the , we can define the exitOnStandardFault for a scope as well. If set to no, which is the default, the scope can handle the faults using the corresponding fault handlers. If set to yes, then the scope must exit immediately if a fault occurs (similarly to if it reached an activity). If we do not set this attribute, it inherits the value from its enclosing or .

Example

To demonstrate how scopes can be used in BPEL processes, we will rewrite our asynchronous travel process example and introduce three scopes: •

In the first scope, we will retrieve the employee travel status (RetrieveEmployeeTravelStatus)

•

In the second scope, we will check the flight availability with both airlines (CheckFlightAvailability)

•

In the third scope, we will call back to the client (CallbackClient)

We will also declare those variables that are limited to a scope locally within the scope. This will reduce the number of global variables and make the business process easier to understand. The major benefit of scopes is the capability to define custom fault handlers, which we will also implement. The high-level structure of our travel process will be as follows: . ... ... [ 134 ]

Chapter 3 ... ... ... ... ...

To signal faults to the BPEL process client, we will use the ClientCallbackFault operation on the client partner link, which we defined in the previous section. This operation has a string message, which we will use to describe the fault. In real-world scenarios, the fault message is more complex and includes a fault code and other relevant information. [ 135 ]

Advanced BPEL

Let us start with the example. The process declaration and the partner links have not changed:

The variables section will now define only global variables. These are TravelRequest, FlightDetails, TravelResponse, and TravelFault. We have reduced the number of global variables, but we will have to declare other variables within scopes:

Next we define the global fault handlers section. Here we use the activity, through which we handle all faults not handled within scopes. We will signal the fault to the BPEL client: [ 136 ]

Chapter 3 string('Other fault')

The main activity of the BPEL process will still be , and we will also specify the activity to wait for the incoming message from the client:

First scope

Now let's define the first scope for retrieving the employee travel status. Here we will first declare two variables needed for the input and output messages for web service operation invocation:

[ 137 ]

Advanced BPEL

Next we will define the fault handlers section for this scope. We will use the activity to handle all faults, including Employee web service WSDL faults, communication faults, and other runtime faults. We will signal all faults to the client, although in real-world scenarios we could invoke another web service or perform other recovery operations: string('Unable to retrieve employee travel status')

Next we will start a sequence (which is the main activity of the scope) and prepare the input variable, invoke the Employee web service, and prepare the input for both airlines' web services:

Second scope

In the second scope, we check the flight availability with both airlines' web services. First we declare two variables for storing output from both web service operations:

Next we define the fault handlers section, where we use the activity, similar to the first scope: string('Unable to invoke airline web service')

The main activity of the second scope will be a , in which we will first concurrently invoke both airlines' web services using a activity and then select the best offer using an activity: $FlightResponseAA.confirmationData/aln:Price <= $FlightResponseDA.confirmationData/aln:Price [ 140 ]

Chapter 3

Third scope

In the third scope. we call back to the BPEL client. For this scope we do not need additional variables. However, we define a fault handler to handle the TicketNotApproved fault. Therefore, we explicitly specify the fault name and the fault variable. Note that we do not use the activity in this fault handlers section, so all unhandled faults will be rethrown to the main process fault handler:

The main activity of this scope is the activity, where we check if the flight ticket has been approved: $TravelResponse.confirmationData/aln:Approved='true' [ 141 ]

Advanced BPEL string('Ticket not approved')

Isolated scopes

For each scope, we can specify whether we require concurrency control over shared variables, partner links, and dependency links. We will need such control if, in our scenario, more than one instance uses shared variables concurrently. This can occur, for example, if we use a parallel loop, which starts several parallel branches of the same . Scopes that require concurrency control are called isolated scopes. In isolated scopes, it is ensured that the results of the scope will be equal, if all conflicting activities on all shared variables and partner links are done in any possible sequence. This guarantees that there will be no conflicting situations if several concurrent scopes access the same set of shared variables. Conflicting operations are, in this case, all read/write and write-only activities, such as assignments, incoming messages stored in variables, and so on. The semantics of isolated scopes are similar to the serializable transaction isolation level.

[ 142 ]

Chapter 3

We denote a scope as isolated using the optional attribute isolated, and setting it to yes. The default value of this attribute is no. Isolated scopes must not contain other isolated scopes (but may contain scopes that are not marked as isolated). The fault handlers (and other handlers) associated with the scope also share the isolation. The following code excerpt shows how to declare a scope as isolated:

Compensation

Compensation, or undoing steps in the business process that have already completed successfully, is one of the most important concepts in business processes. Let us discuss compensation on our travel process and suppose that in addition to checking the flight availability, our business process would also have to confirm the flight tickets, make the payments, reserve a hotel room, and make the payment for the hotel room. If the business travel is canceled (for various reasons), the reservation and payment activities would have to be undone, that is, compensated. In business processes, the compensation behavior must be explicitly defined. Therefore, when defining the BPEL process, we would have to explicitly define how to compensate the flight ticket confirmation, how to compensate the flight ticket payment, and so on. The goal of compensation is to reverse the effects of previous activities that have been carried out as part of a business process that is being abandoned.

Compensation is related to the nature of most business processes, which are long running and use asynchronous communication with loosely coupled partner web services. Business processes are often sensitive in terms of successful completion, because the data they manipulate is sensitive. Because they usually span multiple partners, (often multiple enterprises) special care has to be taken that business processes either fully complete their work or that the partial (not fully completed) results are undone, that is, compensated. In enterprise information systems, processes that have not been able to finish all their activities and need to undo the partial work are usually handled with transactions, more exactly with an ACID distributed transaction model, such as X/Open DTP (Distributed Transaction Processing). ACID stands for Atomicity, Consistency, Isolation, and Durability and defines a transaction model that uses data locking and isolation. Such a model works perfectly well in trusted domains within enterprises, under the prerequisite that the duration of transactions can be relatively short. [ 143 ]

Advanced BPEL

The problem with business processes is that they usually last a long time, sometimes several hours, and sometimes even a few days. This is much too long for the ACID model, because we cannot afford to lock certain data for such a long time and to isolate access to these data. In business processes, compensation is used instead of ACID to reverse the effects of an unfinished process. Compensation requires that an activity specifies a reverse activity, which can be invoked if it is necessary to undo the effect of that activity. BPEL supports the concept of compensation with the ability to define compensation handlers, which are specific to scopes and calls this feature Long-Running Transactions (LRT). The concept of compensation and LRTs as defined by BPEL is independent of any transaction protocol and can be used with various business transaction protocols. BPEL is bound to web services. It is, however, reasonable to expect that in most cases the LRTs will be used with the WS-BusinessActivity (WS-Transaction) specification. The BPEL specification even defines a detailed model of BPEL LRTs based on WSBusinessActivity concepts. It is very important to understand that compensation differs from fault handling. In fault handling, a business process tries to recover from an activity that could not finish normally, because an exceptional situation has occurred. The objective of compensation on the other hand is to reverse the effects of a previous activity, or a set of activities, that have been carried out successfully as part of a business process that is being abandoned. Note that the order in which compensation activities are run is often important. BPEL addresses this aspect with scopes.

Compensation handlers

To define the compensation activities, BPEL provides compensation handlers. Compensation handlers gather all activities that have to be carried out to compensate another activity. Compensation handlers can be defined: •

For the scope

•

Inline for the activity

BPEL 2.0 does not support compensation handlers on the process level anymore. The reason is that such compensation handlers had to be invoked from outside the process, which was difficult and not very practical.

[ 144 ]

Chapter 3

The compensation handler for the scope is defined immediately after the fault handlers section, as shown in the next code excerpt: activity

Sometimes it is reasonable to define a compensation handler for each activity. We could define a scope for each . However, BPEL provides a shortcut where we can inline the compensation handler rather than explicitly using an immediately enclosing scope. This is similar to the inline capability of fault handlers. The syntax is as follows: [ 145 ]

Advanced BPEL

The syntax of the compensation handler is the same for all three cases: we specify the activity that has to be performed for compensation. This can be a basic activity such as or a structured activity such as or .

Example

Let us suppose that within a business process we will invoke a web service operation through which we will confirm the flight ticket. The compensation activity would be to cancel the flight ticket. The most obvious way to do this is to define the inline compensation handler for the activity as shown in the following example:

Let us now suppose that the business process performs two operations in sequence. First it confirms the ticket and then makes the payment. To compensate these two activities we could define an inline compensation handler for both activities. Alternatively, we could also define a scope with a dedicated compensation handler, as shown in the example that follows: [ 146 ]

Chapter 3

Which approach is better depends on the nature of the business process. In most cases, we will define inline compensation handlers or compensation handlers within scopes. In the global BPEL process compensation handler, we will usually invoke compensation handlers for specific scopes and thus define the order in which the compensation should be performed. Let's have a look at how to invoke a compensation handler.

Default compensation handler

If a is not defined for any given , the BPEL engine implicitly creates a default compensation handler, which compensates all inner scopes:

Invoking compensation handlers

Compensation handlers can be invoked only after the activity that is to be compensated has completed normally. If we try to compensate an activity that has completed abnormally, nothing will happen, because an activity will be invoked. This is useful, because it is not necessary to track the state of activities to know which can be compensated and which cannot. BPEL provides two activities to invoke a compensation handler: •

activity to start compensation on all inner scopes.

•

activity to start compensation on a specified

inner scope.

[ 147 ]

Advanced BPEL

Usually we invoke and activities from a fault handler. and activities can only be used within , , , and .

The syntax is simple and is shown in the following code excerpt. The activity has a target attribute through which we specify which scope should be compensated. We have to specify the name of the scope:

To invoke the compensation handler for the TicketConfirmationPayment scope (shown in the previous section), we could simply write:

To start compensation on all inner scopes, we use the activity. It starts compensation on all inner scopes that have already been completed successfully, in default order. The syntax is very simple:

In the same way, we also invoke the inline compensation handler of the activity. If we invoke a compensation handler for a scope that has no compensation handler defined, the default handler invokes the compensation handlers for the immediately enclosed scopes in the reverse order of completion (remember that the order in which compensations are performed is often important). Compensation handlers can be explicitly invoked only from: •

The fault handler of the scope that immediately encloses the scope for which compensation should be performed

•

The compensation handler of the scope that immediately encloses the scope for which compensation should be performed When a compensation handler is invoked, it sees a frozen snapshot of all variables as they were when the scope being compensated was completed.

[ 148 ]

Chapter 3

In compensation, we can use the same variables as in the regular activities and these variables will have the same values as when the activity being compensated is finished. This means that the compensation handler cannot update live data in the variables the BPEL process is using. The compensation handler cannot affect the global state of the business process.

Termination handler

When a BPEL process instance is executing, there are several scenarios which require that the currently executed activity of a process is terminated, for example: •

When a fault handler is invoked, it disables the scope's event handlers and implicitly terminates all enclosed activities

•

A fault in the fault handler causes termination of all running contained activities

•

When the is fulfilled for a parallel activity, all still running directly enclosed activities are terminated

This is called forced termination. The termination handler provides the ability for scopes to control the forced termination. The syntax of a termination handler is as follows: activity

In a termination handler, we can use the same range of activities as in a fault handler. We can use the or activities. However, in a termination handler, we cannot throw any fault. If an uncaught fault occurs within the termination handler, it is not rethrown to the next enclosing scope.

Default termination handler

If a custom for the scope is not present, the BPEL engine will generate a default termination handler. The default termination handler will trigger the compensation. This is convenient, as it does not require always defining a termination handler. The default termination handler has the following syntax:

[ 149 ]

Advanced BPEL

Managing events

A business process may have to react to certain events. We already know that a business process specified in BPEL usually waits for an incoming message using the activity. This incoming message is the event that activates the whole process. A business process also often invokes web service operations asynchronously. For such operations, results are returned using callbacks. The BPEL process often waits for callback messages, which are also events. Using the activity, we can wait for an exactly specified message on a certain port type. Often, however, it is more useful to wait for more than one message, of which only one will occur. Let us go back to our example, where we invoked the FlightAvailability operation and waited for the FlightTicketCallback callback. In a real-world scenario, it would be very useful to wait for several messages, FlightTicketCallback being one of them. The other messages could include FlightNotAvaliable, TicketNotAvaliable, and so on. Even more useful would be to specify that we will wait for the callback for a certain period of time (for example, five minutes). If no callback is received, we continue the process flow. This is particularly useful in loosely coupled service-oriented architectures, where we cannot rely on web services being available all the time. This way, we could proceed with the process flow even if American Airlines' web service does not return an offer— we would then invoke another airline web service operation. In most business processes, we will need to react to two types of events: •

Message events: These are triggered by incoming messages through operation invocation on port types

•

Alarm events: These are time related and are triggered either after a certain duration or at a specific time

Pick activity

BPEL provides the activity through which we can specify that the business process awaits the occurrence of one of a set of events. Events can be message events handled using the activity and alarm events handled using the activity. For each event, we then specify an activity or a set of activities that should be performed. The syntax of the activity is as follows: [ 150 ]

Chapter 3

Within , we can specify several elements and several elements. The elements are optional (we can specify zero or more), but we have to specify at least one element.

Message events

Both elements take additional attributes. The element is identical to the activity and has the same set of attributes. We have to specify the following attributes: •

partnerLink: Specifies which partner link will be used for the invoke,

•

portType: Specifies the used port type

•

operation: Specifies the name of the operation to wait for being invoked

•

variable: Specifies the name of the variable used to store the incoming message

receive, or reply respectively

We can also specify message exchanges, correlation, and from-parts. But we will discuss this later in this chapter. The basic syntax of is shown in the code excerpt below: ...

[ 151 ]

Advanced BPEL

Alarm events

The element is similar to the element. We can specify: •

A duration expression using a duration expression

•

A deadline expression using an deadline expression

For both expressions we use the same literal format as for the activity described earlier in this chapter. Often we will use the event to specify duration. A typical example is for a business process to wait for the callback for a certain amount of time, for example 15 minutes. If no callback is received, the business process invokes another operation or throws a fault. The deadline approach is useful, for example, if the business process should wait for a callback until an exactly specified time and then throw a fault or perform a backup activity. The following code excerpt shows examples of both with hard-coded times/dates: ... 'PT15M' ... '2004-03-18T21:00:00+01:00'

Instead of hard-coding the exact date and time, or the duration, we can use a variable.

[ 152 ]

Chapter 3

Example

Going back to our travel example, we could replace the activity—where the business process waited for the FlightTicketCallback, with the activity— where the business process will also wait for the FlightNotAvaliable and TicketNotAvaliable operations and throw corresponding faults. The business process will wait no more than 30 minutes, when it will throw a CallbackTimeout fault. The code excerpt is shown next: 'PT30M'

For this example to work, we also need to declare the FlightFaultAA variable and to modify the Airline web service WSDL, to add the FlightNotAvaliable and TicketNotAvaliable callback operations. This is not shown here, but can be seen in the example code, which can be downloaded from Packt's website.

[ 153 ]

Advanced BPEL

Event handlers

The activity is very useful when we have to specify that the business process should wait for events. Sometimes, however, we would like to react to events that occur while the business process executes. In other words, we do not want the business process to wait for the event (and do nothing else but wait). Instead the process should execute, and still listen to events and handle them whenever they occur. For this purpose, BPEL provides event handlers. If the corresponding events occur, event handlers are invoked concurrently with the business process. A typical usage of event handlers is to handle a cancellation message from the client. For example, in our travel process, we could define an event handler that would allow the BPEL process client to cancel the travel at any time. We can specify event handlers for the whole BPEL process, as well as for each scope. Event handlers for the whole process are specified immediately after the compensation handlers and before the main process activity, as shown next: ... ... ... ... ... ... activity

Event handlers for the scope are also specified after compensation handlers. [ 154 ]

Chapter 3

The syntax of the event handler section is similar to the syntax of the activity. Instead of , the message event in is called . The most notable difference is that in we can specify zero or more handlers, and/or zero or more handlers. An event handler must contain at least one or element.



The element indicates that the event handler will wait for a message to arrive. The interpretation of the is very similar to a activity. The syntax of an handler is as follows: element="name" variable="name" messageExchange="name"> ...

We have to specify the following: •

partnerLink of the partner link service that can send the message.

•

operation that is invoked by the partner in order to cause the event.

The operation specified in the event handler can be a one-way or a request/response operation. If it is a request/response operation, the event handler should use a activity to send the response. We can specify other attributes, which are optional. Often, we will also specify: •

portType over which the operation that causes the event will be invoked.

[ 155 ]

Advanced BPEL

•

variable identifies a variable local to the event handler that will contain the message received from the partner. For a variable, we can specify the messageType or the element (depending on the type of variable). The type of the variable must be the same as the type of the input message causing the event.

We can also specify message exchange, correlations, and from parts, which we will discuss later in this chapter. We put all activities that should occur within the event handler into a . Message events () in event handlers can occur multiple times, even concurrently, while the corresponding scope is active. We have to take care of concurrency and use isolated scopes if necessary.

Example

Let us go back to the example and define the event handler that will allow the BPEL process client to cancel the travel at any time. The difficult part here is to define the appropriate activities to be performed when the client does the cancellation. The simplest solution is to terminate the process, as shown next: ... ...

In the real world, we would want to undo some work when a cancellation actually occurs. We could use compensation handlers; however, we would need to structure the activities into scopes and compensate the scopes.

[ 156 ]

Chapter 3



The element indicates a time-driven event. There are three possibilities: •

We can specify a time duration after which the event will be signaled. We use a expression for this.

•

We can specify a specific point in time (deadline) when the alarm will be fired. We use an expression for this. Please note that only one of these two expressions may occur in any event.

•

We can also specify a repeating duration event. In this case, an alarm will be fired repeatedly each time the duration period expires. We use a expression for this.

The syntax of an handler is as follows: duration-expression deadline-expression duration-expression ...



We can specify the expression on its own, or with either the or the expression. If we specify the expression alone, the clock for the first duration starts at the point in time when the parent scope starts. If we specify the expression with either the or the expression, the first alarm is not fired until the time specified in the or expression expires. After that, it is fired repeatedly at the interval specified by the expression. The duration for the is calculated when the parent scope starts.

[ 157 ]

Advanced BPEL

Example

The following example shows an alarm using a duration expression of 12 hours. We could use variable data to specify the duration instead of hard-coding it. ... 'PT12H' ...

Other usage scenarios depend on the actual business process. Note that the examples shown for the process could also be defined within scopes. Because the code differences are minimal, these examples are not shown. The event handlers associated with the scopes are enabled when the associated scope starts. The event handlers associated with the global BPEL process are enabled as soon as the process instance is created. This brings us to the process lifecycle, which we will discuss in the next section.

Business process lifecycle

A business process specified in BPEL, has a well-defined structure. It usually waits for the client to invoke the process. This is done using the activity, as we have seen in the previous chapter. A business process can also use the activity to wait for the initial incoming message. Then the business process typically invokes several operations on partner web services and waits for partners to invoke callback operations. The business process also performs some logic, such as comparison and calculation of certain values. The business process terminates after all activities have been performed.

[ 158 ]

Chapter 3

We can see that each BPEL process has a well-defined lifecycle. To communicate with partners, BPEL uses web services. Web services provide a stateless model for operation invocation. This means that a web service does not provide a common approach to store client-dependent information between operation invocations. For example, consider a shopping cart where a client uses an add operation to add items to the cart. Of course, there could be several simultaneous clients using the shopping cart through the web service. We would like each client to have his/her own cart. To achieve this using web services, each client would have to pass its identity for each invocation of the add operation. This is because the web services model is a stateless model; that is, a web service does not distinguish between different clients. For business processes, a stateless model is inappropriate. Let us consider the business travel scenario where a client sends a travel order, through which it initiates the business process. The process then communicates with several web services and first sends a ticket approval to the client. Later it sends a hotel approval and an invoice. There are usually several concurrent clients using the business travel process. Also, a single client can start more than one interaction with the business process. The business process has to remember each interaction in order to know to whom to return the results. In contrast to stateless web services, BPEL business processes are stateful and support long-running interactions with a well-defined lifecycle. For each interaction with the process, a process instance is created. Therefore, we can think of the BPEL process definition as a template for creating process instances. This is similar to the class-object relation, where classes represent templates for creating objects at runtime. In BPEL, we do not create instances explicitly as we would in programming languages (there is no new command, for example). Rather, the creation is implicit and occurs when the process receives the initial message that starts the process. This can happen within the or activities, so both activities provide an attribute called createInstance. Setting this attribute to yes indicates that the occurrence of that activity causes a new instance of the business process to be created. We usually annotate the initial or of each business process with the createInstance attribute. Going back to our business travel example, this is shown in the following excerpt:

[ 159 ]

Advanced BPEL

If, however, we would like to specify more than one operation, we can use a special form of the activity. Using , we can specify several operations and receiving any one of these messages will result in business process instance creation. We specify the createInstance attribute for the activity. However, we can only specify events. events are not permitted in this specific form. The following example shows the initial business process activity, which waits for the TravelApproval or TravelCancellation operations. Receiving one of these messages results in business process instance creation:

A business process can be terminated normally or abnormally. Normal termination occurs when all business process activities complete. Abnormal termination occurs either when a fault occurs within the process scope, or a process instance is terminated explicitly using the activity. In more complex business processes, more than one start activity could be enabled concurrently. Such start activities are required to use correlation sets.

Correlation and message properties

Business processes use a stateful model. When a client starts a business process, a new instance is created. This instance lives for the duration of the business process. Messages sent to the business process (using operations on port types and ports) need to be delivered to the correct instance of the business process. We would expect this to be provided by the runtime environment, such as a BPEL server. This is the case if an appropriate transport mechanism can be used, such as WS-Addressing. However, in some cases where several partners are involved (for example, if the BPEL process calls service A, which calls service B and service B makes a direct callback to the BPEL process), or a lightweight transport mechanism is used that does not provide enough information to explicitly identify instances (such as JMS), manual correlation is required. In such cases, we will have to use specific business data, such as flight numbers, social security numbers, chassis number, and so on. [ 160 ]

Chapter 3

BPEL provides a mechanism to use such specific business data to maintain references to specific business process instances and calls this feature correlation. Business data used for correlation is contained in the messages exchanged between partners. The exact location usually differs from message to message. For example, the flight number in the message from the passenger to the airline might be in a different location than in the confirmation message from the airline to the passenger, and so on. To specify which data is used for correlation, message properties are used.

Message properties

Messages exchanged between partner web services in a business process usually contain application-specific data and protocol-specific data. Application-specific data is the data related to the business process. In our example, such data includes the employee name, employee travel status, travel destination, and dates, and many others. To actually transfer this data (as SOAP messages, for example) additional protocol-specific data has to be added, such as security context, transaction context, and so on. In SOAP, protocol-specific data is usually gathered in the Header section and application-specific data in the Body section of a SOAP message. However, not all protocols differentiate application and protocol-specific data. In business processes, we will always need to manipulate application-specific data, and sometimes even protocol-specific data. BPEL provides a notion of message properties, which allow us to associate relevant data with names that have greater significance than just the data types used for such data. For example, a chassis number can be used to identify a motor vehicle in a business process. The chassis number will probably appear in several messages and it will always identify the vehicle. Let us suppose that the chassis number is of type string, because a chassis number consists of numbers and characters. Naming it with a global property name, chassisNo, gives this string a greater significance than just the data type string. Examples of such globally significant data are numerous and include social security numbers, tax payer numbers, flight numbers, license plate numbers, and many more. These data can be denoted as properties, whose significance goes beyond a single business process and can therefore be used for correlation. Other properties will be data significant for a single business process only, such as uniform identifiers, employee numbers, and so on. Message properties have global significance in business processes and are mapped to multiple messages. So, it makes sense to name them with global property names.

[ 161 ]

Advanced BPEL

Message properties are defined in WSDL through the WSDL extensibility mechanism, similar to partner link types. The namespace used for property declaration within WSDL is http://docs.oasis-open.org/wsbpel/2.0/varprop. The syntax is simple and shown in the following code excerpt. We have to define a property name and its type: ... ...

Let's go back to our travel process example. The flight number is such a significant data element that it makes sense to define it as a property in the Airline web service WSDL: ... ...

Mapping properties to messages

Properties are parts of messages, usually embedded in the application-specific part of messages. To map a property to a specific element (or even attribute) of the message, BPEL provides property aliases. With property aliases, we map a property to a specific element or attribute of the selected message part. We can then use the property name as an alias for the message part and the location. This is particularly useful in abstract business processes where we focus on message exchange description. Property aliases are defined in WSDL. The syntax is as follows: ... [ 162 ]

Chapter 3 query ...

We have to specify the property name, the message type, and message part, or type, or element. More specifically, to define a property alias, we must use one of the following combinations: messageType and part, type, or element. We also have to specify the query expression to point to the specific element or attribute. The query expression is written in the selected query language; the default is XPath 1.0. We now define the property alias for the flight number property defined in the previous section. In our travel process example, we have defined the TravelResponseMessage in the airline WSDL:

The FlightConfirmationType has been defined as a complex type with the FlightNo element of type xs:string being one of the elements. For the complete WSDL with the type definition, please look in Chapter 2. To define the alias, we write the following code: ... ... [ 163 ]

Advanced BPEL /confirmationData/FlightNo ...

With this, we have defined a global property FlightNo as an alias for the confirmationData part of the FlightConfirmationType message type on the location specified by the query.

Extracting properties

To extract property values from variables, BPEL defines an extension function called getVariableProperty, which is defined in the standard BPEL namespace. The function takes two parameters—the variable name and the property name, and returns the node that represents the property. The syntax is as follows: bpws:getVariableProperty ('variableName', 'propertyName')

To extract the FlightNo property from the TravelResponse variable, we write the following: bpws:getVariableProperty ('TravelResponse', 'FlightNo')

The use of properties increases flexibility in extracting relevant data from the message compared to accessing variables. Using properties, we do not have to specify the exact location of the data (such as flight number), but rather use the property name. If the location changes, we only have to modify the property definition.

Properties and assignments

Properties can also be used in assignments, which is particularly useful in abstract processes. We can copy a property from one variable to another using the activity, as shown in the next code excerpt:

To copy the FlightNo property from the FlightResponseAA variable to the TravelResponse variable, we write the following:

[ 164 ]

Chapter 3

Correlation sets

Now that we are familiar with properties, let's go back to the problem of correlation of messages. Correlation in BPEL uses the notion of properties to assign global names to relevant data used for correlation messages (such as flight number) and to define aliases through which we specify the location of such data in messages. A set of properties shared by messages and used for correlation is called a correlation set.

When correlated messages are exchanged between business partners, two roles can be defined. The partner that sends the first message in an operation invocation, and defines the values of the properties in the correlation set, is the initiator. Other partners are followers and get the property values for their correlation sets from incoming messages. Both initiator and followers must mark the first activity that binds the correlation sets. A correlation set is used to associate messages with business process instances. Each correlation set has a name. A message can be related to one or more correlation sets. The initial message is used to initialize the values of a correlation set. The subsequent messages related to this correlation set must have property values identical to the initial correlation set. Correlation sets in BPEL can be declared globally for the whole process or within scopes. The syntax is as follows: ...

[ 165 ]

Advanced BPEL

An example of a correlation set definition named VehicleOrder that includes two properties chassisNo and engineNo is shown next:

Going back to our example, let's define a correlation set named TicketOrder with a single property, FlightNo: ... ...

Using correlation sets

We can use correlation sets in , , , parts of activities, and parts of event handlers. To specify which correlation sets should be used, we use the activity nested within any of the earlier-mentioned activities. The syntax is as follows: ... ...

[ 167 ]

Advanced BPEL

Concurrent activities and links

In business processes, activities often occur concurrently. In BPEL, such concurrent activities are modeled using the activity. Activities within start concurrently as soon as the is started. The completes when all nested activities complete. Gathering nested activities within is straightforward and very useful for expressing concurrency scenarios that are not too complicated. We have used it in the examples in this and the previous chapter. To express more complex concurrency scenarios, provides the ability to express synchronization dependencies between activities. In other words, we can specify which activities can start and when (depending on other activities), and define dependencies that are more complex than those expressed with a combination of and activities. For example, we will often specify that a certain activity or several activities cannot start before another activity or several activities have finished. We express synchronization dependencies using the construct. For each link, we specify a name. Links have to be defined within the activity. Link definitions are gathered within a element. This is shown in the following code excerpt: ...

These links can now be used to link activities together. For actual linking, we use standard elements that can be used with any BPEL activity.

[ 168 ]

Chapter 3

Sources and targets

For each BPEL activity, whether basic or structured, we can specify two standard elements for linking activities and expressing synchronization dependencies. These two standard elements are nested within the activity: •

is used to annotate an activity as being a source of one or more links

•

is used to annotate an activity as being a target of one or more links

Every link declared within must have exactly one activity within the flow as its . It must also have exactly one activity within the flow as its . A link's target activity can be performed only after the source activity has been finished.

The syntax of the element is shown ahead. We have to specify the link name, which has to be defined within the activity. Optionally, we can specify the transition condition. We will say more on transition conditions later in this section. If the transition condition is not specified, the default value is true. We can specify one or more elements within the : boolean-expression



The syntax of the element is also quite simple. We only have to specify the link name. Optionally, we can specify a join condition. We will discuss join conditions later. If no join condition is specified, the default join condition is the disjunction (logical or) of all incoming link statuses for this activity. For now, we will use targets with a default join condition. We can specify one or more elements within the . The syntax is shown next: boolean-expression



[ 169 ]

Advanced BPEL

Example

Let's now consider the business travel example. There the process had to invoke the Employee Travel Status web service first (synchronous invocation) to get the employee travel class information. Then it asynchronously invoked the American and Delta Airlines' web services to get flight ticket information. Finally, the process selected the best offer and sent the callback to the BPEL client. In Chapter 2, we used a combination of and activities to control the execution order. These two activities allowed us to perform basic synchronization, but they are not appropriate for expressing complex synchronization scenarios. In such scenarios, we should use links. To demonstrate how to use links, let's use the business travel example. But keep in mind that the scenario of our example is simple enough to be expressed using a combination of and activities, without the need for links. We will use the example for simplicity. In the real world, we use links only where the scenario is so complex that it cannot be expressed using a combination of and activities. We have modified the asynchronous travel example and gathered all activities, except the initial and the final , within a single activity. We have also added the name attribute to each activity. Although this attribute is optional, we have added it, because it simplifies understanding which activities have to be linked: ... ...

[ 170 ]

Chapter 3 $FlightResponseAA.confirmationData/aln:Price <= $FlightResponseDA.confirmationData/aln:Price

Note that all activities gathered within will start concurrently, which is not what we want. We therefore use links to express dependencies. First we identify the dependencies: •

The input for the Employee web service (EmployeeInput) has to be prepared before the Employee web service can be invoked (EmployeeTravelStatusSyncInv) [ 172 ]

Chapter 3

•

The invocation (EmployeeTravelStatusSyncInv) of the Employee web service has to be finished before the input for both the airlines' web services can be prepared (AirlinesInput)

•

The input for both airlines' web services has to be prepared (AirlinesInput) before the process can invoke the web services of both airlines (AmericanAirlinesAsyncInv and DeltaAirlinesAsyncInv)

•

The invocation of the American Airlines web service (AmericanAirlinesAsyncInv) has to be finished before the callback can be received (AmericanAirlinesCallback)

•

The invocation of the Delta Airlines web service (DeltaAirlinesAsyncInv) has to be finished before the callback can be received (DeltaAirlinesCallback)

•

Both callbacks (from American and Delta Airlines: AmericanAirlinesCallback and DeltaAirlinesCallback) have to be received before the best offer can be selected (BestOfferSelect)

Let us now name the links. We will need the following eight links: •

The link from the EmployeeInput to EmployeeTravelStatusSyncInv

•

The link from the EmployeeTravelStatusSyncInv to the AirlinesInput preparation

•

Two links from the AirlinesInput preparation to AmericanAirlinesAsyncInv and DeltaAirlinesAsyncInv

•

The link from AmericanAirlinesAsyncInv to the receive callback AmericanAirlinesCallback

•

The link from DeltaAirlinesAsyncInv to the receive callback DeltaAirlinesCallback

•

The link from AmericanAirlinesCallback to BestOfferSelect

•

The link from DeltaAirlinesCallback to BestOfferSelect

We have to define the links within the activity, as shown in the following code excerpt: [ 173 ]

Advanced BPEL

The dependency of links and activities is shown in the following activity diagram:

Let us now add the and elements to the BPEL process activities: [ 175 ]

Advanced BPEL [ 176 ]

Chapter 3 $FlightResponseAA.confirmationData/aln:Price <= $FlightResponseDA.confirmationData/aln:Price

With this we have defined synchronization dependencies between activities. Note that, according to the BPEL specification, every link within the activity must have exactly one activity within the flow as its source and exactly one activity within the flow as its target. This prevents us from using the same link as the source or target of two activities.

Transition conditions

A element specifies that a certain activity defines an outgoing link. When BPEL processes are executed, outgoing links are evaluated after the activity has finished. Each outgoing link can have a positive or negative status. This status is important when the decision is made to start the linked activity (denoted with ). In our example, the AmericanAirlinesCallback activity defines an outgoing link AmericanAirlinesCallbackToBestOfferSelect. This link is the incoming link of the BestOfferSelect activity. The BestOfferSelect activity has another incoming link, DeltaAirlinesCallbackToBestOfferSelect, which is the outgoing link of the DeltaAirlinesCallback activity. [ 177 ]

Advanced BPEL

After the AmericanAirlinesCallback activity has finished, the outgoing AmericanAirlinesCallbackToBestOfferSelect link is evaluated. More precisely, the expression of the outgoing link is evaluated. If the is evaluated to true, the link status is positive. Otherwise it is negative. We have already mentioned that the element has an optional nested element called . We have also mentioned that if the element is omitted, a default value of true is used. In our previous example, therefore, the outgoing link status was always true. Let's now modify the example and explicitly add the transition condition. The outgoing link will be positive only if the flight ticket is approved. This is signaled using the Approved element of the FlightConfirmationType complex type, which is a confirmationData part of the TravelResponseMessage message, used for the FlightResponseAA and FlightResponseDA variables (see the previous chapter for corresponding WSDL definitions). We will use the Approved element from the confirmationData part of the message stored in the FlightResponseAA variable. The code is shown next: $FlightResponseAA.confirmationData/aln:Approved='true'

We will do the same for the DeltaAirlinesCallback activity: $FlightResponseDA.confirmationData/aln:Approved='true'

Both outgoing links are now evaluated using the transition conditions and the statuses can be determined.

Join conditions and link status

The AmericanAirlinesCallbackToBestOfferSelect and the DeltaAirlinesCallbackToBestOfferSelect are the incoming links for the BestOfferSelect activity. In order to start the BestOfferSelect activity: •

The status of both the incoming links has to be determined. As we already know, the status is determined using the expression.

•

The join condition for the BestOfferSelect activity has to be evaluated.

The join condition is specified using the standard element called . This element may be specified for each activity that is the target of a link (has at least one incoming link). If no is specified, the default (for the default expression language XPath 1.0) is the logical disjunction (logical or) of the link status of all incoming links of this activity. In other words, if the is not explicitly defined, all incoming link statuses are evaluated and the status of at least one incoming link has to be positive. The consequence of evaluating all incoming link statuses is the synchronization of all incoming activities. In our example, the default (implicit) join condition for the BestOfferSelect is therefore a disjunction of both incoming link statuses—the AmericanAirlinesCallbackToBestOfferSelect and the DeltaAirlinesCallbackToBestOfferSelect. The join condition will be evaluated to true if at least one of the airlines has approved the flight tickets. Please notice that the incoming link statuses of both links will be evaluated prior to the decision.

[ 179 ]

Advanced BPEL

Sometimes the default disjunction will not fit our needs and we will want to define our own join condition. To do this we will use the element. We have to specify this element for the target link activity as the first element under . In our example, we would define the for the BestOfferSelect activity. For the , we can specify any valid Boolean expression using the selected expression language (the default is XPath 1.0). Often we will also want to check the status of the incoming links. We can access the link statuses in a similar way as variables ($link). The link status returns true if the status of the link is positive, and false if the status of the link is negative. In , we can only access the status of links that target the join condition's enclosing activity. We cannot access any other variable. Suppose, instead of the disjunction of link statuses, we would rather use a conjunction. Then we would define the following joinCondition: $AmericanAirlinesCallbackToBestOfferSelect and $DeltaAirlinesCallbackToBestOfferSelect $FlightResponseAA.confirmationData/aln:Price <= $FlightResponseDA.confirmationData/aln:Price

Join failures

Join conditions are evaluated before the activity is started. In our example, the join condition would be evaluated to true only if both link statuses (AmericanAirlinesCallbackToBestOfferSelect and DeltaAirlinesCallbackToBestOfferSelect) are positive. A positive join condition is required for starting the activity.

[ 180 ]

Chapter 3

If a join condition evaluates to false, a standard bpel:joinFailure fault is thrown. A bpel:joinFailure can be thrown even if a join condition is not explicitly specified. In our previous example (before explicitly specifying the join condition), the default join condition would be used and would be evaluated to false if both link statuses were negative. This would be the case if neither American, nor Delta Airlines, would approve the flight ticket.

Suppressing join failures

Sometimes, it would be more useful if, instead of throwing a bpel:joinFailure fault, the activity would simply not be performed without any fault thrown. BPEL provides an attribute through which we can express this behavior. The attribute is called suppressJoinFailure and is a standard attribute that can be associated with each activity (basic or structured). The value of the attribute can be either yes or no. The default is no. In our example, we could suppress join failure for selecting the best offer activity as shown next: $AmericanAirlinesCallbackToBestOfferSelect and $DeltaAirlinesCallbackToBestOfferSelect $FlightResponseAA.confirmationData/aln:Price <= $FlightResponseDA.confirmationData/aln:Price

Please notice that in the previous example the suppressJoinFailure="yes" is an attribute of the activity, not the actual condition. The condition is defined within the expression. This means that if even one link status is negative, the activity will not be performed and no fault will be thrown—in other words, the activity would be silently skipped. Skipping the activity is equivalent to catching the fault locally, with an fault handler.

[ 181 ]

Advanced BPEL

The consequence of skipping an activity is that outgoing links become negative. This way the next activity figures out that the previous activity has been skipped. In our example, the activity to select the best offer does not have outgoing links. The default value of the suppressJoinFailure attribute is no. This is because, in simple scenarios without complex graphs, such behavior is preferred. In simple scenarios, links without transition conditions are often used. Here the developers often do not think about join conditions. Suppressing join failures would lead to unexpected behavior where activities would be skipped. In complex scenarios with networks of links, the suppression of join failures can be desirable. If such behavior is desirable for the whole BPEL process, we can set the suppressJoinFailure attribute to yes in the first process element (often a ). Skipping activities with join conditions evaluated to false, and setting the outgoing link statuses to negative, is called dead-path-elimination. The reason is that in a complex network of links, with transition conditions, such behavior results in propagating the negative link status along entire paths until a join condition is reached that evaluates to true. With this, we have concluded our discussion on concurrent activities, links, and transition conditions. In the next section, we discuss dynamic partner links.

Dynamic partner links

So far we have discussed BPEL processes where all partner links have been defined at design time and related to actual web services. We have used a single partner link for each web service we have communicated with. In an advanced BPEL process, we might want to define the partner link endpoint references at runtime. This means that the BPEL process will dynamically determine which actual web service it will use for a certain invocation, based on the variable content. This is particularly useful in scenarios where the BPEL process communicates with several web services that have the same WSDL interface. This has been the case for our travel process example, where American and Delta Airline web services shared the same interface. To understand how we can define partner link endpoint references dynamically at runtime, let us look at how endpoint references are represented in BPEL. BPEL uses endpoint references as defined by WS-Addressing. For each BPEL process instance, and for each partner role in a partner link, a unique endpoint reference is assigned. We already know that this assignment can take place at deployment or at runtime. To make such an assignment at runtime, we use the activity. There are several ways in which we can use this. We can copy from one partner link to another using the following syntax: [ 182 ]

Chapter 3

In the activity, we have to specify the endpoint role, which can be myRole or partnerRole. In the activity, the partner link is always copied to the partnerRole. We can also copy a partner link to a variable:

The most interesting method, however, is to copy a variable, expression, or XML literal to a partner link. This way, we can store the partner link endpoint reference in a variable and copy it to the partner link at runtime, thus selecting the service, which will be invoked dynamically. The syntax for copying a variable to a partner link is as follows:

The partner link endpoint reference, in BPEL is represented as service reference container . This container is used as an envelope to wrap the actual endpoint reference value. For the actual endpoint reference the WS-Addressing wsa:EndpointReference XML element is used. The wsa namespace URL is http://schemas.xmlsoap. org/ws/2004/08/addressing. The wsa:EndpointReference element is of type wsa:EndpointReferenceType and has the following structure: ServiceURL …

[ 183 ]

Advanced BPEL … PortTypeName ServiceName

We can see that the endpoint reference is the only required element. The should include a valid URL of the partner link service. To dynamically assign an endpoint reference to a partner link, we have to declare a variable of element type , and copy it to the partner link. Alternatively, we can hard-code the address into the BPEL process and copy the XML literal to the partner link. This is shown in the following example. It is assumed that a service is available on the specified URL: http://www.soa.si/default/AmericanAirline

With this, we have concluded the discussion on dynamic partner links. Please refer to Chapter 4, BPEL Processes with IBM WebSphere for a working demonstration.

[ 184 ]

Chapter 3

Message exchanges

In scenarios where operations are invoked using the request/response pattern, we always have a situation where an inbound message activity has to be related with a reply activity. The inbound message activity can be a , , or . The reply activity is always a . In most cases, the BPEL engine will figure out itself which reply activity relates to which inbound message activity. However, if there can be more than one pair of inbound message activities (, , or ) and , we have to explicitly mark the pairing relationship. We do this using message exchanges. To use message exchanges, we first have to declare them. We declare message exchanges immediately after partner links. We can declare message exchanges for the process or for each individual scope: ...

To explicitly specify the pairing, we use the messageExchange attribute on the following activities: • •

, , or for inbound messages for outbound messages

For example, let's suppose we would like to explicitly denote a message exchange called TravelExchange. First, we have to declare it:

Next, we have to add the messageExchange attribute to the corresponding inbound and outbound activities. In our case, we use and : ... [ 185 ]

Advanced BPEL

From-parts and To-parts

In BPEL, activities such as , , , and such others deal with messages. An activity will send a message to the service that is being invoked and will also receive a message from that service as a response (if we use a request/response operation). A operation will wait for an incoming message. A activity will send a response message. Usually these messages are stored in BPEL variables. For example, for an activity, we can specify the inputVariable and outputVariable attributes. However, BPEL provides an alternative. Instead of using variables, we can deal with WSDL messages directly and specify how to store them to and extract them from BPEL variables. This alternative approach is particularly useful if the messages have multiple parts (please refer to Chapter 2 or the WSDL specification for a discussion on message parts). If we use the inputVariable and outputVariable attributes, then the whole message is stored in a single variable. With the alternative approach, we can store and extract each message part separately. This gives us additional flexibility, as we can store different parts to different variables or only store some parts of the message. To specify how message parts should be stored and extracted, we use the

and activities.



The activity is used to specify how to store the different message parts to BPEL variables. We can specify in the following BPEL activities that receive messages: •



•

(within )

• (within ) • (for receiving the response in request/response operations) The syntax is equal for all mentioned activities. The is always nested within one of the mentioned BPEL activities. We have to specify the message part name (part), and the BPEL variable name to which the message part will be stored. We can specify as many parts as we like, as shown next: ... [ 186 ]

Chapter 3

If we specify parts, we must not specify the variable attributes (such as inputVariable and outputVariable). For example, if we would like to use within a activity, we could use it as shown in the following code excerpt: that contains and . In the body, there are usually input data for the service operation (payload). Other data (such as credentials, correlation, and others) are contained in the header. Web services in Java can be implemented with JAX-WS (Java API for XML Web Services) or JAX-RPC (a predecessor of JAX-WS called Java API for XML-based Remote Procedure Call) API. JAX-WS uses annotations introduced in Java SE 5 to make development and deployment of web services and their clients an easier task. JAX-WS is the preferred approach to service development. In WebSphere, JAX-WS supports WS-Policy sets to configure web service behavior in a declarative way. WS-Policy is a framework for expressing characteristics (like capabilities or requirements) of web services. It uses flexible and extensible constructs. Each policy is a collection of many policy alternatives, each containing policy assertions. Policy assertions are used to express web service characteristics. In WebSphere, specific WS-Policy policies are grouped together in policy sets, each policy set containing one or more WS-Policy policies. The main purpose of using WS-Policy in WebSphere is to specify different web service behaviors, for example, to specify different security aspects. One of the most important security specifications for web services supported in WebSphere is WS-Security. WS-Security (WSS) is a specification for delivering end-to-end security for web services. It provides extension to SOAP (to 1.1 and 1.2 versions) for assuring message content integrity and confidentiality. WS-Security supports a variety of security models such as PKI, Kerberos, and SSL. Moreover, WS-Security supports multiple security token formats (username token, binary security token, XML token, and EncryptedData token), trusted domains, signature formats and algorithms (Exclusive XML Canonicalization, SOAP Message Normalization), and encryption technologies (symmetric and asymmetric).

[ 322 ]

Chapter 6

A WSS username token contains a username and is extensible to include possible authentication data, such as a password and additional data to increase security like a nonce (unique identifier to prevent replay attacks) or timestamp (to prevent replay attacks by leveraging message expiration methods). A WSS binary security token provides only one XML element which contains binary data (for example, X.509 certificate or Kerberos ticket). An XML token is an abstract token that is concretized into WSS subsequent specifications. One of the tokens is an SAML token (Security Assertion Markup Language), which is used for exchanging authentication and authorization data between different security domains (identity providers and service providers). An EncryptedData token is an encrypted version of any token contained in a WSS header to provide token confidentiality.

Securing a BPEL process

We will explain how to secure a BPEL process with an example. We will expose the BPEL process as a web service. This way, a client will be able to call it in a standardized way. Next, we will create a new WS-Policy set that will require the client to provide a WS-Security header with UsernameToken containing the username and password for user authentication. We will attach this WS-Policy set to our BPEL process's web service export to protect the process. Only authenticated users will have access to the BPEL process. We will then test the example, with and without providing credentials, to see if security is working. Next, we will see that authentication information (user's identity) is not automatically propagated to the BPEL process. So, the process does not know which user called it. We will extract a user's identity from UsernameToken and propagate this identity to the BPEL process. Through another round of testing, we will see that the user who called the process will become the process instance owner. The final step in this example will be to configure the BPEL process in a way that only authenticated users, who are authorized, will be able to call it. To achieve this, we will have to define the security permission qualifier on our BPEL process, define a role that will have access to our BPEL process, and map users to this role to actually allow specific users to access our BPEL process. Later on, we will be able to add or remove users from the role to enable runtime access permission update for specific users.

[ 323 ]

Securing BPEL Processes

Exposing a BPEL process as web service

We will expose a BPEL process as a web service with the help of the following steps: 1. Let us take the Travel Approval BPEL process and open it in the WebSphere Integration Developer. The Travel Approval process is an SCA component with an interface. The Travel Approval process and surrounding components are shown in the assembly diagram represented in the following screenshot:

The Travel Approval process that we will use in this chapter is very similar to the process that we have developed in the previous chapter. The only difference is that this process also sends an e-mail to confirm the reservation. You can download the sample from http://www. packtpub.com. The sample can be deployed to the IBM WebSphere Process Server using the IBM WebSphere Integration Developer.

2. We can expose this process as a web service by generating a web service export. We can generate the web service export by right-clicking on the TravelApproval process and selecting Generate Export … and then Web Service Binding from the context menu, as shown in the following screenshot:

[ 324 ]

Chapter 6

3. The Travel Approval process implements more than one interface, so a dialog asks us which interface to expose. We should select the interface that is used to run the process, that is, the TravelApprovalPT interface, as shown in the following screenshot:

[ 325 ]

Securing BPEL Processes

4. Next, we have to select the transport protocol. There are four options as we can see in the following image. The first two are using the HTTP protocol with JAX-WS as the implementation framework and the SOAP protocol of versions 1.1 and 1.2 respectively (the name Simple Object Access Protocol behind the SOAP abbreviation was dropped in version 1.2). SOAP 1.2 brings several advancements over SOAP 1.1. For example, it assures better interoperability, better support standards like XML Information Set (a set of definitions for use in other specifications), is truly protocol independent, and has better and more formalized extensibility. The third option uses JAX-RPC as the implementation framework for SOAP 1.1. The last option doesn't use HTTP as the transport protocol but instead uses JMS (Java Message Service). We will use WS-Policy to define authentication rules, so we need the WSPolicy support that is offered only with JAX-WS binding. We will choose usage of SOAP messages of version 1.2, that is, SOAP1.2/HTTP, as the latest standard, as shown in the following screenshot. Alternatively, we could also use SOAP 1.1 with JAX-WS.

5. At this point, we need to save our assembly diagram, because we will rename the newly generated export to have a more descriptive name. We will use the refactoring option for renaming SCA components, imports, and exports. Refactoring is enabled by right-clicking on our newly created web service export, TravelApprovalPTExport1 | Refactor … | Rename, as shown in the following screenshot: [ 326 ]

Chapter 6

6. We choose TravelApprovalWS as the new name for the export and click on Refactor:

7. When we created the web service export, WebSphere Integration Developer generated the following artifacts: °Â°

Web service binding TravelApprovalWS_ TravelApprovalPTHttpBinding in namespace http:// packtpub.com/bpel/travel/Binding

°Â°

A service called TravelApprovalWS_ TravelApprovalPTHttpService with port TravelApprovalWS_TravelApprovalPTHttpPort and endpoint address http://localhost:9080/ SecuringBPELWeb/sca/TravelApprovalWS

[ 327 ]

Securing BPEL Processes

Note that the endpoint address can change when the web service is deployed on another server. We can see all these details if we select our web service export in the assembly diagram and bring up its properties by clicking on Properties | Binding:

8. All these details are actually defined in the WSDL file that was generated in our SecuringBPEL_lib library, which contains data types and interfaces. We can find the TravelApprovalWS_TravelApprovalPTHttpPort WSDL file under Web Service Ports in SecuringBPEL_lib, as shown in the following screenshot:

9. When we open this WSDL file, we can see all the content we described earlier (binding, service, port, address). Notice that the element imports the actual (abstract) interface from TravelApprovalPT.wsdl:

In this section, we have created a web service export for our BPEL process and examined the details that occurred behind the scenes. [ 328 ]

Chapter 6

Creating a WS-Policy set for WS-Security authentication

In this section, we will create a WS-Policy set on WebSphere Application Server through its console. The WS-Policy set will demand WS-Security UsernameToken to be present in the incoming SOAP Header. We will configure UsernameToken to be consumed, and credentials from it authenticated by the WAS users repository to determine if the caller is authentic and can call our TravelApproval BPEL business process. We will achieve the described level of security by completing the following steps: 1. First, we will define a security token that will be consumed at the service. There are UsernameToken, X.509 certificates, LTPA tokens, and Custom tokens available, as shown in the following screenshot. X.509 certificates require that the client send a certificate when invoking the process. An LTPA (Lightweight Third-Party Authentication) token is an IBM-specific token. It allows users to reuse their login credentials across physical servers. A Custom token can be defined to cover some specific requirements. We will use the UsernameToken in our example, because it is the most straightforward to use. Using other tokens is very similar to using UsernameToken, but it requires some additional work on the client side, where the client has to provide additional information (X.509 certificate, for example)

2. Next, we need to make sure that the Universal Test Environment (the WebSphere Application Server instance optimized for the development) is running. Check the Servers view in the WebSphere Integration Developer and if the server is in the state Stopped, run it by right-clicking on it and selecting Start:

[ 329 ]

Securing BPEL Processes

3. After the server is started, open Integrated Solutions Console (enter https://HOSTNAME(localhost):PORT(9043)/ibm/console in the browser or right-click on started server and from the menu select Administration | Run administrative console). Log in as administrator (the default administrator has username admin and password admin). In the console expand Services | Policy sets | Application policy sets:

[ 330 ]

Chapter 6

4. A list of predefined policy sets appears. We will not use a predefined policy set. Rather we will create a new policy set. Click on New… to create a new policy set, as shown in the following screenshot:

[ 331 ]

Securing BPEL Processes

5. To complete the creation of a new policy set, we have to specify its name and optional description. Then we have to add some policies. In our case, we will add only one policy (WS-Security) with one token definition (WS-Security UsernameToken). We will enter WSS UsernameToken only for the Name and Policy that requires client to use WS-Security UsernameToken with proper credentials to access the web service for the Description. Click

on Add | WS-Security:

6. Optionally, we can define intents for each policy that are meant for descriptive (natural language) demands that a policy defines. Enter them in the Intents Satisfied field as shown in the following screenshot (enter Require WS-Security UsernameToken into the text box) and click on Apply.

[ 332 ]

Chapter 6

7. WS-Security is one of the policies in the policy set configuration. Each policy contains a security policy for communication with the service and the bootstrap policy for communication with the trusted service. Secure conversation bootstrap policy is used for the service consumer to acquire a security token for secure conversation from the trust service. This is achieved using a token issuing a WS-SecureConversation or WS-Trust protocol message. We can find both types of policies if we select WS-Security in the Policies list. The communication policy is called Main policy and the bootstrap policy is called Secure conversation bootstrap policy. In our case, the bootstrap policy is disabled and will remain so, because we have not defined any secure/trust requirements in the Main policy. We will not define them, because this is out of the scope of this example.

8. Now, we will set all the details needed for the WS-Security policy to require that the client provides the UsernameToken. If we select Main policy, we can see all available settings that concern WS-Security. By default, Message level protection with asymmetric tokens is enabled. This option is for using digital signatures and encryption. Details are defined in Policy Details section, but more on this a little later. 9. The Require signature confirmation option specifies whether in the response message there should be a signature confirmation token. The WS-Security v1.1 specification defines the XML element , which tells the client what happened when the service checked the request message signature. The Value attribute is important, because it contains the value from the request message. If so, the request was processed as expected. On the other hand, if this attribute is not present, this tells the client that the received response is based on a request that was not signed. If the element is present but empty, this means that something went wrong and the client should proceed accordingly. 10. Under Request message part protection and Response message part protection, we can define parts of request and response messages that should be encrypted and signed. We define this with XPath expressions. [ 333 ]

Securing BPEL Processes

11. Under Key Symmetry, we can choose between symmetric and asymmetric tokens for encryption and signing. After we have chosen the appropriate tokens, we can define all the details for the selected tokens to function properly. Under Policy Details | Algorithms for asymmetric tokens, additional properties for asymmetric encryption are offered. Further discussion on this topic is out of the scope of this example. 12. Security header layout offers four options for elements ordering in the WSSecurity header. A Strict layout means that any usage of other header elements (element referencing) must be preceded with a referenced element declaration. Layout (Lax) allows the order of contents in the header to vary as long as the header elements are defined within the restrictions specified in the WSSecurity specification. Lax but timestamp required first in header and Lax but timestamp required last in header also pose no additional restrictions except on the position of the element that contains a timestamp when the message was created (first or last element in the header). 13. For our example, we will not use message-level protection, so we will uncheck the checkbox next to Message level protection and click on Apply. The result should be as shown in the following screenshot:

14. However, we will use UsernameToken. So, we have to define its usage in the request message. We will select Request token policies under Policy Details (we would choose Response token policies if UsernameToken would be required in the response message). We open the Add Token Type dropdown menu and select UserName: [ 334 ]

Chapter 6

15. To define the UsernameToken usage, we have to specify its name and select its version. For the name, we will enter authentication_token and select WS-Security 1.0. We will use the WS-Security 1.0 specification in this example, as it defines all the necessary elements and is supported in more web service frameworks than the newer v1.1. We could have chosen WS-Security 1.1 without any major differences for the rest of the example

16. We should now save changes to the master configuration by clicking on Save:

We have created a WS-Policy set that demands WS-Security UsernameToken to be present in the incoming SOAP Header. UsernameToken holds user credentials through which users are authenticated on the server. All authenticated users are then allowed to access the TravelApproval BPEL business process. All unauthenticated users cannot access the process any more.

[ 335 ]

Securing BPEL Processes

Securing a BPEL process web service export with a WS-policy set

We have finished configuring the WS-Security policy set. Now, we will export it and import it into WebSphere Integration Developer to include it into the assembly diagram. In this way, we will be able to tell the server to apply the selected policy set on our BPEL process web service export. To use the configured WS-Security policy set on the process web service export, we have to perform the following steps: 1. First, let us export the policy set. On Application policy sets, click the checkbox next to WSS UsernameToken only policy set and click on Export…:

2. A dialog with a link to a ZIP file opens. Click on the link (or right-click and select Save as …) to download the file to a local disk:

[ 336 ]

Chapter 6

3. Next, we have to import the policy definitions to WebSphere Integration Developer. We will select WebSphere Policy Sets and click on Next:

4. Then we will select the ZIP file that we have created in the previous step. The policy set called WSS UsernameToken only is already selected for us to import. We will click on Finish:

[ 337 ]

Securing BPEL Processes

5. Now, we can check if the policy set has been imported properly. To do that, we have to go to the Window | Preferences menu. Select Service Policies in the navigation tree and expand WebSphere Policy Sets | WebSphere v7.0 Policy Sets. There we should see the WSS UsernameToken only policy listed. If we select it, we can see its details (description):

6. The policy set was successfully imported. To use it in the Assembly Diagram editor, we have to restart WebSphere Integration Developer. 7. All that is left here is to apply the imported policy set to our web service export. We will open the assembly diagram of our example. We will select the TravelApprovalWS web service export. In the Properties view, we will select the Policy Sets tab and in the Default policy set: drop-down menu, we select the WSS UsernameToken only policy:

[ 338 ]

Chapter 6

8. The last step is to save the changes made to the assembly diagram. We have successfully defined that the TravelApprovalWS export uses the policy called WSS UsernameToken only. This way, we secured our process through its web service export. We managed to do that by exporting the WSS UsernameToken only policy set from the WebSphere Application Server console and importing it to the WebSphere Integration Developer. The policy set is defined on the server and referenced from our BPEL process module. This way, it is possible to reuse and modify the policy set during runtime.

Testing a secured BPEL process

To test the secured BPEL process, we will deploy our solution on the server, locate the web service endpoint, create a test project, and then test the BPEL process through the web service export. First, we will try to invoke the BPEL process without providing credentials. Then we will invoke it with UsernameToken credentials. 1. First, we will deploy the solution to the server. Open Add and Remove Projects from the server context menu. Select SecuringBPELApp and click on Add. By default, If server is started, publish changes immediately is selected and, in this case, our example will be automatically published on the server. Otherwise, please select this checkbox. Click on Finish.

2. To test the service, we need to locate the TravelApprovalWS web service endpoint. We will use a free tool, soapUI, to test our service. We can download soapUI from http://sourceforge.net/projects/soapui/ files/. [ 339 ]

Securing BPEL Processes

3. To locate the web service endpoint, we will select the export in the assembly diagram and in the Properties | Binding tab and copy the Address: field to the clipboard:

4. We can access the WSDL definition of our web service. This is the best way to create a test project in soapUI. We will paste the URL to the web browser address bar and add a ?wsdl string at the end of the HTTP query string:

5. This way, the browser will redirect us to the absolute path of the WSDL file of our service. We need this address for the soapUI tool to call our BPEL process. 6. We are ready to create a test project in the soapUI. We will open the soapUI tool and create a new soapUI project with the WSDL URL we just located. In soapUI, we will select File | New soapUI Project:

[ 340 ]

Chapter 6

7. To create the test project, we have to provide its name and WSDL location. For the Project Name, we will enter TravelApprovalWS, and in the Initial WSDL/WADL field, we will paste the WSDL URL from the clipboard. Leave other settings as they are and click on OK:

Thus, we have created a test project with a sample request to send to our BPEL process.

Calling a BPEL process without credentials

First, we will try to call our BPEL process without specifying any credentials. This way we will see if the defined security mechanism through the WS-Policy definition works. We will test the security mechanism with the help of the following steps: 1. In the Project tree, we will expand the TravelApprovalWS project until we find the Request 1 SOAP request leaf:

[ 341 ]

Securing BPEL Processes

2. Double-clicking on Request 1 will bring up the skeleton of the SOAP request that soapUI generated from the WSDL file. We can safely delete lines with comments stating that some elements are optional (all lines with ). Now try calling the BPEL process with an empty request by clicking the green triangle ( ) in the top-left corner of the screen.

3. We should get the following error: Error message: A security token whose type is [http://docs.oasisopen.org/wss/2004/01/oasis-200401-wss-username-token-profile1.0#UsernameToken] is required.

We can see that we have secured the BPEL process. We cannot invoke it without security credentials. In the next section, we will provide security credentials in the request.

Calling a BPEL process with credentials

Next, let us specify the credentials in the request and rerun the test by performing the following steps: 1. We will create a UsernameToken containing a username and password for authentication. We will enter the username and the password in the Request Properties view. We will use the default administrator username admin and password admin:

[ 342 ]

Chapter 6

2. Now, we will add the WS-Security UsernameToken to the request by rightclicking on the request content and selecting Add WSS Username Token:

3. UsernameToken supports two types of passwords: °Â° °Â°

PasswordText: Plain text password PasswordDigest: Base-64 SHA-1 hash value of the UTF-8 or equivalent encoded password

The WS-Security specification states that the password digest offers no additional security over the plain text password without using secured transport protocol (such as HTTPS). This is one of the reasons why WebSphere Application Server does not support PasswordDigest. The other reason is that most advanced identity repositories (such as LDAP) use their own encryption/digest algorithms for passwords and many times it is impossible to get a password from the identity repository to create SHA-1 hash and do the comparison between hash from the identity repository and hash in the UsernameToken for authentication. So, we will choose the plain text PasswordText and click on OK, as shown in the following image.

[ 343 ]

Securing BPEL Processes

The wsse:Security header containing UsernameToken with username, password, nonce, and timestamp is inserted. We already mentioned timestamp earlier in this chapter. wsse:Nonce, on the other hand, might be new for us. It is a unique identifier in the request message to prevent replay attacks. See the next image for a nonce example. 4. Now, let us insert some test data into our request. Let us do that, because in the next step we will call our BPEL process with proper credentials and the BPEL process will not work correctly without the data specified.

5. If we try to run our BPEL process, we will see that it starts. We can see a new process instance in the Business Process Choreographer (https:// HOSTNAME(localhost):PORT(9443)/bpc, or right-click on the server in the Server view and select Launch | Business Process Choreographer Explorer). We can locate one process instance of the TravelApproval process in the Process Instances | Administrated by me view. 6. If we click on that process instance, we can see its details. Be aware of Starter and Administrators properties where it states UNAUTHENTICATED. This is because so far we only authenticated the client when receiving the request message on the export. We have not propagated the client user identity to the BPEL process. [ 344 ]

Chapter 6

To propagate the user identity to the BPEL process, we have to define the Caller on the web service export. Caller definition ensures that successfully authenticated user identity is propagated to the succeeding service components within an assembly.

Propagating user identity to a BPEL process

To propagate user identity from the UsernameToken to the BPEL process, we will first have to extract that identity from the UsernameToken. Then, we will propagate it to the BPEL process. We will enable identity extraction and propagation through policy set bindings. Policy set bindings will contain token consumer definition for identity extraction and caller definition for identity propagation.

[ 345 ]

Securing BPEL Processes

Extracting user identity from UsernameToken

To enable the extraction of user identity from UsernameToken, we have to define a new policy set binding. We have to set this binding to use a UsernameToken consumer that will be performing the extraction. To achieve this, we have to complete the following steps: 1. First, we have to create a new policy set binding. We will go to the Integrated Solutions Console and expand Services | Policy Sets | General provider policy set bindings:

2. In the General provider policy set bindings list, we can see provided bindings. Apart from BPC Web Service – Provider, which is used for the Business Process Choreographer web service API, all bindings are only samples. Click on the New… button to create a new binding: [ 346 ]

Chapter 6

3. For the new binding, we need to provide a name, description (optional), and policies that the binding refers to (in our example, WS-Security). For the Bindings configuration name, we will enter WSS UsernameToken to Caller Propagation and Propagate WS-Security UsernameToken authentication information to the runtime environment for Description. Now, expand the Add drop-down menu and select WS-Security to add a WS-Security policy:

[ 347 ]

Securing BPEL Processes

4. Next, we will define the token consumer for identity extraction. After clicking on the WS-Security, we will select the Authentication and protection link to define the UsernameToken consumer:

5. Under Authentication tokens we have: °Â°

Protection tokens, which sign messages to provide integrity or encrypt messages to provide confidentiality

°Â°

Authentication tokens, which are used to provide or assert (propagate) the identity

Detailed signing and encryption settings can be defined in the Request message signature and encryption protection and Response message signature and encryption protection sections. Going into details of these two groups of options exceeds the scope of this example. To add a UsernameToken consumer, we will expand the New Token dropdown menu in Authentication tokens and select Token Consumer:

[ 348 ]

Chapter 6

6. We created a new token consumer. If we want it to be the UsernameToken consumer, we have to specify its name, select UsernameToken for its type, and select the appropriate application login. Application login is basically a Java class that performs the actual authentication of the user based on his/her credentials provided in the token. So, for the token name, we will enter WSS UsernameToken Consumer and for its type, we will select UsernameToken v1.0. We will use version 1.0, as it is sufficient for our example. UsernameToken profile v1.1 contains some additional extensions that are used for deriving keys from the password for protecting message contents in the sense of integrity or confidentiality. After we have selected the Token type, the Local part field is automatically filled in for us. If we would have chosen some other authentication token (for example LTPA), Namespace URI would be automatically filled in for us. [ 349 ]

Securing BPEL Processes

We leave JAAS login at the default value (wss.consume.unt), because it is a default Java Authentication and Authorization Service system login for UsernameToken consumers. All described details are shown in the following screenshot:

7. Now, we should save changes made in the console to the master configuration, as shown in the following screenshot:

We have created a policy set binding with a UsernameToken consumer that can extract user identity from the token.

[ 350 ]

Chapter 6

Propagating an extracted user identity to a BPEL process

With the UsernameToken consumer we have defined a user identity extraction from the UsernameToken. Now we have to define a Caller that will propagate the extracted identity to the succeeding components: 1. We will return to the WS-Security settings using the breadcrumb navigation and select the Caller link:

2. We will click on the New button to create a new Caller. We have to specify its name, identity local part (the URL from the token specification that tells from which type of token the identity should be propagated), and application login (the set of Java classes that takes care of token propagation).

[ 351 ]

Securing BPEL Processes

3. For the Name enter WSS UsernameToken v1.0 Caller and for the Caller identity local part enter the URL http://docs.oasis-open.

org/wss/2004/01/oasis-200401-wss-username-token-profile1.0#UsernameToken. This is the URL defined in the UsernameToken

profile v1.0 to uniquely identify UsernameToken. We will leave JAAS login at default (wss.caller), because it is a default Java Authentication and Authorization Service system login for the UsernameToken caller. Click on OK to finish creating the Caller.

We have successfully defined a policy set binding for propagating the identity from the UsernameToken to the succeeding components. We should now save the changes made through editors to the master configuration.

Assigning a policy set binding to propagate an identity to a provider

All that is left to achieve the propagation of the user identity to the BPEL process is to assign the defined policy set binding to the web service that exports our BPEL process. This procedure is necessary after each (re)deploy of the BPEL process to the server: [ 352 ]

Chapter 6

1. Let us assign the policy set binding to the web service provider that represents the web service export of our BPEL process. In the Integrated Solutions Console, expand Services, and click on Service providers:

2. In the Service providers list we can see several providers. We will definitely see two: BFMJAXWSService and HTMJAXWSService. These two providers represent the already mentioned Business Process Choreographer web service APIs, for working with BPEL processes and human tasks respectively.

[ 353 ]

Securing BPEL Processes

We will also see our TravelApproval provider. We will click on TravelApprovalWS_TravelApprovalPTHttpService:

3. In General Properties, we can see a fully qualified XML name of the service. We can look at the service's WSDL document under Additional Properties. There we can also locate the application and the module of the service. In the Policy Set Attachments table, we can see the attached policies to this service provider. There is already the WSS UsernameToken only policy set attached to the provider. We achieved this through the definition in the assembly diagram earlier in this example. Now, we have to add the policy set binding that contains Caller to propagate a user identity to the BPEL process. We will click on the checkbox next to TravelApprovalWS_ TravelApprovalPTHttpService. We will expand the Assign Binding dropdown menu and select WSS UsernameToken to Caller Propagation:

[ 354 ]

Chapter 6

4. With this, we have attached the policy set binding with the proper Caller defined and enabled the user identity propagation. Our configuration should look like the one shown in the following screenshot:

5. We will now save changes made to the master configuration.

[ 355 ]

Securing BPEL Processes

So far, we have configured everything necessary for the propagation of the user identity to the BPEL process. For the configuration to start working in the previous steps, we assigned the defined policy set binding to the web service export of our BPEL process.

Testing user identity propagation to BPEL process

Let us rerun the test case in soapUI to create another instance of the BPEL process. Now the process contains the user identity from the UsernameToken. Our BPEL process is now running in the name and ownership of the user that was authenticated at the web service export. We can check if this is really the case. In the Business Process Choreographer, we will check the details of the created process instance. We will notice that the Starter and Administrators properties contain the identity of the user that called the web service:

Restricting access to a BPEL process

Now our BPEL process knows who has called it. All authenticated users can start a new instance of this process. The next thing that we will do is to restrict the group of users that can call our BPEL process. Only a specific group of users should be able to call our process. We can achieve this through the use of qualifiers. [ 356 ]

Chapter 6

Setting a security permission qualifier

Qualifiers are means to alter behavior of an SCA component. Our BPEL process is an SCA component, so it is possible to define qualifiers to alter its behavior. For a discussion of qualifiers, please refer to Chapter 4, BPEL Processes with IBM WebSphere. We will add a Security permission qualifier to our process. It will define the role name for the authenticated users. We will map this role to specific users in the deployment descriptor. At the runtime (on the server), it will be possible to add or remove users to/ from this role. This way, we will be able to change a set of users that will have access to our process. To achieve this, we need to accomplish the following steps: 1. First, we have to define the Security permission qualifier on our BPEL process. To add the Security permission qualifier we have to select the BPEL process in the assembly diagram and bring up its properties. Select Properties | Details and then expand the Interfaces | TravelApprovalPT | Qualifiers tab on the right-hand side of the pane:

There is already a Join transaction qualifier set. A join transaction qualifier tells whether the component will join the propagated transaction (value of true) from its client or not (value of false).

[ 357 ]

Securing BPEL Processes

2. We will add another qualifier by clicking the Add button. A dialog opens and we select the Security permission qualifier. The Security permission qualifier on a component allows us to specify a role of users that have access to this component.

Other qualifiers that we can set are Data validation (turns on or off data validation in business object towards XSD schema), Join activity session (tells whether a component will join the propagated session from its client or not) and Store and forward (stores messages sent from the component in case of failure, for the administrator to be able to resubmit failed messages after the problem on the target component was fixed). Qualifiers are described in Chapter 4.

3. Next, we have to specify a role name. A role is a logical group of physical groups of users and users without a group assignment. A role defined through the Security permission qualifier restricts the users that can call the SCA component to this role only (direct assignment or indirect assignment through group membership). Select the newly created Security permission qualifier. The Properties of Qualifier Security permission view pops up. Enter TravelApprovalCaller as Role:. Save the changes made to the assembly diagram:

[ 358 ]

Chapter 6

We have defined the authorized role for calling our BPEL process. But this role does not contain any users yet. At this time, no user will be able to call our process. We will test if this holds true.

Testing the authorization mechanism

Let us test if really no one can access our BPEL process at this time. We will try calling it with our administrative user (admin). Republish the changes made to the integration module to the server. After republishing is finished, we have to reconfigure a WS-Policy set binding for Caller, because it is lost during application redeployment. Please repeat the steps described in the section Assigning a policy set binding to propogate an indentity to a provider to rebind the WS-Policy set binding. Try calling the web service export of our BPEL process from soapUI. The call does not work anymore, because the admin user is not in the TravelApprovalCaller role. We get the following exception: Console Exception: Permission denied: User admin is not in role:TravelApprovalCaller and does not have permission to invoke the method

Now we will add the admin user to the TravelApprovalCaller role.

Adding users to an authorized role

We have to map the admin username to the TravelApprovalCaller role. This mapping can be done in the deployment descriptor of our module/application. We will right-click on the SecuringBPEL module and select Open Deployment Editor:

[ 359 ]

Securing BPEL Processes

1. In Module Deployment Editor for SecuringBPEL, expand Module Deployment Configuration | Application Project. Expand Gather Security Roles and click on the Gather security roles link:

2. WebSphere Integration Developer gathers all role definitions from all over the module (for example, from all Security permission qualifiers). After it finishes, it displays a message as shown in the following screenshot:

3. Click on OK and then expand Application Project to check that Security Role (TravelApprovalCaller) was added. Now, we will map the admin user to this role with the help of an authorization table. An authorization table contains all groups, users, and special subjects such as All authenticated users (everyone that is authenticated on the server) and Everyone (all authenticated users and the ones that are not). 4. Right-click on Application Project and select Add | Authorization Table:

[ 360 ]

Chapter 6

5. An authorization table can contain multiple authorizations, each defining groups, users, and special subjects that map to one specific role. We will add one authorization that will provide the mapping for the TravelApprovalCaller role. Right-click on Authorization Table, and select Add | Authorization:

6. In our example, only one role has been gathered. Therefore, the Security role: in the Authorization section was automatically selected:

If we had more roles, it would be necessary to select the appropriate one from the Security Role drop-down menu. [ 361 ]

Securing BPEL Processes

7. Now we will map the admin user to this selected security role. Right-click on the Authorization (role=TravelApprovalCaller) and select Add |User.

8. In the User section, enter admin as User name:

We should save changes made in the Deployment Editor. After the solution redeploys, only admin should be able to call our BPEL process.

Testing the authorization mechanism with an authenticated and authorized user

We have to redeploy our application to the server and invoke another request from soapUI to test if admin can start the BPEL process now. In the Business Process Choreographer, we can see that admin successfully started a new process instance.

[ 362 ]

Chapter 6

Summary

In this chapter, we have become familiar with the principles of securing BPEL processes. We have learned how to protect a BPEL process and how to achieve that it can be accessed by authenticated users only. We have demonstrated how to limit the access to the BPEL process to only those authenticated users that are also authorized to have access to the process. We have shown how to expose a BPEL process as a web service and protect it to accept requests from authenticated users only. We achieved this through WSSecurity UsernameToken, which should hold the username and password of a service consumer. We have shown how to propagate a caller's identity to the BPEL process instance. This way, the client user can be set as the process instance owner. Finally, yet importantly, we used identity propagation to restrict access to the BPEL process to the users that are authorized to access it. We achieved this with authorization rules that limit access to a BPEL process to specific users and groups only. We have shown how to apply authentication on the web service (WS-Security) and component level (SCA qualifier).

[ 363 ]

Iterative Process Development from BPMN to BPEL In many real-world cases, business process development does not go with a swing from business model to its implementation. Business models are often adapted to everemerging business needs, or the process flow may be optimized for better performance of business process execution. When business models are changed, their process implementations should reflect those changes. Similarly, when changes are made to the process implementation, these changes should be reflected back to the corresponding process model. In this chapter, we will learn how to achieve synchronization between business process model and process implementation. We will:

•

Discuss the iterative development lifecycle

•

Model a business process using BPMN

•

Export a process model from the WebSphere Business Modeler (WBM) modeling tool and import it to the WebSphere Integration Developer (WID) development tool

•

Manage process change synchronization between the two tools

Note that when we talk about a business process model (or business model), we imply the BPMN (Business Process Modeling Notation) style of process model. When we talk about process implementation, we have the BPEL process in mind.

Iterative Process Development from BPMN to BPEL

Iterative process lifecycle

The process implementation will usually not start in BPEL. It will start with a business process model created by one or more business analysts. This model will be passed to an IT developer, who will further develop it for execution on the process server. The business process model may change during the implementation (due to changed requirements) or later when the process is already deployed. It can also occur that while implementing the process, the IT developer will make slight changes to the process logic. Such changes need to be synchronized back to the business model. It is obvious that the process development must be iterative through the process lifecycle. As we have mentioned in Chapter 1, Introduction to BPEL and SOA, business process models are usually modeled in BPMN. BPMN models are the basis for process implementation in BPEL. In this chapter, we will show how to model business processes in BPMN using WebSphere Business Modeler. We will also show how to automatically convert process models to BPEL to enable implementation in WebSphere Integration Developer and how to synchronize changes between BPMN and BPEL.

WebSphere Business Modeler and Integration Developer support an iterative business process development lifecycle and provide the possibility to synchronize changes made in one of the tools to another tool and viceversa. This way we do not export business models for implementation just once and then keep them separated. Rather, we keep these two models in-sync throughout the iterative development cycle. In this chapter, we will show a common scenario of the business process iterative development lifecycle. In our example scenario, a business analyst will prepare the business process model that needs to be implemented and deployed to the process server. The business model will be handed over to an IT developer who will start the process implementation. We will call this transition the initial synchronization. While the IT developer is implementing the process, he will receive a new requirement that demands inclusion of a human task in the process flow. To implement this requirement, the IT developer will have to modify the process logic.

[ 366 ]

Chapter 7

We will show how the IT developer can synchronize the changes back to the business model to keep it in-sync with the current implementation. We will call this kind of synchronization technical synchronization. While the business analyst is reviewing the changes made, he will identify that the human task is not placed at the right location in the process flow. For that reason, he will move the human task to its proper location. These kinds of changes need to be synchronized to the implementation model so that the IT developer's process implementation is consistent with the business model. We will show how changes in the business model can be merged to the previously exported process implementation (from the initial synchronization). We will call this type of update business synchronization. If a change in the business model is made when the process implementation is already deployed in the production environment, we use a special case of business synchronization called round-trip synchronization. We will demonstrate the following steps in this chapter: 1. Show how a business analyst can model the business process in WebSphere Business Modeler. 2. Export the business process model from WebSphere Business Modeler and import it into WebSphere Integration Developer (initial synchronization), in order for the IT developer to implement the process. 3. Show how to synchronize the changes made by the IT developer in the process implementation in WID back to the business model in WBM (technical synchronization). 4. Show how to synchronize changes made to the business model in WBM to the already existing process implementation in WID (business synchronization). 5. Show how to synchronize changes made to the business model by the business analyst (in WBM), based on the monitoring results of the production environment process execution, to the process implementation in WID (round-trip synchronization). In our example, we will use the TravelApproval business process that is used throughout the book.

[ 367 ]

Iterative Process Development from BPMN to BPEL

Process modeling in WebSphere Business Modeler

WebSphere Business Modeler does not only provide powerful business process modeling capabilities, but also simulation, analysis, and reporting features. Process modeling can be the starting point for process implementation. From WebSphere Business Modeler, it is possible to export the process model and create a skeleton of the process implementation model in BPEL in WebSphere Integration Developer. On the other hand, the simulation, analysis, and reporting features are helpful for optimizing the performance of business processes. For these tasks, we can use the monitoring data obtained from WebSphere Business Monitor (for a discussion of process monitoring, refer to Chapter 8, Monitoring Business Processes). This way, we can use the relevant data measured from the actual process execution to enhance the simulation results and to identify the optimization points.

Modeling TravelApproval process

Let us start modeling a business process that will serve as an example for this chapter. We will model the TravelApproval business process. This process is the same TravelApproval process as in the previous chapters. At the beginning of the flow, this process retrieves the Employee Travel Status. After that, it inquires for two offers for the airline tickets from two different airlines. Both inquiries are based on the Employee Travel Status. Next, the process waits for both airline companies to send their offers. After receiving them, the process selects the best offer. It makes the flight reservation with the airline that sent the best offer. The process then waits for the confirmation of the reservation. If the flight ticket has been confirmed, a human task is initiated that allows a dedicated employee to make the approval of the reservation. After that, an e-mail notification about the dedicated person's decision is sent to the employee that requested the travel approved/rejected status. A rejection e-mail notification is also sent if the selected airline company has not confirmed the flight ticket reservation. We will take over the role of the business analyst and create a new Business Modeling Project in WebSphere Business Modeler. We will then import business services that we will use in the process. Before we start with process modeling, we will explain the basic process building blocks. We will show how to model the process step by step. Along the way, we will explain how modeling tools work and how we can achieve the same results by alternative paths.

[ 368 ]

Chapter 7

After completing the process model, we will export it from WebSphere Business Modeler to the WebSphere Integration Developer Project using the project interchange file. At this step, the IT developer will take over the development of the process model and will import it to WebSphere Integration Developer to start the process implementation.

Creating a new Business Modeling Project

The first step in modeling a new business process is creating a Business Modeling Project that contains all artifacts related to the business process. To model the TravelApproval business process, we will create a new Business Modeling Project that will contain the process model and its related artifacts as follows: 1. To create a new Business Modeling Project, right-click on the Project Tree view, select New and then select Business Modeling Project…, as shown in the following screenshot:

2. To define a new Business Modeling Project, we have to enter its name and the default catalog name for storing business processes. Enter packtpub.com as New project name and bpel as Default process catalog name. Uncheck the Create process checkbox, because we will manually create a new process later. Click on Next. 3. We can have two different views of the process diagrams. A Free-form layout is the default type. Swimlane layout is known from BPMN and groups activities based on roles that are performing them. We can choose between Free-form Layout and Swimlane Layout in the last step of creating the new Business Modeling Project. Select Free-form Layout, because we will have no activities in the process that should be arranged into Swimlanes. Click on Finish.

[ 369 ]

Iterative Process Development from BPMN to BPEL

A project tree is generated, as you can see in the following screenshot:

Business items are data types that we define and use in our process model. bpel is the default process catalog. Resources are roles and other resources (roles for information on who executes which task; other resources include items such as timetables for the intervals when a specific resource is available). Organizations allow us to define the hierarchy of our organization, including the physical location of departments. This is useful for simulations. Classifiers help us emphasize the details on the process diagrams or group different activities based on some custom criteria. Visually, classifiers are reflected in the coloring of specific diagram elements. Reports offer means to view and print the information derived from the models (for example, process path analysis). Queries allow us to get information about modeling elements (for example, element statistics, such as the number of business items). Results of queries can be then used in reports. Reports are based on queries and all predefined reports have their own predefined queries. Under Business services and Business service objects, all imported WSDL and XSD files are saved. WSDL files represent existing services and XSD files represent existing business service objects (business items).

We have successfully created a new Business Modeling Project by following these steps.

Importing business services

We will import existing business services for the Employee Travel Status, American Airlines, and Delta Airlines. These are the same services as we have used before in this book. We will import the WSDL interface definitions and XSD schemas for these services. The following steps will guide us through this:

[ 370 ]

Chapter 7

1. Right-click on Business services in the Project Tree view and select Import…. WebSphere Business Modeler is able to import a large variety of sources, as shown in the following screenshot. We are importing business services from WSDL and XSD files, so we choose Business services and service objects (.wsdl, .xsd) and click on Next. Business services and service objects are prepared for this example and can be downloaded from http://www.packtpub.com. All required files are contained in CH7_services.zip. Unzip these files to any directory to use them in the example.

[ 371 ]

Iterative Process Development from BPMN to BPEL

2. We have to select the source folder where our WSDL files are located. We can do that by clicking on the Browse… button. When Source directory is selected in the Files view, there we can check specific files to import. We are going to import everything in the source folder. So it is enough to put a checkmark before the main folder as shown in the following screenshot. Make sure that the packtpub.com project is selected under the Target project drop-down box. Click on Next.

3. In the last step of importing business services, we have to decide in which way we will import selected artifacts. We can choose if we would like to Overwrite existing elements. We do not have any existing elements, so we can leave this option unchecked. Secondly, we have to choose how imported artifacts will be structured. The three options for the Destination catalog creation option are Import without child catalogs (all artifacts in the same folder), Create child catalogs using namespace attributes (artifacts are placed in folders based on their namespace definitions), and Create child catalogs using file folder structure (all artifacts are put into the same folders as in the source from where we import them). Choose Create child catalogs using namespace attributes. This is a good practice because namespaces should uniquely define all artifacts. Click on Finish.

[ 372 ]

Chapter 7

All imported business services have been put into the Business services tree based on the namespace values, as we can see in the following screenshot. There we can see the following services: •

EmployeeTravelStatus: This is for retrieving the travel status of the travel reservation requester

•

FlightAvailability: This is for requesting airline travel offers

•

FlightTicketCallbackAA and FlightTicketCallbackDA: This is for receiving ticket offers from two airline companies (American Airlines—AA and Delta Airlines—DA)

•

MakeReservation: This is for making the flight ticket reservations

•

FlightReservationCallback: This is for receiving flight ticket reservation confirmation

•

SendSimpleAlertEmail: This is for sending e-mail notifications

[ 373 ]

Iterative Process Development from BPMN to BPEL

•

In the project tree, there are Business items (data types) that business services import. They have been put into the Business service objects tree, as shown in the following screenshot:

We have successfully imported the (reusable) business services into our project.

Creating a business process

We can further decompose the business process catalog into sub-catalogs. Let us create one sub-catalog in the default catalog called bpel: 1. Right-click on bpel, select New, and then select Process Catalog, as shown in the following screenshot:

[ 374 ]

Chapter 7

2. To create a new process catalog, we have to provide its name. Enter travel as the Name of new process catalog and click on Finish. 3. Now we can create our first business process. Right-click on the travel sub-catalog, select New, and then select Process as shown in the following screenshot:

4. To create a new process, we have to provide its name. Enter TravelApproval for the Name of new process and click on Finish. Now we are ready to start modeling our TravelApproval business process. However, let us first look at the basic building blocks that we can use for process modeling.

Business process building blocks

From a Business Modeling perspective, the business process editor offers many building blocks for process modeling. We will examine only those which are supported when exporting process business model to WID. The building blocks are grouped inside the modeling Palette, as shown in the following screenshot. Palette also offers some tools for working with these blocks and different groups of building blocks (Activities, Gateways, Data, Events, and Compensations).

[ 375 ]

Iterative Process Development from BPMN to BPEL

Palette

We can use the Selection tool ( ) for selecting and moving around building blocks. We can use the Connection tool ( ) to create connections between building blocks to create business process flow. Look for these two tools in the Palette:

There is also Annotation for making notes on the process diagram. Annotations can be attached to specific building blocks. Alternatively, they can be put self-dependent on the modeling surface. Rectangle offers visual grouping of building blocks to emphasize that the marked blocks have something in common or to emphasize their meaning. Annotation and Rectangle can be combined to make notes on specific groups of building blocks. However, they both have no semantic impact on the business process model.

Activities

Activities are the basic building blocks of a business process model. Connections between them form the process flow. Available activities are Task, Human Task, Receive Task, Business Rules Task, Process, While Loop, Do-While Loop, and For Loop as we can see in the following screenshot:

[ 376 ]

Chapter 7

A Task is a generic building block and represents basic atomic activity that performs some business function. There are three special types of tasks called Human Task, Receive Task, and Business Rules Task. A human task is a type of task that the process execution system delegates to a person for completion. A receive task activity is used for a process to receive the data (message) that some external source will provide. When this happens, the process execution can continue. A business rules task is an automated task that executes business rules. Business rules are a set of if-then rules and are useful for modeling business decisions. A Process building block is actually a sub-process in the process we are modeling. A sub-process is a nested process inside the parent process. We use sub-processes when we want to decompose complex tasks into a series of atomic tasks. Another group of special activities are loops. Loops represent sequences of repeating activities. There are three types of loops in WebSphere Business Modeler: While Loop, Do-While Loop, and For Loop. A While Loop repeats while a specified condition is true. A While Loop tests its condition and if it is true, it runs the contained activities. If the condition is false, it does not run the contained activities any more or maybe not even at all (if the condition at the first check is false). A Do-While Loop works in exactly the same way as a While Loop, but checks its condition at the end of all the contained activities. This means that the Do-While Loop runs its contained activities at least one time. On the other hand, a For Loop makes exactly the specified number of repetitions. It contains a counter that increases each time the contained activities have been executed. There is an additional loop exit condition that can be specified in the For Loop. When this condition is met, the For Loop ends prematurely.

Gateways

Gateways are used for process flow branching, routing, merging, and so on. We can group gateways in different ways. Some gateways split the process flow and some gateways merge it. Splitting the process flow can occur in multiple branches at the same time (Fork), or the flow chooses one of the alternative paths (Simple Decision or Multiple-Choice Decision). If we need to bring these branched flows into one flow, we have to use Merge (for simultaneous parallel paths) or Join (for alternative paths). Check these Gateways in the following screenshot:

[ 377 ]

Iterative Process Development from BPMN to BPEL

A Fork splits the process flow into two or more parallel paths. This enables parallel process execution and multiple tasks to be executed in the parallel. For making decisions about which process path to take, we have two types of decision gateways. A Simple Decision chooses between two alternative paths while a Multiple-Choice Decision chooses paths depending on condition evaluation. Simple Decisions have one condition specified that determines which branch to take (one for evaluation of true and one for evaluation of false). On the other hand, each branch of a Multiple-Choice Decision specifies a condition. Depending on the gateway specification, only the first condition that is evaluated to true can activate its branch (exclusive behavior) or all conditions that evaluate to true can activate their branches (inclusive behavior). For joining multiple process paths into a single path, we can use Join or Merge gateways. A Join gateway synchronizes incoming flows in a way that all paths must complete (reach the gateway) before activities succeeding the gateway can start to execute. This is why a Join gateway works very well with a Fork gateway to combine all paths that have been split with the fork gateway back into one flow. On the other hand, the Merge gateway does not wait for all merging paths to complete, but continues execution with succeeding activities after only one of the branches finishes the execution and reaches the gateway. This is the reason why a Merge gateway works best in combination with Simple Decision and Multiple-Choice Decision gateways for merging the alternative paths back into a single path. To summarize, we normally use Merge gateways after decisions and Join gateways after forks.

Data

The Data group combines all building blocks for data manipulation. There are only two building blocks of this type. The first is Repository and the second is Map, as we can see in the following screenshot:

A repository is a storage area for the data objects in a business process. Data objects carry data along the process flow. Every repository needs to have its type defined. This type determines the type of business items that can be stored in that repository. A repository is useful for sharing data among different process activities, especially if these activities are not directly connected with the process flow. Attaching business items to the process flow is the simplest way to transfer data from one activity to the other. We will talk more on this topic when we are showing how to model the business process, later in this chapter. [ 378 ]

Chapter 7

A map is used for transformation of the data from one data type to another data type. Processes will often need to transform data for diverse interfaces of business services.

Events

Events mark the beginning and the end of a process flow. There are Start, End, and Terminate events available, as we can see in the following screenshot:

A Start event marks the beginning of the process. It is possible to have more than one start event, but for better clarity of the model it is wise to use only one. The start event is usually used in the top-level process. An End event is meant to make the process model easier to read. Reaching the end event in one of the process flows will not affect other process flows that are maybe still executing. End events are required for simulation. Process simulation will not work correctly if every process flow path does not have its end marked with an End or Terminate event. A Terminate event terminates the process execution. It is very important for each business process to have at least one terminate event that ends its execution. If possible, each process model should have only one terminate event for better clarity of the model.

Compensations

Compensations are used to rollback the activities that have already been performed (for example, payment could not be completed, so already booked items should be released). Each activity that needs to be compensated must have an Intermediate Event bound to its border (see the following screenshot):

[ 379 ]

Iterative Process Development from BPMN to BPEL

From there a compensation link must be connected to the compensation Activity. A compensation activity specifies the activities that will occur to rollback the already performed activities. When the process flow reaches the compensation End Event, all compensation events fire the connected compensation activities to rollback all the activities that need to be compensated.

Process modeling

Now that we have become familiar with the basic concepts of business process modeling in WebSphere Business Modeler, we can start modeling our example process. Our process should look like this:

1. First, we will create a Employee Travel Status Scope sub-process. Select Process from the Activities group in the Palette. Click on the modeling surface to place the sub-process on the diagram. Rename it to Employee Travel Status Scope by double-clicking it, as shown in the following screenshot. We can also rename the activities through the Properties view by changing the Name property.

[ 380 ]

Chapter 7

2. Next, open Employee Travel Status Scope in a new page by selecting Open In New Page from the context menu. An empty diagram of Employee Travel Status Scope opens. Every process needs a starting point. Since we did not bring any inputs to the sub-process from business items, we have to add a Start event. From the Palette under Events, select Start and drop it on the diagram. 3. Next, we will add the first business service that will execute as an external activity. Locate the EmployeeTravelStatus business service from the Business services tree in the Project Tree. Expand Business services and select packtpub.com | service | employee | EmployeeTravelStatusPT | EmployeeTravelStatus as shown in the following screenshot:

[ 381 ]

Iterative Process Development from BPMN to BPEL

4. Grab EmployeeTravelStatus and drag it to the diagram. We should now have a diagram as shown in the following screenshot:

5. We can notice that the prepared business service has a different icon than the tasks or human tasks. The business service is already named, but there is no restriction to renaming it. Let us rename EmployeeTravelStatus to a more human-friendly name like Employee Travel Status. We cannot rename a business service by double-clicking on it. We have to do it through the Properties view as shown in the following screenshot:

6. We have to prepare the input for calling the business service. We can use a map to achieve that. Select Map from the Data group of the Palette and put in on the diagram. Name it Assign Employee. Repeat this step to put another map on the diagram. Name this one Assign Ticket Request. Select the End event from the Events group and put in on the diagram. We should have a diagram like the one shown in the following screenshot:

[ 382 ]

Chapter 7

7. We have placed all planned activities and events in the Employee Travel Status Scope sub-process. Now we have to create the process flow. Select the Create a connection tool from the top of the Palette, as shown in the following screenshot:

8. Link together events and activities as shown in the following screenshot. Notice that linking maps to the Employee Travel Status business service creates links with business items assigned (EmployeeTravelStatusRequestMessage and EmployeeTravelStatusResponseMessage). This is because the business service has an interface with the input and the output already defined. We can use the Auto-Layout Left to Right tool (shown in the following screenshot) to allow WBM to automatically layout the diagram for us.

[ 383 ]

Iterative Process Development from BPMN to BPEL

9. We will return to the main process and do some modeling there to store the process input to a repository. Return to the main process diagram by clicking on the TravelApproval entry in the breadcrumb that you can see in the previous screenshot. Add a Map and name it Mediate Travel Request on the main process diagram. Link a process boundary in the diagram to the Mediate Travel Request map. When we cross the process boundary, the mouse cursor changes its shape to the connection tool. Once the connection is created, the tool automatically assigns the Text data type to the connection. The Text data type is the default type in WBM.

10. We will change this type to match the anticipated process input type. Rightclick on the connection between the process boundary and the Mediate Travel Request map. From the context menu, select Associate Data… as we can see in the following screenshot:

[ 384 ]

Chapter 7

11. The Type Selection dialog opens up. Let us type TravelReq into the search box. The TravelRequestMessage business service object is automatically expanded. Select it as shown in the following screenshot and click on OK.

TravelRequestMessage is now associated with the connection between the process boundary and the Mediate Travel Request map.

[ 385 ]

Iterative Process Development from BPMN to BPEL

12. We will now add a repository that will store the process input that we have just defined. The Mediate Travel Request map will take care that the process input will be stored in that repository. From the Data group in the Palette, select Repository and put it on the diagram. Double-click on the repository to bring up its Properties. Change its Name to Travel Request. Click on Browse… in the Associated data section (see the following screenshot) and select TravelRequestMessage as the data type, just like we have done before.

13. Connect the Mediate Travel Request map with the Travel Request repository. The created connection gets the TravelRequestMessage assigned automatically, because we selected it as the repository data type. Now our diagram should look like this:

Until now, we got a feeling about how to model business processes in WebSphere Business Modeler. Now, you should continue the modeling of the TravelApproval process. The top-level process diagram should look like the one in the following screenshot:

[ 386 ]

Chapter 7

The Employee Travel Status Scope sub-process should be as shown in the following screenshot:

The Airline Offers Scope sub-process should be as shown in the following screenshot. Note the use of receive tasks and fork/join gateways in this sub-process.

[ 387 ]

Iterative Process Development from BPMN to BPEL

The Airline Selection Scope should be as shown in the following screenshot. Pay attention to the multiple-choice decision and merge gateways.

The Ticket Confirmation Scope uses a human task as shown in the following screenshot.

The Ticket Confirmation Scope sub-process also defines a sub-process called Email Notification that should look as shown in the following screenshot. Notice the use of simple decision and merge activities.

And now, we should have the whole TravelApproval business process modeled. [ 388 ]

Chapter 7

If we do not wish to model the TravelApproval business process, we can download it from http://www.packtpub.com as the Modeler project file CH7_model_is.mar.

Exporting a business process model to WebSphere Integration Developer

In this section, we will do the initial synchronization between the WBM model and the BPEL process implementation in WID. The initial synchronization consists of two steps: •

First, we have to export the business process model from WebSphere Business Modeler

•

Second, we have to import it into WebSphere Integration Developer

To export the business model, WBM provides the Export Wizard. To make sure that the Export Wizard will run successfully, we need to select the correct modeling mode that will reflect the platform on which the process will execute. We will use the WebSphere Process Server mode. Click on Modeling in the menu bar, select Mode, and then choose WebSphere Process Server as shown in the following screenshot:

According to the modeling mode, the appropriate error checking is applied. Errors and/or warnings can be displayed in the Errors tab. All errors need to be resolved before we can export the business process model. Our TravelApproval process model example already has all errors resolved.

[ 389 ]

Iterative Process Development from BPMN to BPEL

Exporting a process model from WebSphere Business Modeler

When all technical attributes have been set and errors resolved, the business model is ready to be exported to the WebSphere Integration Developer. When exporting a business model, the Project Interchange file is created. The following steps need to be followed for exporting: 1. In the Project tree, right-click on the Business Modeling Project that we want to export (in our case packtpub.com) and select Export....

2. All project content will be exported. If we do not need all of the project content to be exported, it is possible to export any single element or catalog of elements. To achieve this, we would only need to right-click on the desired element or catalog in the project tree and then choose the Export option. 3. When a process is selected for export, all referenced elements will be automatically selected for the export too. We will now select the WebSphere Integration Developer export option and click on Next.

[ 390 ]

Chapter 7

4. We will leave Export entire project and related projects selected and choose the Target directory location where the process elements should be exported to and click on Next.

[ 391 ]

Iterative Process Development from BPMN to BPEL

5. At this step, it is possible to select which elements should be exported. This can be accomplished with the Export specific elements option. When we select this option, the project tree opens. We can select one or more elements to export, as shown in the following screenshot:

6. Next, we will export the whole project. Choose Recommended Export Option as export option and examine other available options.

[ 392 ]

Chapter 7

7. In the Target Project Names section, we can see that the Export Wizard will generate three different modules: °Â°

Business Logic Module: This module will contain the artifacts describing the business logic. The artifacts in this module are the BPEL processes and sub-processes, human tasks (inline or global), exports, and imports.

°Â°

Implementation Module: This module will contain the artifacts that business logic will use when implemented. The artifacts in this module are the components and their implementation skeletons (BPEL, Java, Human Tasks, Business Rules, and WSDL bindings), exports, and imports.

°Â°

Library Module: The library will contain all the supporting artifacts shared by the business logic and the implementation modules. The artifacts in the library are business objects (XSD documents) and interfaces (WSDL documents) for all of the components.

There are five available export options: °Â°

Recommended Export Options: This option exports all modules.

°Â°

Module + Library: This option is useful when we do not need to separate the implementation module. We will choose this option if we will be using the already implemented services.

°Â°

Module: This option can be used for small processes. In this case, all the artifacts will be packed in one module.

°Â°

Library: This option exports all supporting artifacts shared by the business logic. This can be used when only the interfaces and business objects are needed.

°Â°

None: This option exports all the artifacts directly to the specified directory. In this case, no Project Interchange file is created.

8. With every export option, we can select Create default form for processes and human tasks or Create mediation flows for tasks and services. This option has effect only when exporting with Recommended Export Options, Module + Library, or Module. For this scenario we do not need any of these features. 9. The Enable generated BPEL for process versioning checkbox enables the BPEL process versioning in WID. Unselect it because we will use it later in this chapter, when discussing round-trip synchronization. [ 393 ]

Iterative Process Development from BPMN to BPEL

10. The next step is mandatory only when we want to export the process model with the business measures as a monitor model. We will discuss this topic in Chapter 8, Monitoring Business Processes. We will leave the Export business measures as a monitor model or models checkbox empty and click on Finish. 11. When the Export Wizard finishes, a dialog opens showing the status of the export. If there were any errors or warnings, we can click on Details to read them. In our case, we should have the Project Interchange file with all the modules ready for import into the WebSphere Integration Developer. Export Wizard in WebSphere Business Modeler will generate BPEL that uses BPEL with IBM extensions. For more information on IBM extensions to BPEL, refer to Chapter 4, BPEL Processes with IBM WebSphere.

Importing a process model in WebSphere Integration Developer

To import the Project Interchange file into the WebSphere Integration Developer, select Import… from the File menu. In the Import dialog, select Project Interchange and click on Next. Browse for the generated Project Interchange file named packtpub. com_.zip select all included projects, and then then click on Finish.

Two projects (packtpub.com and packtpub.com_lib) are created in the project tree. Now, we can compare the business model and the implementation model of the TravelApproval process. For example, we can notice that the sub-processes in the business model are BPEL scopes in the implementation model. Check out the following screenshot: [ 394 ]

Chapter 7

To make sure that the import was successful, we need to check the errors and warnings in the Problems view. In our case, we can see that we have three errors of the same type and twelve warnings of two different types, as shown in the following screenshot:

[ 395 ]

Iterative Process Development from BPMN to BPEL

The three errors are in the TravelApproval BPEL process Java code. This can happen because the functionality for generating Maps from Business Modeler to XSL Data Maps is new to version 7 and does not yet work for all scenarios without errors. To resolve this type of error, do the following: 1. Double-click on the first error. The process implementation model should open and the Assign Employee activity should be selected. 2. In the Properties view, open the Details tab and select the Java checkbox. 3. When the Question dialog appears, click Yes to proceed. 4. Now you can switch back to Visual.

This way, the Java code is regenerated and the error is resolved. Do the same for the other two errors. The first six warnings are CWSCA9079W—SCA imports must specify the module name of the target SCA export. The next six warnings are CWSCA9080W, which states that SCA imports must specify the name of the target SCA export. We will resolve these two types of warnings later, when we specify the SCA import name and its module name of the already implemented services. [ 396 ]

Chapter 7

Implementing a process in WebSphere Integration Developer

After importing the process into WID, we will implement it. The first thing that we have to do is to import the services. We will do this in a similar way as we have imported the process from WBM. We have to import the services in order to wire the process references to the services. Service implementations for this example are contained in the Project Interchange file named CH7_Services.zip which can be downloaded from http://www.packtpub.com.

When the process model and the services are imported, the Projects view should contain three modules as shown in the following screenshot:

Specifying service references

In the next step, we will specify the service references. In our case, the services are SCA imports in the packtpub.com project's assembly diagram. We will wire all process SCA service imports to the SCA exports of service implementations in the CH7_Services project. We will do the following: 1. Double-click on the Assembly Diagram of the packtpub.com module in the Projects view.

[ 397 ]

Iterative Process Development from BPMN to BPEL

2. Right-click on the first EmployeeTravelStatus SCA import and choose Select Service to Import, and then choose the appropriate export, EmployeeTravelStatusExport.

3. Repeat the previous two steps for all of the remaining SCA imports in the packtpub.com projects Assembly Diagram. Instead of implementing the process yourself, you use the prepared process implementation Project Interchange file CH7_implementation_is.zip, which can be downloaded from http://www.packtpub.com.

Deploying a process

We have wired the services to their implementations. With this, we have completed the implementation and the process is ready to be deployed to the process server. To deploy the process we will do the following: 1. In the Servers view, right-click on the process server and select Add and Remove Projects…(If the server state is stopped, start the server by selecting the Start option from the server context menu.) 2. In the Add and Remove Projects... dialog, click on Add All to deploy CH7_ServicesApp and packtpub.comApp to the process server. Click on Finish. After deployment is finished, the Servers view should look like the following screenshot:

[ 398 ]

Chapter 7

Testing a process

We can now test the TravelApproval process. We will use the Integration Test Client to test the process: 1. Right-click on the TravelApproval process in the Assembly Diagram and click on Test Component. 2. Change Initial request parameters editor to XML editor and insert the following XML: Matej Hertis management [email protected] 11223 LAX LAS 2010-06-23+02:00 2010-06-30+02:00

[ 399 ]

Iterative Process Development from BPMN to BPEL

3. Click on the green play button in the Events pane.

The process instance will execute until it reaches the human task. We need to complete the human task for the process instance to finish. We will do this using the Business Process Choreographer Explorer: 1. Right-click on the Process Server in the Servers view. Select Lunch from the context menu and then select Business Process Choreographer Explorer. 2. Next, on the My To-dos page, work on and complete the Confirm Travel Approval human task. The Confirm Travel Approval output message should look like the following screenshot:

[ 400 ]

Chapter 7

3. After completing the human task, we should see that the last activity, called Send Email Confirmation, has been executed and that a message has been outputted to the server console (see the Console view in the following screenshot). This means that the process has completed successfully.

[ 401 ]

Iterative Process Development from BPMN to BPEL

With this, we have demonstrated how to implement a process by modeling it in the WBM, exporting in to WID, and finishing the implementation in WID. The major thing that we had to do in WID has been to wire the service references to the existing service implementations. We have demonstrated how to implement the process. In the real world, however, it will be very likely that we will have to change and modify the process. Therefore, in the next section, we will demonstrate how we can synchronize changes between WBM and WID.

Process change synchronization

Process change synchronization is required, when we want to keep the business model in WBM and its implementation model in WID, in sync. Requests for changes are coming at different stages in the process lifecycle. For the purpose of this section, we will show the three most common scenarios: •

Synchronization of implementation changes is required when we make changes to the BPEL process in WID. If we make the changes in WID, the business model in WBM gets out of sync and does not reflect the actual model of the process anymore. We will show how these changes can be synchronized back to the WBM business model. This synchronization is called technical synchronization.

•

After the process implementation in WID has already started, the business analyst can make changes to the WBM business model. These changes must be synchronized with the BPEL implementation in WID. The IT developer should, however, not lose any work already done in WID. This is called business synchronization.

•

The third synchronization scenario will demonstrate a situation where the business analyst will optimize the business model in WBM, based on the metrics gathered from the process monitoring (process monitoring is addressed in Chapter 8). We will show a scenario where the process has already been implemented and deployed to the process server. This is called round-trip synchronization.

In the following subsections, we will describe the three synchronization scenarios.

[ 402 ]

Chapter 7

Synchronizing implemented changes

First, let us demonstrate how to do the technical synchronization of changes made in WID, to the business model in WBM.

Changing a process in WID

To effectively demonstrate this feature, let us first modify our TravelApproval BPEL process. In WID, we will add an additional human task to the BPEL process. This human task will allow a user to review the travel approval at the very end of the process. To add the human task, we will do the following: 1. Create a new interface with right-clicking on packtpub.com_lib | Interfaces in the Projects view and selecting New | Interface. Then use the following data: °Â°

Namespace: http://packtpub.com/bpel/travel/

TravelApproval/TicketConfirmationScope/ ReviewTravelApproval/ReviewTravelApprovalInterface

°Â°

Folder: bpel/travel/travelapproval

°Â°

Name: ReviewTravelApproval

°Â°

Two way operation: ReviewTravelApproval

°Â°

Input name: TravelResponse

°Â°

Input message: TravelResponseMessage

°Â°

Output name: FlightReservation

°Â°

Output message: FlightReservationMessage

2. Create a new human task by Name as ReviewTravelApproval and Interface as ReviewTravelApproval. 3. In the Properties tab under Description of the human task, set Name to ReviewTravelApproval and Display name to Review Travel Approval. 4. In the Properties tab under Details of the human task, set Inputs to the TravelResponse variable and Outputs to the FlightReservation variable.

[ 403 ]

Iterative Process Development from BPMN to BPEL

5. Next, move the new human task to the Mail Confirmation Scope and link it to the Send Email Confirmation activity.

Technical synchronization from WID to WBM

To do the technical synchronization from WID to WBM, we will use the synchronization wizard. The synchronization wizard compares the changes between the last WBM export and the current state of WID workspace while taking into account the last synchronization between both. The wizard will show the changes that have been made in the WID workspace and the changes made in the WBM business model. To invoke the wizard, we will do the following: 1. In the Projects view, right-click on the packtpub.com module and then click on Synchronize with the WebSphere Business Modeler Export…. 2. A Synchronize dialog will show up. We need to browse for the initial Project Interchange file that contains the WebSphere Business Modeler export for WebSphere Integration Developer and click on Next.

[ 404 ]

Chapter 7

3. In the next dialog, we can review how the wizard linked the WBM project to the WID project. If we have used the WBM export since the first iteration (as we did in this chapter), all projects will be linked automatically. 4. If the projects are changed too much for the synchronization wizard to auto-link them, we would need to manually link the corresponding projects. The dialog has two panes for this purpose. In the left pane, WBM Project Interchanges are listed and in the right pane projects from the WID workspace are listed. To link the corresponding projects, we have to select the corresponding projects in the left and in the right pane and link them by clicking on the Link Projects button. Those projects that a user links manually have the (user-linked) postfix and the automatically linked ones have the (autolinked) postfix. 5. Next, we will click on Synchronize to review the changes.

[ 405 ]

Iterative Process Development from BPMN to BPEL

6. The Synchronization dialog with Synchronization Information will show up. Click on OK to proceed. 7. Again, the synchronization dialog is divided into two main panes. The left pane contains the affected artifacts and the right one shows the changes in the selected artifact from the left pane. Both panes have tabs that group the changes by their origin (workspace or modeling). In our case, the synchronization wizard has identified the changes in the CH7_Services project. As we do not want to synchronize the changes in the direction from WBM to WID, we have to reject these changes. Please keep in mind that we do the synchronization from WID to WBM in this section. To reject the identified changes (in the WBM to WID direction), we have to: Select the CH7_Services project in the Affected Artifacts pane, then in the Changes in the Selected Artifact pane, right-click on Modeling Changes and click Reject all Incoming Changes.

8. Next, we need to accept the changes that we have made in the WID workspace to the packtpub.com project. Remember that we have added a human task, wired the service references, and regenerated the Data maps Java code (to fix the initial error with the WBM export). We could do other changes to the BPEL process in WID. However, due to simplicity we have not. With the described procedure, all changes made to the BPEL process in WID would be synchronized with WBM business model. [ 406 ]

Chapter 7

If we select the TravelApproval as an affected artifact, we can see that we have made the changes during implementation. The main changes are the new Human Task activity that has been added to the Email Notification scope and the import of its interface. Three changes listed are concerning the Java code that we have regenerated to fix the errors. The other two changes were made by the Integration Developer automatically. We will accept all changes as follows: Select the bpel folder in the packtpub.com project in the Affected Artifacts pane. In the Changes in the Selected Artifact pane, right-click on Workspace Changes and click on Keep all Workspace Changes, if they are not already accepted.

The Review Travel Approval human task is implemented with a newly created interface in the packtpub.com_lib project. Therefore, we need to accept the changes made to that project too, as follows: 1. Select the packtpub.com_lib project in the Affected Artifacts pane. In the Changes in the Selected Artifact pane, right-click on Workspace Changes and click on Keep all Workspace Changes, if they are not already accepted. We have also wired the SCA exports on the Assembly Diagram in the packtpub.com project to the service implementation SCA imports. This wiring has resulted in several changes. We will accept them all as follows.

[ 407 ]

Iterative Process Development from BPMN to BPEL

2. Select Assembly Diagram in the packtpub.com project in the Affected Artifacts pane. In the Changes in the Selected Artifact pane, right-click on Workspace Changes and click on Keep all Workspace Changes, if they are not already accepted. Now that we have accepted the changes, we can proceed and commit our selection. 3. Click on Commit to commit all selected changes.

Some changes are automatically marked as accepted. These are all workspace changes and all non-conflicting incoming changes. We can alter this by un-checking the Automatically accept resolvable differences for repository merge session checkbox in Window | Preferences | General | Compare/Patch | Modeling Compare/Merge.

We need to propagate the changes made to the BPEL implementation in WID back to the business model in WBM. To accomplish this, we need to create a change report, which is the basis for the WBM change analysis and synchronization. After clicking on the commit button, a new dialog is shown, asking us if we want to export the change report, which we will: 4. Click on Yes to proceed to the Change Report Export Wizard.

[ 408 ]

Chapter 7

5. Select the packtpub.com module, fill out the Target file to which the change report will be saved, and click on Finish.

Importing a change report to WBM

Next, we will import the change report to WBM. Please notice that in real-world projects, this would usually be done by two different persons. The WID-related steps would be done by an IT developer, while the WBM-related steps would be done by a business analyst.

[ 409 ]

Iterative Process Development from BPMN to BPEL

To synchronize the changes from WID to the WBM business model, we will do the following: 1. In WebSphere Business Modeler in the Project Tree, right-click on the packtpub.com project and click on Analyze Model Implementation Changes…

2. Browse for the change report file created in WID with the Change Report Export Wizard.

[ 410 ]

Chapter 7

Two analysis modes are available. The Compare and Merge the Changes analysis mode is available because we have created a new human task in the BPEL process implementation. The human task has required a new interface and the corresponding business objects. The new interface in our case is the human task interface. If it was not a human task but a business service instead, we would need to synchronize the business services and the related business object schema definitions. To achieve this, we would use the Compare and Merge the Changes functionality. We will proceed with the synchronization of the process logic using the Change Analysis Report analysis mode: 3. For Analysis Mode, choose Change Analysis Report and click on Next. The dialog will show all elements in the WBM business model that have not been changed during the implementation in WID. We will execute the change analysis against all elements that are not modified. 4. Check the Modeler elements not modified since last export checkbox and click on Finish. If the elements have been changed during the implementation, the changed elements will be shown in the next dialog.

[ 411 ]

Iterative Process Development from BPMN to BPEL

Reviewing changes

After performing the synchronization, we should see that the changes have been propagated from WID to the WBM business model. To see what has been changed, we have to look into the Change Analysis View as follows:

We can see that there have been changes made to the Email Notification sub-process in the TravelApproval process. The Change Analysis View shows that a human task named ReviewTravelApproval has been added and linked with the Send Email Confirmation activity. This is exactly what we have done in WID.

Applying changes

Now we, as the business analyst, have to apply the changes. We needed to apply changes done in the WID implementation to the WBM business model manually. We have to follow the next steps in WBM: 1. Add a Human Task activity to the Email Notification sub-process. 2. Set human task attributes in the Properties view: °Â°

Under the General tab, set Name to Review Travel Approval

°Â°

Under Inputs, click on Add and set Name to TravelResponse, Associated data to TravelResponseMessage, Input source to Repository, and its value to Travel Response

°Â°

Under Outputs, click on Add and set Name to FlightReservation, Associated data to FlightReservationMessage, Output target to Repository, and its value to Flight Reservation

[ 412 ]

Chapter 7

3. Connect the Review Travel Approval human task between Send Email Confirmation and the End activity.

After we have entered all the changes, we need to update the status of the incoming changes to applied as follows: 4. Click on Email Notification in the Change Analysis View tab and click on Change Applied All.

[ 413 ]

Iterative Process Development from BPMN to BPEL

Resynchronizing with WID

Now that the WBM process business model is updated, we need to export it to WID again to resynchronize the changes. This step is required because the business analyst in WBM could decide to implement the changes in a different way than the IT developer has done in WID. In our case, for example, the business analyst could implement the human task in a different way or locate it elsewhere in the process flow. In the real world, the business analyst usually decides about the process flow. The procedure that we have described requires that the business analyst reviews all the changes that the IT developer has made to the BPEL implementation and reapplies them to the WBM business model. The IT developer has to synchronize with the WBM model again to adopt any changes the business analyst might have introduced. Changes made by the business analyst might be different from those made by the IT developer. In our example, the changes in WBM do not differ from the changes in WID. We will, however, still need to do the resynchronization. We do it in the same way as before, as follows: •

Use Export Wizard to export the business model to WebSphere Integration Developer (as explained earlier in this chapter).

Next, we as an IT developer need to go to WID to synchronize the changes from WBM as follows: •

Use Synchronize with the WebSphere Business Modeler Export… (as demonstrated earlier in this chapter).

In the synchronization wizard, we can see that one new Human Task activity has been added to the Email Notification cyclic flow and that one Human Task activity has been deleted. This means the human task from WBM has been added to WID and that the human task that we have initially added in WID has been deleted:

[ 414 ]

Chapter 7

Because the human tasks have been modeled and implemented in different models (one in WID, the other in WBM), the synchronization tool does not have the association between these two activities on the model level. The association is required to enable the identification that the two activities are the same. We will create a custom association that will allow the synchronization mechanism to identify the relation between the human task from WBM and the human task in WID, as follows: 1. Click on the Associate button ( ) in the upper-right corner. 2. Confirm with OK, the question about specifying custom mappings. The Custom Associations wizard has opened, which is showing two panes with artifacts. The left pane shows the artifacts from the WBM business model and the right pane shows the artifacts from the WID process implementation. We need to create a link for the artifacts of the human task: 1. Navigate to the ReviewTravelApproval.wsdl file in both panes and click on them. 2. Select the interface file ReviewTravelApproval in the artifacts details pane. 3. Click on the Associate button to associate the selected pair. Repeat last two steps for the ReviewTravelApproval.wsdl interface and for its operation.

[ 415 ]

Iterative Process Development from BPMN to BPEL

Now that we have associated the interface operations, we can proceed to associate the human task definition. In the bottom pane, we can review the custom associations made for the human task as shown in the following steps: 1. Navigate to the TravelApproval_ReviewTravelApproval human task definition in the left pane and click on it. 2. Navigate to the ReviewTravelApproval human task definition in the right pane and click on it. 3. Select the human task TravelApproval_ReviewTravelApproval in the left, and ReviewTravelApproval in the right artifacts details pane. 4. Click on the Associate button to associate the selected pair. 5. Click on Finish and return to the Synchronization wizard.

In the Affected Artifacts pane of the synchronization wizard, we can see that no new Human Task activity or interface was created in the WID workspace. Synchronization will use the human task and the interface developed previously by the IT developer, and will refactor them to comply with the changes made by the business analyst. [ 416 ]

Chapter 7

We will reject the changes that would erase the work already done to the process implementation and accept all incoming changes that modify the process logic as follows: 1. Select the CH7_Services project in the Affected Artifacts pane. Then, in the Changes in the Selected Artifact pane, right-click on Modeling Changes and click on Reject all Incoming Changes. 2. Next, select Assembly Diagram in the packtpub.com project in the Affected Artifacts pane. Then, in the Changes in the Selected Artifact pane, rightclick on Modeling Changes and click on Reject all Incoming Changes. 3. Then, select the bpel folder in the packtpub.com project in the Affected Artifacts pane. Then in the Changes in the Selected Artifact pane, right-click on Modeling Changes and click on Accept all Incoming Changes except three regarding the Java code. 4. Select the packtpub.lib project in the Affected Artifacts pane. Then in the Changes in the Selected Artifact pane, right-click on Modeling Changes and click on Accept all Incoming Changes. 5. Click on Commit and when asked about saving the change report, click on No.

[ 417 ]

Iterative Process Development from BPMN to BPEL

To merge the properties of both the human tasks, one modeled by the business analyst in the WBM business process model and one created by the IT developer in the WID process implementation, the synchronization wizard will execute refactoring by following these steps: 1. Click on Refactor in the Refactor Merged Artifacts wizard.

2. When the synchronization and refactoring is complete, we can examine the BPEL process implementation. The process is changed towards the end, where the human task called Review Travel Approval is located. Before synchronization, the human task implementation was ReviewTravelApproval. After synchronization, the human task is coming from WBM. Its implementation is TravelApproval_ReviewTravelApproval and in addition to that, some human task properties are locked and can only be modified in WBM.

[ 418 ]

Chapter 7

With this example, we have demonstrated technical synchronization. We have seen that the synchronization of business logic in the WBM business model has to be done manually by the business analyst. This way, the business analyst has the possibility to decide which changes he will incorporate into the business model. On the other hand, the business services and the business objects are synchronized automatically by the compare and merge wizard. Because the changes in the WBM business model could differ from the changes made by the IT developer in WID, resynchronization with the WID implementation is required. We have shown how the changes in the business model are synchronized back to the WID process implementation, where these changes have already been made. The synchronization procedure in this section might look complicated, because it includes the following steps: 1. The IT developer makes a change in WID. 2. This change is propagated to WBM, where the business analyst reviews it and applies it to the WBM model. 3. The WBM model is resynchronized with WID. To simplify it is simple—all changes to the process flow should be done by the business analyst in WBM. We will show this in the next section.

Synchronization of modeling changes

In this section, we will demonstrate business synchronization. Let us assume that the business analyst has changed the WBM process model. The IT developer has already started the BPEL process implementation. When synchronizing the changes between WBM and WID, we as an IT developer, must not lose any work already done on the WID process implementation. We will demonstrate how we can achieve such synchronization without losing the work already done on the implementation. For this example scenario to work, we need the WBM business model and the WID process implementation of the TravelApproval process. These files can be downloaded from http://www.packtpub.com. Files needed are included in the CH7_implementation_bs.zip and CH7_model_bs.mar.

[ 419 ]

Iterative Process Development from BPMN to BPEL

Modifying process

To demonstrate this scenario, we will modify the Email Notification sub-process of the Ticket Confirmation sub-process in the Travel Approval process. The original sub-process before the modification is shown in the following screenshot:

We will modify the sub-process in WBM. We will change the process flow so that the Review Travel Approval human task will be executed before the confirmation email is sent. To make this change, we will re-link the existing activities on the WBM business model. First, we need to remove all links from activities between the Merge gateway and the End event: •

Remove links: °Â°

From the Merge gateway to the Send Email Confirmation activity.

°Â°

From the Send Email Confirmation business service to the Review Travel Approval human task.

°Â°

From the Review Travel Approval human task to the End event.

[ 420 ]

Chapter 7

After removal, the Send Email Confirmation activity and Review Travel Approval human task do not have any input or output links. We have to create new links in a way that the Review Travel Approval human task will be executed before the Send Email Confirmation activity: •

Create links: °Â°

From the Merge gateway to the Review Travel Approval activity.

°Â°

From the Review Travel Approval human task to the Send Email Confirmation business service.

°Â°

From the Send Email Confirmation business service to the End event.

The changed business model should like the following screenshot:

Synchronizing changes

To synchronize the changes, we will export the model in the same way as we have exported the initial WBM process model earlier in this chapter. We have explained how to execute the WID Synchronization wizard and the options earlier in this chapter. After the WBM business model is exported as the Project Interchange file, we can use it for synchronization: 1. In the Projects view, right-click on the packtpub.com module and then Synchronize with the WebSphere Business Modeler Export…. [ 421 ]

Iterative Process Development from BPMN to BPEL

2. The Synchronize dialog will show up and we need to browse for the Project Interchange file with the refined business model and click on Next.

In the next dialog, all projects will be automatically linked. We can review them and proceed. Click on Synchronize to review the changes. The Synchronization dialog with Synchronization Information dialog will show up. Click on OK to proceed. We can see that for the TravelApproval process, changes have been made in WBM. The eight listed modeling changes in the TravelApproval process are stating that the Review Travel Approval human task has changed its position within the process flow with the Email Notification activity. Those are exactly the changes that we made in WBM. We will accept all the modeling changes by following the steps given next: 1. Select the TravelApproval process in the packtpub.com project in the Affected Artifacts pane. Then in the Changes in the Selected Artifact pane, right-click on Modeling Changes and click on Accept all Incoming Changes, except the three changes regarding the Java code. 2. Select Assembly Diagram in the packtpub.com project in the Affected Artifacts pane. Then in the Changes in the Selected Artifact pane, right-click on Modeling Changes and click on Reject all Incoming Changes. 3. Select the CH7_Services project in the Affected Artifacts pane. Then in the Changes in the Selected Artifact pane, right-click on the Modeling Changes and click on Reject all Incoming Changes. 4. Click on Commit and when asked about saving the change report, click on No.

[ 422 ]

Chapter 7

Now the synchronization is complete and we can examine the BPEL process implementation. Towards the end of the process, we can find a human task called Review Travel Approval. It is the last activity after Send Email Confirmation. Before synchronization, the order of these two activities was reversed:

We have successfully propagated the changes from the WBM business model to the WID process implementation, without losing the implementation work that has already been done in WID. The WBM and WID models are synchronized, and represent the most current state of the process. [ 423 ]

Iterative Process Development from BPMN to BPEL

The IT developer has to continue with the process implementation in WID until it is ready for the deployment on the process server. The next scenario that we will discuss in the next section is round-trip synchronization, which requires an already deployed version of the process on the process server.

Round-trip synchronization

Let us assume that the IT developer has finished the process implementation and we have a working version of the process deployed on the process server. Now that the process is executing on the process server, monitoring data from the process execution is gathered. Based on this data, we will change the WBM business process model to accommodate the new requirements. The WID implementation model will have to change too, to reflect these changes. This scenario is called round-trip synchronization and is unique because it requires that we preserve the deployed version of the process (which is used in the production environment). We can manage the round-trip synchronization challenges with somewhat different techniques: •

•

•

If we want both versions of the BPEL process in the same WID workspace, we can copy the production version of the modules and refactor their names so that they reflect their versions. Then we can synchronize the new modules with the changes in the WBM business model. A more simple solution would be to export the workspace as a Project Interchange file to keep a backup of the current version and do the modification on the new version of the process. If we use a version control system, such as CVS (Concurrent Versions System) or IBM Rational ClearCase, we can create a version of the workspace.

Exporting a new version from WBM

In the following step, we will demonstrate how to apply the first option. Starting in WebSphere Business Modeler V7.0.0.2, the Export Wizard provides the Enable generated BPEL for process versioning option, which enables copying the production versions of the modules and re-factoring their names. Basically, it automates the first mentioned technique for managing round-trip synchronization challenges. For the Enable generated BPEL for process versioning option to work correctly, the entire development environment (WebSphere Business Modeler, WebSphere Integration Developer, and WebSphere Process Server) should be of version 7.0.0.2 or later. [ 424 ]

Chapter 7

We will use the Enable generated BPEL for process versioning option to export the WBM business model. This way, we will utilize the New Process Version functionality in WebSphere Integration Developer: •

In the WBM Export wizard, check Enable generated BPEL for process versioning and click on Finish.

Now that we have the new process model version with the enabled option for process versioning exported from WBM, we need to synchronize it wih WID. Only when the process model with this option enabled is synchronized, are we able to use the wizard for creating new process version in WID. For the Enable generated BPEL for process versioning option to work, we should select it in the first initial synchronization and then in every subsequent synchronization. In this case, we can use the option for creating new process version at any time without the need for additional business synchronization.

[ 425 ]

Iterative Process Development from BPMN to BPEL

Synchronizing with WID

We will synchronize the Travel Approval process with WID. We will synchronize it as we have done in the previous section, but this time we will accept only the changes in the bpel folder of the packtpub.com project, as shown in the following steps: 1. Select the bpel folder in the packtpub.com project in the Affected Artifacts pane. Then in the Changes in the Selected Artifact pane, right-click on Modeling Changes and click on Accept all Incoming Changes, except the three changes regarding the Java code. 2. Select Assembly Diagram in the packtpub.com project in the Affected Artifacts pane. Then in the Changes in the Selected Artifact pane, right-click on Modeling Changes and click on Reject all Incoming Changes. 3. Select the CH7_Services project in the Affected Artifacts pane. Then in the Changes in the Selected Artifact pane, right-click on the Modeling Changes and click Reject all Incoming Changes. 4. Click on Commit and when asked about saving the change report, click on No.

[ 426 ]

Chapter 7

Resolving errors

Again, we have to resolve the errors. We have an error related with the display ID, as shown in the following screenshot:

This error has occurred because we have used the same business service twice in the same process with the SCA import defined in the technical attributes of the business model. The Enable generated BPEL for process versioning functionality is new to the WebSphere Business Modeler 7.0.0.2 and we believe that it will be improved in future versions so that this error will not occur anymore. Until then, we have to resolve the CWWBD0206E error manually. The error is saying that the Display ID is used more than once in the BPEL file. This is because of the Display ID's need to be unique in the context of a BPEL process. The export has, however, generated the same ID twice (due to the fact that we have used the same service twice). We will modify the Display ID in the TravelApproval BPEL file and make it unique as follows:

1. Right-click on the TravelApproval process in the packtpub.com project and select Open With and XML editor. 2. In the TravelApproval.bpel editor, click on the Source tab to see the BPEL source code. 3. Right-click on the source code and choose Source and then Format. 4. Locate the code part where the FlightAvailabilityPartner partner link is defined.

[ 427 ]

Iterative Process Development from BPMN to BPEL

5. From the code, we can see that the FlightAvailabilityPartner and the FlightAvailabilityPartner2 partner links have the same wpc:id with value WMPLJNHUORDZ0D (this value can vary). The same is true for the MakeReservationPartner and MakeReservationPartner2 partner link. They both use wpc:id with value WMI1C6U1KGBGND (can also vary). We need to make these IDs unique: °Â°

Change wpc:id of FlightAvailabilityPartner to WMPLJNHUORDZ0B.

°Â°

Change wpc:id of MakeReservationPartner2 to WMI1C6U1KGBGNB.

These two changes fixed the error. The TravelApproval.bpel should now look as shown in the following screenshot:

Creating a new process version

Now we can proceed with the creation of the new process version by following the steps shown next: 1. In the Projects window, right-click on the project and then click on New Process Version….

[ 428 ]

Chapter 7

2. Next, we can give new names to the modules or accept the default values and click on Next.

[ 429 ]

Iterative Process Development from BPMN to BPEL

3. Now, we have to specify the date from when the new process version becomes valid. We leave Now checked (current time will be set) and click on Select All to select all process components. Click on Finish.

4. Next, we should see in the Projects view, the original project version that has been already deployed in production, and the new version of the same project with the suffix _1.

[ 430 ]

Chapter 7

The project modules with the suffix _1 represent the new version of the process. We can continue the development on these modules. Business and implementation synchronization can now be performed in a standard way, while the production version of the process is preserved. All project modules are treated as a single unit previously exported from the WebSphere Business Modeler. The synchronization mechanisms work in the same way as described previously in this chapter. Finally, let us mention that the New Process Version Wizard also creates the Process Migration Specification that enables process instance migration at runtime. This way, the existing process instances can be migrated to the new process version. Instance migration techniques exceed the scope of this book.

Summary

In this chapter, we have become familiar with the concepts of iterative process development. Iterative development is required because the business requirements are changing during the process implementation or later when the process is already in production. We have demonstrated how to model business processes in WebSphere Business Modeler. We modeled the Travel Approval process and used this process for different synchronization scenarios. First, we have shown how to do the initial synchronization between the WBM business process model and the BPEL implementation in WID. The initial synchronization consists of two steps: exporting the business model from WBM as a Project Interchange file and importing it to WID. Second, we have explained the technical synchronization. This synchronization synchronizes the changes done in WID back to the WBM business model. Ideally, all changes made in WID would be strictly implementation by nature. In this case, they are synchronized automatically. If the changes in WID are changing the process flow, then the business analyst has to review and apply the changes to the process model in WBM. Third, we have demonstrated business synchronization. This scenario covers a common situation where the IT developer implements the process in WID. While the implementation is in progress, the business analyst modifies the WBM business model. We have shown how to make the synchronization from WBM to WID in a way that the work already done in WID is not lost.

[ 431 ]

Iterative Process Development from BPMN to BPEL

Fourth, we overviewed round-trip synchronization. This type of synchronization is common when a version of the process has already been implemented and is used in production. During the execution of the process on the process server, monitoring data is gathered. The business analyst uses this data to optimize the WBM process model. The current version of the process running on the process server, however, needs to be preserved. A new version of the process implementation model is needed. We have demonstrated how to create a new version while synchronizing the model between WBM and WID, leaving the current version of the process intact.

[ 432 ]

Monitoring Business Processes In this chapter, we will cover the basic concepts of Business Monitoring, also known as Business Activity Monitoring (BAM). We will explain how to use IBM WebSphere to monitor BPEL processes and show how to develop a monitor model and a dashboard by: •

Discussing the motivation behind Business Monitoring

•

Taking a look at how Business Monitoring works

•

Building an exemplary monitoring model by following these steps: °Â°

Develop monitor model in Business Modeler

°Â°

Transfer and refine monitor model in Integration Developer

°Â°

Build and publish monitoring application to WebSphere Monitoring Server

°Â°

Configure dashboards in Business Space

°Â°

Run and test the example and view monitoring results

Motivation for Business Monitoring

For the success of a company, it is very crucial to have a comprehensive overview of all ongoing processes and detailed insight of the current state of the business. Business Monitoring provides access to real-time data about current states and results of activities and processes. Based on gathered data and thorough analysis, business stakeholders and managers can make better decisions and the business can respond faster to ever-changing markets and customer needs.

Monitoring Business Processes

Business goals are an important concern in business process design. We have to determine business goals as early as in the planning and modeling phase of business process development. Process stakeholders define areas and criteria crucial for the success of a business process. Based on these goals, we prepare business measures by which we can measure process performance against preset goals. Business Monitoring helps identify how our business processes perform and where to optimize them. Business Monitoring gathers information about the time required to complete the different activities of a process. It can then provide reports with average values for each activity. Having these numbers can be very helpful, because we can use them to identify which activities take the longest time to execute. With this, we can identify those parts of a process where we will realize the largest benefit of optimizing it. With Business Monitoring, we can gather data about process execution, such as: •

How long does it take for my process to execute on average?

•

Which activities are the most time-consuming?

•

How long does it take for human tasks to be claimed and completed?

Business Monitoring can show us how many process instances are active at a specific time and how long, on average, it takes to complete a process. They can also show us which users (employees) have started how many process instances, and so on. We can also monitor more specific data, related to the process. For our Travel Process example, we could monitor the following: •

The average price for the flight ticket for each travel class (economy, business, first).

•

The percentage of flight tickets bought by each vendor.

•

The number of flight tickets that have/have not been approved.

•

The average duration of a business travel.

•

The time required for the user's ticket to be approved (through the human task).

•

The average number of business travel requests per week/month.

You can see that there can be several interesting indicators that we can monitor on a process. The more complex a process is, the more interesting are the indicators we can follow. The added value of Business Monitoring in BPEL/SOA is that the BPEL process server provides means to monitor BPEL processes in a relatively simple way. This way, we can develop process monitor dashboards quickly and efficiently. [ 434 ]

Chapter 8

Business Monitoring is often overlooked in the development of SOA composite applications. However, executive people often see the major added value, particularly in the ability to monitor business processes and observe the key indicators. Therefore, we should plan to develop business monitor dashboards for each BPEL process composite application.

In this chapter, we will demonstrate how to implement Business Monitoring on our Travel Approval process. We will show how to gather the business indicators from the process model and how to present them on a dashboard, as schematically shown in the following screenshot:

[ 435 ]

Monitoring Business Processes

Business Monitoring in WebSphere

Business Monitoring in WebSphere is based on the Common Event Infrastructure (CEI), which provides basic event management services, such as event generation, transmission, persistence, and consumption. CEI is designed to enable event exchange between different systems, running on different (possibly heterogeneous) infrastructure and using various event formats and data stores. An event is a standardized structured notification, holding information about an occurred situation, the identity of the affected component, and the identity of the component that is reporting the situation. WebSphere supports the Common Base Event (CBE) specification, which defines a standard XML-based format for business and system events and performance information. Processes and applications running on WebSphere Process or Application Servers use CEI and CBE to generate business events that contain information relevant to the business. This information is then captured and analyzed in the WebSphere Business Monitor model and presented to the business users. For example, capturing and analyzing business events can reveal whether the performance of our business process has fallen beneath expected level, or whether the number of received orders has exceeded the current production capability. To make use of Business Monitoring in IBM WebSphere, we have to develop a: •

Monitor model

•

Dashboard

Monitor model

A monitor model specifies which data will be gathered from a BPEL process (or other software component) at runtime. We can develop a monitor model in two ways: •

We can develop it in WebSphere Business Modeler (WBM) and refine it in WebSphere Integration Developer (WID)

•

We can develop it in WID only

The first approach is recommended, as it closes the gap between modeling and implementation. However, we will show both approaches in this chapter. A monitor model consists of the following constructs: •

Events: They provide a means of communication between a monitoringenabled application (in our case, it is a BPEL process) and a monitor model. During execution, a BPEL process instance emits a series of events. These events contain data stored in BPEL process variables. [ 436 ]

Chapter 8

•

Triggers: They can execute based on incoming events, changed values of metrics, and so on. They can be used to trigger evaluation of a metric or to manipulate counters and stopwatches.

•

Counters: They are special metrics for counting. Triggers and inbound events can be configured to add, subtract, or reset counters.

•

Stopwatches: They are special metrics for measuring duration. Triggers and inbound events can be configured to start, stop, or reset the stopwatches.

•

Instance metrics: They contain data from BPEL process instances.

•

Aggregate metrics: They contain results calculated across multiple instances of the BPEL process.

•

Key Performance Indicators: They present measurements across multiple instances of the process, which are used to compare the actual performance to specified business objectives.

•

Dimensional model: It provides tools for dimensional analysis of collected data. A dimensional model consists of several cubes, that is, multidimensional representations of information available for analytical processing. Each cube contains: °Â°

Measures (aggregate metrics)

°Â°

Dimensions and dimension levels

Dashboard

A dashboard shows various indicators in a graphical interface. In most cases, a dashboard will use graphs and other visual elements to make it easy to observe various indicators and to achieve an attractive look and feel. We will show how to develop a dashboard in Business Space. To demonstrate how to develop a monitor model and a dashboard, we will develop an example for the Travel Approval process. This is the process that we have used throughout the book. We will do the following: •

We will show how to develop a monitor model in WebSphere Business Modeler. We will use the same Business Modeler model that we used in the previous chapter, where we demonstrated how to model a business process in WBM and transform it to WID.

•

Then we will export the monitor model to WebSphere Integration Developer. In WID, we will refine the model and add some additional indicators. This way, we will demonstrate how to develop a monitor model in WID.

•

Finally, we will show how to develop a dashboard in Business Space. [ 437 ]

Monitoring Business Processes

Developing a monitor model in WebSphere Business Modeler

In this chapter, we will define metrics, key performance indicators, and a dimensional model for the Travel Approval process in Business Modeler. We will define the following measurements: •

Instance metric for measuring the duration of each Travel Approval process instance

•

Aggregate metric for measuring the average duration of the Travel Approval process

•

Instance metric for specifying the requestor of the Travel Approval request

•

KPI for calculating the average duration of the Travel Approval process

•

Dimension, based on the requestor metric, that will allow us to analyze data in relation to this metric

•

Instance metric that will specify whether the travel request has been approved or not

•

KPIs that will count the number of travel requests and the number of approved ones

•

KPI that will calculate the percentage of approved travel requests

Then we will export the model to the Integration Developer. In the Integration Developer, we will: •

Review the generated monitor model

•

Discuss and resolve possible warnings that might occur

•

Update the Travel Approval process to generate additional events when the flight ticket reservation service is invoked and import these events into the monitor model

•

Create triggers based on these events

•

Specify two additional instance metrics that will measure whether the American or the Delta airlines have been selected for ticket reservation

•

Specify two KPIs that will count the number of times the American and the Delta airlines have been selected for ticket reservation

•

Define two KPIs that will calculate the percentage of selected offers for each airline

•

Define a new dimension that will allow us to analyze the data in relation to the approval (or non-approval) of travels [ 438 ]

Chapter 8

Finally, we will generate the monitoring application and publish it to the Monitoring Server. We will design a dashboard in Business Space, where we will display the values of the specified KPIs and demonstrate the analytic abilities of the dimensional model. We will also show how to define alerts that will be raised when the value of a KPI reaches a certain value. The example in this chapter is based on the Travel Approval business process model that was developed in the previous chapter, where you became familiar with business modeling and the WebSphere Business Modeler tool.

Business measures

Let us now start with the development in WebSphere Business Modeler. Besides modeling processes, WebSphere Business Modeler enables users to define metrics, key performance indicators, and dimensional analysis in the model of a business process. WebSphere Business Modeler has a view called Business Measures that enables us to specify values to monitor and business performance indicators to calculate. To open the Business Measures view, we will follow these steps: 1. We select Window | Business Measures (additionally, we can select Window | Show View | Other and then look for Business Measures).

[ 439 ]

Monitoring Business Processes

2. Business Measures view is displayed below the process diagram panel. It consists of two tabs: Business Performance Indicators and Monitored Values. The Business Performance Indicators tab is shown in the following screenshot:

The Monitored Values tab is shown next:

Specifying a metric

We will start building our monitor model by specifying a metric for measuring the processing time of the Travel Approval process execution. For this purpose, we will use a predefined monitoring model: 1. We switch to the Monitored Values tab in Business Measures view and check the Processing Time checkbox in the TravelApproval row:

[ 440 ]

Chapter 8

2. As a result, the monitor model will enable all events that are required for measuring process instance duration. If we switch to the Business Performance Indicators tab, we will see that this also created one new instance and one aggregate metric, related to the TravelApproval Processing Time.

3. Next, we double-click on the TravelApproval Processing Time instance metric to open the Business Measure Details window. Here we can view and configure metrics details. We will see that this instance metric is calculated based on the predefined business measure template called Elapsed Duration and it measures duration of the TravelApproval process instance.

[ 441 ]

Monitoring Business Processes

4. If we take a look at the details of the Average TravelApproval Processing Time aggregate metric, we will see that this metric is calculated based on the instance metric TravelApproval Processing Time and the function Average.

Adding an instance metric

Now, we will add a new instance metric to the Travel Approval process. We will call it Requestor and it will contain the name of the employee who invoked the travel approval request and, therefore, started a certain instance of a process. This information is contained inside the Travel Approval process input. Later, we will use this instance metric to analyze the travel approval requests based on the employees who requested it. To create a new instance metric, we need to perform the following steps: 1. In the Business Measures window under Business Performance Indicators tab, we click on Add. 2. In the Name field, we enter Requestor and select type Instance metric. 3. In the Business Measure Details tab, we check Specify a default value and type, select Text as default Type, and enter N/A for Default value. 4. We will also check the Specify how to calculate this instance metric: checkbox and leave Using a predefined business measure template for a process element selected. 5. As a template, we select Business Item Input and then TravelApproval as a Process element. [ 442 ]

Chapter 8

6. We click on Browse and select TravelRequestMessage.employee.LastName for Attribute and click on OK.

7. We click on OK to close the Business Measure Details editor.

[ 443 ]

Monitoring Business Processes

Specifying Key Performance Indicators

Key performance indicators (KPI) are business-related measurements that are used to compare actual process performance against predefined business objectives. In our example, we will first define the most common KPI for all processes—one that will measure the average process duration. We will call it Average Travel Approval Processing Time. To specify this KPI, we should follow the next steps: 1. In the Business Measures window, under the Business Performance Indicators tab, we click Add. 2. We enter Average Travel Approval Processing Time in the Name field and select KPI as Type.

3. In the Business Measure Details tab, we check Specify a target type and value, select Duration as default Type, and set 1 hour for Target value

KPI target value is the exact value that a KPI should achieve. In our example, we expect most of the travel approval requests to be processed within one hour.

4. We will not define any Ranges or Alerts for this KPI, so leave these sections empty.

[ 444 ]

Chapter 8

Each range presents a span of possible values for a certain KPI. Ranges can be specified either as actual values, or as percentages of the target value, and are defined by start and end values. Ranges can be useful when we specify alerts, triggers, or outbound events. We can bind each of these indicators to the KPI values reaching or exceeding a certain range or achieving a target value.

5. The value of the KPI that we are currently building will be calculated by averaging the value of the Travel Approval processing time instance metric, across process instances. Therefore, in the KPI Calculation Details section, we check Specify how to calculate this KPI and select the Based on an instance metric and an aggregation function option. KPI values can be calculated in two ways: either based on an instance metric and an aggregation function, or using an expression involving other KPIs. With the first option, we can aggregates metric values across process instances using functions such as average, count, or sum. If we select the second option, we can build an XPath expression that includes values of other KPIs.

6. We select TravelApproval Processing Time as Instance metric to aggregate and Average as Aggregation function.

7. The Time Period for Data Collection and KPI Data Filter sections enable us to filter instance metric values included in the calculation of KPI values. But for the current KPI, we will include all process instances, so we leave all fields empty. [ 445 ]

Monitoring Business Processes

8. We click on OK to close the Business Measure Details editor. WebSphere Business Modeler has a library of predefined KPIs that can be used in monitor models. Industry-standard predefined KPIs are based on the APQC (American Productivity and Quality Center) process classification standard. To browse through available KPIs, we click on Add from KPI Library. In our example though, we will build KPIs ourselves and won't be using the predefined ones.

Creating dimensions

Dimensions are used to perform a business analysis of collected data. We will define a new dimension using the instance metric Requestor that we defined earlier. As already mentioned earlier, this dimension will enable us to decompose aggregate metrics based on the travel approval requestor. Using this dimension in dimensional analysis, we will be able to focus only on the travel requests entered by a certain employee. For instance, if our monitor model shows five travel approval requests last week, this dimension could reveal that three of them have been entered by John First and two by Mike Second. To create a new dimension, we should follow these steps:

[ 446 ]

Chapter 8

1. In the Business Measures window, under Business Performance Indicators, we right-click on Dimensions and then click on Add.

2. We enter Requestor Dimension as Name and select Requestor as Instance Metric. 3. We click on OK to close the Business Measure Details editor. 4. Next, we double-click on Average TravelApproval Processing Time under Aggregate Metrics, scroll down to Dimensions for Analysis, check Specify the dimensions that will be available in the dashboard for analysis of this metric, and add Requestor Dimension with the Requestor instance metric.

5. Finally, we click on OK to save the changes. Using this procedure, we have defined a dimension based on the Requestor instance metric. With it, we will be able to drill down aggregate metrics to perform further data analysis.

[ 447 ]

Monitoring Business Processes

Adding additional metrics and KPIs

We will add an additional KPI and required metrics following a procedure similar to the earlier one. One of the interesting KPIs for our process is the percentage of approved travels. For this purpose, we will first need to define a metric that will specify whether a travel request has been approved or not. Next, we will count the number of all travel requests and the number of approved ones. Finally, we will calculate the percentage of approved travel requests by dividing the number of approved travel requests by the number of all travel requests. To create the approved travels percentage KPI, we need to define the following measures: •

Instance metric that will specify whether travel request was approved

•

KPI that will count all travel approval requests

•

KPI that will count approved travel requests

•

Finally, KPI that will calculate percentage of approved travel requests

Travel is approved in the Ticket Confirmation scope, so first we have to move there: We right-click on Ticket Confirmation Scope and select Open In New Page.

Defining an instance metric

Now, we have to define a metric that will specify whether the travel request in a certain process instance was approved or rejected. If we take a look at the business model, we can see that the output of the human task, Confirm Travel Approval, is the last activity in the process where the travel can be approved. To define the instance metric that will extract this value, we do the following:

[ 448 ]

Chapter 8

1. In the Business Measures window under the Business Performance Indicators tab, we click on Add. 2. We enter Travel Approved in the Name field and select Instance metric as Type. 3. In the Instance Metric Calculation Details section, we check Specify how to calculate this instance metric and select the Using a predefined business measure template for a process element option. 4. We select Business Item Output as Template and Confirm Travel Approval as Process element. 5. We click on Browse and select FlightReservationMessage. FlightReservation.Confirmed for Attribute.

6. Next, we have to return to the Type and Default Value section above and check the Specify a default value and type checkbox. 7. We select false as Default value (it is possible that travel is rejected earlier in the process and this human task in not generated; therefore, it is important that the default value of this instance metric is set to false). 8. We click on OK to close the Business Measure Details editor.

[ 449 ]

Monitoring Business Processes

Specifying KPIs

At this time, we will specify two KPIs, which will hold the number of all travel approval requests and the number of approved ones. To define the KPI that will count all the travel approval requests, we have to count all instances regardless of the approval state. For this purpose, we will count all Travel Approved metrics regardless of their value. 1. In the Business Measures window under the Business Performance Indicators tab, we click on Add. 2. We enter All Requests Count in the Name field and select KPI as Type. 3. We check the Specify a target type and value checkbox. 4. We select Number as Type and leave 0,00 as Target value. 5. We need to scroll down to KPI Calculation Details and check Specify how to calculate this KPI. 6. We leave Based on an instance metric and aggregation function selected, select Travel Approved as Instance metric to aggregate, and Count as Aggregation function. 7. Finally, we click on OK to close the Business Measure Details editor. To define the KPI that will count only the approved requests, we will once again count the Travel Approved metrics, but only those whose values are true. We do this by repeating the previous steps with the following differences: 1. We enter Approved Requests Count as Name. 2. In the KPI Data Filter section, we check the Specify data filters to limit the values included in the calculation of this KPI checkbox and click on Add. 3. We enter request_approved as Data Filter Name, Travel Approved as Instance Metric, equal to as Operator, and True as Values to include.

[ 450 ]

Chapter 8

Now we can create the KPI that will measure the percentage of successfully approved travel requests. The value of this KPI will be calculated by dividing the number of approved requests by the number of all travel requests. We will set the target value of this KPI to 100% and we will also define two ranges: Unacceptable and Acceptable. Let's assume that the performance of our process is acceptable when the percentage of approved travel requests is higher than 70%. To perform this, we have to follow the next steps: 1. Add a new KPI named Approved Travels Percentage, check the Specify a target and value checkbox, select Number as target Type, and 1,00 as Target value. 2. For this KPI we will also specify two ranges, so check the Specify range details checkbox and select Percentage of target value for the range definition. 3. Add two ranges: °Â°

Unacceptable: 0% - 70%.

°Â°

Acceptable: 70% -100%.

4. To define the KPI calculation details, we first check the Specify how to calculate this KPI checkbox and then select Using an expression involving other KPIs.

[ 451 ]

Monitoring Business Processes

5. We click on Edit and build an expression Approved Requests Count or All Requests Count with Expression Builder.

6. We click on Apply and OK to save the expression.

7. We click on OK once more to close the Business Measure Details editor. In the following figure, we can see the outcomes of our previously described activities. [ 452 ]

Chapter 8

When we have defined all the planned metrics and measures, we are ready to transfer the monitor model to the Integration Developer, where we can further develop it and publish it to the monitoring server.

Exporting a monitor model to WebSphere Integration Developer

In the previous chapter, we have seen the procedure of transferring the business model from WebSphere Business Modeler to WebSphere Integration Developer, where we can further develop, implement, and deploy the business process. A similar story goes with monitor models. In Business Modeler, we design and build basic measurements, and then we transfer the monitor model to the Integration Developer with the installed Business Monitor development toolkit, where we can review, edit, further develop, and publish it to the monitoring server. The WebSphere Business Monitor development toolkit provides wizards, libraries, and a test environment for creation and testing of monitor models. The WebSphere Business Monitor development toolkit can be installed in an existing WebSphere Integration Developer environment. You need to install the Business Monitor development toolkit in order to run the samples from this chapter.

[ 453 ]

Monitoring Business Processes

To transfer the business model along with the related monitor model, we first need to export it from the Business Modeler and then import it into the Integration Developer. The procedure is fairly similar to transferring a plain business model and is done by following these steps: 1. We start by right-clicking on the packtpub.com project in Project Tree and selecting the Export… option:

2. We select the WebSphere Integration Developer export option and click on Next.

3. We have to make sure Export entire project and related projects is selected, then we select Target directory for model, monitor export, and click on Next.

[ 454 ]

Chapter 8

4. We choose Recommended Export Option and click on Next. 5. We check Export business measures as a monitor model or models and click on Finish. This option defines whether besides the process model, we also want to export the monitor model.

[ 455 ]

Monitoring Business Processes

This export procedure creates two archives in the selected folder: •

packtpub.com_.zip contains the BPEL process

• packtpub.com_Monitor_.zip contains the monitor model This completes our work in Business Modeler. We will continue the development in WebSphere Integration Developer.

Developing and refining a monitor model in WebSphere Integration Developer

In this section, we will show how to import a monitor model from WebSphere Business Modeler into WebSphere Integration Developer (WID) and how to refine the model in WID. We will also show how to add business measures in WID directly. To edit the monitor model in WID, we first have to make sure that the Business Monitor development toolkit is installed.

Importing into WID

We will start by importing the modeled process into WID. To do this, we will do the following: 1. We right-click in the Projects window and select Import….

2. We select Project Interchange and click on Next. [ 456 ]

Chapter 8

3. We browse for the generated packtpub.com_.zip file and then click on Select All included projects and click on Finish.

This creates two projects in our workspace, packtpub.com and packtpub.com_lib. If necessary, we have to prepare the BPEL process for execution, as described in the previous chapter.

[ 457 ]

Monitoring Business Processes

Now, if we take a look at the Travel Approval process diagram, we will notice yellow flags in the upper-right corner of certain activities. These flags mark activities that are generating events.

The Business Monitoring perspective

To edit and publish a monitor model, we also have to import the second ZIP file that we previously created with the modeler. It contains the monitor model. To do this, we repeat the previous steps and select the packtpub.com_Monitor_. zip file. In case you do not want to build the monitor model in WebSphere Business Modeler, or if you have some existing processes without the WBM business model, you can also create the monitor model in WebSphere Integration Developer from scratch. To do this, right-click on your project in the Projects window and select Generate Monitor Model. Select an existing or create a new monitor project and enter a name for the monitor model. In the Generate Monitor Model window, select events you want to monitor or KPIs you want to measure. We will take a more detailed look at the Generate Monitor Model dialog a little later in this chapter, when we will be updating the existing monitor model with additional events. [ 458 ]

Chapter 8

The monitor model can be edited in the Business Monitoring perspective. To enable it, we do the following: 1. In the menu bar, we select Window | Open perspective | Other….

2. Select Business Monitoring from the list of available perspectives and click on OK.

3. In this perspective, there are three projects in Project Explorer: °Â°

packtpub.com and packtpub.com_lib are the same as in the

Business Integration perspective, but here only monitoring-related content is visible. [ 459 ]

Monitoring Business Processes

°Â°

packtpub.com_Monitor contains the monitor model, related SVG files, and basic event definitions.

4. If we look at the packtpub.com_Monitor project in Project Explorer and expand the Monitor Models folder, we will find a file called TravelApproval_ Mon.mm, which contains the monitor model for our Travel Approval process.

Resolving warnings

After importing the monitor model or making changes to the corresponding application (business process in this case), we can see warnings in the Problem view, which remind us that the monitor model might not be synchronized. To remove these warnings, we synchronize the monitor model with the BPEL process in the following way: 1. We right-click on the TravelApproval_Mon.mm monitor model and select Synchronize with Application….

[ 460 ]

Chapter 8

2. WID will identify any inconsistencies and display the report:

[ 461 ]

Monitoring Business Processes

3. We review suggested changes and click on OK to confirm them. When importing the monitor model from WBM to WID, different warnings might show up, such as: •

(CWMMV1500W) The monitor model might not be synchronized with one or more associated applications: This type of warning occurs when we transport the monitor model from WBMA to WID. To remove them, we right-click on each of the monitor models in our project and select Synchronize with Application.

•

(CWMMV1309W) The specified target context reference was not found. An invalid reference might exist or the specified target context might exist in another model: This type of warning is associated with the Visual Model presentation, where a diagram link can specify a context in another monitor model. The context that this diagram link refers to cannot be found, but that does not necessarily mean that it does not exist. For our example to work, you can safely ignore these warnings.

•

(CWMMV0706W) For this event, the correlation expression does not reference the key metric in the parent context of this context: This type of warning occurs on a creation event, when not all of the keys in the parent monitoring context are referenced in the correlation expression and, therefore, an instance of the parent context cannot be uniquely identified. In our example, we can ignore these warnings, because when inbound events create new monitoring contexts, there will be only one instance of parent monitoring context that will match the correlation expression.

•

(CWMMV0518W) The expression potentially returns values in a wider range than the metric accepts. Value required metrics should not be assigned empty values: This type of warning occurs when a metric is set to require a value, but the metric value expression might produce a null result. This warning can be ignored if it is ensured that the expression will never return null. In our example, we can ignore this warning as all our instance metrics have default values specified.

Monitor model overview

Let's now take a look at TravelApproval_Mon.mm. We double-click on the file in Project Explorer to view it in the editor. Information about the monitor model is divided into five tabs: •

Monitor Details Model: It contains information about events emitted from the monitored application, related triggers, and all available instance metrics, including counters and stopwatches. [ 462 ]

Chapter 8

•

KPI Model: It contains all defined key performance indicators that we have defined in the Business Modeler.

[ 463 ]

Monitoring Business Processes

•

Dimensional Model: It contains aggregate metrics and specified levels for dimensional analysis of collected data.

•

Visual Model: It enables us to view a graphic model of a monitored process (we have to install the required Adobe SVG Viewer plug-in).

[ 464 ]

Chapter 8

•

Event Model: It contains event definition references that are imported in the event model.

•

TravelApproval_Mon.mm: It displays source code of the entire monitor model as an XML file.

[ 465 ]

Monitoring Business Processes

Adding business measures in WID

Besides viewing and editing the metrics and the KPIs from the Business Modeler in WID, we can also define additional measures. In this example, we will define two KPIs that will display the percentage of selected offers from American and Delta airlines. We will figure out whether American or Delta airlines has been selected, based on which reservation service has been invoked. Then we will count how many times each airline has been selected and, finally, we will calculate the percentage by dividing each selection count by the number of both selections.

Defining events

For this purpose, we have to define the required events; namely, invocation of the Delta airlines and American airlines reservation services to be emitted from the business process (enable events in the application). We can do this in the following way: 1. We have to switch to the Business Integration perspective. 2. In the Projects view, we expand packtpub.com | Integration Logic | Processes. 3. In the bpel/travel/travelapproval folder, we double-click on TravelApproval to open the BPEL process in the process editor.

4. We look for the Airline Selection Scope and select the Delta Airlines Reservation activity. 5. In the Properties view, we select the tab Event Monitor. 6. We select the option Selected, check Entry, and leave the other options at their default values.

[ 466 ]

Chapter 8

7. We do the same procedure once again for the American Airlines Reservation activity. 8. Finally, we save changes to the BPEL process. With the previous procedure, we have configured the BPEL process to emit proper events when the ticket is reserved with either the Delta or American Airlines service. In the next section, we will use these events to monitor which airline has been selected.

Importing events

Now our Travel Approval business process will generate two new events. We have to import these events, if we want to be able to detect and process them in our monitor model: 1. We switch back to the Business Monitoring perspective. 2. Then we expand packtpub.com_Monitor in Project Explorer and open the folder Monitor Models. 3. We double-click on TravelApproval_Mon.mm and select the Monitor Details Model tab.

[ 467 ]

Monitoring Business Processes

4. Before we make updates to the monitor model, we have to ensure that the monitor model is synchronized with the application. Therefore, we rightclick the Travel Approval monitoring context, select Synchronize with Application…, and click on OK to confirm.

5. Now, we right-click on the Travel Approval monitoring context and select Update from Application – packtpub.com.

[ 468 ]

Chapter 8

6. In lower-right corner of the Generate Monitor Model window, we select the Include only the events that have been turned on in the application option. 7. We expand Airline Selection Scope and look for American Airlines Reservation activity. 8. We switch to the Emitted Events tab and check the American Airlines ReservationENTRY event. 9. Now, we do the same for the Delta Airlines Reservation activity and the Delta Airlines ReservationENTRY event.

10. We click on Next and Finish to complete the operation.

[ 469 ]

Monitoring Business Processes

In the Generate Monitor Model window, there are two tabs: Monitoring Templates and Emitted Events. In the Monitoring Templates tab, we can select from the list of predefined monitoring templates and the monitor model will automatically include all the required events and create the appropriate measures. In the Emitted Events tab, we can manually select single events that we want to consume in our monitor model. An important setting in this window is the one to Select events. This setting controls whether the monitoring template you select will include all the predefined events and automatically enable them in the application, or only a subset that has previously been enabled in the application. There are three possible options: •

Include all selected events: This means that the selected Monitoring Templates and Emitted Events tab will include all available events. If these events are not set to be emitted by the application, they will never be generated.

•

Include all selected events and enable them in the application: This option will, in addition to the first one, enable all selected events in the application.

•

Include only the events that have been turned on in the application: This means that only already emitted events will be visible in the Emitted Events tab and included in the selected Monitoring templates.

11. As a result, two new events are added in Monitor Details Model view:

[ 470 ]

Chapter 8

Defining triggers

With events imported into our monitor model, we can now think of defining two instance metrics. They will specify whether the offer from American Airlines or from Delta Airlines has been selected. We first need to specify the triggers that will assign the value to these metrics. For example, when the American Airlines ReservationENTRY event is received, a trigger should fire, which will assign the value true to the metric that the American Airlines has been selected. To specify the triggers, we do the following: 1. We right-click Travel Approval Context and select New | Trigger.

2. We enter AA Reservation Entry Trigger as Name. 3. Under Trigger Sources,we click on Add and select the Other source type option, then the American Airlines ReservationENTRY event as source.

[ 471 ]

Monitoring Business Processes

4. We click on OK to confirm.

5. In the same way, we add DA Reservation Entry Trigger and select the Delta Airlines ReservationENTRY event as source.

[ 472 ]

Chapter 8

Specifying instance metrics

We will specify two instance metrics that will specify whether American or Delta Airlines has been selected: 1. We right-click on the Travel Approval monitoring context and select New | Metric.

2. We name this metric American Airlines Selected, select Boolean as Type, and click on OK.

3. We check the A value is required for this metric checkbox and select false() for the default value.

[ 473 ]

Monitoring Business Processes

4. Under the Metric Value Expressions section, we click on Add and select AA Reservation Entry Trigger for Trigger and true() as Expression. This way we have ensured that this metric will be true when the American Airlines reservation service is invoked.

5. Similarly, we add another metric named Delta Airlines Selected and select DA Reservation Entry Trigger for Trigger. The two metrics we defined in this section will identify which airline has been selected in each process instance. Based on their value, we will build KPIs that will count how many times each airline has been selected altogether.

Creating KPIs

With the instance metrics ready, we can now create two KPIs that will count how many times each airline service has been selected. To calculate this value, we will count the instances that have the appropriate Selected Count metric set to true: 1. We switch to the KPI Model tab. 2. We right-click on the TravelApproval KC KPI context and select New | KPI.

[ 474 ]

Chapter 8

3. We name it AA Selected Count and click OK. 4. We have to make sure that Decimal is specified as Type and then we set 0 as Decimal precision. 5. We scroll down to the KPI Value section and select Base this KPI on a metric and an aggregation function. 6. We select Travel Approval as Monitoring context.

7. We select American Airlines Selected as Metric and Count as Aggregation function. 8. In the Data Filter section, we Add a new filter, select American Airlines Selected as Metric, and enter true() in the Values column.

9. We click on Save to confirm changes. 10. Now, we repeat the previous steps and create a DA Selected Count KPI based on the Delta Airlines Selected metrics.

[ 475 ]

Monitoring Business Processes

Finally, we have everything ready for defining the KPIs that will display the percentage of the accepted offers from each airline. To calculate this value, we will divide the number of times individual airlines have been selected, by the number of times any of airlines has been selected: 1. 2. 3. 4.

We add a new KPI and name it AA Selected Percentage. Next, we set the type to Decimal and check the Show as percentage checkbox. We set Decimal precision to 2. We scroll down to the KPI definition section and choose the Write an expression to calculate this KPI based on existing KPIs option. 5. Then we click in the text area and press Ctrl+space to bring up content assist and build the following expression: if (AA_Selected_Count + DA_Selected_Count eq 0) then 0 else (AA_Selected_Count div (AA_ Selected_Count + DA_Selected_Count)).

6. We save changes and then, in the same way, build DA Selected Percentage, using the expression if (AA_Selected_Count + DA_Selected_Count eq 0) then 0 else (DA_Selected_Count div (AA_Selected_Count + DA_Selected_ Count)).

Defining a dimension

We are almost done now. We will just add another level for dimensional analysis to demonstrate this functionality. In Business Modeler, we have already defined the requestor dimensional level and this information is presented in the Dimensional Model tab of the monitor model editor: 1. If we switch to the Dimensional Model tab, we will see four cubes that correspond to the generated monitoring contexts. 2. Three of them are empty and we won't be using them. So, we can go ahead and delete them.

[ 476 ]

Chapter 8

3. In TravelApproval Cube, there are already aggregate metrics Average TravelApproval Processing Time and requestor dimension, which we have previously defined in Business Modeler. We will define another dimensional level, called Approved dimensional level that will enable us to analyze the measurements based on whether the travel request has been approved or not. To achieve this, we first have to define an instance metric in the Travel Approval context that will specify whether the travel has been approved or not (an already defined metric is not available in the appropriate context). We will use an existing trigger and only copy the value from the existing metric in the Confirm Travel Approval scope to a newly created metric in the Travel Approval scope. 4. We move back to the Monitor Details Model tab and add a new metric to the Travel Approval context.

5. We name it Travel Approved and select Boolean as Type. 6. We check A value is required for this metric and select false() as the default value.

[ 477 ]

Monitoring Business Processes

7. We add a new entry in the Metric value expressions table and select Travel Approved Value Change Trigger as Trigger.

8. We choose Ticket_Confirmation_Scope | Confirm_Travel_Approval | Travel_Approved as Expression.

[ 478 ]

Chapter 8

With the instance metric prepared, we can now define the dimensional level: 1. We move again to the Dimensional Model tab. 2. We right-click on Travel Approval Cube and select New | Dimension. 3. We enter Approved Dimension as Name. 4. Now, we right-click on the newly created dimension and select New | Dimension Level. 5. Once again, we enter Approved Dimension as Name and select Travel Approved as Source metric.

6. We click on OK to confirm and then save the changes. In this section, we have gone through the complete procedure of defining dimensions. We have defined an instance metric and the corresponding evaluation expression. Based on this metric, we have then defined a new dimension that will enable more detailed data analysis in the monitor dashboard.

[ 479 ]

Monitoring Business Processes

Building and publishing a monitor application

When we finish building our monitor model, we have to generate the JEE projects from it and publish them to the WebSphere Business Monitor Server: 1. We right-click on TravelApproval_Mon.mm in Project Explorer and select Generate Monitor JEE Projects.

2. We click Finish. 3. Next, we open the Servers view, right-click monitor server, and select Add and Remove Projects….

[ 480 ]

Chapter 8

4. We select TravelApproval_MonApplication in the left column and click on Add.

5. We click on Finish to publish the monitoring application to the server. In this section, we have transformed our monitor model into a JEE application, which we can publish to the monitor server. Once published, the monitoring application will start gathering monitoring data and we will be able to view the monitoring results. In the following sections, we will show how to view monitoring results.

[ 481 ]

Monitoring Business Processes

Preparing a dashboard in Business Space In the previous step, we have concluded the development of the monitor model. In this section, we will look at how we can develop a dashboard. A dashboard presents various business indicators and allows us to follow them in a graphical representation. We will develop a dashboard in Business Space. To open the business space for presenting KPIs, we have to do the following: 1. We right-click on the monitor server and select Launch | Business Space.

2. This will open the Business Space page in our web browser; we need to install the required certificates and log in with our username and password.

[ 482 ]

Chapter 8

Configuring Business Space

We have to configure the business space to display the available measures. First, we will create a new space: 1. We click on Manage Spaces in the upper menu bar. 2. In the Space Manager window, we click on Create Space. 3. We enter packtpub.com as Space name, leave Blank as Template, and click on Save. 4. Now, we click on the newly created space, packtpub.com, to open it. The created space has one page, named Page 1. We will first rename this page: 5. We open the menu next to Page 1 title and select Edit Settings….

6. We enter packtpub.com business information as Page name and click on Save. Next, we will add a widget for displaying the KPIs: 7. We click on the Edit Page button.

8. Then we drag the KPIs widgets onto the page.

[ 483 ]

Monitoring Business Processes

9. We click on the menu in the upper-right corner of the KPIs widget and select Edit Settings….

10. We expand TravelApproval_packtpub.com.bpel.travel 2010-08-07 21:52:04 and select the following KPIs: °Â°

AA_Selected_Percentage

°Â°

Approved Travels Percentage

°Â°

DA Selected Percentage

11. We switch to the Layout tab and select Half Gauge as the display type. You can also experiment with the other display types. 12. We click on OK to confirm changes. [ 484 ]

Chapter 8

Defining an alert

At this point, we will define an alert that will inform the user when the value of the Approved Travels Percentage has fallen beneath the defined value: 1. We click on the menu button in the upper-right corner of the Approved Travels Percentage KPI. 2. There we select Alert Manager:

3. We click on New Alert. 4. We specify Low Approved Travels Alert Percentage as Alert name and Travel Approved Alert percentage has dropped below 70% as Description. 5. In the Conditions section, we set the condition to Below range and value to Acceptable (the range that we have previously defined for this KPI). 6. For testing purposes, we will set the timing to 5 minutes and leave Notification frequency at Once per selected period when the condition applies.

[ 485 ]

Monitoring Business Processes

7. In the Alert Content tab, we can customize the content of the alert message. But in this example, we will leave it as default. 8. In the Notification tab, we check Dashboard Alert in our username row.

9. We click on OK to confirm. To view these alerts, we have to add another widget to our monitoring page: 10. We drag the Alerts widget from the widget palette to the page in editing mode. 11. If there are already existing alerts, we remove them so we can note new alerts more easily. With the previous steps, we have defined an alert that will be raised when the percentage of approved travels falls below 70%. Users are able to subscribe to such alerts and all subscribers receive notifications when such situations occur.

Preparing a widget for dimensional analysis With KPIs and alert widgets now ready to use, we will also add and configure a widget for the dimensional analysis: 1. We drag the Dimensions widget to the page. 2. We click on the menu button in the upper-right corner of the Dimensions widget and select Edit Settings. 3. We select TravelApproval (All Versions) as Monitoring Model: and Travel Approval as Monitoring context:. 4. We add Requestor Dimension to Row dimensions, Approved Dimension to Column dimensions, and Measures to Page dimensions.

[ 486 ]

Chapter 8

5. We click on OK to confirm the settings and then Save and Finish Editing to save changes. At this point, our business space page should look like this:

[ 487 ]

Monitoring Business Processes

In this section, we have prepared a widget for dimensional analysis. This widget displays a graph of aggregate metrics included in page dimensions, which can be drilled up and down, based on the selected row and column dimensions. We will show how this works in the next section.

Testing the dashboard

We will create and complete a few instances of the Travel Approval process and observe how the dashboard displays the various indicators: 1. First, we start a process instance with the values First as LastName, management as Department, enter a valid e-mail address, and set Confirmed to true in the human task: John First management [email protected] F20984 Seattle Las Vegas 2010-08-26 2010-08-31

If we look at the KPIs, we will see that their values have already changed. Approved Travels Percentage has risen to 100%, as well as DA Selected Percentage, while the value of AA Selected Percentage is still 0%.

[ 488 ]

Chapter 8

We will create a few more process instances to demonstrate the alerts and analytics ability provided by the dimensional model: 2. We start another instance with similar input as the earlier one, but set marketing as Department and then set Confirmed as false in the human task. We can see that the values of the KPIs have again changed. Approved Travels Percentage has dropped from 100% to 50%. This means that the alert we previously defined should be triggered. If we wait for 5 minutes (or the time period you have set earlier), we should see a new alert in our Alerts widget.

A new alert will be raised every five minutes, as long as the value of the KPI is below 70%. If we want to unsubscribe from this alert or edit timing settings, we can do the following: °Â°

We click on the menu button for the selected KPI.

°Â°

We select Alert Manager.

°Â°

To unsubscribe from the chosen alert, we uncheck all boxes in its row.

°Â°

To edit the settings, we click on the pen icon and reconfigure our alert.

[ 489 ]

Monitoring Business Processes

Now we will start two more instances of our Travel Approval process: •

For the first instance, we set Mike as FirstName, Second as LastName, research as Department, and set Confirmed to true.

•

For the second instance, we use the same input as in the previous one but set Confirmed to false in the human task.

Now let's take a look at our dashboard once again: 1. We log back into Business Space and click on Go to Spaces in the upper menu bar. 2. We click on packtpub.com from the list of available spaces. 3. In the Dimensions widget, we right-click on the All Requestor Dimension column and select Drill Down.

4. We can drill all defined dimensions up and down. 5. We can switch between Measures (page dimensions) using the drop-down box.

[ 490 ]

Chapter 8

With this, we have concluded the testing of the dashboard.

Summary

In this chapter, we have become familiar with business process monitoring, which is an important part of SOA and BPEL development. It should not be overlooked, as business managers often see great value in business monitor dashboards, which enable them to follow business indicators, such as KPIs for process execution. We have explained the concepts of Business Monitoring in WebSphere. We have demonstrated how to develop a monitor model and a dashboard in WebSphere. To develop a monitor model in WebSphere Business Modeler, we have shown how to create business measures, specify metrics, add instance metrics, specify KPIs, and create dimensions. Monitor model is then exported from Business Modeler and imported into Integration Developer. We have shown how to do this. We have also explained how to use the Business Monitoring Perspective in WID and how to resolve possible warnings. We have shown how to refine the monitor model in WID. We have explained how to define events in WID, define triggers and instance metrics, create KPIs, and define dimensional models. To be able to observe the business indicators, we have to develop a dashboard, which is a graphical representation of various indicators gathered by the monitor model. We have demonstrated how to develop a dashboard in Business Space.

[ 491 ]

IBM BPM Enabled by SOA: Overview A Business Process Management (BPM) approach enabled by Service Oriented Architecture (SOA) approach is the key to achieving operating efficiencies and competitive advantage for any organization. Organizations need a BPM enabled by SOA framework (herein referred to as BPM-SOA framework), which will allow them to constantly evolve their collaborative process automation and process improvement approaches. In this chapter, we will look at IBM's BPM-SOA positioning, the methodology, the core products that help you become successful with this approach, core capabilities provided by the products, and how these products can be applied in an appropriate phase of the BPM-SOA approach. We will look at numerous examples as we go through each of the topics. First, we will take a look at IBM's SOA Fundamentals, their SOA Programming Model. We will then look into the core capabilities that are required in a BPM platform and how IBM's BPM-SOA provides those capabilities. We will go into detail about each of the capabilities with practical examples. We will also briefly discuss the Industry Content Packs that provide instant acceleration and help jumpstart BPM-SOA projects. The goal of this chapter is to cover the following items and topics: •

Overview of IBM's BPM-SOA approach

•

Overview of the capabilities and products that make up this platform

•

Discuss the key building blocks for a business-process-driven integration, enabled by SOA

•

Briefly discuss the value of reference architectures and IBM SOA reference architecture

•

Overview of IBM's BPM product stack

IBM BPM Enabled by SOA: Overview

•

Overview of WebSphere Integration Developer (WID), WebSphere Process Server (WPS), and how and where they fit in the larger BPM and SOA application development lifecycle

•

Explain some of the fundamental concepts around workspace, modules, libraries, assembly diagram, palette, and solution diagram

•

Explain where WID/WPS fits in with WS-BPEL and how to work with BPEL components in WID

•

Discuss types of business process you can build using WID—Long-Running versus Microflows

•

Building the first business-process-based project in WID

•

Deploying the module on a server and testing the project

Achieving success through BPM enabled by SOA Many organizations have many applications, which are disparate in terms of technology, programming languages on which they are based, capabilities exposed through interfaces or services or API's, and so on. For example, creating a purchase order in an order entry system will need information about the customer from customer information management systems, product information, a product catalogue, and so on. Hence, there is a constant struggle to make all the applications integrate.

IT is under constant pressure to address these requirements for managing layerupon-layer of legacy systems that may or may not interoperate with any degree of simplicity. This is where integration comes in and helps connect applications together with the right communications and server infrastructure, as well as the right business process capabilities. This will give IT and enterprise leaders the ability to create composite applications that meet new flexible and dynamic business needs. The process of building an SOA is a journey and possibly an ever-evolving, everlearning, and never-ending one. With SOA, you progress and mature over time to reach a state where you can truly achieve the benefits as promised. Getting integration right is one of the key aspects to get SOA right and it enables the integration of disparate applications. Integration is only one half of the struggle; there are several techniques and modes in which you can integrate applications. They include (but are not limited to): •

Presentation-based integration, which provides interaction and collaboration capabilities [ 494 ]

Chapter 9

•

Process-driven integration, which helps streamline business processes

•

Information-centric integration, for unified access to information from heterogeneous data sources

•

Bare bones connectivity-based integration

We will see what a BPM-SOA framework is and what it consists of in the following sections.

Business Process Management

I'm sure you have read about BPM. BPM is a discipline that focuses on process modeling, design, automation, management, and continuous improvement. It is not a Technology or a Product. It covers the full range of application-to-application, interapplication, workflow, and person-to-person process management, including process modeling, design, automation, management, and continuous improvement. The core and basic components of BPM include (but are not limited to): •

Modeling and simulation

•

Policies and rules

•

Collaboration through human task processing

•

Content-centric processing

•

Process execution including choreography and orchestration

•

Business Activity Monitoring (BAM)

•

Support for common business objects

•

Intuitive process definition tool

•

Customizable work portal

•

Historical process analysis

•

Wide range of integration capabilities and adapters

•

Process tracking and notification

•

Process performance analysis

•

System scalability and process performance

•

Provision for parallel human task approvals

•

Capability to work with and modify in-flight processes

[ 495 ]

IBM BPM Enabled by SOA: Overview

Building blocks of a BPM enabled by SOA framework

According to the IBM Global CEO Study from 2008, 85% of CEOs report that they require more visibility into their businesses. Customers understand their business processes very well, and systems must be improved to meet the imperatives of today's business environment. An IBM BPM-SOA framework covers and provides a set of collaborative, role-based capabilities for customers to model, simulate, execute, rapidly change, monitor, and optimize their core business processes. Businesses understand very well that their core (and differentiating) business processes will have to be automated (post integration) and they need to be able to externalize these from end applications. Process-driven integration is about bringing people, processes, information, and systems together using a BPM-SOA approach. This approach requires a solid technology platform and of course an over-arching methodology that will offer a prescriptive guidance on how to deliver solutions. So what are these core building blocks? They include: •

Business process modeling

•

Business policies and rules

•

Enterprise service bus

•

Business process monitoring

•

Information model

Now let's briefly look at each of these core building blocks/capabilities that are needed for achieving success in a business-process-driven integration.

[ 496 ]

Chapter 9

Business process modeling

This is the starting point, where you discover and document various other business processes (using a modeling notation such as business process modeling notation— BPMN) that might exist on paper or even in the minds of some subject matter experts and document it with business modeling. Also, once the processes are modeled, you have the ability to run model simulations and try out various what-if scenarios to forecast what would happen if you altered the process. Based on these simulations, you arrive at an optimal process design. The process modeling exercise also helps identify the SOA services that will have to be specified, realized, and also, in many cases, reused.

Business process execution (including choreography)

Once the business processes have been modeled, they will have been defined in an executable format (such as business process execution language, BPEL) and deployed on a standard-based process execution platform that supports both the business process execution environment and the packaging of business tasks as services. The assembly, sequencing, orchestration, and choreography of existing services and new services result in the realization of a deployable process model. This assembly should be based on industry standards such as Service Component Architecture (SCA). The execution platform must also support human interaction for both participants in the business process and administrators of the business process. The runtime should also provide a variety of administrative capabilities, required to configure the environment for the applications that are installed.

Enterprise Service Bus

ESB provides the underlying connectivity and backbone infrastructure for SOA to connect applications. An ESB is essentially an architecture pattern that provides capabilities including connectivity, communications, message queuing, message routing, message transformation, reliable messaging, protocol transformation and binding, event handling, fault handling, message-level security, and many more. It enables loose coupling between service consumers and providers and thus enhances the ability to rapidly change and introduce new business services into the environment. An ESB typically would leverage a service registry and repository to provide information about service endpoints.

[ 497 ]

IBM BPM Enabled by SOA: Overview

Business policies and rules

Policies and rules can make business processes highly flexible and responsive. A business policy represents a key piece of domain knowledge, externalized from a business process and applied when a particular request context is met. Examples could be: all purchase orders that include order items such as Oxygen Canisters are deemed critical orders, orders worth over $1,000 have to be shipped overnight, and such others. Metadata elements such as order item and order amount are deemed as the business domain vocabulary the values of which can change (you can add Defibrillator to the critical items list), and which will have to be externalized from the business process. A business rule is a statement that defines or constrains some aspect of the business. They are typically atomic and cannot be broken down further. An example would be say, in a loan origination business process, at each step of the process, business analysts identify rules that must be met by the loan staff and underlying systems. In traditional banking systems, these rules reside within the loan origination system itself, so changing the rules means modifying the application. When the rules are abstracted from the loan origination, systems reside in a business rules engine. As a result, bank management can identify those activities that change rapidly, such as decisions related to FICO® scores, and then, instead of changing the process and its underlying application, they change only the decision point within the business process, which in turn resides in the business rules engine (external to the process itself). This capability adds agility to the process by reducing the time, costs, and resources necessary to respond to changing conditions.

Business process monitoring

While the business processes are being deployed, executing data that provides information about the processes must be captured. This data can be analyzed to determine if the business processes are performing as expected. Both businessrelated information and IT-related information can be captured for monitoring. You should also be able to visually define dashboards based on Key Performance Indicators (KPI), based on the monitor model deployed for the business process, providing a visual display of business process status.

[ 498 ]

Chapter 9

Information model

For a process-driven integration approach coupled with SOA to succeed, a common and enterprise-level information model is required, which becomes the basis for the messages exchanged between processes and services, and also serves as the glossary for the business policies and rules. When dealing with applications that have disparate data and information models, use of this common information model shields the business processes from the gory details of each and every individual system. The ESB provides capabilities to transform from this Canonical Data Model to the target system's format. A canonical data model minimizes dependencies between integrated applications that use different data formats. A typical one could leverage industry standards such as Tele Management Forum's Shared/Information Data model (SID) and such others, to define the information models. A mind map is a diagram used to represent words, ideas, tasks, or other items linked to and arranged around a central key word or idea. Mind maps are used to generate, visualize, structure, and classify ideas, and as an aid in study, organization, problem solving, decision making, and writing.

[ 499 ]

IBM BPM Enabled by SOA: Overview

The mind map shown in the following figure, sums up the key capabilities that should be provided by a BPM-SOA platform.

[ 500 ]

Chapter 9

Having listed the key characteristics of a BPM-SOA platform, which products from IBM provide those capabilities? The core products that make up IBM's BPM platform are as follows: •

WebSphere Business Modeler (Modeler)

•

WebSphere Business Compass (Compass)

•

WebSphere Integration Developer (WID)

•

WebSphere Process Server (WPS) including WebSphere Enterprise Service Bus (WESB)

•

WPS is the runtime for BPEL components

•

WebSphere Business Monitor

•

WebSphere Industry Content Pack (WICP)

IBM SOA reference architecture

IBM's SOA reference architecture defines a vendor- and technology-agnostic set of comprehensive IT capabilities that are required to support SOA at each stage in a typical lifecycle. When an organization defines a solution architecture based on this reference architecture, they would not need all of the capabilities initially. But over time, to be successful in SOA, all the capabilities need to be evolved and added to. A reference architecture is useful for: •

Providing a common ground domain model

•

Realizing an architecture vision

•

Providing key architectural guidance and a blueprint as a baseline

The reference architecture is typically abstract and is abstract for a purpose. You typically instantiate or create solution/system architectures based on the reference architecture. For example, a reference architecture includes: Unisys 3D Blueprints, IBM Insurance Application Architecture, NGOSS reference architecture from the TM Forum, and so on.

[ 501 ]

IBM BPM Enabled by SOA: Overview

Key elements of an IBM SOA Reference Architecture

The IBM SOA Reference Architecture is a reference model that lets you leverage information, applications, and tools as services in an interoperable, system-independent way. The following figure shows the IBM SOA Reference Architecture organized around the key capabilities required for building any SOA-based solution.

•

Development Services provide capabilities in terms of development tools for the end users to efficiently complete specific tasks and create specific output, based on their skills. These tools include WebSPhere Business Modeler, WebSphere Integration Developer, and such others.

•

Interaction Services provide user-interaction capabilities required to deliver the business services and data to end users.

•

Process Services provide the control, management, choreography, and orchestration of the business processes that interact with multiple services.

•

Information Services provide the capabilities required to federate, unionize, and transform data from one or multiple information or data sources.

•

Enterprise Service Bus delivers all the connectivity capabilities required to leverage and use services implemented across the entire enterprise.

[ 502 ]

Chapter 9

•

Business Innovation and Optimization Services provide monitoring capabilities and manage the runtime implementations at both the IT-and business-process levels.

•

Business Application Services are services provided by existing applications or ones that will have to be exposed by the applications themselves including third-party systems.

•

Access Services allow access to the end applications, legacy applications, prepackaged applications, enterprise data stores (including relational, hierarchical, and nontraditional, unstructured sources such as XML and text), and many more, using a consistent approach. These typically leverage the business application services.

•

Infrastructure Services provide security, directory, IT system management, and virtualization capabilities to the SOA solution.

•

Partner Services provide capabilities for the efficient implementation of business-to-business processes and interactions.

So, what is the relationship between the process integration, key capabilities needed for successful process integration, SOA, IBM SOA Reference Architecture, and IBM's BPM-SOA framework products (of which WebSphere Process Server and WebSphere Enterprise Service Bus are key ones)? The answer is pretty obvious. The book is about how you build SOA- and BPM-based solutions (leveraging the BPEL standards) with these two products, and these two products indeed provide a majority of the capabilities that are essential for a successful SOA, if not all. Now, let's delve into what these two products are all about with more focus on WebSphere Process Server. Having defined the essential elements of our BPM-SOA approach and having explained the need for a reference architecture (and in particular what IBM's SOA reference architecture is all about), how does it all come together? How would a (reference) solution architecture based on the IBM SOA reference architecture look? The following figure shows one such instantiation of the BPM enabled by SOA solution architecture. It incorporates all the building explained earlier, as categorized and organized into the appropriate IBM SOA reference architecture buckets/layers. Also detailed is what each layer and each building block should have as capabilities within itself.

[ 503 ]

IBM BPM Enabled by SOA: Overview

[ 504 ]

Chapter 9

IBM SOA programming model

When embarking on an SOA journey, developers often come across the daunting realities of multiple programming languages, technologies, data format representation, implementation framework options, and such others, when they build services, use services, and develop solutions that aggregate services. The focus should be on programming the business and service design, not on the technology of the underlying implementation. IBM's SOA programming model provides a set of rules and languages that lets you focus on creating an implementation of a business design. The programming model addresses the aspects of service components and the data that is exchanged between services as service data, over a service bus. Now, let us look at the key aspects of this programming model.

Service Component Architecture

We design and build applications (for example, account opening, loan underwriting, order management, customer care, customer billing, and so on) so that an organization can run their business effectively and efficiently. Applications can be looked at as a collection of software components that are assembled or integrated together for a particular purpose. Ideally, you should have the freedom to implement the different components in the technology of your choice. However, at times you may have to inherit or work with existing systems, technologies, or work with third parties who have a different set of technologies. When you adopt an SOA approach to building applications, these components can be viewed as services. When we look at the constructs that make up a service, two things immediately come to mind: •

The What part: Data that should be passed to the service and data received back from the service

•

The How part: The mechanism required to realize the service and how it can be invoked or can be made available to a service consumer

For each of the previous two questions, there are many standards and programming models and, at times, it may get too overwhelming. This is where an SCA model comes in and mitigates these complexities. SCA is not another programming language or replacement, but rather gives a model to assemble and build SOA applications by choosing any technology specific to the implementation approach. The fundamental goal and premise of SCA is to separate business logic from infrastructure logic. IBM's BPM development tool WID provides the design time environment to build SCA-based applications using a bottom-up (expose services out of existing applications and make them available through the Enterprise Service Bus) or top-down approach (more a business-driven approach to identify the right set of services needed to achieve a larger goal, capability, or solution). [ 505 ]

IBM BPM Enabled by SOA: Overview

Therefore, WID enables architects and developers to spend more time working on solving a particular business problem rather than focusing on the details of which implementation technology to use. BPEL is one of those components that are available in WID to build applications. Defining SCA SCA is a set of specifications that describes a model for building applications and systems using an SOA approach. SCA extends and complements prior approaches to implementing services and SCA builds on open standards, such as web services. SCA divides the steps in building a service-oriented application into two major parts: • The implementation of components (including BPEL) that expose (export) services and consume (import) other services •

The assembly of sets of components to build business applications, through the wiring of references to services

SCA uses Service Data Objects (SDO) to represent the business data that forms the request and response values of services, providing uniform access to business data to complement the uniform and consistent access to business services offered by SCA itself. SCA supports bindings to a wide range of access mechanisms used to invoke services. The complete set of SCA specifications can be found at http://www.osoa.org/display/Main/Service+Component+Ar chitecture+Specifications.

SCA emphasizes the decoupling of service implementation and of service assembly from the infrastructure capabilities, from technology or programming language specifics, and from the details of the access methods used to invoke services. SCA components operate at a business level and use a minimum of middleware-specific APIs. The basic elements of SCA include: •

Service components

•

Service assembly

•

Service data objects

The basic building block in SCA is the service component and represents a business service that publishes or operates on business data. The SCA Component Fundamental Structure figure depicts the essential pieces of a service component definition. A service component can have one or more interfaces with which it is associated. The interfaces associated with a service component advertise the business operations associated with this service. These interfaces can be specified as either Java interfaces or WSDL port type interfaces. [ 506 ]

Chapter 9

The arguments and return types for these interfaces are specified as simple Java types, Java classes, SDOs, or XML Schema (for WSDL port type interfaces). Also, implementation is associated with a service component definition. As the figure indicates, there are multiple language and component types available for implementing a service component. When specifying a component interface, you cannot mix Java and WSDL port type interfaces on the same service component definition.

A service assembly deals with the aggregation of components and the linking of components through wiring or wires. Think of the assembly model as how, when building a kitchen, you would assemble various components including kitchen cabinets, sink, appliances, counter top, and so on. The assembly model is independent of implementation language. An analogy would be, you don't care how and where the dishwasher is engineered, manufactured, and built, but rather focus on the features, functions, and durability.

[ 507 ]

IBM BPM Enabled by SOA: Overview

As depicted in the following figure, an SCA-based application Order Handling System can be made up of one or many modules and hence one or many components. Components can be combined into composites, a logical construct. In the following figure, we can see that the Order Handling System is made up from two composites, an Order Processing Composite and a Third-Party Shipping Composite. In WID, a composite can be compared to a Service Module, which in essence becomes the basic unit of deployment and administration in WPS or WESB (SCA runtime). A service module typically contains the following artifacts: •

•

•

Module Definition °Â°

An SCA-specification-defined deployment model for packaging components into a service module. In WID, the sca.module file contains the definition of the module.

°Â°

In the following figure, the Order Processing Composite and Third-Party Shipping Composite are the modules.

Service Components °Â°

Each service component can be implemented in various ways (BPEL, Mediation Flow Component, State Machine, Java, and so on), specified by the implementation definition.

°Â°

Service components can invoke other service components or imports, defined in the current service module as defined by an appropriate reference.

°Â°

A component can have 1..N interfaces.

°Â°

Each service component definition can have zero or more references to other services.

°Â°

In the following figure, the Order Validation Component and Order Handling Component are the service components whose implementations are BPEL and state machine respectively.

°Â°

In WID, the service component definition is included in the .component file.

Imports and Exports °Â°

Allows SCA components in one module to invoke SCA components in other modules.

°Â°

A service module can have zero or more imports included with it.

°Â°

Imports have a name and a set of 1..N interfaces. [ 508 ]

Chapter 9

°Â° °Â°

°Â°

°Â° °Â°

A Binding attribute describes how the external service is bound to the current module. Once an import has been defined, other services within the module can reference the imported service as if it was a regular service component defined in the module. In the following figure, the Order Handling Component imports a component from the Third-Party Shipping Composite via a reference. In WID, import definition is included in an .import file. Imports can use the following bindings, which can be remote or local: °Â° °Â° °Â° °Â° °Â° °Â° °Â°

°Â° °Â°

°Â° °Â° °Â° °Â° °Â° °Â°

SCA Web service HTTP Messaging (JMS, MQ JMS, generic JMS, MQ) Stateless session bean EIS Exports

Allows SCA components in a module to expose their capabilities to components in other modules. In order to invoke any of the services in the order handling application by any client (SCA or non-SCA), the service must be exposed with an export. A service module can have zero or more exports included with it. Export components include a name and a target attribute. A Binding attribute describes how the service is bound externally. In the following figure, the Order Validation Component has an export named Order Validate Export. In WID, import definition is included in an .export file. Exports binding can be: °Â° °Â° °Â°

SCA Web service HTTP [ 509 ]

IBM BPM Enabled by SOA: Overview

•

•

°Â°

Messaging (JMS, MQ JMS, generic JMS, MQ)

°Â°

Stateless session bean

°Â°

EIS

References °Â°

Inline

°Â°

Stand-alone

Interfaces, Business Objects, Java classes, and other components

In order to invoke any of the services in the Order Handling System by any client (SCA or non-SCA), the service must be exposed with an export. A service module can have zero or more imports included with it. An import is used to access services that are outside the current SCA module. Once an import has been defined, other within the module can reference the imported service as if it was a regular service component defined in the module. As depicted in the following figure, the service module Order Processing Composite can have zero or more exports included with it. An export is used to expose a particular service to clients, outside the current SCA module. A service may also include a stand-alone references file that includes references to services in the module that can be used by SCA and non-SCA services. An SCA service module is packaged and deployed to the native SCA container strategy provided by WPS. This capability allows a developer not to use any to generate runtime-specific artifacts prior to installing a module. Unlike the previous releases of WPS and WESB, with version 7.0 the native container provides greater performance improvements due to the elimination of ejbDeploy for standard SCA applications.

[ 510 ]

Chapter 9

Service data objects

SCA gives us a universal model to define business services. The SDO provides the technology to represent a universal model for data that flows between components in an SCA. Each SCA component pass and exchange data with each other in a neutral fashion by passing SDOs. Data objects are the preferred form for data and metadata in SCA. The fundamental concept in the SDO architecture is the data object, a data structure that holds primitive typed data and/or other data objects. The data object also holds references to metadata that provide information about the data included in the data object. SDOs allow the integration developer to focus on working with business artifacts. In fact, service data objects are transparent to the integration developer. They are defined by a service data object's Java Specification Request (JSR) and for more information refer to the link as follows, http://www.jcp.org/en/jsr/detail?id=235

In the SDO programming model, data objects are represented by the commonj.sdo.DataObject Java interface definition. This interface includes method definitions that enable clients to get and set the properties associated with the DataObject. Another important concept in the SDO architecture is the data graph, a structure that encapsulates a set of data objects. From the top-level data object contained in the graph, all child data objects are reachable by traversing the references from the root data object. Another important feature included in the data graph is a change summary, which is used to log information about what data objects and properties in the graph have changed during processing. The WebSphere Process Server implements the SDO specification by way of business objects. SCA components can exchange data by passing around business objects as shown. The following figure is a mindmap that summarizes the various concepts behind an SCA application.

[ 511 ]

IBM BPM Enabled by SOA: Overview

Please take time to go through it and recollect some of the concepts explained in the previous sections.

Common business process implementation types Some of the common implementation types of business process that can be implemented using WPS include: •

GUI Intensive Process °Â°

Navigational flow and data aggregation is controlled from a user interface layer rather than in a BPEL process in WPS.

°Â°

WPS is not involved in process navigation, but may be used to provide swiftly responding synchronous services.

[ 512 ]

Chapter 9

°Â° •

Synchronous Transactional Process °Â°

°Â° °Â° °Â° •

A slight extension to the GUI Intensive Process type. A collection of short-running BPEL processes provide real-time responses to graphical user interfaces or for transactional subprocesses. Transactional and therefore, it must complete within the global timeout. No state is persisted by the process. Errors are typically translated for clarity and then passed back to the caller. Use for cases when you need high performance and the caller needs a response immediately.

Asynchronously Initiated Transactional Process °Â°

°Â° °Â°

°Â°

•

Use for cases where a GUI application performs the process orchestration or control.

The caller transaction is minimal and just makes a request, but does not wait for a response. The process is assured to occur at a later time in a separate transaction. The caller seeks feedback via notifications or e-mail. Error handling is more complex than a simple Synchronous Transactional Process, since the caller is no longer present to take action. Use for cases when you need high performance and the caller does not need a response immediately, but only an acknowledgement.

Briefly Persisted Process °Â°

°Â°

°Â° °Â°

A special use of a long-running process, where the process completes relatively swiftly. The process lifespan is deliberately short (seconds, maybe minutes), such that process versioning issues can be avoided. The process must be designed to complete in a timely fashion, so no human tasks are allowed and error handling actions should be pushed out of the process. It may not receive inprocess events. Allows parallel processing, so it is good for aggregation. This is one of the most common motivations for this usage type. When choosing this pattern of business process place extra care and emphasis on exception handling to handle multitrasaction scenarios [ 513 ]

IBM BPM Enabled by SOA: Overview

•

•

°Â°

A Synchronous Transactional Process is always preferable, if at all possible. For Briefly Persisted Processes, persistence adds a significant overhead and the error handling is much more complex.

°Â°

Use for cases where the process will take a long time (more than the runtime transaction timeout) and the process instance can be flushed through to enable simple maintenance.

Versioned Long-lived Process °Â°

A true long-running process that will last a relatively long time (days, weeks, and so on). Process instances will always be present in the systems, so the complex issues of process versioning will be taken into account.

°Â°

Can contain human tasks and complex error handling, such as compensation.

°Â°

May receive in-process events, which need to contain sufficient information to be correlated with the existing process instance.

°Â°

Invocation typically does not provide a response and latebinding techniques need to be well understood.

°Â°

Activities can be set to wait for manual intervention on error.

°Â°

Use for cases where the process will take a long time (more than the runtime transaction timeout) and the process contains external system interactions.

Task-Based Process °Â°

Used to balance multiple tasks between a number of different users, possibly in different teams/departments.

°Â°

Necessitates long-lived processes and hence must consider process versioning issues.

°Â°

Allows progressive automation of tasks.

°Â°

This is a very broad category still and can be broken into four sub-types: °Â°

Structured Workflow

°Â°

Case Handling

°Â°

User Modeled Flows

°Â°

Pageflow

[ 514 ]

Chapter 9

°Â°

Use for cases where the process will take a long time (more than the runtime transaction timeout) and the process contains human interactions.

IBM's BPM enabled by SOA platform

Earlier, in the previous section, we saw the key products from IBM that are core to the BPM-SOA framework. These products, from a business standpoint, allow an organization to do the following: •

Discover and Design, model and simulate core business processes to link strategy to process execution.

•

Adapt and Respond Dynamically with end-to-end BPM lifecycle capabilities to empower the business to rapidly respond to a change.

•

Transform Insight into Action by monitoring and analyzing business processes and events for effective decisions.

•

Process Automation to increase operating efficiency and optimize costs by streamlining business processes.

While BPM is a team sport, that underlying platform should help realize this team approach and provide collaborative process modeling, process design, deployment, execution, management, and governance capabilities. Now, let us look at each of the products in detail and how they come together and help realize the larger vision of empowering the end user to understand the benefits of the BPM-SOA framework.

WebSphere Business Modeler

WebSphere Business Modeler (which is not in the scope of this book) offers process modeling, simulation, and analysis capabilities to help business users understand, document, and deploy business processes for continuous improvement. It provides the following capabilities: •

Enables business users to model, document, simulate, analyze, and report business processes in a standard-based notation (BPMN) format.

•

Simulate the modeled processes based on modeled and actual data.

•

Helps you to visualize and identify bottlenecks and inefficiencies in processes.

[ 515 ]

IBM BPM Enabled by SOA: Overview

•

Integration with the IBM WebSphere Process Server through role-based Business Space, a unified end-user interface that integrates BPM content for a holistic management of business processes.

•

Enables subject matter experts to share models and collaborate to translate business intent into process models using a web browser with WebSphere Business Compass.

•

Export the modeled business process models in formats such as BPEL, WSDL, XSD, FDL, and UML.

Shown in the following screenshot is an example of a business process that is modeled in WebSphere Business Modeler using the BPMN notation.

WebSphere Integration Developer

WID is part of the WebSphere BPM suite and is the Eclipse-based authoring environment to build SOA-and BPM-based solutions. WID is primarily used in the assembly, implementation, and testing of SCA-based applications. It enforces a topdown, assembly-driven approach to build SOA-and BPM-based applications. The fundamental construct in a WID centric world are components. Components are services, which are assembled to form end-to-end applications. In WID, the focus is on the assembly of components. The implementation of components can be done later or can be reused from capabilities exposed by existing IT systems. Users of WID typically produce artifacts or components such as business processes, state machines, data transformations, mediation flows, adapters, and so on that are assembled together visually, to form a solution.

[ 516 ]

Chapter 9

WID provides the visual environment to build these artifacts and make the users focus on business logic implementation, by providing this layer of abstraction, and not worry about the component implementation. It also provides integrated testing, debugging, and deployment capabilities. WID provides an embedded unit test environment into which the applications can be deployed for testing and validation. Finally, solutions that are created using WID are based on the most common and prevalent industry standards, including JMS, BPEL, Web Services, SOAP, JCA, and such others.

The relationship of the various components in WID, how they relate to WPS, and where they are developed in WID as they apply to the tooling, is shown in the preceding figure. Notice that a business process (BPEL) is one of the components available for you to assemble and implement your solutions. Using the WID assembly editor, one can assemble, implement, and deploy service components to build SOA-based applications and hence, the solutions that these applications belong to. These components can be grouped into modules or mediation modules and specify which service interfaces are exposed by the components and, therefore, the module to outside consumers. Services that are available include imported components such as Java beans or web services and service components that WPS (and WESB) provide. Modules are then connected to form complete integration solutions.

[ 517 ]

IBM BPM Enabled by SOA: Overview

Getting around with WID

The primary tool for defining and assembling SCA artifacts is the assembly editor. This editor will allow one to visually assemble SCA applications such as components, exports, imports, and stand-alone references and to wire them together to build composite applications/solutions. The following screenshot shows how a sample assembly would look:

When using the assembly editor, there are several development approaches. First, you can build your SCA application using a top-down development model. In this case, you can use the assembly editor to diagram and model your application before you create any backing business logic. Once components are added to the assembly diagram in the editor, you can assign interfaces and even create new interface definitions for each component from within the editor. Once the SCA components are defined with their interfaces and references, you can generate skeleton implementations (and edit them) to add your business logic. In the bottom-up development model, you start by defining your business logic by implementing BPEL processes, business state machines, business rules, and human tasks. Then, you create the SCA components for these implementations by dragging-and-dropping them into the assembly diagram. As part of this process, the appropriate interfaces and references are automatically added to the components. You can complete the assembly by wiring the SCA elements together. Finally, in the development model, you can define the elements in the assembly diagram and their implementations in parallel. As with the top-down approach, you create the assembly diagram in the assembly editor. But unlike the top-down approach, you do not generate implementations from the elements in the diagram. Instead, you select the appropriate implementation that you created in parallel. Be aware that the parallel activities, creating the diagram, and creating their implementations, are not done in isolation. You must know the interfaces and references for each element in order to create its implementation, and vice versa. The point is that you do not have to wait for one activity to finish before you begin with the other. [ 518 ]

Chapter 9

Imports and exports

An import allows you to use functions which are not a part of the module that you are assembling. Imports are used in an application in exactly the same way as local components. Imports have interfaces that are the same as, or a subset of, the interfaces of the remote service that they are associated with, so that those remote services can be called. To share the interfaces between modules, put the interfaces into a library. Then, for both modules, add a dependency on the library to use its resources. Imports and exports require binding information, which specifies the means of transporting the data from the modules. An import binding describes the specific way an external service is bound to an import component. For an import that is generated from an export, the binding type of the import will be specified for you. Imports can use the following bindings: •

SCA

•

Web service

•

HTTP

•

Messaging (JMS, MQ JMS, generic JMS, and MQ)

•

Stateless session bean

•

EIS

If you are creating the import using the palette in the assembly editor, you will have to specify a binding type for the external service in order to test it. An export is a published interface from a component or import that offers its service to the outside world, for example a web service. Exports have interfaces that are the same as or a subset of the interfaces of the component or import that they are associated with, so that the published service can be called. An export dragged from another module into an assembly diagram will automatically create an import. Exports that are shown under the module assembly in the Business Integration view can also be used to create imports in other modules. Each export has an address at which it will be deployed on the server. The export can be exposed at that address. Imports and exports require binding information, which specifies the means of transporting the data from the modules. When you use the Generate Export action from the menu of a component, you need to select the binding so that the binding is generated when the export is created.

[ 519 ]

IBM BPM Enabled by SOA: Overview

Project types

Now let us look at how you work with WID and the different types of artifacts you would create and be dealing with, when building applications.

Working with modules and libraries

There are two important project types when doing business integration development in WebSphere Integration Developer. A module project represents a basic unit of deployment and encapsulates SCA resources (SCA Module), J2EE projects, Java projects, and dependent libraries. A library project is also another type of business integration project. Unlike the module project, a library project is not a deployable unit. The library project holds artifacts that can be shared between multiple modules. However, it is important to note that at runtime the library is not shared. In this case, the library is deployed individually with the module that is dependent upon it. A module is a business integration project type for developing SCA-based applications. A module is a basic unit of deployment to the WebSphere Process Server runtime environment and, as such, is packaged in an EAR file. The EAR file contains all the SCA-based artifacts packaged in a JAR file, J2EE projects, such as Web and EJB modules, dependent Java projects, and any dependent libraries packaged as JAR files. Also included in this project are other business integration artifacts that make up the overall application. This would include BPEL definitions, interface definitions, and XML Schema definitions.

Project dependencies

If a module or mediation module needs to use resources from a library or if a library needs to use resources from another library, you have to open the module or library with the dependency editor and add a dependency to the required library. Business objects and interfaces are examples of the resources that you would want to share. Libraries must be deployed with modules that have dependencies on them so that the resources are available during runtime. With the dependency editor, you can add dependencies on libraries and Java projects as well as on J2EE projects.

Creating and visualizing interfaces

The fundamental building blocks of an SOA-based business solution are the Service Components Architecture components. These SCA components can be assembled and wired together using the WID assembly diagram and deployed to the WebSphere Process Server. The SCA components can be implemented using different implementation types, which can include business processes (BPEL), business rules, Java, and many more. [ 520 ]

Chapter 9

The components by themselves, apart from their implementation, have one or more interfaces. You are aware that in the WID assembly diagram, the components appear as rectangular icons. The interface provides the input and output of a component. To users of a service component, all that matters is its interface, which dictates how to use it. Technically, an interface that is independent of the implementation of the component can be created. WID is flexible, in the sense that it lets you build interfaces either before or after component implementation, with the same results. All components have WSDL type interfaces, but Java components can have Java interfaces as well as WSDL interfaces.

For an interface, you can specify a preferred interaction style as synchronous or asynchronous. The interfaces that are defined on the component are defined in the synchronous form and asynchronous support is also generated for them. Interfaces link the different components in a module. The inputs and outputs of each component, specified by the interface determine which data can be passed from one component to another.

Business objects and business graph

At the core of the BPM discipline are the business processes, that is, systemto-system, inter or intra systems, and workflow or person-to-person process management. Business processes need a standardized and systematic language to communicate both within and with other external processes or services. This lingua franca, or the systematic language, is Business Objects. These business objects represent the data that is produced, manipulated, and exchanged between activities within business processes, and transferred to external services or other business processes that the parent business process invokes. Typically, and more fundamentally, these business objects should be in a form that is understood by the business (that is, not to be defined by technical folks!). Another purpose of these business objects is to provide data abstraction to the SCA-based business applications. From a WPS point of view, SDO represents the business data that forms the request and response values of processes and services, providing uniform access to business data.

[ 521 ]

IBM BPM Enabled by SOA: Overview

Now, how do these business objects become a key enabler of SOA? The whole point of adopting an SOA approach is to build business applications. If you look at the three pillars of SOA—processes, services, and data, there needs to be a way to represent the data that is exchanged between processes and services. Data is often an ignored stepchild in the world of SOA. Since, processes and services are assembled into larger business applications, data is very critical to the agility and loose coupling of the business application architecture itself. Imagine if you had five different versions of a Customer entity and, worse, if it changes by region, Line Of Business (LOB), and so on, within the same organization. Hence, in WPS (and in WESB too), the data that are exchanged between business components are the business objects, which are based upon SDO. These business objects provide data abstraction and, hence, loose coupling and agility to SOA. In WPS, business objects provide additional capabilities that SDO does not provide. The following screenshot shows how you can visualize (and also create/modify) business objects visually, in WID. When modeling BPEL using WID, these business objects (defined on an interface) are available as variables for you to manipulate and extract data coming into the process or going out.

So, here is a summary of some of the key concepts related to business objects that you need to remember: •

Business Object (BO) °Â°

Fundamental data structure that forms the request and response values of processes and services, providing uniform access to business data. [ 522 ]

Chapter 9

°Â°

Within WPS it is represented in memory with the SDO type commonj.sdo.DataObject.

One business object can inherit another business object, that is, one can be a superset of another. •

Business Graph (BG) °Â°

Similar to the concept of the data graph in the SDO architecture, a structure that encapsulates a set of data objects.

°Â°

Is a wrapper for business objects and contains additional or enhanced information such as: °Â°

Change Summary Used for denoting/recording changes to a BO contained within a BG

°Â°

Event Summary (enhanced for WPS)

°Â°

Verb (enhanced for WPS) Standard verbs include Create, Update, Delete, UpdateWithDelete, Retrieve

°Â°

Business Graph complex type provided by the WPS is the part of the business graph that provides the change summary and event summary to a business graph.

°Â°

To create a BG in WID, right-click on the BO and select Create a Business Graph.

°Â°

So why do we need BG's? A couple of data patterns distinctively bring out the need for BGs, they are: °Â°

Disconnected Data Pattern Consider this scenario: A business process (say BP) contains invocations to many services (say SVC-1 and SVC-2). The same business object (BO-x) is used to exchange data between SVC-1 and SVC-2. To maintain data concurrency between SVC-1 and SVC-2, a data graph can be used, especially in cases where the invocation of SVC-2 may change BO-X and will have to be subsequently communicated to SVC-1.

°Â°

Event Pattern Used especially in data synchronization cases, where a combination of event summary and verb, can keep different southbound applications in synch. [ 523 ]

IBM BPM Enabled by SOA: Overview

•

Business Object Type Metadata °Â°

Metadata to annotate BO

Where does WID/WPS fit in with WS-BPEL?

So where does WID/WPS fit in with WS-BPEL (also referred as BPEL)? BPEL is one of the many options that are provided in WID to implement an SCA component. Once you model a business process using BPEL, you will need to deploy the BPEL process on a BPEL runtime engine that can interpret the business process modeled, invoke the appropriate services, maintain state, handle faults and associated compensations, and also support long-running processes than can span days, weeks, or even months. We will be getting into these topics as we progress into the later chapters.

[ 524 ]

Chapter 9

IBM and WS-BPEL 2.0 standard WID/WPS v7.0 supports WS-BPEL version 1.1 specification completely and version 2.0 partly. The majority of WS-BPEL 2.0 language elements are available in WID/WPS version 7.0. Additional value-add functions in WPS/WID even go beyond the standard. The link to BPEL specification v1.1 is http://www.ibm.com/ developerworks/library/specification/ws-bpel/ The link to BPEL specification v 2.0 is http://docs.oasis-open. org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html As you very well know, WS-BPEL (or BPEL used interchangeably) provides the ability to express stateful, long-running interactions between web services. IBM was the author of the original proposal for the BPEL specification, one of the first vendors to support BPEL and supports WS-BPEL throughout its products including: •

WebSphere Business Modeler

•

WebSphere Integration Developer

•

WebSphere Process Server

•

WebSphere Business Monitor

The WS-BPEL 2.0 specification can found at http://docs.oasisopen.org/wsbpel/2.0/wsbpel-v2.0.html and was approved in April 2007. IBM is a major contributor to the WS-BPEL 2.0 standard. Diane Jordan from IBM has been the chair of the OASIS technical committee and several others from IBM are on the technical committee.

When you are building a business process in WID, the fundamental WS-BPEL activities you work with, as provided in the WID business process editor palette, are shown in the following table. You would use a combination of these activities to visually build your business process that accomplishes a particular function or goal.

[ 525 ]

IBM BPM Enabled by SOA: Overview

The fundamental WS-BPEL activities that you deal with within WID are shown in the following table:

Working with a business process (WS-BPEL)

A business process is the set of business-related activities, tasks, rules, and conditions invoked and executed in a defined sequence to achieve a business goal. As explained in the previous section, WS-BPEL or BPEL provides a grammar for describing the behavior of a business process including interactions within the process, with external partners, and with other processes. BPEL is one of the options that are provided in WID to implement an SCA component. The business processes can be either long running or microflows. Now let us look at the specifics behind the business process types and their differences.

[ 526 ]

Chapter 9

WebSphere Process Server

WPS is one of the key and core products in the IBM WebSphere BPM suite that supports the BPEL specifications. Referring back to the key capabilities needed for a successful process-driven integration approach enabled by SOA, WPS addresses capabilities including Business Process Execution, Business Rules, Enterprise Service Bus, and is a key enabler for Business Process Monitoring. The WPS platform provides a standard-based, uniform programming model for representation of data, invocation of services, and structure of composite applications. It provides a unified tooling, WebSphere Integration Developer for the visual development of composite applications.

Role of WPS in SOA

As explained in the previous sections, process integration is fundamentally built on the concept of an SOA. Nowadays, most of the applications expose web services. These services, which may be very fine grained or atomic in nature, will have to be assembled into coarse-grained services that make meaningful sense to the business. A process-driven integration leverages these business services as business tasks in the larger choreography or orchestration of a business process. Because of the fact that fine-grained atomic services are assembled into coarse-grained business services, the use of the service is independent of the IT infrastructure needed to accomplish the task. Each business service then becomes a building block that, when combined with other business services, can provide an overall business process. The structuring of business processes in this way provides a flexible solution to real business problems, allowing the creation of new and modified processes easily. You can use WPS to develop and execute standards-based, component-based business integration applications using an SOA approach. The use of standards-based technology, including web services, helps to make the SOA vision a reality. WPS leverages a programming model that is very fundamental to understanding how applications are developed in WPS and WID (as explained earlier, WID is the integrated development environment for WPS). The programming model has three parts: •

Invocation Model—defines how invocations of processes and services are made. Invocation is the way in which a request is made from one piece of code to another. Programmatically, there are several methods of invocation including REST, HTTP, EJB stateless session beans, JAX-WS,JAX-RPC, JDBC for communicating with databases, JMS for messaging, and so on. WPS has adopted SCA specifications as the basis for its invocation model. SCA is a set of specifications that describe a model for building applications and systems using an SOA approach. [ 527 ]

IBM BPM Enabled by SOA: Overview

SCA divides the steps in building a service-oriented application into two major parts: °Â°

The implementation of components, which expose (export) services and consume (import) other services

°Â°

The assembly of components to build business applications, through the wiring of references to services

SCA uses SDO to represent the business data that forms the request and response values of the BPEL components. SCA supports bindings to a wide range of access mechanisms used to invoke services and also through both synchronous and asynchronous programming styles. •

Data Model—defines how data can be represented. Programmatically, there are several ways to represent data—EDI message, JDBC row set, a JMS message, Java Persistence API (JPA), and so on. WPS has been standardized in the way in which data is represented and will be using BOs. BOs are extensions of SDO that provide an abstraction layer for data access. BO includes some extensions that are very important for integration solutions and further describes the data that is being exchanged between Service Component Architecture-based services. This includes metadata such as change history or information about the context of the data, such as update, create, delete, and so on.

•

Composition Model—how you put together a series of invocations. WPS has adopted BPEL as the way to define the overall business process. When the business process accesses data, it does so by making calls to SCA services passing Business Objects.

Platform architecture

WPS at its core is built on WebSphere Application Server, providing a robust application server runtime with capabilities that the process server implementation can exploit, such as JMS messaging and enterprise beans. It can also make use of the application server qualities of service such as transactions, security, and clustering. The following figure shows the platform architecture of WPS and the different components it is made up of.

[ 528 ]

Chapter 9

The components in the WPS platform architecture can be categorized as follows: •

SOA core The foundation of SOA includes main components, such as SCA, BOs, and the Common Event Infrastructure (CEI). The CEI provides the foundation architecture for the management and handling of events produced by business processes. This is essential for enabling the monitoring of business processes with products, such as the WebSphere Business Monitor.

•

Supporting services On top of the SOA Core are a set of Supporting Services, which provide the transformation primitives required when building SOA solutions using SCA and BO. These include: °Â°

Interface maps that enable mapping to semantically similar but syntactically different interfaces.

°Â°

Business object maps enable the transformation of business data between fields of Business Objects.

°Â°

Relationships enable the correlation and synchronization of data representing the same business entity stored in multiple backend systems. [ 529 ]

IBM BPM Enabled by SOA: Overview

•

°Â°

Selectors provide a dynamic invocation of a target.

°Â°

Java to invoke Java code.

Service components Service components provide different component types that can all be assembled together when building an SOA solution: °Â°

Business processes which are defined using BPEL realize an executable version of a business process in which the different activities of the process are by making calls to the individual SCA services that implement the specific activities.

°Â°

Human tasks provide the human task capabilities for people to participate and collaborate with the business processes. Human tasks can be integrated directly into the BPEL.

°Â°

Business State Machines are another way of modeling a business process that are highly event-driven and are well suited to being thought of in terms of a state transition diagram. The Business State Machine component allows you to model the business process using similar constructs as UML 2.0 state machine support and then generates BPEL for the implementation.

°Â°

Business rules enable the implementation and enforcement of business policy. Business rules are to be managed independently from other aspects of an application. There are two styles of business rule—if then rule sets and decision tables. A web client is provided, where the parameters of business rules can be changed by a business user using a natural language.

°Â°

Adapters are used for integration with various applications and backend systems that are external to the WPS. Adapters are categorized into technology and application adapters. These adapters are compliant with the Java Connector Architecture (JCA) 1.5 specification.

Common BPM adoption scenarios

In the collection of patterns for e-business, IBM has leveraged its vast experience from its architects and solutions. It has also developed various classes and categories of patterns that can be applied to create solutions rapidly, whether for a small local business or a large multinational enterprise. This site, http://www.ibm.com/ developerworks/patterns/, breaks down these pattern assets into the following elements: [ 530 ]

Chapter 9

•

Business patterns

•

Integration patterns

•

Custom designs

•

Application and runtime

•

Product mappings

•

Guidelines

Of the previously mentioned points, integration patterns give an interesting insight as to how to integrate applications and data within an individual business pattern. At its highest level, application integration by itself is divided into process integration and data integration patterns. Now, let us look at some of the most common BPM adoption patterns and, more specifically, how WPS can be adopted in real-life client scenarios. IBM's BPM adoption patterns are classified into the following broad categories: •

•

Process automation—streamlining and automation of manual business processes to gain, and hence optimize, costs and efficiency. Examples include: °Â°

Automation of insurance rate-quote-issue process across multiple product lines.

°Â°

Customer billing and invoice inquiry or dispute process automation in telecommunications industry.

°Â°

Order handling business process automation applicable to several vertical industries.

°Â°

Member/patient claims handling processes automation in healthcare.

°Â°

Automation of student registration/on-boarding in education.

Capture insights for effective actions—achieve visibility through monitoring, and capture new insights to seize opportunities and mitigate risks. BAM, in combination with role-based dashboards, augments and helps deliver this capability. For example, it includes: °Â°

Defining time bound KPI's on loan origination and approving business processes in the banking industry and act on them.

°Â°

Detecting root cause of service activation requests in the telecommunication industry and acting on them.

°Â°

Based on strategically defined business goals, improving customer satisfaction (defined as KPI), and improving customer problem handling business processes. [ 531 ]

IBM BPM Enabled by SOA: Overview

°Â°

•

Discover and Design—unlock valuable process opportunities and uncover critical improvement areas by focusing on high Return On Investment (ROI) areas. Examples include: °Â°

°Â°

°Â° •

Define fraud detection rules (too many withdrawals on an account from an ATM, high rate of claims requests, and such others) and act on them appropriately by automating the detection and acting upon processes.

Leveraging existing SOA service models and industry content to rapidly enable process modeling and automation efforts. IBM's Industry Content Packs is a good example here. Define library of KPI models based on the particular industry vertical, and use it as a means to measure and monitor strategic business goals. Leverage third-party content, collaborate on process models, and bring them into your ecosystem.

Adopt and Respond Dynamically to Change In the white paper titled BPM Process Patterns: Repeatable Design for BPM Process Models, BP Trends May 2006, Dan Atwood has discussed in detail six categories of process design patterns.

IBM WebSphere Enterprise Service Bus WebSphere Process Server includes WebSphere Enterprise Service Bus.

An ESB is fundamentally an architectural pattern. As explained in the IBM SOA reference architecture, from an SOA point of view, an ESB provides the connectivity layer between services and serves as the core backbone for the SOA. It's the nervous system. The service consumers in a service interaction are connected to the ESB, rather than directly to one another, including the service provider. When the service requester connects to the ESB, the ESB takes responsibility for delivering its requests, using messages to a service provider, offering the required function and quality of service. The ESB facilitates seamless interactions between a service consumer and service provider, by handling any protocol transformation and data transformation that may be required. An ESB can also enable or enhance monitoring and management. [ 532 ]

Chapter 9

The ESB provides virtualization and management features that implement and extend the core capabilities of SOA. So, what are the core capabilities that an ESB should support? The fundamental capabilities of an ESB include: •

Message processing

•

Mediations and communications

•

Service interactions

•

Integration

•

Quality of services

•

Security

•

Service level

•

Management and autonomic services

•

Infrastructure intelligence

Role of WESB in SOA

SOA mandates that the service's providers and the service's consumers be loosely coupled and support the use of explicit interfaces. This flexibility enables IT change with very limited impact, such as the update or replacement of a given business service or the development of a new composite solution, which leverages existing services, that is, the power of the ESB, enabling you to realize the full value of SOA. As shown in the following figure, interposing the ESB between the participants in an SOA ecosystem enables you to modulate their interactions through a logical construct called mediation. Mediations operate on messages in transit between service consumers and service providers. For complex interactions, mediations can be chained sequentially. The following figure lists the core capabilities that are provided by WESB and how it interacts with the various backend applications and how it exposes them to the service-consuming layers north of it (process services and business services). In some cases, interaction services can also become consumers of these WESB mediations. But it is always preferable to have the mediation wrapped into business services, because you may want to expose core business functions to the service consumers and, in doing so, you can account for service variability within the business service through the use of business policies and rules. An example would be, WESB can expose mediations that manipulate customer data from one or many customer information management systems. Which customer information system is chosen will depend on the business context of the request (geography the customer belongs to, type of customer, that is residential or commercial, service-level agreements with the customer, and request priority). All these account for service variability behavior and how the service should behave based on a combination of such cases. [ 533 ]

IBM BPM Enabled by SOA: Overview

Having such processing logic within the WESB mediation flows is not preferable for the simple reason that it can change as business conditions change. Hence, WESB as an SOA architecture should be positioned to deal with the hardcore integration and connectivity needs and should not be overloaded with capabilities it is not meant to have architecturally.

As shown in the WPS platform architecture, mediation flows belong to the support services. The mediation flows provide capabilities that include: •

Centralizing the routing logic, so that service providers can be exchanged transparently

•

Performing tasks such as protocol translation and transport mapping

•

Acting as a facade to provide different interfaces between service consumers and providers

•

Adding logic to provide tasks, such as logging

In the following screenshot, there is an example of mediation flow that provides routing, transformation, and logging operations on the messages through the use of mediation primitives. Mediation primitives are the smallest building blocks in WESB and are contained within a mediation flow. With mediation primitives, you can change the format, content, or target of service requests, as well as log messages, perform database lookups, and so on. WESB can interconnect a variety of different service consumers and providers using standard protocols including JMS, SOAP/ HTTP, SOAP/JMS, HTTP, and many more. [ 534 ]

Chapter 9

It supports web service standards including WS-Security and WS-Atomic Transactions. It also includes Universal Description, Discovery, and Integration (UDDI) version 3.0, which can be used to publish and manage service end-point metadata, which enables service definitions to be made available to client applications. WESB also supports the IBM WebSphere service registry and repository and is used for cases where you may have to perform dynamic end-point lookup.

Common WESB usage scenarios

There are three categories of usage patterns into which WESB-based solutions fall: •

Interaction patterns

•

Mediation patterns

•

Deployment patterns

Now, let's look in more detail at some of the most common usage scenarios that belong to these categories and that WESB can be used in.

Interaction patterns

These are very basic sets of patterns that allow service interactions to occur via the WESB. Types of interactions include: •

•

Synchronous °Â°

request/response

°Â°

one-way or notifications

°Â°

request/multi-response

Asynchronous °Â°

request/response

°Â°

publish/subscribe

°Â°

Anonymous, one-way publish of messages, or such others

[ 535 ]

IBM BPM Enabled by SOA: Overview

Mediation patterns

These are the next level of message exchange and manipulation patterns. This category of patterns typically deals with message mediations, having to work on the messages before allowing service interactions to occur. Some example message exchanges include: •

•

• • •

Protocol switch/transformation—typically dealing with protocol transformation, for example, receiving a JMS request from a service consumer and going to a service provider who supports MQ. Data transformation—transforms and translates the incoming message from one schema format to the target schema format. Thsi includes performing and applying data validation, integrity, and transformation rules. Data enrichment—augments or enriches the incoming message payload by fanning-out and fetching data from one to many sources, and fanning-in. Content-based routing—routes the message from a service consumer to one among many service providers, based on some message content. Message observer—monitors and observes messages (non-invasively) as they pass through the mediation by applying filters for example, watching out for too many ATM transactions on the same account, observe response time from a particular backend application, and monitoring SLA breaches, or logging and auditing messages.

Deployment patterns

This category of patterns deals with how WESB can be deployed in a variety of ways including, but not limited to, federated, brokered, and so on. •

•

•

Global ESB: All services share one namespace and each service provider is visible to every service requester across a heterogeneous, centrally administered, and geographically distributed environment. It is used by departments or small enterprises, where all the services are likely to be applicable throughout the organization. Directly connected ESB: A common service registry makes all of the services in several independent ESB installations visible. It is used where services are provided and managed by a line of business but made available enterprisewide. Brokered ESB: In this pattern, the ESB allows you to share services across different geographies or departmenrs or domains. It makes a service that is locally availabile only in a particular domain or geography to a centralized place via bridge services. In this pattern when service consumer requests a service from its local ESB, the request is mediated and routed to the broker ESB, that performs a second mediation and routing the request to the service provider. [ 536 ]

Chapter 9

Service interactions between ESBs are facilitated through a common broker that implements the bridge services. It is used by departments, who develop and manage their own services, but share a few of them, or selectively access services provided across the enterprise. •

Federated ESB: One master ESB to which several dependent ESBs are federated. Service consumers and providers connect to the master or to a dependent ESB, to access services throughout the network. It is used by organizations that want to federate a set of moderately autonomous departments under the umbrella of a supervising department.

WebSphere Business Monitor

WebSphere Business Monitor provides business activity monitoring capabilities that offer real-time insight into business processes. It provides visualization dashboards, through Business Space, such as business process information, human task activities, process diagrams, KPIs, dimensional views, visualizing a process flow, and so on.

Business Space

Business Space provides an integrated, flexible, and collaborative user interface to monitor and manage those BPM solutions that build using WID and WPS. It is not a separate product, but a face to the different products within the WebSphere Business Process Management portfolio that enables business users to model business processes, administer common tasks like human task flows, and monitor key performance indicators through a secure browser-based graphical user interface developed on Web 2.0 concepts. The following figure provides a comprehensive view of Business Space within the portfolio:

Business Space helps a business user in the administration, monitoring, and managing of applications, making these activities more solution-and business-centric and less deployment-centric. It also helps drive for more agile, richer processes that originate from the business users that are closest to problems the processes solve. [ 537 ]

IBM BPM Enabled by SOA: Overview

A business user in Business Space is able to create a mash up or combination of different web applications, called widgets, on a page. This enables the user to have access to all the information the user is most interested in, on one unified screen. These widgets can be sourced from different BPM products. For example, a user can have a Human Task widget from WebSphere Process Server and a monitor widget from WebSphere Business Monitor on the same page. Further, a business user can have multiple such related pages that serve a business purpose. Users are given the ability to create and share pages and spaces with other users to enable a collaborative environment. Shown in the following screenshot is a Solution Administration space, a pre-configured template that come with Business Space, which contains pages and widgets that allow you to manage all the modules deployed on the server through Module Browser:

Creating your first BPEL solution

Having read about all the fundamental concepts behind the IBM BPM products, and more specifically WID and WPS, let's build something now. Let's get into action and build our first simple Hello World solution that returns an interactive greeting. As simple as it sounds, I would like you to understand how to use the WID tooling and, in due course, relate it back to the various concepts that I have been talking about. Though the application we are building is simple, let's start looking at it from a solution point of view. So, the requirements for our first Greeting application are:

[ 538 ]

Chapter 9

•

It should be capable of getting user input and, more specifically, their first name, last name, and age

•

It should return a customized greeting based on their age: °Â° °Â° °Â°

•

Ages 25 and younger, it should return What's up ! Ages 26 to 65, it should return What's happening, ! Ages 65 and above, it should return Good Day to you !

The solution should be exposed via web services We are assuming that the reader has already installed WID version 7.

I know this is a very simple application that could be written in a few lines of Java code or any other programming language of your choice. But, the point here is to build this as your first WID application using business process (BPEL) components, which should allow you to understand the various features of WID and how to use them. Now, having given the requirements, there is a capability in WID that you can make use of to organize multiple modules, mediation modules, libraries, and other dependent projects into one scope. This capability is called Integration Solution. It provides a diagrammatic representation of how modules, mediation modules, libraries, and other dependent projects are connected/inter-connected. Let's follow a nine-step process to build our first Greetings application. As we go through each of the steps, we will illustrate this with appropriate screenshots: 1. Start WID and switch to Business Integration perspective. 2. Enter the Integration solution name: as Greeting_Solution. Integration Solution is a development time concept only and the servers have no idea about them. The servers still will view an integration solution as a set of .ear files.

[ 539 ]

IBM BPM Enabled by SOA: Overview

3. Create a Library project named GreetingLibrary and create the following in that library: °Â°

Create a Party business object under the folder structure com/solution/greeting/bo

°Â°

Create a HandleGreetingMessage Interface under the folder structure com/solution/greeting/interfaces. The operation name in the interface should be returnGreeting with input of type Party and output of type String A library project is used to store the resources that are required by other projects, and hence has reuse potential. Libraries contain: •

Business Objects

•

Interfaces

•

Transformations

•

Mediation Subflows

Once you create a library project, it can be added as a dependency in the module or a mediation module project. A library cannot be deployed by itself to WPS or WESB. But you can add a library to the module and select to deploy it with the module option. There can be nested library dependencies also. That means library-A can be dependent on library-B.

4. Create a Module project named Greeting and add in Dependencies the GreetingLibrary.

[ 540 ]

Chapter 9

5. After the module has been defined, create a business process/BPEL component named HelloProcess (of type Microflow) under the folder structure com/solution/greeting/processes and the interface for the BPEL as HandleGreetingMessage. 6. Add the Module and Library to the Integration Solution as project references. 7. Implement the BPEL component: i. In the business process editor, from the palette select the Choice activity and drag-and-drop it to the business process editor between the Receive and Reply activities. ii. Replace the default Display name with the name CheckPartyAge. The Display Name field can be changed as well, in the Description section of the Properties view; a change of the display name will update the Name field. Now let's add case statements, each checking and handling a particular age range. iii. Click on the Case activity within the Choice activity scope and in the Properties view give the name for this case as LessThan25. Click on the Details tab and choose the Expression Language to be of type XPath 1.0. Here we will write an XPath expression to check the age of the Party. Using an XPath expression, you will be able to reference parts of the variables or business objects of a BPEL. An XPath expression may reference simple data types (for example, strings and integers) as well as complex data types. [ 541 ]

IBM BPM Enabled by SOA: Overview

In our case, we will check the Age in the Party business object that comes as an input to the business process (remember we set this as the input when we defined the interface and operation). The XPath expression can be $inputPartyInfo/Age