Business Processes in the Context of Grid and SOA

Business Processes in the Context of Grid and SOA

assoc. prof., dr. Vladimir DimitrovFaculty of Mathematics and Informatics

University of Sofiae-mail: [email protected]

The term business process has very broad meaning. In this paper the term is investigated in the context of Grid computing and Service-Oriented Architecture. Business process in this context is a composite Web service written in WS-BPEL and executed by a specialized Web service, called “orchestrator”. Grid computing is intended to be an environment for business process of this kind and even more, this environment to be implemented as Web services. The problems in implementation of business processes with WS-BPEL in Grid environment are investigated and discussed.

Abstract

OMG in defines business process as “A defined set of business activities that represent the steps required to achieve a business objective. It includes the flow and use of information and resources.” These business activities are sometimes called “tasks”.

Business Process and Web ServicesWhat is business process?

A task can be local one (implemented as part of the business process) or external one (available for reuse to the other processes). In the last case, the task is specified as Web service, following OASIS WS-* specifications. The process is a Web service too. So, it is available as a Web service to the other processes. A process can have as a step sub process, but it is implemented as a part of the enclosing process.

Business Process and Web ServicesTasks

Web services could be simple or composed ones.The first ones are implemented in some programming language.The second ones are implemented as composition of other Web services, i.e. as business process. Sophisticated hierarchies of composite Web services could be implemented at different abstraction levels.

Business Process and Web ServicesSimple & Composite Web Services

The business process has a business objective. This business objective could be scientific one. This means that a business process could be classified as scientific business process. How the business process achieves its objective has to be measured. This measurement could be implemented via monitoring of Key Performance Indicators (KPI) of the business process. So, monitoring subsystem is an essential part of the Business Process Management System (BPMS) – the execution environment of the business process.

Business Process and Web ServicesMonitoring

The business process is defined by its workflow – the all possible sequences of execution of its steps (tasks). Every task needs resources and possibly information to run. These resources and information have to be provisioned to the process for its execution. The information can be local one (process state) or derived from an external source (i.e. Web service). In such a way, Web services supporting local state are called “stateful” to distinguish them from the “stateless” Web services that do not support conversational state.

Business Process and Web ServicesStateful vs Stateless Web Services

Business process could be specified in BPMN or in WS-BPEL. A BPMN specification is at higher level of abstraction and does not contain any implementation information. WS-BPEL specifies business process as composite Web service of other Web services as is presented above. It is possible a BPMN specification to be directly interpreted and executed in a business process execution environment (IBM WebSphere Lombardi), but usually it is translated in WS-BPEL specification that is interpreted by a specialized Web service called “orchestrator” (IBM WebSphere Business Modeler & Process Server).

Business Process and Web ServicesWS-BPEL & BPMN

The first approach is used for fast prototyping of business processed developed from scratch. The second approach is used for development of sophisticated business processes integrating reusable software exposed as Web services.

Business Process and Web ServicesWS-BPEL & BPMN (cont.)

Business process management (BPM) is a holistic management approach focused on aligning all aspects of an organization with the wants and needs of clients. It promotes business effectiveness and efficiency while striving for innovation, flexibility, and integration with technology. BPM attempts to improve processes continuously. It can therefore be described as a "process optimization process." It is argued that BPM enables organizations to be more efficient, more effective and more capable of change than a functionally focused, traditional hierarchical management approach.

Business Process Management

BPM is business process development process. Its life cycle is: vision, design, modeling, execution, monitoring, and optimization.

Business Process ManagementLife cycle

Functions are designed around the strategic vision and goals of an organization. Each function is attached with a list of processes. Each functional head in an organization is responsible for certain sets of processes made up of tasks which are to be executed and reported as planned. Multiple processes are aggregated to accomplishment a given function and multiple functions are aggregated to and achieve organizational goals.

Business Process ManagementVision

It encompasses both the identification of existing processes and the design of "to-be" processes. Areas of focus include representation of the process flow, the actors within it, alerts & notifications, escalations, Standard Operating Procedures, Service Level Agreements, and task hand-over mechanisms. Good design reduces the number of problems over the lifetime of the process.

