31,79 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
In Detail
jBPM is an open source business process management (BPM) solution used for defining and executing business processes. Java developers can use jBPM to analyze, improve, and maintain their business processes. This book steers you through each point of the jBPM framework and its implementation to model your business processes.
The book starts by explaining the key concepts in a Business Process Management framework. It will help you to learn and practice all of the conceptual and theoretical terms used in the Business Process Management field. Then you will master jPDL, the preferred process language for jBMP, which will let you specify exactly how your processes must be defined and implemented.
From here on, the book takes a closer look at the engine, discussing a broad range of topics from building real business processes inside real applications to learning and implementing advanced capabilities of the jPDL and jBPM framework. It will also help you to handle vital information and tasks related to persistence, integrating jBPM with other enterprise systems, and deploying jBPM to existing J2EE application servers.
By the end of this book, you will gain all the experience required to implement solutions that use the framework as well as to make decisions about how the framework needs to be used in particular situations.
Use the Java language to develop powerful Business Process Management solutions using jBPM
Approach
This book is a complete developer's guide to working with jBPM in a J2EE enterprise environment. It is packed with examples of implementations that will provide you with all the experience needed in real-life implementations. Extensive discussions about how the framework is implemented internally will contribute to creating a robust knowledge of when and how your projects will include this framework.
Who this book is for
This book is mainly targeted at Java developers and Java architects who need to have a deep understanding of how frameworks behave in real-life implementations.
The book assumes that you know the Java Language well and also know some widely used frameworks such as Hibernate and Log4J. You should also know the basics of relational databases and the Eclipse IDE. A brief introduction to Maven2 is included in this book but extra experience might be needed for more advanced usages.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 477
Veröffentlichungsjahr: 2009
Ähnliche
Table of Contents
jBPM Developer Guide
Mauricio Salatino
jBPM Developer Guide
Copyright © 2009 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: December 2009
Production Reference: 1101209
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-847195-68-5
www.packtpub.com
Cover Image by Filippo Sarti (<[email protected]>)
Credits
Author
Mauricio "Salaboy" Salatino
Reviewers
Jeronimo Ginzburg
Federico Weisse
Acquisition Editor
David Barnes
Development Editor
Darshana S. Shinde
Technical Editors
Ishita Dhabalia
Charumathi Sankaran
Copy Editor
Sanchari Mukherjee
Indexer
Rekha Nair
Editorial Team Leader
Gagandeep Singh
Project Team Leader
Priya Mukherji
Project Coordinator
Leena Purkait
Proofreader
Andie Scothern
Graphics
Nilesh R. Mohite
Production Coordinator
Shantanu Zagade
Cover Work
Shantanu Zagade
About the Author
Mauricio Salatino (a.k.a. Salaboy) has been a part of the Java and open source software world for more than six years now. He's worked with several technologies (such as PHP, JSP, Java SE, Java ME, and Java EE) during these years and is now focused on JBoss frameworks. He got involved with the JBoss Drools project about a year and a half ago as a contributor, gaining a lot of experience with the open source community and with multiple technologies such as JBoss jBPM, JBoss Drools, Apache RIO, Apache Mina, and JBoss Application Server.
During 2008 he dictated the official jBPM courses for Red Hat Argentina several times, and he was involved in several JBoss jBPM and JBoss Drools implementations in Argentina. He was also part of the Research and Development team of one of the biggest healthcare providers in Argentina, where he trained people in the BPM and Business Rules field.
Mauricio is currently involved in different open source projects that are being created by the company he co-founded, called Plug Tree (www.plugtree.com), which will be released in 2010. Plug Tree is an open source based company that creates open source projects and provides consultancy, training, and support on different open source projects.
Mauricio is an Argentinian/Italian citizen based in Argentina. In his free time he gives talks for the JBoss User Group Argentina (www.jbug.com.ar), that he co-founded with a group of local friends. He also runs his personal blog about JBoss, jBPM, and JBoss Drools, that was originally targeted to Hispanic audiences but is now aimed at an international audience and receives more than five hundred questions per year.
I would like to thank my family for always being there to support my decisions and adventures, my new and old friends who have helped me during this process, all the Packt Publishing staff who have guided me during these months of hard work; and last but not least, the open source community guys who are always creating new, interesting, and exciting projects.
About the Reviewers
Jeronimo Ginzburg has a degree in Computer Science from Universidad de Buenos Aires, Argentina. He has more than 10 years of experience in designing and implementing Java Enterprise applications. He currently works at Red Hat as a Middleware Consultant, specialized in JBoss SOA-P (jBPM, Rules, ESB, and JBoss AS). During the last four years, Jeronimo has been researching Web Engineering and he has co-written articles published on journals, proceedings, and as a book chapter.
Federico Weisse was born in Buenos Aires, Argentina. He has over 10 years of expertise in the IT industry. During his career he has worked with several technologies and programming languages such as C, C++, ASP, PHP; different relational databases (Oracle, SQLServer, DB2, PostgreSQL), platforms (AS400, Unix, Linux) and mainframe technologies.
In 2002, he adopted Java as his main technology. He has been working with it since then, becoming a specialist in this field. A couple of years later, he got involved with BPM systems.
Nowadays, he is a J2EE architect of a BPM system based on OSWorkflow in one of the most important healthcare providers of Argentina.
I want to thank Mauricio for choosing me to review his book, which I think has great value for the developers who want to get to know BPM theory and jBPM technology.
I also want to mention the effort and dedication of all the developers around the world who provide open source software of excellent quality, making it accessible for anyone eager to get new IT knowledge.
Dedicated to my loving future wife Mariela, and especially to my mother who helps me with the language impedance.
Preface
You are reading this because you are starting to get interested in the open source world. This book is especially for Java architects and developers with a free mind, who want to learn about an open source project. The fact that jBPM is an open source project gives us a lot of advantages, but it also comes with a big responsibility. We will talk about both—all the features that this great framework offers us and also all the characteristics that it has, being an open source project.
If you are not a Java developer you might find this book a bit harder, but it will give you all the points to understand how the open source community works.
I would like to take you through my own history, about how I discovered jBPM so that you can identify your situation right now with mine. Take this preface as an introduction to a new field—integration. It doesn't matter what your programming skills, experiences, and likes (user interfaces, code logic, low level code, simple applications, enterprise applications, so on) are, if you are a courageous developer you will like to tackle down all types of situations at least once.
With the myriad of web technologies these days, it's not a surprise that the new developers' generation starts building web applications. I have been working in the software development field for approximately six years now. I used to spend most of my time creating, developing, and designing web-based applications. I have also learned more "low level" languages such as C and C++, but in the beginning I could not make money with that. So, PHP and JSP were my first options. Although it was challenging I realized that I could not create bigger projects with my knowledge about JSP and PHP. The main reason for this, in my opinion, is that bigger projects become unmanageable when you start having web pages that contain all your application logic. At that point I recognized that I needed to learn new paradigms in order to create bigger and scalable applications. That is when I switched to Java Enterprise Edition (version 1.4), which provides us with a componentized way to build applications in order to be able to scale and run our applications on clusters and with all these features about high availability and fault tolerance. But I was not interested in configuring and making environmental settings, I just wanted to develop applications. An important point in my career was when I started getting bored as I had to spend hours with HTML and CSS frontend details that I did not care about. So, I looked for other frameworks like JSF, which provides a componentized way to build UIs and newer frameworks like JBoss Seam/web beans (JSR-299) that have intimate relationships with the EJB3 specification, but once again I had to check for HTML and CSS details for end users. I think that the fact that I used to get bored with HTML and CSS is one of the biggest reasons why I got interested in integration frameworks. When I use the word integration, I mean making heterogeneous applications work together. Most of the time when you are doing integrations; the user interfaces are already done and you only need to deal with backends and communication stuff. That was my first impression, but then I discovered a new world behind these frameworks. At this point two things got my attention: the open source community and the theoretical background of the framework. These two things changed my way of thinking and the way I used to adapt to a new open source framework. This book reflects exactly that. First we'll see how we can adapt all the theoretical aspects included in the framework and then move on to how we can see all these concepts in the framework's code. This is extremely important, because we will understand how the framework is built, the project direction, and more importantly how we can contribute to the project.
I have been involved with the open source community for two years now, working with a lot of open source frameworks and standards that evolve every day. When I got interested in jBPM I discovered all the community work that is being done to evolve this framework. I wanted to be part of this evolution and part of this great community that uses and creates open source frameworks. That is one of the main reasons why I created a blog (http://salaboy.wordpress.com) and started writing about jBPM, I also cofounded the JBoss User Group in Argentina (http://www.jbug.com.ar) and now Plug Tree (http://www.plugtree.com), an open source-based company. With these three ventures I encourage developers to take interest in new frameworks, new technologies and the most important thing, the community.
What this book covers
Chapter 1, Why Developers Need BPM? introduces you to the main theoretical concepts about BPM. These concepts will lead you through the rest of the book. You will get an idea of how all the concepts are implemented inside the jBPM framework to understand how it behaves in the implementations of the projects.
Chapter 2, jBPM for Developers, introduces the jBPM framework in a developer-oriented style. It discusses the project's main components and gets you started with the code distribution.
Chapter 3, Setting Up Our Tools, teaches you to set up all the tools that you will be using during this book. Basic tools such as Java Development Kit and the Eclipse IDE will be discussed. It will also provide you with a brief introduction to Maven2 here to help you understand how to build your projects and the framework itself. At the end of this chapter you will see how to create simple applications that use the jBPM framework.
Chapter 4, jPDL Language, introduces the formal language to describe our business processes. It gives you a deep insight in to how this language is structured and how the framework internally behaves when one of these formal definitions is used.
Chapter 5, Getting Your Hands Dirty with jPDL, gets you started with working on real-life projects. You will be able to create your first application that uses jBPM and define simple processes, using the basic words in the jPDL language.
Chapter 6, Persistence, sheds light on the persistence service inside the jBPM framework, which is one of the most important services to understand in order to create real-life implementations using this framework. The persistence services are used to support the execution of long-running processes that represent 95% of the situations.
Chapter 7, Human Tasks, describes the human interactions inside business processes, which are very important because humans have specific requirements to interact with systems and you need to understand how all this works inside the framework.
Chapter 8, Persistence and Human Tasks in the Real World, mainly covers configurations to be done for real environments where you have long-running processes that contain human interactions. If you think about it, almost all business processes will have these requirements, so this is extremely important.
Chapter 9, Handling Information, helps you to understand how to handle all the process information needed by human interactions inside the framework, as the human interactions' information is vital to get the activities inside our business processes completed.
Chapter 10, Going Deeply into the Advanced Features of jPDL, analyzes the advanced features of the jPDL language. This will help you improve your flexibility to model and design business processes, covering more complex scenarios that require a more advanced mechanism to reflect how the activities are done in real life.
Chapter 11, Advanced Topics in Practice, provides us with practical examples on the topics discussed in the previous chapters. This will help you to understand how all the advanced features can be used in real projects.
Chapter 12, Going Enterprise, introduces the main features provided by jBPM to run in enterprise environments. This is very important when your projects are planned for a large number of concurrent users.
Who this book is for
This book is mainly targeted at Java developers and Java architects who need to have an in-depth understanding of how this framework (jBPM) behaves in real-life implementations. The book assumes that you know the Java language well and also know some of the widely-used frameworks such as Hibernate and Log4J. You should also know the basics of relational databases and the Eclipse IDE. A brief introduction to Maven2 is included in this book but prior experience might be needed for more advanced usages.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "As you can see, inside the <task-node> tags different tasks (<task> tag) can be defined."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "If we take a look at the Source tab, we can see the generated jPDL source code."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an email to <[email protected]>, and mention the book title via the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book on, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Tip
Downloading the example code for the book
Visit http://www.packtpub.com/files/code/5685_Code.zip to directly download the example code.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration, and help us to improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to any list of existing errata. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or web site name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. Why Developers Need BPM?
I will start this book with a sentence that I say every time that I talk about jBPM. "jBPM is a framework, keep it in mind". That's it, this is all that developers and architects want to know to be happy, and it keeps them excited during the talks. For this reason, the aim of the book is to give all developers an in-depth understanding of this excellent, widely-used, and mature framework.
In this chapter we will cover the following topics:
To give you a brief introduction to this chapter, we are going to explain why developers need to know about BPM and when they should use it. Before reaching to this important conclusion we are going to analyze some new concepts like business process, business process management discipline, and business process management systems because it's important that developers manage the specific terminology pretty well. Bearing these new concepts in mind, you will be able to start analyzing how your company handles everyday work, so you can rediscover your environment with a fresh perspective.
This chapter deals with vital conceptual topics that you need to know in order to start off on the right foot. So, do not get disappointed if you feel that this is all about theoretical stuff. Quite the opposite, just think that with all this conceptual introduction, you will know, even before using the framework, why and how it gets implemented as well as the main concepts that are used to build it internally. I strongly recommend reading this chapter even if you don't know anything or if you don't feel confident about the BPM discipline and all the related concepts. If you are an experienced BPM implementer, this chapter will help you to teach developers the BPM concepts, which they need in order to go ahead with the projects that will be using it. Also if you are familiar with other BPM tools, this chapter will help you to map your vision about BPM with the vision proposed by the jBPM team. Because it's a vast theoretical topic, it is important for you to know the terminology adopted by each project reducing and standardizing the vocabulary.
The moment you get to the concepts that we are going to see in this chapter, you will get a strange feeling telling you: "Go ahead, you know what you are doing". So you can take a deep breath, and brace yourself to get your hands on planning actions using the concepts discussed in this chapter. Because these concepts will guide you through till the end of this book.
First things first, we will start with business process definition, which is a main concept that you will find in everyday situations. Please take your time to discuss the following concepts with your partners to get an insight to these important concepts.
Business Process, why should I know about that?
As you can see, jBPM has Business Process (BP) in the middle; so, this must be something very important. Talking seriously, Business Process is the first key concept to understand what we are really going to do with the framework. You must understand why and how you describe these Business Processes and discover the real application of this concept.
A common definition of Business Process is: Business Process is a sequence of tasks that happen in a repeatable order, executed by humans and/or systems to achieve a business goal.
To understand this definition we need to split it into three pieces and contrast it with a real example.
"A sequence of tasks that happen in a repeatable order"
This definition shows us two important points:
As you can see, these examples are concrete, and the rule of thumb is that these tasks should be described with an action (verb in the sentence, Reviewing for example) and a noun (document in this case) that represents where the action is applied.
Note
Developers and architects should avoid thinking that "call myMethod()" will be a good example of a task in a Business Process. Because this is not! "call myMethod()" does not have anything to do with the business field.
Also remember that this is a conceptual definition and is not related to any particular technology, language, or system.
The second important word that we notice is "sequence", which demands a logical order in which the actions are executed. This kind of sequence in real scenarios could be seen as: Buyer buys an Item -> Buyer pays the bill -> Dispatch buyer the order. An important thing to note here is that this sequence does not change in a short period of time. This means that we can recognize a pattern of work and an interaction that always occurs in the same order in our company to achieve the same business goals. This order could change, but only if we suffer changes in business goals or in the way that we accomplish them. Also you can see that this sequence is not achieved by one person; there is some kind of interaction/collaboration among a group of people to complete all the activities.
"executed by humans and/or systems"
Here we will see who performs these activities. But probably you have a question, why definition makes these distinctions about humans and/or systems? This is because humans behave differently from systems. Human beings are slow (including me) and machines are fast, so we need to handle this interaction and coordination carefully. Why are humans slow? From the application perspective, this is because when a task is assigned to a human being, let's say Paul, this task must wait for Paul to be ready to do the job. In case Paul is on vacation for a month, the task would have to wait for one month to begin. Systems (also called automatic procedures) on the other hand, just execute the action as fast as they can, or when the action is required. These two opposite behaviors are one of the principal influences in the design of the framework. For this reason, we are going to see how these behaviors are implemented inside the framework in the following chapters.
Another important thing to keep in mind about these two behaviors is: ''waiting for humans to respond'' and ''executing it as fast as possible for systems'', are the behaviors that we will need to synchronize. In real-life situations, we will have them in a random order. (The order could be somewhat like: wait, execute as fast as you can, wait, wait, execute as fast as you can, and so on) Let's clarify these points with a practical, real-world example. Imagine that we are in a company called Recycling Things Co. In one of the company branches papers are recycled. This branch of the company is in charge of recycling used paper, processing it, and storing it until someone buys it. Probably this process contains the following activities/tasks:
To have a clear understanding of this example, we can graph it, in some non-technical representation that shows us all the steps/activities in our just-described process. One of the ideas of this graph is that the client, in this case Recycling Things Co. manager, can understand and validate that we are on the right track regarding what is happening in this branch of the company.
As you can see, the process looks simple and one important thing to notice is that these chained steps/activities/tasks are described from a higher-level perspective, like manager level, not employee perspective. It is also necessary to clarify the employee perspective and add this detail to each activity. We need to have a clear understanding of the process as a whole, the process goal, and the details of each activity.
Note
If you are trying to discover some processes in your company, first ask at manager level, they should have a high-level vision like in the Recycling Things Co. example. Then you should know what is going on in everyday work. For that, you should ask every person involved in the process about the activities that they are in charge of. In a lot of companies, managers have a different vision of what is going on everyday. So ask both sides, and remember employees have the real process in their minds, but they don't have full visualization of the whole process. Pay close attention to this. Also remember that this kind of discovering task and modeling process is a business analyst's job.
"to achieve a business goal"
It is the main goal of our jobs, without this we have done nothing. But be careful, in most cases inexperienced developers trying to make use of their new framework forget this part of the definition. Please don't lose your focus and remember why you are trying to model and include your processes in your application. In our previous example, Recycling Things Co., the business goal of the process (Recycle paper) is to have all the recycled papers ready as soon as possible in order to sell it. When the company sells this paper, probably with another process (Sell recycled paper), the company will get some important things: of course money, standardized process, process formalization, process statistics, and so on. So, stay focused on relevant processes that mean something to the company's main goal. Try not to model processes everywhere because you can. In other words, let the tools help you; don't use a tool because you have it, but because it's in these situations where all the common mistakes happen.
I know what BPs are, but what about the final "M" in BPM?
If we have a lot of business processes, we will need to manage them over time. This means, that if we have too many process definitions, and also we have executed these definitions, we will probably want to have some kind of administration that lets us store these definitions as well as all the information about each execution. You may also want to keep track of all the modifications and execution data throughout. This is really necessary because the process will surely change and we need to adapt to the new requirements of our business that evolves each day. That is why BusinessProcessManagement (BPM) emerges as a discipline to analyze, improve, automatize, and maintain our business processes. This discipline proposes four stages that iteratively let us have our business processes in perfect synchronization with business reality.
BPM stages
Now we are going to analyze the stages that this discipline proposes to us:
As you can imagine, all these stages are iteratively repeated over time. Take a look at the following figure that shows us all the BPM stages. It also includes the most common artifacts that are generated in each step.
BPM stages in a real-life scenario
One entire cycle that goes through all these stages is one step forward to our well-defined processes that will guide our company everyday.
If we take the previous example of Recycling Things Co., we can say that BPM works as follows:
At the end of stage four, another cycle begins: improving, adapting, and rediscovering all the processes continuously in the company.
In the next section we are going to discuss about all the advantages that this discipline gives us.
This description of BPM is incomplete, but for developers who want to use jBPM, it is fine. If you are interested in learning more concepts and theoretical background about this discipline there is plenty of interesting literature out there. You just need to search BPM on the Internet and many pages and articles will appear. For example, take a look at http://en.wikipedia.org/wiki/Business_process_management and http://www.bpminstitute.org/index.php?id=112.
BPM improvements
BPM, as with any other discipline, gives us a large number of practical advantages that we want to know before we adapt it. Here we are going to discuss some of the most important advantages and improvements that we can have if we adopt BPM and how they can benefit our company.
Global understanding of our processes
When we find a process in our company, we discuss it with the manager and the business analysts. This process now could be formalized in some formal language. (Formal means it has no ambiguous terms, and it's said the same for everybody who understands it.) If we achieve that, we gain two main things:
Agile interaction between systems, people, and teams
When our process definitions are executed, all the employees will be guided through their tasks, making the system integrations transparent to them, and improving people's communication. For example, say in a post office we have a task called receive letter. The person at the front desk there receives the letter and fills all the information about the destination address of the letter on a form. When delivery time arrives, some other task (say Deliver letter) will use all this information. In this case, the process itself will be in charge of moving this data from one activity to another, taking away the responsibility from both users. The data will go from one task to another, making the information available for everyone needing it.
Reduce paperwork
In all the human tasks (tasks that need an interaction with people) the most common behaviors will be:
So, this results in saving money and not having to wait for the forms that may not arrive or could be lost on their way.
Make a decision: Choose if something is OK or not and take some special path in the process (we will talk about different paths in our process later). In our post office example, when the Recycling Station guy checks the quality of the just-recycled paper, he needs to choose if the recycling of paper is done properly or it needs to be retried. Here the quality of the paper and the number of retries could be maintained as process information, and do not need to be written down on a paper or form. The machine can automatically inform our process about all this data. In these cases, the advantage that BPM gives us is that we can make automatic decisions based on the information that the process passes from one activity to the next.Real-time process information
In every process execution and at any moment, our managers can see in which activity the process is currently stopped and who must complete it. With this valuable information about the status of all the processes, the manager will know if the company is ready to make commitments about new projects. Also you can switch to other methodologies, such as, BAM (BusinessActivityMonitoring) to make a more in-depth and wider analysis about how your company processes are working.
Process information analysis
With the formal definition of our processes we can start improving the way the information is treated in each of our processes. We can analyze if we are asking for unnecessary data or if we need more data to improve performance of our processes.
Statistics and measures about each execution
With audit logs of each execution we can find out where the bottlenecks are, who is a very efficient worker, and who spends too much time on an assigned task without completing it.
As you can see there are a lot of advantages of BPM but we need to understand all the concepts behind it to implement it well.
BPM and system integration "history"
We as developers see BPM closely related to system integration, so in our head when we see BPM we automatically merge the concepts and disciplines:
This mix gives us important advantages and flexibility, which let us manage all the interactions and information inside our company in a simple way. But this mix also brings a lot of confusion about terminology in the market.
At this point, when BPM began to appear in the market, vendors and customers had their own definition about what BPM meant. Some customers just wanted BPM; it didn't really matter what BPM really was, but they wanted it. Also vendors had different types of technologies, which they claimed to be BPM just in order to sell them.
When all this confusion lessened a bit and not everyone wanted to buy or sell BPM tools, the big boom of SOA (ServiceOrientedArchitecture) began. SOA was born to bring us new architecture paradigms into give us more flexibility at design and integration time. The main idea is: with SOA, each business unit will have a set of services that can be easily integrated and have fluid interactions with other business unit services and also with other business server partners.
At this point, the confusion about overloaded terms came again. Also with the addition of SOA, new languages come to play; one of the most fashionable languages was BPEL (BusinessProcessExecutionLanguage, also known as WS-BPEL—WebServicesBPEL). BPEL is basically an integration language that allows us to communicate with heterogeneous systems, which all talk (communicate) using Web Services Standards. All of this is done in a workflow-oriented way (but only for systems and not for people), so we can describe systems' interactions with a graph that shows us the sequence of systems calls.
Also ESB (EnterpriseServiceBus) products started gaining a lot of popularity among vendors and customers. This product proposes a bus that lets us connect all our services, which speak in different languages and protocols, and allows them to communicate with each other.
But as you can see, SOA has two faces, one is technological and the other corresponds to the architectural design patterns. This second face contributes a lot to today's enterprise architectural choices that are being taken by big companies around the world.
In the next section we are going to see some brief definitions about all these technologies that are around BPM as they always bring confusion to all of us. If we understand the focus of each technology, we will be able to think and implement software solutions that are flexible enough and have the right concepts behind them. Do not confuse technical terms with theoretical definitions.
Some buzzwords that we are going to hear when people talk about BPM
In this short section we are going to discuss words that sometimes confuse us and sometimes we misuse these words as synonyms. This section is aimed at clarifying some ambiguous technical and theoretical terms that surround BPM. These terms will be distinguished as theoretical definitions and technological terms. Sometimes you will notice that different roles have different perspectives about the same term.
Theoretical definitions
These theoretical definitions try to clarify some concepts that aim to define topics that are agnostic to technology, trying to understand the cornerstones behind terms that are often used by technical people. Feel free to query other bibliographies about these terms to get all the background that you need.
Integration (system integration)
We frequently hear about integration. BPM is about integration, but what exactly do we need to understand when we hear that?
Probably when someone says "I want to integrate my systems", we understand that this person wants all his or her company systems to talk (communicate) to each other in order to work together. That is the most common understanding, but we also need to understand that this integration will include the following out-of-the-box implicit requisites:
Workflow
One of the most overloaded words in the market. When we hear conversations about workflows in most cases, we are talking about situations where only people get involved. Most of the workflows are related to documents that are moved through business units inside the company, where these business units modify these documents, to achieve some business goal. Currently, in many companies the terms BPM and workflow are used as synonyms, but in this book we are trying to make the distinction between them clear.
Here when we talk about workflows we refer to some steps inside them and specific application domains. BPM is like a more generic and extended set of tools, which let us represent situation that integrate heterogeneous systems and people's activities, with a fine-grained control.
However, workflows and BPM share the same theoretical nature; try to see workflows like a domain specific set of activities and BPM as a set of tools to integrate and communicate all the work that is being done in the company.
Service Oriented Architecture (SOA)
Here we will discuss the theoretical aspect of the term SOA. When people talk about SOA, most of the time they are talking about some specific architectural design patterns that let our application be designed as services communicating with each other. This means that in most of the cases our applications will be used across the company business units. This requires one application to interact with services of each unit. So, SOA advises us about how to build our application to have flexibility and fluid communications between each business unit services.
Orchestration
This term refers to the possibility to coordinate the interaction between systems calls. This coordination is always achieved by a director that will know which is the next system call in the chain. This term is used to represent a logical sequence, which is used to obtain a business result using different calls to different systems in a specific order. This term is used very frequently in conjunction with BPEL. We'll discuss that in the next section.
Technological terms
These technological terms, in contrast with all the theory that we see behind them, give us the knowledge that we need to use tools in the way that is intended. Try to link all this technical information with the theory that we have seen before. If you feel that something is missing, please read more bibliographies until you feel confident with it. But don't worry, I will do my best to help you.
Workflow
When developers talk about workflows, probably they are referring to some framework, tool, or product, which lets them define a sequence of steps that one application will take. That is, they mean some kind of state machine that will be embedded in the application. As we mention this in most of the cases, workflows are specific to one domain and probably to one application.
Enterprise Service Bus (ESB)
Enterprise service buses emerge as very flexible products that implement a lot of connectors, which let us plug our heterogeneous applications to them and then interact with each other. With ESB, we achieve the abstraction about which protocol we need to use to talk with another application and we only need to know how to talk with the bus. Then the bus is in charge of the translation between different protocols and languages.
BPEL (WS-BPEL)
BusinessProcessExecutionLanguage (BPEL) is a language that defines how web services calls are coordinated one after the other to obtain some business information or to achieve some business action. This language lets us define how and when web services for different applications need to be called and how the data should be passed through these calls.
Note
One final thing to notice here is that BPM is a discipline. This means that BPM is technology agnostic, you can implement this discipline in your company just with a pen and paper, but if you are a developer I would think that you wouldn't want to do that.
That is why BPMS comes to save us.
Business Process Management Systems (BPMS), my tool and your tool from now on
Now, we know about BPM as a discipline, so we can implement it; but wait a second, we don't need to. That's because jBPM is a framework that lets us implement the main stages of BPM (unless you want to implement it in pen and paper!). BPMS makes up for a piece of software that lets us implement all the main stages that the discipline describes. These tools are frameworks that provide us with the designing tools to describe our Business
