Business Processes in the Context of Grid and SOA

1. Business Processes in the Context of Grid and SOA assoc. prof., dr. Vladimir Dimitrov Faculty of Mathematics and Informatics University of Sofia e-mail: cht@fmi.uni-sofia.bg

2. Abstract 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.

3. Business Process and Web ServicesWhat is business process? 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”.

4. Business Process and Web ServicesTasks 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.

5. Business Process and Web ServicesSimple & Composite Web Services 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.

6. Business Process and Web ServicesMonitoring 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.

7. Business Process and Web ServicesStateful vs Stateless Web Services 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.

8. Business Process and Web ServicesWS-BPEL & BPMN 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 WebSphereLombardi), 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).

9. Business Process and Web ServicesWS-BPEL & BPMN (cont.) 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.

10. Business Process Management 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.

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

12. Business Process ManagementVision 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.

13. Business Process ManagementDesign 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.

14. Business Process ManagementDesign (cont.) 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.

15. Business Process ManagementModeling 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.

16. Business Process ManagementExecution 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.

17. Business Process ManagementExecution (cont.) 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.

18. Business Process ManagementMonitoring 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.

19. Business Process ManagementMonitoring (cont.) 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.

20. Business Process ManagementOptimization 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.

21. Business Process ManagementRe-engineering 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.

22. Workflow 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.

23. WorkflowWorkflowvs Business Process 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.

24. WorkflowWorkflow Management System 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;

25. WorkflowWorkflow Management System (cont.) 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.

26. Service-Oriented Architecture 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.

27. Service-Oriented ArchitectureServices 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.

28. 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.

29. Service-Oriented ArchitectureServices 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.

30. Service-Oriented ArchitectureServices 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).

31. Service-Oriented ArchitectureServices 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.

32. Service-Oriented ArchitectureServices 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.

33. Service-Oriented ArchitectureWeb Services 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.

34. 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.

35. Open Grid Services Architecture 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.

36. Open Grid Services Architecture(cont.) 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.

37. Open Grid Services ArchitectureOGSA Compliant 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.

38. Open Grid Services ArchitectureBusiness Process 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.

39. 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.

40. Open Grid Services ArchitectureBusiness Process (cont.) 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.

41. OGSA & SOA 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.

42. OGSA & SOA(cont.) 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.

43. 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.

44. SOA in Grid 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.

45. SOA in Grid(cont.) 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#.

46. Grid & WS-BPEL 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.

47. Grid & WS-BPEL(cont.) 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.

48. WS-BPEL vs Others 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.

49. WS-BPEL vs Others(cont.) 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.

50. WS-BPEL Orchestrator 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.