Business Process ManagementDesign

Whether or not existing processes are considered, the aim of this step is to ensure that a correct and efficient theoretical design is prepared. The proposed improvement could be in human-to-human, human-to-system, and system-to-system workflows, and might target regulatory, market, or competitive challenges faced by the businesses.

Business Process ManagementDesign (cont.)

Modeling takes the theoretical design and introduces combinations of variables (e.g., changes in rent or materials costs, which determine how the process might operate under different circumstances). It also involves running "what-if analysis" on the processes.

Business Process ManagementModeling

One of the ways to automate processes is to develop or purchase an application that executes the required steps of the process; however, in practice, these applications rarely execute all the steps of the process accurately or completely. Another approach is to use a combination of software and human intervention; however this approach is more complex, making the documentation process difficult. As a response to these problems, software has been developed that enables the full business process to be defined in a computer language which can be directly executed by the computer.

Business Process ManagementExecution

The system will either use services in connected applications to perform business operations or, when a step is too complex to automate, will ask for human input. Compared to either of the previous approaches, directly executing a process definition can be more straightforward and therefore easier to improve. However, automating a process definition requires flexible and comprehensive infrastructure, which typically rules out implementing these systems in a legacy IT environment. Business rules have been used by systems to provide definitions for governing behavior, and a business rule engine can be used to drive process execution and resolution.

Business Process ManagementExecution (cont.)

Monitoring encompasses the tracking of individual processes, so that information on their state can be easily seen, and statistics on the performance of one or more processes can be provided. An example of the tracking is being able to determine the state of a customer order so that problems in its operation can be identified and corrected. In addition, this information can be used to work with customers and suppliers to improve their connected processes. These measures tend to fit into three categories: cycle time, defect rate and productivity.

Business Process ManagementMonitoring

The degree of monitoring depends on what information the business wants to evaluate and analyze and how business wants it to be monitored, in real-time, near real-time or ad-hoc. Here, business activity monitoring (BAM) extends and expands the monitoring tools generally provided by BPMS. Process mining is a collection of methods and tools related to process monitoring. The aim of process mining is to analyze event logs extracted through process monitoring and to compare them with an a priori process model. Process mining allows process analysts to detect discrepancies between the actual process execution and the a priori model as well as to analyze bottlenecks.

Business Process ManagementMonitoring (cont.)

Process optimization includes retrieving process performance information from modeling or monitoring phase; identifying the potential or actual bottlenecks and the potential opportunities for cost savings or other improvements; and then, applying those enhancements in the design of the process. Overall, this creates greater business value.

Business Process ManagementOptimization

When the process becomes too noisy and optimization is not fetching the desire output, it is recommended to re-engineer the entire process cycle. BPR has become an integral part of manufacturing organization to achieve efficiency and productivity at work.

Business Process ManagementRe-engineering

The definition of this term is given by Workflow Management Coalition is: “Workflow is concerned with the automation of procedures where documents, information or tasks are passed between participants according to a defined set of rules to achieve, or contribute to, an overall business goal. Whilst workflow may be manually organized, in practice most workflow is normally organized within the context of an IT system to provide computerized support for the procedural automation and it is to this area that the work of the Coalition is directed.” Workflow is associated with business process re-engineering.

Workflow

Workflow is the computerized facilitation or automation of a business process, in whole or part. This means that workflow is a more specialized term than business process. The last one do not concerns only automation and here the term business process is preferably used instead workflow.

WorkflowWorkflow vs Business Process

Workflow Management System is a system that completely defines manages and executes “workflows” through the execution of software whose order of execution is driven by a computer representation of the workflow logic. All WFM systems may be characterized as providing support in three functional areas: the Build-time functions, concerned with defining,

and possibly modeling, the workflow process and its constituent activities;

WorkflowWorkflow Management System

the Run-time control functions concerned with managing the workflow processes in an operational environment and sequencing the various activities to be handled as part of each process;

the Run-time interactions with human users and IT application tools for processing the various activity steps.

WorkflowWorkflow Management System (cont.)

