OpenWFE is an open source java workflow engine and Business Process Management suite, with 4 components: an engine, a worklist, a webclient and a reactor (host for automatic agents).
OpenWFE 1.5.0 is a major step in this open source workflow engine's development: the workflow instantiation mechanism has been completely revised, making the OpenWFE process definition language even more expressive and powerful.
Along with this change, functions in the process definition language have been heavily enhanced.
The worklist now relies on a decoupled store/storage system with get and put strategies for workitems : one can easily supply its own storage implementation and take advantage of existing QueryGetStrategy implementations.
The participant map service has been simplified and now relies heavily on regular expressions : a default participant map could fit a lot of organizational models, of course, stores still have to be defined for roles and/or users.
Great to see things like this happen. It's certainly a good idea to base a workflow or business process management engine on the patterns listed at workflowpatterns.com.
Whether or not an engine with a proprietary definition language will be able to compete with implementations of well-known standards like BPEL is of course questionable. I think depends on how fast BPEL 2.0 is going to be released (and if the features 1.0 is lacking are added).
In my next project that needs workflow I'll certainly have a look at this!!
OpenWFE is around for 3 years, its process definition language is mature now, as well as the engine itself.
Indeed, the 'workflow patterns' are great guides for the implementation of a serious workflow engine.
The team is looking for serious developers to implement either an xpdl2owfe or a bpel2owfe filter/compiler/adapter.
OpenWFE could thus be adapted to any standard "en vogue". The engine being like a VM for 'bytecode' generated from various languages.
Thanks for your positive comment.
When I first heard the term "Workflow", I thought it's interesting and decided to look into it.
I found the Wfmc (work flow) and downloaded and read 1 or two papers explaining workflows from their site
Well, I just was not impressed, first, I didn't understand what the heck they are trying to say from the first run (first reading), then, after I think I got, I am still not sure they are offering a new solutions or even a better implementation
The term Workflow I believe is a bad way to express, making an application scriptable and extensible
Or possibly it could be a bad way to express separation of policy and mechanism
Basically the idea is to define data types, and use the workflow engine to manipulate this data type (take it from one state to the other)
It's programming, but done givin a different name, so it becomes illusive, if it is programming, call it programming, that way I can readily use my programming skills, instead of deluding myself that I am doing something else, got my point.
I don't really think that anything that call it self workflow is worth investing in.
Well, not to bash it completely, it's a different way to program, it for sure will have some advantages, but it definitely seem to have disadvantage, like, not offering much flexibility
Okay I think we can say that workflow is a domain language, that comes with the good and bad of domain languages, but I think it's a bad domain languages.
I just don't like they were not being direct about it in those papers I read, it felt like a scam, like one of those new wonder case tools
Well, workflow is programming but it is intended for the business users mostly and non technical people.
It's programming, but done givin a different name, so it becomes illusive, if it is programming, call it programming, that way I can readily use my programming skills, instead of deluding myself that I am doing something else
I know of a class of system, where you define your data and their relations in a special language called DDL.
Then you can manipulate and query the data and relations using a language called SQL. Those evil marketing people insist that I call it a Relational Database Management System ;-) but it really programming, and I can use my programming skills, so I don't delude myself - because in reality it all about bits being moved around within/between the computer(s)
I think you see my point Ali.
i understand your confusion.
there are 2 fundamental goals to workflow and bpm : graphical representation and persisting execution
each workflow and BPM solution has the ability to persist an execution of a process. note that this is not so easy to do in plain java. (it would be something like serializing a thread)
secondly each workflow and BPM solution has a graphical representation of the process that is based on a directed graph. the graph is targetted for the business analysts or requirements provider.
the confusion starts when vendors start mixing these responsibilities with a number of other related responsibilities like integration, task management, asynchronous communication, ... imho, current solution do a very poor job of separating the core essence of workflow from the related value add features. jbpm 3 (now in alpha stage) contains more information about the individual responsibilities in workflow management systems.
Tom BaeyensJBoss jBPM
I would not point at graphical representation and persisting execution as goals.
The graphical representation of a process is a mean of understanding it. Some workflow definition language may rely on graphs (see YAWL), but it's also a mean of expressing the process.
Persisting the execution is also a mean to support the goal of workflow and BPM. Without persistence, processes are 'transient'.
Extending persistence may lead to clusterability and distributability.
So then what is the goal ? To enact [business] processes.
In the end, managers do not care if they have a nice diagram or an excerpt of an ISO 900x folder, their processes have to be digitized.
Persistence ? It depens on the process, some may die and get restarted without damage for the business.
After enactment comes monitoring and then data mining :
What processes are currently running and how are they performing ? Are there any bottlenecks ?
How many instances of one particular processes were run ?
How many invoices got refunded ?
In these further steps, [higher] goals may be found for a workflow management system.
Being able to easily monitor and report on the execution of a business process and then easily modify the process based on the results should be one of the major benefits of using a workflow engine over coding a point solution in Java etc.
You should be able to ask "business" type questions, such as "is our supplier meeting their service level agreements", "what is different about the loan approvals that take longer than our target time". Reporting should also include searching, both design time (find me all the processes that Bob was working on that access DB2), and run time (find me all the loan approval processes for loans over $30,000 where no action has occurred in the last week), and both at once (find me all processes that call SAP where some action is scheduled to occur between 18:00 and 21:00 on Saturday).
It is about providing the business a better and clearer view of what it's doing and how well it is doing it and being able to easily change the processes in response to changing business circumstances and goals.
for those interested in this domain. W3C currently is working on the policy rules initiative, which covers many of these topics and areas. The next policy rules conference is this year and will be in boston. Many large mortgage companies are already using rule engines to do this in realtime and get accurate reports on the production environment.
another area where these types of processes use rule engines is insurance industry. The larger institutions use rules to route, filter and sort inbound claims and bills.
After enactment comes monitoring and then data mining :What processes are currently running and how are they performing ? Are there any bottlenecks ?How many instances of one particular processes were run ?How many invoices got refunded ?In these further steps, [higher] goals may be found for a workflow management system.
These days customers/enterprises seem to be asking for
more than vanilla workflow services. Enterprise want to
close the loop on business processes by having the the ability to react and make decisions in real time and also make sense out of the noise (business events) that get generated out by systems.
(1) graphical representation
(2) persisting executing processes
(3) Provide business analytics in real time (BAM) to react
to the events in the enterprise and making sense out of noise (business events) in the underlying systems
(4) Provide business events that can be consumed by other systems/services
All the above seem to fit at the core and deliver the requirements being asked by customers/enterprises.
Above characterstics seem to be nicely addressed by a combo
of BPEL, (with workflow services provided by the BPEL engine) and BAM solutions. The neat thing about using BPEL is leveraging the standards stack (as there seem to be enough BPEL engines from vendors and opensource
implementations) so that developers don't have to learn a new scripting or workflow language and at the same time have the portability if need be.
You actually have a point, but there is a clear purpose to workflow, as Tom Baeyens stated.
I've been using workflow for five years now. Clearly, the ability to run two functions in sequence (for example) is not clever. You only need write to lines of Java code to see that. In workflow systems, however those two tasks are generally complex. You can't just write two lines of code.
For example, if you are writing an order management system you might want to send a request to a system to dispatch the good, wait for a reply (which may take days) and then notify the billing system that the order was shipped. It is possible that at some time one of the systems, including the workflow system, is temporarily unavailable.
The order has to survive all of this reliabily, so generally it is necessary to persist the state of the order. You also have some sort of transactional support to ensure that you always know exactly where you are.
I am not totally sold on the idea that workflow has to have a graphical interface. This seems to be basically a sales tool to impress senior management rather than a productivity tool. And since workflow tools are usually very expensive, this is important. My experience is that using a GUI is slower that text configuration, and in any case, usually a lot of business logic still ends up in behind-the-scenes code and the workflow is simply a very high level view.
The other problem with workflow is that the control flow and structural abilities of the workflow language are usually not much more advanced than the average assembly language. You are a million miles away from the power of Java, so if you want to do any clever, you usually can´t. For example: can I have an abstract control pattern that I can apply to another workflow pattern with a specific signature? Easy in Java - in workflow packages, it's another issue.
I agree with your observations in many aspects. The current approach to workflow is nothing but a shift from coding logic in a textual notation to a graphical notation. So far there's no value added. Things might even get worse, because the graphical workflow notations are of a procedural nature and are typically lacking concepts like encapsulation, inheritance and thelike.
However there are different approaches to workflow, which are not trying to express logic as graphs but rather separate business logic from technical aspects.
I agree with your observations in many aspects. The current approach to workflow is nothing but a shift from coding logic in a textual notation to a graphical notation.
Well, not quite. Perhaps a forum focussed around coding and development is the wrong place to discuss areas of their obsolesence, but a key goal of most organisations is to build workflow using simple tools, preferably accessible to business domain experts, not developers or technology experts. That means putting developers out of a job, when it comes to workflow problems. Maybe your workflow problems are solved by design and coding - fine, if that works for you. At least checkout workflow patterns (www.workflowpatterns.com) to ensure that you've got the full picture.
Re encapsulation, inheritance etc: why do I need them, if I've reduced the business problem down to a simple graph, rather than 1000 lines of code?
Real world business problems can hardly be reduced down to a simple procedural graph. Maybe you can cover the normal case with a simple graph. However, if you consider all special cases and exceptions of a real world business problem, your graph will get rather complex and unmaintainable.
I completely agree. Anyone who thinks any but the simplest business processes can be represented as simple procedural graphs is smoking something. Even if the the process isn't riddled with exceptions, just try adding asynchronous events to the mix like cancellation, or semi-dependent parallel flows.
Take a look at the petri nets used to demonstrate some of the advanced patterns on the workflow patterns site. Now tell me that someone without a programmer-type mind could construct them, and that drawing the pictures would be easier for such a person than coding it.
Based on what I am hearing from W3C policy rules initiative, many companies are asking for dynamic workflows and real-time capabilities. As BPM and workflows mature, I would think this trend will continue.
But is sounds to me that Workflow is trying make business procedure a bit more coarser, and more importantly, exposed to management.
Even if management could not necessarily create the flows out of whole cloth, they're (ideally) easier to understand because they're hide the minutae that plagues computer programming. And as a side benefit it monitors and traces the data flow through these procedures.
If you have a good framework that provides a coarse enough granularity for your processes (at, no doubt, some cost in performance), then ideally you're striving more toward the ivory tower goal of reusable, plug and play business components.
This lowers the overall complexity, and when you lower complexity, then you need to be less specialized to understand and manipulate it.
Simply put, computers are STILL "too slow" to be able to make this kind of reality practical.
But, when business processes become about as complex as a modern spreadsheet to leverage, then "user programming" becomes that much more of a reality. It's not that the higher ups are not capable of this kind of programming. They're the ones that create the process, procedures, and exceptions that we deal with everyday in the first place.
They just can't communicate them in the detail that is necessary for their ideas to be useable by a computer.
The Java-RDBMS duo nicely serves lots of single request-response interactions that serve individual user interactions. Once you get a use case that requires more than one human participant to complete it though, MVC + O/R + RDMBS starts looking a little thin.
Workflow as a solution domain addresses a different problem domain than object-oriented languages like Java. The Process is the primary abstraction, whereas OO has objects, and SQL works on set logic. In any large business application, you're going to run into a mix of problem domain issues that require a mix of solution domain implementations to meet the requirements.
That's why nobody writes any large business app in 100% java. You put oracle under it because oracle is good at dealing with transactions and large volumes of data. You put java on top of Oracle because well, I haven't seen web MVC implemented in PL/SQL but my guess is it look and work like ass. Java's much better at the presentation problem domain. Data in database. Presentation in Java. Many suggest that business processes likewise go in workflow.
That said, I haven't used a workflow engine that I liked. There's a need to be filled, I just haven't found anything that works without some serious shoe-horning and hair-pulling. It's not easy to 'test drive' workflow servers. They all require substantial investments of time to learn their languages and integrate with your existing application code. If you don't evaluate the integration features and try to model something from your app in their language, you're ignoring the vast majority of the work involved.
Someday workflow servers will be where databases are now. You can (relatively ;) easily move from one rdbms to another, with the help of jdbc and O/R mapping software. Perhaps the next step for workflow would be 'jwfc' or maybe a O/WF mapper? If I weren't so lazy I'd check to see if there's a JCP for that already.
Oh, and thanks for writing OpenWFE. I'll try to check it out soon.
Can anyone point me to a good cookbook or step-by-step using workflow?
I'd like to see code without workflow and code used using workflow. I'd like to see how it can make my life easier.