The moment jPDL was developed, XPDL was not a widely accepted standard. And even up to now many other companies use an import facility to load an existing xpdl. If you then manipulate it and save.... sorry export it again in XPDL, you loose many of the work you did in the designers of these companies.
So yes, jpdl is proprietary, but also very extensible, as opposed to other systems proprietary standards.
There are differences between xpdl and jdpl and if someone could draw them up (on the xml level), we'd be happy to comment on it to a certain extend and maybe help with an xslt or so for conversion.
We have no idea how many companies did not start using jBPM because of the proprietary nature of jPDL. We (I) certainly have not heard of one, so it might be that there is no problem at all ;-) and thus no impact.
There is a shallow comparison between jPDL and XPDL in this topic: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=72991&start=0
Apart from that, XPDL embeds UI data such as node coordinates and sizes in the process definition. I think that's a bad design decision, but anyway. This and other features in XPDL make me feel an XSL transformation wouldn't be enough. It could be a good start, tough...
I do not neccesarily think combining the info in one file is bad design. There is lots of duplication between the jpdl and gpd file. Getting things to fragmented and split over multiple files is also not to great... but anyway.... :-)
If I find the time somewhere (maybe in 2007) I'll have a quick look again at xpdl (it has been a long time since I've used it a little)
I know what you mean. J2EE deployment descriptors are a perfect example of how bad things can get. However, UI-related data in a business process makes it less readable, as they are irrelevant to the business logic. Of course, if you assume that most of the time you'll be looking at the graphical view and regard the document as an interchange format, then merging all details in a single file makes complete sense. IMO this is a matter of the intention of the text representation.
I know jBPM 1.0 used a single file. What's the approach taken by other workflow products?
It all depends what you understand under the nomer 'proprietary'. The fact that XPDL originates from the WfMC and that there is a (small) number of products using it, does not make it a widespread standard. And if it is not a widespread standard, I would also call it proprietary. BPMN has as many claims to be called a 'standard' as XPDL.
I am not saying I would be able to convince your management on this one, but I think you should certainly mention the enormous fragmentation with at least five 'standard' notations in the workspace/bpm space. So at this moment there is no clear agreement on standards and in such a situation I think you should pick whatever you feel most comfortable with.
My 2 cents,
also, with XPDL, and any process language so far, it is very hard (read: impossible) to get to our goal: creating a common language between business analyst and developer. business analyst must be in charge of the graphical representation, while the developer must have all the executional and technical details under his/her control.
we have documented our approach as Graph Oriented Programming. and recently, we see that MS takes a similar approach with WWF.
To be honest, I would not know how others do it, and the choice mad by jBPM is in my opinon certainly not the wrong one. One disadvantage is that I should never, never change the process outside the IDE, since it makes the gpd corrupt. That would not happen if it was in one file with namespaces uesd to differentiate between the purpose of the elements.
In other workflow products xpdl (as far as I can see) gets supported more and more. As is true for BPMN. As a matter of fact, we internally (at the company I work for during the day (like now, answering this question) came to the conclusion that the BPMN notation with the ability to add additional info to nodes, like documents needed etc, fits hour needs more then fine. Timeouts, 'cancellations' are in there, and I think it is not that far of the jBPM GPD. We are looking at Enterprise Architect from Sparxsystems for requirements capturing, uml desing, AND bpmn notation.
I'm all in favour of using jpdl as the processdefinition and the GPD as the technical process designer. So XPDL is not an issue for me, since I do not care about portability at that level. Desiging a new process when moving from e.g. Staffware/Tibco to jBPM (which I still hope I can pull off) is less difficult than the issues on the integration level (until jbi comes in). Besides that, I agree the business should be (partially) in control of the graphics. But imo bpmn is a very nice notation. The ui of the GPD is not that much off (if you do not count the looks)
Now since we are talking about the number of xml files, I'm realy surprised to see the page being introduced in jpdl. There was this nice separation between processflow and pageflow. One guy working on the process and one one the pageflow, each with their own editor. We choose jsf for the latter, which suits our needs realy fine. I have no clue how this separation will be done when the pageflow is in the jpdl. I kind of get a flasback of the designer (html) and coder (scripting) both working in jsp pages.
For me jbpm is the controler of the businesslogic/process and jsf pageflow is the controler of the frontend.
The trend in BPM among big vendors is to leverge a BPM engine (such as a BPEL one) and a rules engine together as a foundation for everything in their middleware suite--much of which does not entail human interaction. I just returned from a meeting with Oracle (read sales pitch) in San Francisco last week at which this was precisely their message.
In such an environment processes will be worked on by analysts and back-end developers, while front ends will be built by other individuals. You wouldn't want a core process def deployed every time a GUI developer wants to move something around. There is a genuine need to keep presentation specific data out of the core process def in the work flow world just as you would want to keep your presentation logic separate from business logic in any other multi-tiered application. Anything else would be limiting your solution to very specific use cases, and any solution that makes a policy of muddying the separation of concerns will not scale across the enterprise, regardless of whether the solution is an open standard or not.
So you've heard about oracle fusion. What is your opinion on it? I've heard others call it a frankenstein architecture.
Here is a scenario that may lend to the discussion--
A good sized business process is broken out into many sub-processes, and the entire process is "handled" in two tiers. The first tier is handled primarily by a business analyst, and is responsible for overall orchestration of second tier processes. Second tier processes may involve various integrations or complicated transformations, etc. and are worked primarily by developers.
A second tier process may involve a complicated user interaction. Should the same process engine that is responsible for orchestrating the entire parent process also be the flow engine behind the flow of the UI, or should the developer use some other web framework to define screen flow? The trend is toward one core engine being used for all kinds of flow.
By properly defining sub-processes, separation of concerns can be accomplished as a matter of policy and tooling. If a process definition language can "do it all", it is simply important that "best practices" be defined to help ensure the success of users and fend off criticism.
Yes, I know it looks like this post conflicts with my previous one, but hey, I'm thinking out loud. ;-)
The trend is toward one core engine being used for all kinds of flow.
This is not what I heard from some big players in this field. They tend to separate concerns but at the same time do not switch to standards for at least the ui frontend (unfortunately I cannot comment in detail due to some stupid NDA)
This kind of corresponds to our own experience, where the reuse of a subprocess (not jBPM :-( ) required a completely different pageflow. Even if it is one person doing them both, separation of roles/concerns should still take place.
Well, they did a pretty good job of presenting it. Sure, they're combining lots of open standards and open source libraries; however, that will probably be their strong point within a year or two. They are emphasizing tight integration and tooling of lots of standard "commodity" components. No, everything isn't perfect today, but what I saw had more to do with what they'll be releasing in 10.1.3 later this year as well as what should be included in 11g. I think they're going in the right direction and will do well with it.
That doesn't mean I think Oracle's work flow solution is a particularly strong option right now. This is an analysis I wrote after we got back from San Francisco last week...maybe it will help someone here with a decision...
Oracle appears to be pushing their software solutions in all the right directions, with software that is extensible, compliant with open standards, and reasonably modular. The company's seemingly ubiquitous push toward open standards and it's contributions to those standards shows a mature understanding of the present and near term future of durable software solutions.
We saw quite a few software solutions Thursday in San Francisco that any Oracle-running shop would (and should) be eager to put into production, such as their Enterprise Service Bus for lending some management to a company's web service portfolio, etc. However, with Business Process Management (BPM) as a key topic, it is worth putting some analysis in to that area of their offerings.
Oracle's current work flow solution is primarily (and for the time being, almost exclusively) a BPEL engine. To paraphrase one of Oracle's developers on Friday, the Business Process Execution Language (currently in version 1.1 and also in the 2.0 draft) is an orchestration language that internally has made no real provision for handling human tasks. While Oracle developers have taken a step to address this limitation in BPEL by creating a custom web service component that wraps some user-assignable functionality, an effective enterprise-wide work flow solution must offer a complete set of features for managing human tasks. Two task management features missing from Oracle's near term solution are swimlane assignment of tasks and separate work group assignment for tasks (in which task ownership is simultaneously composed of both user and work group information).
For those who may not be familiar with swimlanes and work group assignment as mentioned in this context, please consider the following two examples:
Swimlane assignment: NTC generates a large portion of it's revenue by the renewal of existing commercial contracts. Securing a renewal is a predominately human process in which a representative assigned to a particular customer may contact the customer several times over a period of months, attempting to both secure a renewal of the contract as well as up-sell services, maybe having to offer discounts or appease some dissatisfaction along the way. Once a representative has begun working on a particular renewal, it is generally important that that same representative be subsequently assigned to every customer contact task that follows in that process instance. It is also generally important that if a particular customer renewal is reassigned to a different rep for some reason, that the new rep be automatically associated with all further tasks. In this described case (and given a swimlane implementation) all human contact tasks in the process form a 'Rep' swimlane, and each newly created task instance belonging to the Rep swimlane will be automatically assigned to the individual user currently associated with the swimlane. At some point, the swimlane (or role) within the process instance can be associated with a different user, and subsequent tasks in that swimlane will be automatically assigned to that new user.
Work group association: consider that a particular trouble ticket task is associated with a 'Ticket Pool' from which members of the Customer Care group claim tasks. A user named Bill claims a task out of the pool but does not perform the task for some reason, and the ticket must revert back to the pool. If our system supports separate work group assignment, our task contains assignment data related to both the current actor (Bill) and it's governing work group (the Ticket Pool); consequently, simply disassociating Bill from the task allows the system to see this task as being back in the Ticket Pool. If we didn't have both user and group data simultaneously associated with the task, the system wouldn't know to which pool to return the task. We could not determine this simply by referencing to which pool Bill belongs, because Bill may work out of more than one pool.
Naturally, each work flow feature, like those listed above, not found in a particular commercial package adds to the amount of in-house development required to be layered on top of the package. In addition, information like swimlane/task association which should arguably be developed (and stored) as part of the process definition, must be developed and stored apart from the package's core definitions. Of course, if the the commercial package is upgraded, those in-house extensions/customizations must keep pace.
Oracle's product will likely make up the difference in features at some point in the future, but ...<stuff probably covered by some NDA somewhere>
Also, to add a bit of perspective to the holy grail that quite a few people seem to be looking for, Oracle's developers also confirmed that it is basically impossible for a business analyst to produce truly robust process definitions without the involvement of a developer at some point. This is not knocking either BPEL or Oracle's solution; I believe this is simply the nature of the beast and will hold true no matter who's software or standard is evaluated.
On a positive note, the extensive number of connectors provided out of the box means developers wouldn't have to spend much time tooling handlers for FTP, file system access, and several other popular, third party systems. Also, Oracle's GUI for process design seems to be quite thorough.
On Thursday, one of the presenters mentioned explicitly that it was not possible to manually override a BPEL process (ie., administratively completing an otherwise automated state); however, one of the developers assured us that this was possible through the APIs. This needs to be clarified, since the ability to manually administer the completion of an otherwise automated process state is occasionally an unfortunate necessity.
In the end, Oracle's product is an excellent first shot at BPM; however, as an architect, I would have liked to see them put some of the effort that went into connectors and the GUI, rather, into fleshing out a better framework for handling human oriented work flow. The lack of the latter in up-coming releases may prove costly for current adopters who intend to deploy the software business-wide.
There is a difference between "one engine being used for all kinds of flow" and "one language to do it all". All kinds of flow boil down to a state machine and context associated with each instance traversing it. Yet the widely varying environment in which each flow operates fully justifies the use of different languages.
In your example I'd feel tempted to use BPEL in the first tier since 1) all the actors are systems, 2) subprocesses lend themselves well to be exposed as services and 3) the design discussions at this level will be more intense, and the fact it is a standard helps establish a common foundation. I'm not completely sure, tough, because XML schema types, WSDL definitions and structured constructs aren't in the vocabulary of business analysts.
For the second case 'd go for something closer to my development environment, to ease the integration and transformation tasks, and with built-in support for human involvement.