Service-Oriented Architecture (SOA) “is the architectural solution for integrating diverse systems by providing an architectural style that promotes loose coupling and reuse.” SOA is architectural style, which means that it is not a technology. SOA fundamental construct are the service (logical, self-contained business function), service provider and service consumer. The service is specified with implementation independent interface and the interaction between service consumer and service provider is based only on this interface.

Service-Oriented Architecture

Stateless. SOA services neither remember the last thing they were asked to do nor do they care what the next is. Services are not dependent on the context or state of other services, only on their functionality. Each request or communication is discrete and unrelated to requests that precede or follow it.

Discoverable. A service must be discoverable by potential consumers of the service. After all, if a service is not known to exist, it is unlikely ever to be used. Services are published or exposed by service providers in the SOA service directory, from which they are discovered and invoked by service consumers.

Service-Oriented ArchitectureServices

Self-describing. The SOA service interface describes, exposes, and provides an entry point to the service. The interface contains all the information a service consumer needs to discover and connect to the service, without ever requiring the consumer to understand (or even see) the technical implementation details.


Composable. SOA services are, by nature, composite. They can be composed from other services and, in turn, can be combined with other services to compose new business solutions.

Loose coupling. Loose coupling allows the concerns of application features to be separated into independent pieces. This separation of concern provides a mechanism for one service to call another without being tightly bound to it. Separation of concerns is achieved by establishing boundaries, where a boundary is any logical or physical separation that delineates a given set of responsibilities.


Governed by policy. Services are built by contract. Relationships between services (and between services and service domains) are governed by policies and service-level agreements (SLAs), promoting process consistency and reducing complexity.

Independent location, language, and protocol. Services are designed to be location transparent and protocol/platform independent (generally speaking, accessible by any authorized user, on any platform, from any location).


Coarse-grained. Services are typically coarse-grained business functions. Granularity is a statement of functional richness for a service—the more coarse-grained a service is, the richer the function offered by the service. Coarse-grained services reduce complexity for system developers by limiting the steps necessary to fulfill a given business function, and they reduce strain on system resources by limiting the “chattiness” of the electronic conversation. Applications by nature are coarse-grained because they encompass a large set of functionality; the components that comprise applications would be fine-grained.


Asynchronous. Asynchronous communication is not required of an SOA service, but it does increase system scalability through asynchronous behavior and messaging techniques. Unpredictable network latency and high communications costs can slow response times in an SOA environment, due to the distributed nature of services. Asynchronous behavior and messaging allow a service to issue a service request and then continue processing until the service provider returns a response.


The most popular technological implementation of SOA is Web services. Starting from version 1.1, Web services specifications diverge to capture more SOA. Not all above mentioned requirements are directly supported by Web services, but SOA can be supported at design time. Some of the requirements are not desirable in some environments, like stateless services in Grid that is why SOA is an architectural style but not technology.

Service-Oriented ArchitectureWeb Services

By the way, Web services specifications have been modified to capture Grid requirements to Web Services. The most important result of this initiative is Web Services Resource Framework (WSRF) - an extension to Web services. More details on these extensions are discussed below.

Service-Oriented ArchitectureWeb Services

Open Grid Services Architecture (OGSA): “OGSA realizes the logical middle layer … in terms of services, the interfaces these services expose, the individual and collective state of resources belonging to these services, and the interaction between these services within a service-oriented architecture (SOA). … The services are built on Web service standards, with semantics, additions, extensions and modifications that are relevant to Grids.” This means Grids that are OGSA-compliant, are SOA-compliant, based on Web services.

Open Grid Services Architecture

The Core WS-* specifications does not include orchestration of Web services, but the full power of SOA could be achieved only with WS-BPEL orchestrators. This is well understood by the main SOA vendors and they usually offer several variants of orchestration. Why it is so important SOA suitcases to have orchestrator service? Because with the orchestrator reusability of the services is accomplished very well and it is possible simply to compose new Web services in hierarchies at different abstraction levels.

Open Grid Services Architecture(cont.)

