Analyse et optimisation de l'architecture des moteurs BPEL
Rapport de stage Olivier Coupelon Master Recherche Informatique, 20062007
LIMOS Complexe scientifique des Cézeaux, 63177 Aubière Cedex Université Blaise Pascal 34, avenue Carnot BP 185 63006 ClermontFerrand Cedex
A BSTRACT Web services are becoming more and more used in corporations, and with them the BPEL language has become the most commonly used language for web services orchestration. Many businesses are running BPEL engines and there is a growing demand for efficiency in this domain. Moreover, no corporation will put a BPEL engine in production without activating its persistence capabilities. We first analyze the BPEL engines, showing their internal architecture, based on the analysis of ActiveBPEL. We particularly focus on its persistence management. This contribution is one of the first work on the subject, previously undocummented. Then we show that such persistence capabilities can be improved by determining accurately when dehydrations and hydrations should occur, either partially or totally. This is done by analyzing the BPEL processes internal activities, grouping them in blocks. We show that we can therefore minimize the required ressources, thus improving responsiveness and performances of BPEL engines.
R E´ SUM E´ Les services web sont de plus en plus utilis´es en entreprise, le langage d’orchestration qui leur est d´edi´e, BPEL, est ainsi devenu un standard. De nombreuses entreprises utilisent des moteurs BPEL, d’ou` la forte demande actuelle pour l’am´elioration de la performance de ces moteurs. Nous pr´esentons tout d’abord une analyse des moteurs BPEL, de leur architecture interne, en se basant sur le moteur ActiveBPEL. Nous nous int´eressons particuli`erement a` la gestion de la persistance. Cette contribution est une des premi`eres r´ealis´ees dans ce domaine, jusqu’alors non document´e. Par la suite, nous proposons une nouvelle m´ethode permettant d’am´eliorer la gestion de la persistance, en d´eterminant pr´ecis´ement quand doivent avoir lieu les hydratations et d´eshydratations, qu’elles soient partielles ou totales. Cette m´ethode se base sur l’analyse des activit´es des programmes BPEL, en les regroupant en blocs. Nous montrons qu’il est ainsi possible de r´eduire la charge du moteur, am´eliorant de ce fait les temps de r´eponse et les performances des moteurs BPEL.
2
Acknowledgement
This master internship was first proposed to me by Yannick Loiseau, Julien Ponge and Farouk Toumani. They offered me the opportunity to integrate the LIMOS Web Services team, this is why I address them my first thanks. I am particularly grateful for their support and assistance all along this period. Altough really demanded by his work, Farouk Toumani has always been there to assist me in my researches. Yannick Loiseau has been more than just a supervisor, since he was always available and of good advice. Finally, Julien Ponge, despite being working on his thesis, was always present to give me hints and information about my work and how I should proceed. I wish to express my gratitude to Boualem Benattalah and Fabio Casati who brought me their experience in the domain, by attending to the presentations I made, and providing helpful feedbacks. I also thank every member of the team for their support, formation and most of all patience. All were to me of an invaluable help and allowed me to acquire or increase my knowledge in the domain.
3
CONTENTS
1
Introduction
6
2
Web Services
8
2.1
The Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.1
Simple Object Access Protocol (SOAP) . . . . . . . . . . . . . . . .
9
2.1.2
Web Services Description Language (WSDL) . . . . . . . . . . . .
9
2.1.3
Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2
2.3
3
Web Services coordination and composition . . . . . . . . . . . . . . . . . 11 2.2.1
Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2
Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Business Process Execution Language (BPEL) . . . . . . . . . . . . . . . . 12 2.3.1
BPEL process components . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2
BPEL business features . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3
A simple BPEL process . . . . . . . . . . . . . . . . . . . . . . . . . 15
BPEL Engines Architecture
18
3.1
BPEL engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2
ActiveBPEL architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1
The engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2
Process management . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3
Queue manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.4
Work manager and time manager . . . . . . . . . . . . . . . . . . 23
3.2.5
Transaction manager . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.6
Event management . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4
CONTENTS
4
BPEL Engines persistence 4.1
5
Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.1
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2
Dehydration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3
Hydration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2
BPEL engines persistence strategies . . . . . . . . . . . . . . . . . . . . . 25
4.3
ActiveBPEL persistent storage analysis . . . . . . . . . . . . . . . . . . . . 27 4.3.1
ActiveBPEL database . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2
ActiveBPEL logging information . . . . . . . . . . . . . . . . . . . 30
4.3.3
ActiveBPEL persistence strategy . . . . . . . . . . . . . . . . . . . 31
BPEL Engines persistence optimization
34
5.1
Related works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2
Optimization goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3
5.4
5.5 6
24
5.2.1
Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.2
Dehydrate immediately . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.3
Don’t dehydrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.4
Hydrate earlier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.5
Don’t hydrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Information sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.1
Time information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.2
Waiting activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Blocks of activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.4.1
Blocks usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4.2
Blocks creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4.3
Blocks management . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Conclusion & Future Work
44
A Sample BPEL program
45
5
CHAPTER 1 Introduction
Until recently, application integration in business processes was done manually. This is why middleware softwares were imagined and developed. With them, corporations began to automate the exchange of data between applications, leading to Enterprise Application Integration (EAI). This is one of the major improvements that networking brought to corporations, in that computer where not only useful as computations unit, but also helped in sharing and increasing the inter-enterprise communications, replacing paper work. Businesses don’t want to limit their integration process to internal applications any more, but want to use those technologies with their business partners, as this can lead to better communications, thus to more significant profit. However, the architecture defined by EAI is centralized, and communications between the involved programs are imposed to be synchronous. Indeed, in a single corporation, the communications between different services can be made directly, by creating an internal communication layer. In a Business to Business (B2B) communication, transactions should be made in a distributed fashion, as none of the businesses is probably willing to let the other manage the whole process. Moreover, every partner should use the same trusted technologies. Web services, and as a more general concept Service Oriented Architecture (SOA) were designed with such capabilities in mind. With them, all functionalities of the system can be made available using a universal description language, commonly WSDL. This way, services can be used and understood widely, and are platform and language independent. Helped by those new technologies, corporations now have the ability to achieve B2B communications, and by the way application integration. In the first part of this report, I’ll present more in details the most commonly used standards of web services, what they are used for and how they complement each others. This first part is a survey of the existing standards, a valuable and necessary part of my work, which helped me understanding the key concepts of web services. I’ll then present existing BPEL engines, focusing on their internal architecture. This 6
CHAPTER 1. INTRODUCTION
work was made because of the team will to find part of the BPEL engines that could be optimized, a field of research not yet explored. I have specifically studied their persistence capabilities, which will be explained. This analysis was made because of the lack of documentation in the domain. In a final part, I’ll discuss about the optimization of the BPEL engines persistence, and present our newly created method for improving persistence performances.
7
CHAPTER 2 Web Services
2.1
The Web Services
According to the W3C, ”A Web service is a service that supports Web standards”. It is a networked interface to an application designed to be used by other applications. This is made possible through the use of a formal description of the service functionalities, often made using WSDL. Web Services are able to communicate with other applications, usually using the SOAP protocol, transported in HTTP. Web Services are just an abstract notion, which should be implemented by a concrete software or a least an interface to it. This agent is the one who can really communicate, the Web Service being only the resource defining the set of available methods. This distinction allows two services to be interchanged transparently, as long as they offer the same functionalities [1]. Their internal design, such as the language they were developed in doesn’t matter.
Orchestration
BPEL
Description
WSDL
Messaging
SOAP
Transport
WS-Security, WS-Coordination, WS-Transaction...
Moreover, web services are generally able to work behind a firewall, and are widely supported by software vendors.
HTTP, SMTP, XMPP...
Figure 2.1: Key Web Services standards
8
CHAPTER 2. WEB SERVICES
2.1.1
Simple Object Access Protocol (SOAP)
SOAP [2] is an XML based protocol, which allows the exchange of messages between distant applications. It is often transported over HTTP, but its technical specifications allow any protocol to be used, such as Java Message Service (JMS) for its reliability, XMPP, or SMTP. It is by design stateless, which implies that it doesn’t keep any information between communications. It is also a one-way protocol, and it’s up to the messages content or underlying protocols to implement any communication pattern. For instance, SOAP messages might be transported over HTTP, which can help in creating a synchronous communication. Alternatively, SMTP can ensure that messages will be processed with respect to their transmission order, acting like a queue. XMPP can handle those two aspects, and can therefore be considered as a good alternative. A SOAP message consist of an envelope, containing two parts: • A body which is the core information to be transmitted. • An optional header specifying additional informations. This is demonstrated by the following example, where the header is used to identify the customer, and the body contains only the data related to the purchase: 54B42CF401A 32158546 "http://notarypublic.example.com" light gadget 430
Listing 2.1: A SOAP example One of the main downside of SOAP is its incapacity to easily transfer binary data. There are several ways to overcome such a problem, for instance by encoding data with Base64, or using SOAP with Attachments (SwA).
2.1.2
Web Services Description Language (WSDL)
WSDL [3] is used to describe the publicly available functions and methods of a Web service. A WSDL interface is written using an XML grammar. It is to web services what IDL is to CORBA objects. A WSDL interface can be divided in two parts (see Figure 2.2), an abstract part which defines general informations, and a concrete part which gives technical information helping in finding () and using () the Web Service. 9
CHAPTER 2. WEB SERVICES
Here is a description of the information that can be found in a WSDL document: • is the root WSDL Element. • define the type of data used while communicating. They can be described thanks to XML Schema, RelaxNG, or DTDs. • represent a single communication with a Web Service. • describes the operations supported by the Web Service. • defines the information concerning the message format and protocol in use. • indicates where to find a Web Service, providing it’s location. Abstract part
Concrete part
Figure 2.2: Structure of a WSDL Document Unfortunately, a WSDL interface doesn’t contain any semantical information, which would help a computer understanding what the provided functionalities should be used for. Consequently, such a service description is only understandable by humans.
2.1.3
Service Discovery
The discovery process, provided by a discovery service, helps in finding information about a service. There are several steps involved in such a process : 1. The requester asks the discovery service for information about the required services. Depending on its capabilities, the discovery service might return a full service description, or a list of the matching services. 2. The requester and service provider must then agree on the way they are about to communicate. 3. The two entities might start exchanging SOAP messages, according to the requested functionalities. 10
CHAPTER 2. WEB SERVICES
One example of such technology is UDDI. It defines an XML based registry that holds and share information about Web Services. On public UDDI registry, businesses can publish their own Web Services definitions, usually their WSDL interfaces, which are then made available to the world. Although it can be considered as a core standard of the Web Services World, it is in fact hard to exploit. UDDI offers three main types of services: • White Pages, which holds addresses, contacts, and known identifiers. • Yellow Pages, which contains industrial categorizations based on standard taxonomies • Green Pages, giving technical information about services exposed by the business Many corporations manage a private UDDI Registry for their own use.
2.2
Web Services coordination and composition
All of those technologies can be used together, as depicted in Figure 2.3.
Service discovery Publication, Indexation
Request WSDL Customer
SOAP
Service provider
Figure 2.3: Web Services coordination At this step, only basic Web Services can be used automatically. The lack of a real coordination protocol that would organize the Web Services invocations prevents us to ensure coherent transactions.
2.2.1
Coordination
WS-Coordination is a framework for providing protocols that coordinate the actions of distributed applications. On top of it, WS-Transaction is a framework that defines how transactions should be dealt with to complete successfully. Among other things, it needs to specify the precise order in which operations need to be executed. As business applications are involved in transactions, they might require manual operations, which implies that transactions in Web Services can be long-running. 11
CHAPTER 2. WEB SERVICES
Thus, we can’t generally preserve the ACID properties that hold for databases transactions, as involved resources would remain locked during the whole transaction. This is why in such cases ACID properties can be relaxed. Transactions need not to be atomic anymore, but a compensation procedure needs to be implemented, allowing for rollbacks in case of the transaction abortion.
2.2.2
Composition
The concept of composition consist in creating a new service based on existing ones. As thought, it defines some sort of coordination. However, one important difference between coordination and composition is that the coordination protocol is designed to be accessible by everyone to correctly invoke services. On the other hand, the composition process is not to be disclosed, as it is part of the internal definition of a service. So far, composition was done by programming an integration layer, a middleware, using standard languages such as C++ or Java. This approach suffer from being mostly static, and any modification of the applications to be composed impact the middleware. On the other hand, if the workflow of the process was separated from the middleware, those modifications would only require to adapt the workflow description. This is why BPEL was designed.
2.3
Business Process Execution Language (BPEL)
Business Process Execution Language (BPEL) is a process-oriented composition language. It defines the precise order in which Web Services need to be invoked, while providing a general purpose programming language allowing the modeler to develop a real functional service. However, it’s not as powerful as full featured programming languages like Java, mainly because it has been developed to only represent business processes. BPEL programs are executed by BPEL engines. This way, any BPEL compliant engine is supposed to be able to run any BPEL written program. As though, if any changes are needed at the workflow level, they can be made without modifying the engine. Asynchronous Web Services invocations is supported, and is often used for longrunning processes. This kind of process are supposed to take a long time (maybe weeks), mostly because they might contain manual operations. A BPEL process is a Web Service. Consequently, a BPEL process can be invoke by other BPEL processes transparently, as it will behave like a normal Web Service. The current version of BPEL, called WS-BPEL is numbered 2.0 and was finally approved by OASIS the 12th April of 2007 [4]. This new version, which was previously available as a draft, has been implemented in most of the actual BPEL Engines. It replaces the version 1.1 and is hardly backward compatible [5].
12
CHAPTER 2. WEB SERVICES
2.3.1
BPEL process components
BPEL defines several sets of components, each having their own functionalities. BPEL Process
Partner Links
Basic Activities
Variables Compensation Correlation sets
Structured Activities
Event Handlers
Figure 2.4: A BPEL Process
Activities Activities are the operators of the language. They define the steps the process has to walk through in order to complete the intended operation. There a two types of activities, basic and structured activities. Basic activities: This kind of activities can’t contain any other activities. They represent an individual step in the process evolution. Some basic activities are: • : Waits for a message to arrive. • : Invokes a one-way or request-response operation from a partner. • : Updates the value of a variable with new data. • : Wait for/until a given time. Structured activities: Those ones offer a way to structure the BPEL process. They help in managing the flow of a process, for instance by enabling concurrent activities, by allowing fault handling, or by making it possible to coordinate activities. Some structured activities are: • : Contains a collection of activities to be performed sequentially. • : Specify a set of activities that should be run concurrently. • : Is used to select the execution of an activity based on a condition. • : Waits for the occurrence of exactly one event from a set of events, then executes the activity associated with that event. Other activities do exist, which can be found in [4]. 13
CHAPTER 2. WEB SERVICES
Partner Links BPEL allows to describe relationship between partner processes, that is, processes that interact with each others. As thought, involved Web Services are always modeled as partner links. Each BPEL process has at least one partner link as there has to be one client that invokes the process. is used to describe the partner services, and characterizes the role of each partner services in the communication. Variables BPEL, as most languages, offers the possibility to store messages in variables. They can hold complex data, for instance SOAP messages from a partner, or simpler data which are only used internally. Variables are defined and usable within their , and can also be accessed from their underlying scopes. In WS-BPEL 2.0, their names and types are defined as a reference to a WSDL message type, an XML Schema type (simple or complex), or an XML Schema element.
2.3.2
BPEL business features
As BPEL has been designed to model business processes, it has special features to manage them easily. Compensation Compensation is one of the most studied problems of BPEL. It defines the way aborted transactions can be reversed, as changes may have been committed but not wanted any more. Within a given scope, developers can implement a compensation handler which will be called when needed. This is some kind of exceptions handling mechanism. Scopes Scopes are defined to split the processes into smaller tasks. When the activities in a scope are finished, changes are usually committed, which is why compensation handlers might be useful, as scopes might not represent a full transaction. Correlation Correlation is the process which helps in associating an incoming message with the targeted process instance This can be a non trivial task since several instance of the same process might be waiting for similar messages. For this purpose, might be used, that refers to a unique identification value that will help in determining the right process instance.
14
CHAPTER 2. WEB SERVICES
Event handlers Every scope can implement an event handler. When the specified event occur, the process switches to the event handling code. There are two kinds of events a BPEL process can react to: • Message events, , can be compared to in that they are both waiting for an incoming message. • Alarm events, , is used when a specified amount of time needs to be awaited before something occur. Event handlers are different from normal activities in that they are only executed when an event occurs. If no event occurs within a given scope, the process leaves it and continues its execution.
2.3.3
A simple BPEL process
Here is a simple BPEL process example, from [6], illustrated by figure 2.5. At first, it waits () for a message carrying the name of a person. It then appends "Hello" before that name (), and finally sends back the crafted message (). All of this code is part of a structured activity, a , which ensures that every activities are run in the correct order.
Figure 2.5: BPEL Hello process One should note that this example is so simple that is doesn’t invoke any other Web Service. The and activities are there because a BPEL process is itself a Web Service and as though must at least something (from a client point of view, be invoked).
15
CHAPTER 2. WEB SERVICES
Listing 2.2: A simple BPEL process, saying ”Hello” The message types used in this code are declared in the associated WSDL, which needs to exist because of the BPEL process being a Web Service. Here is the corresponding WSDL description:
16
CHAPTER 2. WEB SERVICES
Listing 2.3: A WSDL description It is now clear that we can create a Web Service only using BPEL, but such a Web Service won’t probably be of any use because BPEL was above all created to compose Web Services and is therefore not strong enough to build complex services on its own. BPEL is a standard language, so even if this example was at first written for the JBoss jBPM platform, every BPEL engines should be able to execute it.
17
CHAPTER 3 BPEL Engines Architecture
3.1
BPEL engines
A BPEL engine is the piece of software that’s able to interpret the BPEL language. There is nowadays a large choice of free or commercial BPEL engines, but no common architecture is being used, as no standard defines how a BPEL engine should be designed. Our goal here is to determine the basic architecture of BPEL engines to see where they can be optimized. Supported
Engine
BPEL Version
License
ActiveBPEL Engine
1.1 & 2.0
Open source
Apache ODE
2.0
Open source
eInsight BPM
2.0
Open source
IBM WebSphere Process Server
2.0
Proprietary
JBoss jBPM BPEL
2.0
Open source
Oracle BPEL Manager
1.1 & 2.0
Proprietary
Table 3.1: Most commonly used BPEL engines Several BPEL engines researches were published, either by commercial companies, by researchers, or by open source BPEL engines developers (See table 3.1). In the 18
CHAPTER 3. BPEL ENGINES ARCHITECTURE
following, we’ll describe interesting sources of information. BPEL-Mora [7] and Sliver [8] are two BPEL engines that are designed to be used in embedded systems. Their architectures are described in [9] and [10] respectively. Although their concepts seem really interesting, none of them yet implement the full WS-BPEL 2.0 [4] specifications, which is not acceptable for production use. IBM produced some documentation for their BPWS4J engine [11]. There’s a good general description of the engine [12], but it doesn’t bring any details about the engine’s internal implementation. ActiveBPEL [13] is an open source BPEL engine produced and maintained by Active Endpoints. It is the most commonly used open source BPEL engine. As though, it has been the most studied for research purposes. Its architecture is documented [14], but there’s still many features not described. Indeed, Active Endpoints also sells a commercial version of their engine, so they surely should not explain too much of their architecture to anyone. It’s up to the researchers to investigate their choices, based on the publicly available source code. Such an operation can be quite complex, as the source code is composed of more than a thousand classes. However, some third party studies were made publicly available, which help in understanding the internals of the engine. In [15] and [16], the event processing of the engine is described. In [17], [18] and [19] (For the last two, no English translations seem to be available), one can find a detailed overview of the main functionalities of ActiveBPEL. In the following, we’ll try to give the reader a good understanding of the internals of ActiveBPEL.
3.2
ActiveBPEL architecture
ActiveBPEL is an open source BPEL engine written in Java. It handles both BPEL 1.1 and 2.0 specifications. It can read BPEL code and related standards, and create its own representation of BPEL processes. When a client invokes a BPEL process, the engine creates a new instance of it. The engine can manage persistence, queues, alarms, and many other execution details. Because writing BPEL processes can be error prone, ActiveBPEL has also developed a freely available BPEL Designer (but it’s not open source), based on the Eclipse framework. Unfortunately, it’s only available for the Microsoft Windows operating system. The figure 3.1 represents the basic components of the ActiveBPEL engine architecture. We will describe them in the following, analyzing the currently available ActiveBPEL version, numbered 3.1. The engine runs on top of a servlet container. Its messages communications are handled by an embedded version of Apache Axis. The process manager is the central part of the engine in the sense that it manages processes from their deployment to their termination. It uses other managers, for instance queues, work, time, and transaction managers. They are designed to handle specific parts of the processes. The event manager is build to support internal event communications in the en19
CHAPTER 3. BPEL ENGINES ARCHITECTURE
Web Service Container (Apache Axis)
BPEL Engine Process Manager
Work Manager
Processes Instances Timer Manager Activities Database Persistence
Queues Manager Processes Definitions Transactions Manager
Events Manager
Engine Administration Interface
Servlet Container (Apache Tomcat)
Figure 3.1: ActiveBPEL engine architecture gine, for logging and debugging. The administration interface grants control over the engine to the administrators.
3.2.1
The engine
A servlet is a Java application running inside an application server. ActiveBPEL is run as a servlet, commonly using Apache Tomcat. The class AeProcessEngineServlet is the servlet class. It extends AxisServlet (from Apache Axis), and is started by its init() method, as every servlet. It runs the BPEL process engine, as well as the Apache Axis server. Apache Axis [20] is the SOAP engine embedded in ActiveBPEL. It manages all the incoming and outgoing SOAP messages. Communication between ActiveBPEL and Axis is based on protocol-specific handlers, AeBpelRPCHandler and AeBpelDocumentHandler, which translate data from a particular protocol to a message and vice versa. The engine also creates several services for managing processes. They are defined in the code as Managers. One can tweak precisely which managers are used via the configuration file aeEngineConfig.xml. This file is the main configuration interface. Although there exists a configuration interface in the administration interface, directly modifying aeEngineConfig.xml gives way more options, such as the name of the classes to be used, whether to use persistence or not, and much more.
20
CHAPTER 3. BPEL ENGINES ARCHITECTURE
3.2.2
Process management
The process management is the most important part of the engine. Its main functionalities are provided by the process manager interface (IAeProcessManager) which defines the required methods for managing processes. The method createBusinessProcess() allows to create new process instances, of IAeBusinessProcess type. A business process is defined by its processId. Deployment procedure Process Deployment
Process Instanciation
BPEL document
Process Definition
Process Instances
XML Source
AeActivityDef
AeActivityImpl
Figure 3.2: Processes Life Cycle To be run by the engine, a BPEL process must be converted into the engine’s own format. This is the deployment procedure. It is first run when the engine starts. Its goal is to analyze the BPEL processes sources, and to build their internal definitions. The engine periodically watches for processes’ code modification, including deletions or additions of processes. If a process is deleted, the engine must wait for all instances to terminate in order to completely suppress it. On the other hand if a process is added, its internal definition is created so that it can be used. Processes definitions can be used to create processes instances. This is done using a Visitor pattern [21]. Request processing ActiveBPEL Engine
Apache Axis
Document or RPC Handler
Queue Manager
Business Process Engine
Process Instances n tio ea ation r C rel r Co
Figure 3.3: Request Processing When a SOAP message is received by Axis, it calls the invoke method of the corresponding protocol handler (See figure 3.3). The process manager, along with the queue manager (See section 3.2.3) determines how the message should be handled. At this point, the message may have been queued, dropped, or transmitted to the 21
CHAPTER 3. BPEL ENGINES ARCHITECTURE
correct instance, using the message’s correlation set. A new process instance might have been created if the corresponding message’s activity is marked with createInstance=yes. Activities Every activity in ActiveBPEL is represented as a class extending AeActivityDef. When they are executed, activities are instantiated via the Visitor pattern implemented in AeDefToImplVisitor. Every activity has its own implementation class, extending AeActivityImpl. Each activity has an associated state, defined in AeBpelState. For a list of the possible states, refer to table 3.2. Status INACTIVE READY TO EXECUTE EXECUTING FINISHED FAULTED DEAD PATH
QUEUED BY PARENT TERMINATED
Description The activity wasn’t used yet. This is the default state. All conditions are met for the activity to start. The activity is being processed. An activity might stay in such a state while waiting for an incoming message. The activity has finished without faulting. The activity has finished but faulted. The activity was removed from the execution queue because it’s conditions can no longer be met. This can happen when a activity is completed, and the corresponding activity wasn’t the current one. This activity has been added to the execution queue by it’s parent activity. The activity has been terminated.
Table 3.2: ActiveBPEL activities states
3.2.3
Queue manager
IAeQueueManager is an interface defining the methods required to deal with incoming messages or events. When an activity waiting for a message is executed, like a or a , it is queued by the queue manager (addMessageReceiver()) until the corresponding data are received (matchInboundReceive()). The queue can also contain messages (at most DEFAULT UNMATCHED RECEIVES COUNT, 50 by default) that did not yet match any receive activity, as long as they contain correlation information. This functionality is required for asynchronous communications. The queue manager is also able to schedule an invoke activity (addInvoke()) and an alarm (scheduleAlarm()).
22
CHAPTER 3. BPEL ENGINES ARCHITECTURE
3.2.4
Work manager and time manager
Those two manager follows the IBM/BEA specification [22]. The work manager (AeWorkManager) is a specialized alternative to threads, and is used in ActiveBPEL to schedule asynchronous operations. They are designated as ”Work objects”. The time manager (AeTimerManager) provides facilities for timed operations, such as suspending, waiting or resuming operations.
3.2.5
Transaction manager
The interface IAeTransactionManager defines the methods to be used when dealing with transactions. This kind of transactions can’t be considered as the one found in databases, as atomicity can’t be assumed here. A transaction can be long running, and might fail although parts of it were already ”committed”. Nonetheless, a class implementing IAeTransactionManager should provide begin(), commit() and rollback() methods.
3.2.6
Event management
The discussed events are those produced as a consequence of the execution of BPEL processes. In ActiveBPEL, event processing is done using the observer pattern [21]. Every event holds an XPath value indicating which activity has triggered the event. Event can be used for two related purposes : Logging and debugging. Logging is defined by the interface IAeProcessListener, and logging to a file is implemented in AeFileLogger. Logs are saved in the {user.home}/AeBpelEngine/process-logs directory if logging was turned on from the ActiveBPEL Administration interface, or to database if persistence was also activated. A study was conducted to extend the event mechanisms with aspect-oriented programming [15].
23
CHAPTER 4 BPEL Engines persistence
4.1
Persistence
In a BPEL engine, every piece of information required by a process instance are by default stored in memory. That is, variable values, incoming messages, or processes definitions are all kept in memory. However, in the event of a system failure, such as a crash or a power failure, everything can be lost if no care was taken to store those information in a safer place. To this end, many corporation are now using the persistence capabilities of their BPEL engine, which allow the processes instances data to be stored in a database, so that the the engine can reload them back when needed. The persistence for a BPEL engine consists in three operations, logging, dehydrating and hydrating which we will define in the following (See figure 4.1). Those definitions are established to clarify things in the persistence domain of BPEL engines. Every BPEL engines are using those notions, while not calling them the same way. For instance, in ActiveBPEL [23] the term “dehydration” is known as “process state saving”, mainly because “dehydration” is an Oracle term, referring to their dehydration store [24].
Memory
Database Dehydrate/Hydrate
Logging
Figure 4.1: Logging, Dehydration and Hydration
24
CHAPTER 4. BPEL ENGINES PERSISTENCE
4.1.1
Logging
The procedure of logging information to database is done every time a process activity performs a new operation that should be remembered by the engine. When a message is received, a variable is modified, or a timer is triggered, it should be persisted to database. This way, when a problem occurs, such as a crash or a power failure, the BPEL engine can safely reload (hydrate, see section 4.1.3) the data from the database to the memory, and continue the process execution.
4.1.2
Dehydration
We define here dehydration as the process which just frees the memory from the BPEL process instance, or part of it. Indeed, when the BPEL engine is running, it keeps every information about the execution of its processes in memory, including their definitions, instances, and every other pieces of required information. As the logging task ensures that everything is stored in database, the information kept in memory concerning a given process instance might be safely freed, either partially or completely when needed. This is not to be confused with logging, as the dehydration process does not involve any database access. It only has positive effects, such as freeing memory and ressources, and thus could be executed whenever possible. However, the dehydration procedure must often be followed by an hydration operation, which has impacts on performances.
4.1.3
Hydration
The hydration procedure consists in reading the database for every information that is required to load back a process into memory. This operation is time consuming, and should only be done when strictly required.
4.2
BPEL engines persistence strategies
ActiveBPEL Engine • License : Open source. • Information : http://www.activebpel.org/infocenter/ActiveBPEL/ v211/topic/org.activee.rt.bpeladmin.opensource/html/SvrUG1-2. html. • Persistence Manager : None. • Supported databases : DB2, MySQL, Oracle, SQLServer, Tamino (XML) • Other databases are supported, but a description should be written for them.
25
CHAPTER 4. BPEL ENGINES PERSISTENCE
Apache ODE • License : Open source. • Information : http://incubator.apache.org/ode/databases.html. • Persistence Manager : Apache Derby. • Most databases are supported by Hibernate, the database manager. eInsight Business Process Manager • License : Open source. • Information : http://192.18.109.11/819-7398/819-7398.pdf (Chapter 6). • Persistence Manager : None. • Supported databases : Oracle, Sybase, MS SQL Server, DB2. IBM WebSphere Process Server • License : Proprietary. • Information : http://www3.software.ibm.com/ibmdl/pub/software/ dw/wes/pdf/0605 kapadia-config-oracle-wps.pdf. • Persistence Manager : Cloudscape. • Other supported databases : Oracle, SQL Server, DB2, Sybase, and roughly any database with a JDBC 2.0 interface. JBoss jBPM BPEL • License : Open Source. • Information : http://docs.jboss.com/jbpm/v3/userguide/persistence. html. • Persistence Manager : None. • Most databases are supported by Hibernate, the database manager.
26
CHAPTER 4. BPEL ENGINES PERSISTENCE
Oracle BPEL Manager • License : Proprietary. • Information : http://download-east.oracle.com/docs/cd/B32110 01/ core.1013/b28942/tuning bpel.htm. • Persistence Manager : Dehydration Store. • Conditions required to store : – Wait activity – OnAlarm branch of a pick activity – Receive activity – OnMessage branch of a pick activity – An activity with false (http://www.oracle.com/technology/products/ias/bpel/documents/ bpel admin 10.1.3.1.0.pdf). If the engine stops while processing such an activity, it won’t be executed again when the server is restarted.
4.3
ActiveBPEL persistent storage analysis
Our goal here is to highlight what is to be saved precisely when talking about persistence, hence giving us ideas on how to improve dehydration’s performances. We focused on ActiveBPEL as it is the most commonly used open source BPEL engine. Two complementary techniques were used to define the stored information. First we’ve configured ActiveBPEL to run in persistent mode, using MySQL, to monitor what is stored in the database. The second method was to analyze directly the ActiveBPEL source code, to obtain the remaining information. The database schema given in figure 4.2 is the one used by the ActiveBPEL engine for persistence. It has been obtained by reverse engineering the database structure, using MySQL Workbench. In the following, we will detail each of its tables, indicating when they are used and for which purpose. This work is partially based on researches conducted in [25].
4.3.1
ActiveBPEL database
AeProcess The main table in this schema is AeProcess. Everytime a process is run by the engine, a new row is added to this table. It stores the ProcessId, its name (ProcessName), and other information concerning its execution. It has a status (ProcessState), which can take one of the following values : • P ROCESS LOADED = 0 27
CHAPTER 4. BPEL ENGINES PERSISTENCE
Figure 4.2: ActiveBPEL Storage Schema
28
CHAPTER 4. BPEL ENGINES PERSISTENCE
• P ROCESS RU N N IN G = 1 • P ROCESS SU SP EN DED = 2 • P ROCESS COM P LET E = 3 • P ROCESS F AU LT ED = 4 The ProcessDocument column contain XML data, in the form of a lightweight DOM, defined by the class AeFastDocument, from the package org.activebpel.rt.bpel.impl.fastdom. It represents the state of the process. It is obtained from the process via the method IAeBusinessProcess.getProcessSnapshot(), and serialized into XML with serializeProcess(true). AeAlarm This table helps in storing all the activities defined timeouts of a process. AeProcessJournal The AeProcessJournal table maintains the journal of processes execution. It stores a list of all the documents (SOAP messages, Alarm events...) treated during the evolution of the instance execution. AeProcessJournal rows are deleted whenever the information they hold have been added to the process state (see the protected AeProcessStateWriter.writeProcess() method). AeProcessLog This contains a trace of the execution of the last process. It is detailed, giving information about each executed activities in the longtext column ProcessLog. Listing 4.1 illustrate the content a a randomly selected ProcessLog from AeProcessLog. [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29 [12][2007-03-29
16:07:22.241] : Executing [/process] 16:07:22.241] : Executing [/process/flow] 16:07:22.241] : Executing [/process/flow/receive] 16:07:22.257] : Completed normally [/process/flow/receive] 16:07:22.257]Link : status is true [/process/flow/links/link[@name=’L1’]] 16:07:22.257] : Executing [/process/flow/assign] 16:07:22.257] : Completed normally [/process/flow/assign] 16:07:22.257]Link : status is true [/process/flow/links/link[@name=’L2’]] 16:07:22.257] : Executing [/process/flow/invoke] 16:07:22.444] : Completed normally [/process/flow/invoke] 16:07:22.444]Link : status is true [/process/flow/links/link[@name=’L3’]] 16:07:22.444] : Executing [/process/flow/assign[2]] 16:07:22.444] : Completed normally [/process/flow/assign[2]] 16:07:22.444]Link : status is true [/process/flow/links/link[@name=’L4’]] 16:07:22.444] : Executing [/process/flow/reply] 16:07:22.538] : Completed normally [/process/flow/reply] 16:07:22.538] : Completed normally [/process/flow] 16:07:22.538] : Completed normally [/process]
Listing 4.1: Content of a ProcessLog from AeProcessLog
29
CHAPTER 4. BPEL ENGINES PERSISTENCE
AeVariable This table stores every variable values, for each executed process. AeQueueReceive This table is the persistent representation of the queue manager’s data ( See section 3.2.3). It stores awaiting activities and unmatched messages. Correlation information are stored there, as part of their activity’s properties. AeCoordination This table stores information related to the processes coordinations, in conformance with the WS-Coordination specification [26]. AeUrnValues URN stands for Uniform Resource Name. This table, managed by the class AeURNStorage, is used to store and retrieve URN mappings. From ActiveBPEL documentation : ”URN mappings provide a flexible and dynamic way to define target endpoint references. Use URN mappings to specify the physical address of a partner link endpoint reference instead of using the address specified in a process deployment descriptor (.pdd) file or WSDL file. By mapping an URN to an URL, you do not have to rely on invoking a statically defined endpoint address. URN mappings give you flexibility, for example, to deploy the same BPR files for testing and production environments.” AeTransmissionTracker This table helps in tracking transmission by storing their ID, state, and message’s ID. AeCounter This table stores persistent counters, which are used by ActiveBPEL to get unique ID, not previously used. Start values for JournalId, ProcessId and QueuedReceiveId are kept there. AeMetaInfo This table keeps the ActiveBPEL version number. It’s useful for patching purposes.
4.3.2
ActiveBPEL logging information
Three log sources where used in this study.
30
CHAPTER 4. BPEL ENGINES PERSISTENCE
The first one is provided by the ActiveBPEL engine which has the ability to log data concerning the processes. Starting from version 3.1, it is possible to chose between ”full”, ”execution”, and no logging. We used the full logging option, which is the most verbose. It is managed by the class IAeProcessLogger. When persistence is activated, logs are stored in the database (See 4.3.1). The process manager can be logged in another way, by adding in the ”ProcessManager” entry of the aeEngineConfig.xml configuration file. The following output is an example of the generated informations for a BPEL process called HelloYou : Process Process Process Process Process Process
401: 401: 401: 401: 401: 401:
HelloYou, persistenceType = full, transactionType = bean received message for location 0 invoke pending at location 27 received data for invoke at location 27 sent reply id 401 saved (282 millis) (averted 50%)
The last log source we used was provided by MySQL. It has an option for logging every query that it received. We used it to trace back the ActiveBPEL persistence strategy.
4.3.3
ActiveBPEL persistence strategy
BPEL processes are composed of activities. When an activity is executed by the BPEL engine, its input data are stored in the required tables of the database, for the engine to remember that the activity has already been executed. When available, the resulting values are written to the database. Atomic and long running activities are handled differently by the ActiveBPEL engine. A full example is provided in appendix A. Atomic activities An atomic activity must be completed to be written to the database. That is, input and output data must either be all written are all lost. For this to be achieved, ActiveBPEL only commits changes to the database at the end of the activity. With MySQL, the first command issued for an atomic activity is SET autocommit=0, and the last ones are commit; SET autocommit=1. Here is a simple example of an atomic activity being stored to the persistence database : SET autocommit=0 UPDATE AeProcess SET ProcessDocument = ’...internal process representation...’, ProcessState = 1, ProcessStateReason = -1, StartDate = ’2007-04-10 12:26:32’, EndDate = null, PendingInvokesCount = 0, ModifiedDate = ’2007-04-10 12:26:42’, ModifiedCount = ModifiedCount + 1 WHERE ProcessId = 606
31
CHAPTER 4. BPEL ENGINES PERSISTENCE
SELECT LocationId, VersionNumber FROM AeVariable WHERE ProcessId = 606 INSERT INTO AeVariable(VariableDocument, ProcessId, LocationId, VersionNumber) VALUES (’...SOAP message...’, 606, 11, 11) INSERT INTO AeProcessLog(ProcessId, ProcessLog, LineCount) VALUES (606, ’...processes log messages...’, 6) DELETE FROM AeProcessJournal WHERE JournalId = 623 commit SET autocommit=1
This is just a simple assign activity. The AeVariable and AeProcessLog tables are updated with the same commit, to ensure atomicity. Long running activities A long running transaction is managed differently. The input information are committed to the database once they have all been issued. When the activity is terminated, the output data are committed. If the engine is restarted, it detects that the long running transaction was started but never finished, so the activity is not completely restarted. The following SQL commands shows a wait activity being stored : SET autocommit=1 INSERT INTO AeAlarm(ProcessId, LocationPathId, Deadline, DeadlineMillis, GroupId, AlarmId) VALUES (606, 24, ’2007-04-10 12:26:52’, 1176200812451, 24, 2) SET autocommit=1 -- Note: Wait until the alarm timeout SET autocommit=0 DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND GroupId = 24 DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND LocationPathId = 24 DELETE FROM AeAlarm WHERE ProcessId = 606 AND LocationPathId = 24 AND AlarmId = 2 INSERT INTO AeProcessJournal(JournalId, ProcessId, EntryType, LocationId, EntryDocument) VALUES (625, 606, 1, 24, ’...alarm document...’) commit SET autocommit=1
In this example, the alarm is first stored in the AeAlarm table, which indicates the engine that the activity has been started. When the wait’s alarm is triggered, the wait activity is over, and the last commands are committed. Processes dehydration In ActiveBPEL dehydration is referred as process state saving. It is different from the journaling process described below in that it happens only when a process has been idle for a given time period. When it happens, the current state of the process and its variable are all stored in the database. The time to wait for an idle process to be stored in the database is given by the ReleaseLag entry value in the ProcessManager section of the configuration file aeEngineConfig.xml. By default, it equals to 10 seconds.
32
CHAPTER 4. BPEL ENGINES PERSISTENCE
Concurrent processes The ActiveBPEL engine can’t manage an infinite number of concurrent BPEL processes. By default, 50 processes can be run concurrently. The list of running processes is maintained as a map, within the class AeProcessWrapperMap. When a process needs to be run, it waits until an AeMutex is freed by calling getProcessWrapperWithMutex(), and keeps it until it has finished its activities. The mutex is unlocked by a call to releaseProcessWrapperWithMutex(), or releaseProcessMutex() if the process is not yet terminated. To change the amount of processes that can be run concurrently, one must modify the ProcessCount value of the ProcessManager entry in the aeEngineConfig.xml configuration file. Persistence information usage We mentionned already that the ActiveBPEL engine has the ability to store every information required for a process to be loaded back in case of a crash in a database. Data stored this way are only loaded back in two cases : • When the engine needs to re-hydrate the processes states. • When an administrator browses the journal of active processes, to get informations about a given process. ActiveBPEL never uses the data stored in database to lower its memory usage, except when (de)hydration occurs. Everything is kept both in memory and in database, not to loose performance querying the database.
33
CHAPTER 5 BPEL Engines persistence optimization
5.1
Related works
In this section, we present results found in other domains, and show their interest in the optimization of BPEL engine persistence. In virtual memory management, a commonly faced problem is page fault management [27]. The physical memory, which is often larger than the addressable memory is divided into blocks of memory, called pages so that they can be accessed sequentially. This is done by mapping a physical page into the virtual memory. Several algorithms have been created to this end, such as Least Recently Used (LRU), Least Frequently Used (LFU), or Page Fault Frequency (PFF). They define an ordered list of pages mapped into memory. When a new page needs to be accessed, they add it to the list by eventually unmapping another page. Such algorithms can be applied to BPEL process management, comparing pages of memory to processes. However, we have another constraint here, as the less processes we have in memory, the more efficient are the others. This isn’t a constraint of page replacement algorithms as mapped pages have no impacts on performances. Moreover, in the following we will define rules from the processes inner activities, with a finer level of granularity. Cache memory in databases [28], and more generally cache coherency [29] has many things in common with BPEL persistence. In databases, cache memory is used to improve performances of database access by storing in memory the most commonly used data. This is however the inverse of what is required here, in that databases systems try to preserve the coherency of the memory, while BPEL engines store their information from memory to the database (Figure 5.1). Another field where researches have brought up results are self tuning databases [30]. They offer a clever way to determine the best configuration required for a database to work efficiently. However, as for the other techniques, such researches only focus on the “process view”, not taking into account the specificities of the internal activities.
34
CHAPTER 5. BPEL ENGINES PERSISTENCE OPTIMIZATION
BPEL engine : Logging Memory
Database
Database : Memory cache coherency Figure 5.1: Databases and BPEL engines
5.2
Optimization goals
There are several ways to improve data persistence in a BPEL engines. The first, obvious one, is to carefully choose the appropriate database. However, no matter how good it is, it will slow down the whole processing [31]. Depending on the BPEL engine, the time before a process is dehydrated can be set, per processes or for the whole engine. Our contribution is to analyze the process workflow at the activity level. This way, we can tune more precisely the behavior of each process instances, thus improving the general performances. Our goal is to determine for each activities whether they are about to idle the process or not, in order to adapt their hydrations and dehydrations policies.
5.2.1
Motivations
BPEL engines performances is a problem in real world applications. Most BPEL engines would be improved by hardware upgrades, even supporting clustering, but buying hardware isn’t always possible, or wanted. According to Oracle [31], the most common bottlenecks of BPEL engines are, among others : • Response Time: – Too much database activities. – Database is slow. • Concurrency: – Too few BPEL engine threads. Moreover, although BPEL engines can be more or less tuned to improve performances, the persistence management is still quite simple, and doesn’t take into account the inner structure of the BPEL programs. For instance, the dehydration time for a process in ActiveBPEL is 10 seconds after it being idled, even if the waiting time is known to take 11 seconds.
35
CHAPTER 5. BPEL ENGINES PERSISTENCE OPTIMIZATION
Taking into account the structure and information we have about processes can be used by the engine to save memory as well as to reduce databases access. This will be shown in the following, basically by anticipating or delaying hydration and dehydration time. We have established four goals based on our observations:
5.2.2
Dehydrate immediately
When a long running activity is being executed, it can be dehydrated immediately. In the following, the term “long” should be specified regarding the processes specificities. To determine whether or not an activity is about to take a long time, we have several sources of information, see 5.3.1. As illustrated in figure 5.2, the activity is a typical long running activity that does nothing, which allows it to be dehydrated immediately.
Wait 1h
Memory
Dehydrate immediately Database Figure 5.2: Dehydrate immediately
5.2.3
Don’t dehydrate
This rule is the opposite of the previous one. When an activity is expected to take few time, it should not be dehydrated. This won’t free the memory, but will ensure that the operations are performed as fast as possible.
Memory
Receive 15s
Don't dehydrate Database Figure 5.3: Don’t Dehydrate For instance, if the current activity is a waiting one, but is known to only take 15 seconds, it would be a waste of performances and resources to actually dehydrate the process.
36
CHAPTER 5. BPEL ENGINES PERSISTENCE OPTIMIZATION
5.2.4
Hydrate earlier
We can always hydrate a process a few times before a known timeout, to make it more responsive when the timeout occurs. This information can be guessed from timed protocols, as well as from information mining. We can choose not to apply this rule depending on the engine’s load.
Memory
Wait 1h Hydrate earlier
Database
59min
Figure 5.4: Hydrate earlier
5.2.5
Don’t hydrate
There are several cases where a process or part of it is dehydrated, hydrated back to load the next activity, and dehydrated again. This should clearly be avoided whenever possible, especially if the operations performed when the process is hydrated can be delayed. This can occur for instance when two consecutive activities are executed.
(a) Sequential
(b) Parallel
Figure 5.5: BPEL receive sequence Figure 5.5(a) shows such an example. When the first is executed, we might decide to dehydrate. When it has finished, the process is hydrated, starts the second , then again might be dehydrated. Moreover, between the two , only one variable might have been modified, but could have been later with no incidence on the second . The same can happen with different processes, taking for example the one presented in figure 5.5(b) where the two are executed in parallel. The join operation won’t be passed through until both the have completed, thus the process doesn’t need to be hydrated when the first has finished.
37
CHAPTER 5. BPEL ENGINES PERSISTENCE OPTIMIZATION
Memory
Receive 1h
Don't hydrate Database Figure 5.6: Don’t hydrate
5.3 5.3.1
Information sources Time information
One of our concerns is to determine as accurately as possible the time each activity will have to wait. This is easy when dealing with , or in a activity, as the BPEL program contains the timeout information. However, with the only help of the BPEL process, we can’t determine much more. The following lists some information sources (See also figure 5.7), which when available can be used to improve the accuracy of our optimization: 1. User knowledge. This is not an automated approach, but in some processes, the user might have some information. For instance, when a credit card payment is awaited, it can’t be expected to be done in less than a minute, as it involves human interaction. 2. Using the processes timed protocol [1]. Indeed, if the running process was built with an associated protocol, or if this protocol was extracted from the process [32], it might contain information regarding the time the current operation will take. 3. Using a partner’s timed protocol. When available, such information can be used to know how the partner is expecting the communication to be performed. It might be possible to extract the information we were missing about the protocol, thus determining the time a waiting activity is supposed to take. 4. By mining the previous execution logs [33]. Those works suppose that we already have executed the current process, which is not always the case. However, this can help is determining real world statistics, and should be used when available.
5.3.2
Waiting activities
There are only a few number of the BPEL activities that can be subject to waiting times, that is, activities that might produce nothing for a given period of time. They are: • : Waits for an incoming message. 38
CHAPTER 5. BPEL ENGINES PERSISTENCE OPTIMIZATION
User Knowledge
Log mining
Timed protocol
Partner's timed protocol
Figure 5.7: Time information • : Waits for/until a given time. • : In its synchronous form (two-ways), it might wait for a message, as a activity. Contrary to the other activities, always does something before its idle period, since it first sends a message. • : Concurrent waits and receives. • : The empty activity does nothing by itself. However, it is often used as a synchronization point in . • : Might contain waiting activities, alarms or events. It is really complex, and often requires the engine to perform many operations. Actually, it is like a sub-process, can be isolated from the rest of the process, and it can do everything a process can. So in many cases it won’t be possible to predict anything from its behavior. • : A contains only s, that should be executed a fixed amount of time. In rare simple cases its behavior can be predicted. Moreover, we have structured activities, that can be passed through without altering the process state: • : Its first activity might be a waiting one , so it will do nothing and can be considered as a waiting activity. • : Same as , but might start with several waiting activities. Those activities can’t be considered as waiting activities, but should still be analyzed. Indeed, in the following we will analyze consecutive activities, whose behavior are dictated by the structured activities they are contained in. The other activities cannot be directly subject to waiting times, because they all require some sort of computations that would break a waiting period.
39
CHAPTER 5. BPEL ENGINES PERSISTENCE OPTIMIZATION
5.4
Blocks of activities
To achieve the goals defined is section 5.2, we introduce the concept of “blocks” of BPEL activities, which we define as groups of consecutive activities that either can all wait, called D-Blocks for dehydration blocks, or that can’t at all, called H-Blocks. Figure 5.8 shows a BPEL program whose blocks have been highlighted.
Assign Sequence
Receive
Assign
Invoke
Invoke
Flow
Assign Receive
HBlocks
Reply
Wait
DBlocks
Figure 5.8: A BPEL process with its blocks highlighted
5.4.1
Blocks usage
Within a block, no hydration or dehydration can occur. If a D-Block’s waiting time is long enough (5.2.2), it will be dehydrated, and won’t be hydrated until every activities within it are terminated. Incoming messages will be queued upon termination of the D-Block, as well every other required operations. When an H-Block is executed, no dehydration should occur, as the engine knows that this block is about to perform non idling operations. The goals we setted in section 5.2 have in common that they all focus on activities waiting times. The goal 5.2.5 which tells us not to hydrate when two consecutive activities are waiting ones, can be achieved simply by creating D-Blocks. Moreover, blocks enable us to work on a larger set of the BPEL process while staying at the activity level. Blocks of activities can be used just as activities could be, and rules 5.2.2 to 5.2.4 can be improved by simply using blocks instead of activities. We can for instance decide to dehydrate a block immediately following the rule 5.2.2, or not dehydrate at all (5.2.3) exactly as with activities.
5.4.2
Blocks creation
H-Blocks and D-Blocks can’t be created whenever wanted. Indeed, depending on the moment they are generated, the amount of information available will vary, and with it the shape of the blocks. We define two approaches for generating blocks: • We can decide to create the blocks only considering the activities types. This way, activities presented in 5.3.2 would always be in a D-Block. Such analysis can be 40
CHAPTER 5. BPEL ENGINES PERSISTENCE OPTIMIZATION
made whenever wanted, but won’t take into consideration the actual waiting time of each activity, so the goals we fixed in section 5.2 will still need to be verified. • Blocks generation can be made with the available time information (see section 5.3.1). This way, we can analyze the waiting time of activities, and decide whether or not they should belong to a D-Block. The major drawback of this approach is that it might be necessary to wait until the execution time to correctly define the blocks, as partner’s protocol might not be available before. However, we will use this approach as it enables us to both generate the blocks and achieve our goals. H-Blocks activities are made up from all the process activities that are not in DBlocks, and that are not structured activities, namely or . Thus, we only need to identify D-Blocks, deducing H-Blocks from them. All that needs to be generated is the longest D-Block from the current activity, with it’s associated minimum waiting time. We create the blocks starting at a given activity, so that they can be generated even at runtime. 1. If the current activity is a waiting one (See section 5.3.2), we can add it to the list, among with its waiting time. 2. We do the same for each activities that follows directly the current one and that are waiting activities. Every activies that were following activities, but not waiting ones should be executed normally, as being part of H-Blocks. While looking for the following activities of the current one, we should avoid considering the structured activities like or , by looking directly at their first activities. D-Blocks characterization can be made hard when the structure is used. This activity coordinates others using . This might bring indeterminism when used with the constructs and . They represent boolean conditions evaluated at execution time, determining whether a link should be followed or not. When such a condition is present, it can be hard to determine which path will be executed, thus the following activities of the current one. It is often not possible before that link is crossed, because the conditions are dependant of the previously followed links. Once the minimum waiting time has been computed, we can easily check rules 5.2.2 to 5.2.4, planning hydrations and dehydrations consequently.
5.4.3
Blocks management
In the previous sections, we defined H-Blocks and D-Blocks, used to group activities according to their waiting time and their possible dehydration. In the following, we will present their requirements in terms of ressources and how to handle them.
41
CHAPTER 5. BPEL ENGINES PERSISTENCE OPTIMIZATION
Blocks termination conditions A D-Block is terminated if several conditions are met : • Every activity within the D-Block are terminated. Every awaited messages must have been received, and the amount of time required by activities like or must have been spent. • The following activities must be reachable. This implies that links targeting the following activities can be evaluated. If one of those conditions are not met, the D-Blocks is not considered to be terminated and can’t be left. An H-Block has less constraints, and terminates as usual when its last activities terminate. Memory and database requirements Using blocks of activities instead of considering only processes as a sequence of independent activities helps in managing the memory more efficiently. We have shown in the previous sections that it can increase the time a process is dehydrated, thus lowering the ressources requirements. We can also use this structure to lower memory requirements, by only keeping in memory the executed blocks of activity, and loading the other information from the database, when needed. To achieve that, we have to determine the resources required by a block to be executed. D-Blocks, as passive blocks require no information in memory. The engine only needs to verify if conditions are met to terminate it, as explained in section 5.4.3. When a D-Block terminates, some variables might need to be modified, for instance to store an incoming message, and the next block of activity should be accessible. H-Blocks require more information, as they can do just about anything, and access hypothetically every part of the process. However, if we can determine that they are using only a small amount of information, such as the required variable, we can choose to only make these parts available, keeping other information in database. Finally, as a BPEL process is most of the time a sequential execution of activities, we can determine which activities won’t be used anymore, choosing to dehydrate these parts of the process, freeing as much memory as possible.
5.5
Example
Let us illustrate this on an example, using the BPEL process presented in figure 5.8 and its associated protocol shown in figure 5.9 as a timed automata. When the process starts, it is in an H-Block, and as though will not be dehydrated. Once it reaches the first D-Block, the engine can decide how to proceed by analyzing the block’s waiting time.
42
CHAPTER 5. BPEL ENGINES PERSISTENCE OPTIMIZATION
T0:login(+) Caller, receive
T1:bookARoom() P1, invoke
T2:roomOk(+) P1, invoke
T6:sendMoney() P2, invoke
CInvoke(T1≥15s) T3:roomReady(+) P1, receive CInvoke(T2≥1h)
T9:moneyOk(+) P2, invoke
T10:roomReady(+) P1, receive
CInvoke(T6≥3s)
CInvoke(T2≥1h)
T7:roomReady(+) P1, receive
T8:moneyOk(+) P2, invoke
T11:accept() Caller, reply
CInvoke(T2≥1h)
CInvoke(T6≥3s)
T4:sendMoney() P2, invoke
T5:moneyOk(+) P2, invoke
CInvoke(T3≥1min || T7≥1min || T10≥1min)
CInvoke(T4≥3s)
Figure 5.9: The multi-party timed protocol [32] associated with the BPEL program from figure 5.8 The minimum time that will be spent in the D-Block is 1 hour (, from T3, T7 or T10), 1 minute (, merged into T11) and 15 seconds (, from T2). The BPEL engine can decide to dehydrate immediately the whole block and then wait for the hydration conditions to be fulfilled (See section 5.4.3). The activity, itself an H-Block from the other branch of the needs to be executed after at least 15 seconds. It will be followed by a D-Block, containing the last . When it is reached, this D-Block can be merged into the existing D-Block (composed by the , and activities), so that both blocks need to be terminated to pass the join point. In the end, the and can be executed, and the process is terminated.
43
CHAPTER 6 Conclusion & Future Work
This master internship gave me the opportunity to discover a truly interesting domain of computer science, web services. I had the chance to work with a really motivated team, who brought me lot of knowledge and a good experience in the field. The domain is still pretty young, but there are established standards such as SOAP or WSDL that have emerged to be the one to use. Around them, many other standards are growing, such as BPEL, whose evolution is critical for business integration. During this internship I was initiated to research, looking for novel techniques to improve BPEL engines persistence performances. Two main contribution were brought in the field: 1. The description of BPEL engines architecture based on ActiveBPEL. This is one of the first available documentation on the subject, and covers many aspects of the BPEL engines architecture. This work is important for future researches about BPEL engines. 2. A new method for optimizing the BPEL engines persistence. It is based on the structural analysis of BPEL programs, which had never been done before. Although the methods proposed in this paper might not be directly adaptable to every existing BPEL engines, it is clear that with such a design in mind, the engines could gain in memory usage. We have shown that by creating groups of activities, we can predict the behavior of processes parts, thus taking decisions on how to manage them more efficiently. There are many prospects for future work on this topic. An implementation of the presented ideas should be developed, for instance based on ActiveBPEL. Benchmarking the current implementation of the hydration and dehydration procedures should also be made, to get a more precise idea of the improvements. Moreover, BPEL engines tend to be more and more used in the Web Services domain [34], but no common engine’s architecture have emerged, and every corporations involved in BPEL engines development deal with each problems their own way, which tend to diminish the portability of the BPEL programs. At the long term, there is a clear need for standardization, at every level of the conception of BPEL engines. 44
APPENDIX A Sample BPEL program
This is a sample BPEL program we have created to analyze the ActiveBPEL persistence strategies.
Figure A.1: Sample BPEL program The following is the corresponding SQL logs extracted from MySQL while executing of the process. It has been commented for a better understanding: ---------------------------------------- activity, Beginning of the process ---------------------------------------- Columns: -- Date Connection Operation Command --------------------------------------070410 12:26:32 6 Query SET autocommit=1 6 Query SET autocommit=0 6 Query INSERT INTO AeProcess(ProcessId, PlanId, ProcessNamespace, ProcessName, ProcessState, ProcessStateReason, StartDate) VALUES (606, 0, ’http://HelloYou’, ’HelloYou’, 1, 1 , ’2007 0 4 1 0 12:26:32’) 6 Query INSERT INTO AeProcessJournal(JournalId, ProcessId, EntryType, LocationId, EntryDocument) VALUES (623, 606, 2, 0, ’\n\n \n \n http://172.16.174.2:8180/ a c t i v e bpel/services/HelloBPELServicens5:HelloYouns5:HelloBPELService\n \n \n \n \n Longer\n \n\n’) 6 Query commit ---------------------------------------- activity, for 10 seconds. ActiveBPEL will dehydrate, then hydrate immediately --------------------------------------6 Query SET autocommit=1 6 Query SET autocommit=1 6 Query SET autocommit=1 INSERT INTO AeAlarm(ProcessId, LocationPathId, Deadline, 6 Query DeadlineMillis, GroupId, AlarmId) VALUES (606, 17, ’2007 0 4 1 0 12:26:42’, 1176200802347, 17, 1) SET autocommit=1 6 Query 070410 12:26:42 6 Query SET autocommit=1 6 Query SET autocommit=0 6 Query DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND GroupId = 17 DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND 6 Query LocationPathId = 17 6 Query DELETE FROM AeAlarm WHERE ProcessId = 606 AND LocationPathId = 17 AND AlarmId = 1 6 Query INSERT INTO AeProcessJournal(JournalId, ProcessId, EntryType, LocationId, EntryDocument) VALUES (624, 606, 1, 17, ’\n\n’) 6 Query commit ---------------------------------------- activity --------------------------------------7 Connect root@localhost on ActiveBPEL 7 Init DB ActiveBPEL SELECT 1 7 Query 7 Query SET character_set_results = NULL 6 Query SET autocommit=1 SET autocommit=1 6 Query 7 Query select round(’inf’), round(’ i n f ’), round(’nan’) 7 Query SHOW VARIABLES 7 Query SHOW COLLATION 7 Query SET autocommit=1 7 Query SET autocommit=1 7 Query SET autocommit=0 7 Query UPDATE AeProcess SET ProcessDocument = ’\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n http://172.16.174.2:8180/ac tive bpel/services/HelloBPELServicens5:HelloYouns5:HelloBPELService\n \n \n \n \n http://localhost:8180/axis2 /services/HelloWorldns5:HelloWorld\n \n \n \n \n \n\n’, ProcessState = 1, ProcessStateReason = 1 , StartDate = ’2007 04 1 0 12:26:32’, EndDate = null, PendingInvokesCount = 0, ModifiedDate = ’2007 0 4 1 0 12:26:42’, ModifiedCount = ModifiedCount + 1 WHERE ProcessId = 606 7 Query SELECT LocationId, VersionNumber FROM AeVariable WHERE ProcessId = 606 7 Query INSERT INTO AeVariable(VariableDocument, ProcessId, LocationId, VersionNumber) VALUES (’\n\n Longer\n\n’, 606, 11, 11) INSERT INTO AeProcessLog(ProcessId, ProcessLog, LineCount) 7 Query VALUES (606, ’[606][2007 0 4 1 0 12:26:32.336] : Executing [/process]\r\n[606][2007 0 4 1 0 12:26:32.337] : Executing [/process/sequence]\r\n[606][2007 0 4 1 0 12:26:32.337] : Executing [/process/sequence/receive]\r\n[606][2007 0 4 1 0 12:26:32.346] : Completed normally [/process/sequence/receive]\r\n[606][2007 0 4 1 0 12:26:32.346] : Executing [/process/sequence/wait]\r\n[606][2007 0 4 1 0 12:26:32.347] Wait : = Tue Apr 10 12:26:42 CEST 2007 [/process/sequence/wait]\r\n’, 6) 7 Query DELETE FROM AeProcessJournal WHERE JournalId = 623 7 Query commit ---------------------------------------- activity, for 10 seconds. --------------------------------------7 Query SET autocommit=1 7 Query SET autocommit=1 7 Query SET autocommit=1 7 Query INSERT INTO AeAlarm(ProcessId, LocationPathId, Deadline, DeadlineMillis, GroupId, AlarmId) VALUES (606, 24, ’2007 0 4 1 0 12:26:52’, 1176200812451, 24, 2) 7 Query SET autocommit=1 070410 12:26:52 7 Query SET autocommit=1 7 Query SET autocommit=0 DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND GroupId = 7 Query 24 7 Query DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND LocationPathId = 24 DELETE FROM AeAlarm WHERE ProcessId = 606 AND LocationPathId = 24 7 Query AND AlarmId = 2 7 Query INSERT INTO AeProcessJournal(JournalId, ProcessId, EntryType, LocationId, EntryDocument) VALUES (625, 606, 1, 24, ’\n\n’) 7 Query commit ---------------------------------------- activity --------------------------------------6 Query SET autocommit=1 6 Query SET autocommit=0 6 Query UPDATE AeProcess SET ProcessDocument = ’\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n http://172.16.174.2:8180/ac tive bpel/services/HelloBPELServicens5:HelloYouns5:HelloBPELService\n \n \n \n \n http://localhost:8180/axis2 /services/HelloWorldns5:HelloWorld\n \n \n \n \n \n\n’, ProcessState = 1, ProcessStateReason = 1 , StartDate = ’2007 04 1 0 12:26:32’, EndDate = null, PendingInvokesCount = 0, ModifiedDate = ’2007 0 4 1 0 12:26:52’, ModifiedCount = ModifiedCount + 1 WHERE ProcessId = 606 SELECT LocationId, VersionNumber FROM AeVariable WHERE ProcessId 6 Query = 606 6 Query INSERT INTO AeVariable(VariableDocument, ProcessId, LocationId, VersionNumber) VALUES (’\n\n \n Longer\n \n\n’, 606, 13, 13) 7 Query SET autocommit=1 7 Query SET autocommit=1 6 Query INSERT INTO AeProcessLog(ProcessId, ProcessLog, LineCount) VALUES (606, ’[606][2007 0 4 1 0 12:26:42.449] : Completed normally [/process/sequence/wait]\r\n[606][2007 0 4 1 0 12:26:42.449] : Executing [/process/sequence/assign]\r\n[606][2007 0 4 1 0 12:26:42.450] : Completed normally [/process/sequence/assign]\r\n[606][2007 0 4 1 0 12:26:42.451] : Executing [/process/sequence/wait[2]]\r\n[606][2007 0 4 1 0 12:26:42.452] Wait : = Tue Apr 10 12:26:52 CEST 2007 [/process/sequence/wait[2]]\r\n’, 5) 6 Query DELETE FROM AeProcessJournal WHERE JournalId = 624 6 Query commit 6 Query SET autocommit=1 6 Query SET autocommit=1 SET autocommit=1 6 Query 6 Query INSERT INTO AeProcessJournal(JournalId, ProcessId, EntryType, LocationId, EntryDocument) VALUES (626, 606, 9, 26, null) 6 Query SET autocommit=1 6 Query SET autocommit=1 6 Query SET autocommit=0 6 Query INSERT INTO AeProcessJournal(JournalId, ProcessId, EntryType, LocationId, EntryDocument) VALUES (627, 606, 3, 26, ’\n\n \n \n Hello Longer\n \n \n\n’) 6 Query commit ---------------------------------------- activity, for 10 seconds. --------------------------------------6 Query SET autocommit=1 6 Query SET autocommit=1 6 Query SET autocommit=1 6 Query INSERT INTO AeAlarm(ProcessId, LocationPathId, Deadline, DeadlineMillis, GroupId, AlarmId) VALUES (606, 27, ’2007 0 4 1 0 12:27:02’, 1176200822586, 27, 3)
48
APPENDIX A. SAMPLE BPEL PROGRAM
070410 12:27:02
6 6 6 6
Query Query Query Query
SET autocommit=1 SET autocommit=1 SET autocommit=0 DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND GroupId =
27 6 Query
DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND
6 Query
DELETE FROM AeAlarm WHERE ProcessId = 606 AND LocationPathId = 27
LocationPathId = 27 AND AlarmId = 3 INSERT INTO AeProcessJournal(JournalId, ProcessId, EntryType, 6 Query LocationId, EntryDocument) VALUES (628, 606, 1, 27, ’\n\n’) 6 Query commit ---------------------------------------- activity. --------------------------------------7 Query SET autocommit=1 7 Query SET autocommit=0 6 Query SET autocommit=1 SET autocommit=1 6 Query 7 Query UPDATE AeProcess SET ProcessDocument = ’\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n http://172.16.174.2:8180/ac tive bpel/services/HelloBPELServicens5:HelloYouns5:HelloBPELService\n \n \n \n \n http://localhost:8180/axis2 /services/HelloWorldns5:HelloWorld\n \n \n \n \n \n\n’, ProcessState = 1, ProcessStateReason = 1 , StartDate = ’2007 04 1 0 12:26:32’, EndDate = null, PendingInvokesCount = 0, ModifiedDate = ’2007 0 4 1 0 12:27:02’, ModifiedCount = ModifiedCount + 1 WHERE ProcessId = 606 7 Query SELECT LocationId, VersionNumber FROM AeVariable WHERE ProcessId = 606 7 Query INSERT INTO AeVariable(VariableDocument, ProcessId, LocationId, VersionNumber) VALUES (’\n\n \n Hello Longer\n \n\n’, 606, 14, 14) 7 Query INSERT INTO AeProcessLog(ProcessId, ProcessLog, LineCount) VALUES (606, ’[606][2007 0 4 1 0 12:26:52.496] : Completed normally [/process/sequence/wait[2]]\r\n[606][2007 0 4 1 0 12:26:52.497] : Executing [/process/sequence/invoke]\r\n[606][2007 0 4 1 0 12:26:52.584] : Completed normally [/process/sequence/invoke]\r\n[606][2007 0 4 1 0 12:26:52.585] : Executing
49
APPENDIX A. SAMPLE BPEL PROGRAM
[/process/sequence/wait[3]]\r\n[606][2007 0 4 1 0 12:26:52.586] Wait : = Tue Apr 10 12:27:02 CEST 2007 [/process/sequence/wait[3]]\r\n’, 5) 7 Query DELETE FROM AeProcessJournal WHERE JournalId = 625 7 Query DELETE FROM AeProcessJournal WHERE JournalId = 626 DELETE FROM AeProcessJournal 7 Query WHERE JournalId = 627 7 Query commit ---------------------------------------- activity, for 10 seconds. --------------------------------------7 Query SET autocommit=1 7 Query SET autocommit=1 7 Query SET autocommit=1 INSERT INTO AeAlarm(ProcessId, LocationPathId, Deadline, 7 Query DeadlineMillis, GroupId, AlarmId) VALUES (606, 33, ’2007 0 4 1 0 12:27:12’, 1176200832633, 33, 4) 7 Query SET autocommit=1 070410 12:27:12 7 Query SET autocommit=1 SET autocommit=0 7 Query 7 Query DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND GroupId = 33 DELETE FROM AeQueuedReceive WHERE ProcessId = 606 AND 7 Query LocationPathId = 33 7 Query DELETE FROM AeAlarm WHERE ProcessId = 606 AND LocationPathId = 33 AND AlarmId = 4 7 Query INSERT INTO AeProcessJournal(JournalId, ProcessId, EntryType, LocationId, EntryDocument) VALUES (629, 606, 1, 33, ’\n\n’) 7 Query commit ---------------------------------------- activity, the process is then terminated. --------------------------------------7 Query SET autocommit=1 7 Query SET autocommit=1 7 Query SET autocommit=1 7 Query INSERT INTO AeProcessJournal(JournalId, ProcessId, EntryType, LocationId, EntryDocument) VALUES (630, 606, 5, 0, ’\n\n’) 7 Query SET autocommit=1 7 Query SET autocommit=1 7 Query SET autocommit=0 UPDATE AeProcess 7 Query SET ProcessDocument = ’\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n http://172.16.174.2:8180/ac tive bpel/services/HelloBPELServicens5:HelloYouns5:HelloBPELService\n \n \n \n \n http://localhost:8180/axis2 /services/HelloWorldns5:HelloWorld\n \n \n \n \n\n’, ProcessState = 3, ProcessStateReason = 1 , StartDate = ’2007 0 4 1 0 12:26:32’, EndDate = ’2007 0 4 1 0 12:27:12’, PendingInvokesCount = 0, ModifiedDate = ’2007 0 4 1 0 12:27:12’, ModifiedCount = ModifiedCount + 1 WHERE ProcessId = 606 SELECT LocationId, VersionNumber FROM AeVariable WHERE ProcessId 7 Query = 606 INSERT INTO AeVariable(VariableDocument, ProcessId, 070410 12:27:13 7 Query LocationId, VersionNumber) VALUES (’\n\n Hello Longer\n\n’, 606, 12, 16) 7 Query INSERT INTO AeProcessLog(ProcessId, ProcessLog, LineCount) VALUES (606, ’[606][2007 0 4 1 0 12:27:02.629] : Completed normally [/process/sequence/wait[3]]\r\n[606][2007 0 4 1 0 12:27:02.629] : Executing [/process/sequence/assign[2]]\r\n[606][2007 0 4 1 0 12:27:02.632] : Completed normally [/process/sequence/assign[2]]\r\n[606][2007 0 4 1 0 12:27:02.633] : Executing [/process/sequence/wait[4]]\r\n[606][2007 0 4 1 0 12:27:02.633] Wait : = Tue Apr 10 12:27:12 CEST 2007 [/process/sequence/wait[4]]\r\n[606][2007 0 4 1 0 12:27:12.647] : Completed normally [/process/sequence/wait[4]]\r\n[606][2007 0 4 1 0 12:27:12.648] : Executing [/process/sequence/reply]\r\n[606][2007 0 4 1 0 12:27:12.979] : Completed normally [/process/sequence/reply]\r\n[606][2007 0 4 1 0 12:27:12.980] : Completed normally [/process/sequence]\r\n[606][2007 0 4 1 0 12:27:12.980] : Completed normally [/process]\r\n’, 10) 7 Query DELETE FROM AeProcessJournal WHERE JournalId = 628 7 Query DELETE FROM AeProcessJournal WHERE JournalId = 629 7 Query DELETE FROM AeProcessJournal WHERE JournalId = 630 7 Query commit 7 Query SET autocommit=1 7 Query SET autocommit=1
51
BIBLIOGRAPHY
[1] J. Ponge, F. Toumani, B. Benatallah, and F. Casati, “Fine-grained compatibility and replaceability analysis of timed web service protocols,” 2007. [2] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Nielsen, S. Thatte, and D. Winer. (2003) Soap 1.2. [Online]. Available: http://www.w3. org/TR/SOAP [3] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. (2001) Web Services Description Language (WSDL) 1.1, 2001. [Online]. Available: http://www.w3.org/TR/wsdl [4] A. Arkin, S. Askary, B. Bloch, F. Curbera, Y. Goland, N. Kartha, C. Liu, S. Thatte, P. Yendluri, and A. Yiu. (2007) Web Services Business Process Execution Language Version 2.0. [Online]. Available: http://docs.oasis-open.org/wsbpel/2.0/ [5] D. Linthicum. (2006) Ws-bpel 2.0: Not backward compatible? [Online]. Available: http://webservices.sys-con.com/read/291050.htm [6] (2006) Hello world example. [Online]. Available: http://docs.jboss.com/jbpm/ bpel/tutorial.hello.html [7] T. Gunarathne, D. Premalal, T. Wijethilake, I. Kumara, and A. Kumar. Bpel-mora. [Online]. Available: http://www.cse.mrt.ac.lk/projects/batch02/project10/ [8] G. Hackmann, M. Haitjema, C. Gill, and G.-C. Roman. (2006) Sliver. [Online]. Available: http://mobilab.wustl.edu/projects/sliver/ [9] T. Gunarathne, D. Premalal, T. Wijethilake, I. Kumara, and A. Kumar. Bpel-mora: Lightweight embeddable extensible bpel engine. [Online]. Available: http: //ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-234/paper1.pdf [10] G. Hackmann, M. Haitjema, C. Gill, and G.-C. Roman. (2006) Sliver: A bpel workflow process execution engine for mobile devices. [Online]. Available: http://www.cse.wustl.edu/∼cdgill/PDF/icsoc06 sliver.pdf [11] IBM. Bpws4j. [Online]. Available: bpws4j
http://www.alphaworks.ibm.com/tech/
52
BIBLIOGRAPHY
[12] F. Curbera and R. Khalaf. (2005) Implementing bpel4ws: The architecture of a bpel4ws implementation. [Online]. Availhttp://www.extreme.indiana.edu/groc/ggf10-ww/implementing able: bpel4ws rania khalaf/Implementing%20BPEL4WS.pdf [13] A. Endpoints. Activebpel. [Online]. Available: http://www.activebpel.org/ [14] ——. Activebpel engine architecture. [Online]. Available: activebpel.org/docs/architecture.html
http://www.
[15] A. Houspanossian and M. Cilia. (2005) Extending an open-source bpel engine with aspect-oriented programming. [Online]. Available: http://www.dvs1. informatik.tu-darmstadt.de/publications/pdf/ASSE05.pdf [16] A. Houspanossian. (2006, April) Enhancing a bpel4ws engine: Supporting the execution of flexible ws-flows according to the refflow model. BSc Thesis, UNICEN. [Online]. Available: http://www.dvs1.informatik.tu-darmstadt.de/ publications/BScs/Alejandro.Houspanossian Apr06.pdf [17] R. Mietzner. (2006) Extraction of ws-business activity from bpel 1.1. [Online]. Available: http://elib.uni-stuttgart.de/opus/volltexte/2006/2864/ [18] J. Nitzsche. (2006) Entwicklung eines monitoring-tools zur untersttzung von parametrisierten web service flows. [Online]. Available: http://elib.uni-stuttgart. de/opus/volltexte/2006/2591/ [19] D. Wutke. (2006) Erweiterung einer workflow-engine zur untersttzung von parametrisierten web service flows. [Online]. Available: http://elib.uni-stuttgart. de/opus/volltexte/2006/2592/ [20] A. S. Foundation. Webservices - axis. [Online]. Available: http://ws.apache.org/ axis/ [21] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns: elements of reusable object-oriented software. Addison-Wesley Professional, 1995. [22] I. B. M. Corp. and I. BEA Systems. (2004) Timer and work manager for application servers. [Online]. Available: http://ftpna2.bea.com/pub/downloads/ commonj/Commonj-TimerAndWorkManager-Specification-v1.1.pdf [23] Active-Endpoints. Activebpel. active-endpoints.com/
[Online].
Available:
http://www.
[24] Oracle. Bpel process manager. [Online]. Available: http://www.oracle.com/ technology/products/ias/bpel/index.html [25] WS-DIAMOND. (2006) Enrichment of semantic web service description languages. [Online]. Available: http://wsdiamond.di.unito.it/Reports/d2 1.pdf [26] BEA, IBM, and Microsoft. (2004) Web services coordination (ws-coordination). [Online]. Available: http://specs.xmlsoap.org/ws/2004/10/wscoor/wscoor. pdf 53
BIBLIOGRAPHY
[27] A. V. Aho, P. J. Denning, and J. D. Ullman, “Principles of optimal page replacement,” J. ACM, vol. 18, no. 1, pp. 80–93, 1971. [28] K. Elhardt and R. Bayer, “A database cache for high performance and fast restart in database systems,” ACM Trans. Database Syst., vol. 9, no. 4, pp. 503–525, 1984. [29] J. Handy, The cache memory book. sional, Inc., 1993.
San Diego, CA, USA: Academic Press Profes-
[30] G. Weikum, A. Moenkeberg, C. Hasse, and P. Zabback, “Self-tuning database technology and information services: from wishful thinking to viable engineering,” in VLDB Conference, 2002. [31] Oracle. Bpel performance tuning. [Online]. Available: http://www.oracle.com/ technology/products/ias/bpel/pdf/bpel-performance-webinar.pdf [32] S. Rivet, “D´ecouverte de protocoles de services web a` partir de programmes ˆ bpel,” M´emoire, Diplome d’ing´enieur C.N.A.M. Centre r´egional d’Auvergne, January 2007. [33] D. Grigoria, F. Casati, M. Castellanos, U. Dayal, M. Sayal, and M.-C. Shan, “Business process intelligence,” Computers in Industry, vol. 53, pp. 321–343, April 2004. [34] D. Sholler, C. Abrams, J. Thompson, D. Gootzit, G. Phifer, R. Valdes, R. Wagner, C. Haight, M. Govekar, N. Gall, R. E. Knox, T. Friedman, D. Feinberg, J. B. Hill, J. Sinur, D. C. Plummer, D. W. Cearley, R. J. Witty, and A. Allan, “Hype cycle for web services and related standards and specifications,” Gartner Group, 2006. [35] G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web Services: Concepts, Architecture and Applications. Springer Verlag, 2004. [36] T. Piispanen. (2006) Bpel & soa. [Online]. Available: ∼tpiispan/BPEL SOA.pdf
http://users.tkk.fi/
[37] I. Braun. (2005) Ein logik-basiertes verfahren zur dynamischen und naherungsweisen zusammensetzung elektronischer web-dienste. [Online]. Available: http://iaks-www.ira.uka.de/calmet/stdip/dip-braun.pdf
54