In reality it is still far away from OGSA-compliant Grids. Even OGSA specification still continues to visualize the Grid as mega batch computer. There is terminology mismatch in OGSA from the past and the future. In the next versions of OGSA we hope that this will be overcome – GGF and WS are very closely working together. Today, OGF uses WS-* specifications deriving its own profiles for OGSA and do not extend them. In these profiles the word MAY is mainly changed to MUST for Grids.

Open Grid Services ArchitectureOGSA Compliant

Our focus here is on the business processes. What is specified in OGSA on that topic? “Many OGSA services are expected to be constructed in part, or entirely, by invoking other services—the EMS Job Manager is one such example. There are a variety of mechanisms that can be used for this purpose. Choreography. Describe required patterns of

interaction among services, and templates for sequences (or more structures) of interactions.

Open Grid Services ArchitectureBusiness Process

Orchestration. Describe the ways in which business processes are constructed from Web services and other business processes, and how these processes interact.

Workflow. Define a pattern of business process interaction, not necessarily corresponding to a fixed set of business processes. All such interactions may be between services residing within a single data center or across a range of different platforms and implementations anywhere.

Open Grid Services ArchitectureBusiness Process

OGSA, however, will not define new mechanisms in this area. It is expected that developments in the Web services community will provide the necessary functionality. The main role of OGSA is therefore to determine where existing work will not meet Grid architecture needs, rather than to create competing standards.”In other words, OGSA do not say anything about the central competition issue of SOA platforms vendors. OGF wait for solutions from the Web services world.

Open Grid Services ArchitectureBusiness Process (cont.)

There are two important thinks that have to be mentioned when we talk about service orientation of Grids. First is that a Grid could be service-oriented implemented, but this doesn’t necessary means that it is a service-oriented environment for execution of service-oriented solutions. Second one is that an environment could be service-oriented environment for execution of service-oriented solutions, but this does not means that this environment has to be service-oriented implemented.

OGSA & SOA

OGSA specifies service-oriented architecture for Grid implementation, but it does not necessary specify Grid as service-oriented platform supporting execution and development of service-oriented solutions. It is extremely primitive to consider a batch job as a business process and job tasks as services as is done by some authors. What is the difference? Services have a fixed location even in the case of WSRF extension. This means that they are installed, configured, managed and supported at given locations. Every service has an owner responsible for it.

OGSA & SOA(cont.)

The service needs of supporting execution environment – it is not possible a service to be executed at any free computing resource. This is the same to expect that a program written in high level programming language can be executed directly on the computer without compiling etc. Service-oriented solution is like a program written in high level programming language and in comparison batch job is like a machine code program. Ideas are the same, but technologies, tools and the most important programmer productivity are extremely different.

OGSA & SOA(cont.)

The next question is how business processes could be implemented in Grids, i.e. how Grid could become service-oriented platform? In practice, SOA platforms are very different from what is manifested by their vendors. SOA solutions running on one platform in one data center are really execution optimal.

SOA in Grid

When a business process has to access remote Web service, it has to do intensive XML-interchange with the remote Web service. This problem could be solved only with specialized hardware solutions that off-load the servers from XML-processing and security protection tasks. When a business process is running on one server, it is translated to simple object-oriented program in Java or C#.

SOA in Grid(cont.)

It is clear for now that business process specification for Grids would be WS-BPEL with some possible Basic Profiles. The most important is the orchestrator Web service. Nowadays we have many orchestrators from different vendors. All of them are using WS-BPEL with some extensions. There is no WS specification for orchestration service and such a service no vendor has intention to specify.

Grid & WS-BPEL

The situation is like in the pre-Internet era: many vendors have had supplied incompatible private network solutions and standardization organization have had tried to develop commonly accepted networking standards. The Internet has tried to create network of networks and then has happened that its protocols have become local ones protocols. That is why today OGF has to try to establish orchestrator Web service specification – orchestrator of the orchestrators, no vendor would do that.

Grid & WS-BPEL(cont.)

One remark on the business process specification language: Some researchers have tried to use specification languages other than WS-BPEL, arguing that it is not human friendly, but there is no BPEL-engine that has no tools for graph representation of WS-BPEL that is really human friendly. Even some of these researchers try to argue that Petri nets as a simple formal technique are better than WS-BPEL.

WS-BPEL vs Others

First, WS-BPEL uses Petri nets (links) and by my opinion it is the worst part of the specification – my experience shows that most of the bad errors are resulted of links. Petri nets are good formal technique; their power as a formal technique is that their expression power is more than that of finite state automata and less of that of Turing machine. So extending Petri nets to Turing machine expressing power is nonsense, but that’s the way of business process composition with Petri nets in these researches.

WS-BPEL vs Others(cont.)

There are two scenarios for BPEL orchestrator. In the first one, orchestrator engine is located in the Grid. In this case, all Grid functionality is fully available to the engine. At this point we have to mention some performance issues. SOA solutions could be high performance or not. This is achieved mainly with SOA architect efforts – it is not a problem of automatic optimization. How this is done? The orchestrator has its own supporting infrastructure. The last one is located in the site where is located the orchestrator.

WS-BPEL Orchestrator

Then most of the services used in the business process composition are local one – on the same site. Only some of the services are not local one. Think of data as services – the standard SOA approach. Then this means that the data exchange among the services of the business process are optimized and supported in the local site by high performance local area network and other applicable technics. Interactions with remote services are slow, but acceptable. Business process is an optimal solution developed by the SOA architect – it is not a subject of automatic optimization.

WS-BPEL Orchestrator(cont.)

In the first scenario, the orchestrator and its entire infrastructure is a part of the Grid. This means that orchestrated Web services are located in the Grid on the orchestrator‘s site. Some of them could be exposed outside the Grid, but they are mainly for consumption in the Grid. Every site could have different BPEL-orchestrator – it is exposing Web services. In the Grid overall compatibility of these orchestrator engines have to be defined using a Basic Profile.

WS-BPEL Scenario 1

In the second scenario, the orchestrator engine is outside the Grid. This means that its business process could use some Grid services as remote services as is mentioned above. These processes could be results visualization ones. In this scenario the main problem is the security issue – how Grid services have to be accessed from the outside. Not that this problem does not exists inside the Grid, but in this situation it is more difficult. WS-Security framework cold be used, but it has to be part of the Grid functionality.

WS-BPEL Scenario 2

One final remark, do not think of Grid as a mega batch engine. This old vision still exists in OGSA, but think of Grid as an ocean of services. These services are located at fixed Grid sites; they are exposed and could be used. What is the purpose of this remark? Many researchers continue to accept the Grid in the old fashioned way and as result of that their efforts are mainly directed to capsulate the job batch engine as Web service. For them the task is a task in the job but not in the Web service. Even the business process is compiled to batch job that is sent for execution in the Grid. This is not OGSA.

Final Remark

1. OMG, Business Process Model and Notation (BPMN). Version 2.0, 3 January 2011, http://www.omg.org/spec/BPMN/2.0

2. OASIS, Web Services Business Process Execution Language Version 2.0, OASIS Standard, 11 April 2007, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf

3. vom Brocke, J.HKVJH & Rosemann, M., Handbook on Business Process Management: Strategic Alignment, Governance, People and Culture (International Handbooks on Information Systems) (Vol. 1), Berlin, Springer, 2010

4. Workflow Management Coalition, The Workflow Reference Model, 19 January 1995, http://www.wfmc.org

5. IBM, WebSphere Lombardi Edition, http://www-01.ibm.com/software/integration/lombardi-edition

6. IBM, WebSphere Business Modeler Advanced, http://www-01.ibm.com/software/integration/webphere-business-modeler/advanced/features

7. IBM, WebSphere Process Server, http://www-01.ibm.com/software/integration/wps8. Holley K., A. Arsanjany, 100 SOA Questions, Asked and Answered, Pearson Education Inc.,

Published by Prentice Hall, Upper Saddle River, New Jersey 07458, 20119. OGF, GFD-I.080, The Open Grid Services Architecture, Version 1.5, 24 July 2006,

http://www.ogf.org/documents/GFD.80.pdf

References

This research is supported by ДДВУ02/22/20.10.2011 funded by the Bulgarian Science Fund.

Acknowledgments

Business Processes in the Context of Grid and SOA

Documents

Transcript of Business Processes in the Context of Grid and SOA