What am I Missing?
My recent trip to Microsoft reintroduced me to a few goings on in “The Enterprise”, which is thankfully something of a dim memory for me. The one thing which always seemed like garbage to me is BPEL (and any other XML workflow tool). However there are a bunch of smart people who clearly think that there’s some merit to it. I’m fairly opinionated, it goes with the territory but I figure I should ask “what is it I’m missing”?
For the readers who have yet to learn about BPEL, check out this oracle tutorial.
One of the constructs BPEL gives you is the ability to specify conditionals:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
<switch> <case condition="bpws:getVariableData('FlightResponseAA','confirmationData','/confirmationData/Price') <= bpws:getVariableData('FlightResponseDA','confirmationData','/confirmationData/Price')"> <!-- Select American Airlines --> <assign> <copy> <from variable="FlightResponseAA"/> <to variable="TravelResponse"/> </copy> </assign> </case> <otherwise> <!-- Select Delta Airlines --> <assign> <copy> <from variable="FlightResponseDA"/> <to variable="TravelResponse"/> </copy> </assign> </otherwise> </switch> |
Of course we already have that:
1 2 3 4 5 |
if FlightResponseAA.confirmationData.Price <= FlightResponseDA.confirmationData.Price TravelResponse = FlightResponseAA else TravelResponse = FlightResponseDA end |
It also lets you invoke processes:
1 2 3 4 5 6 7 8 9 10 11 12 |
<flow> <sequence> <!-- Async invoke of the AA Web service and wait for the callback--> <invoke partnerLink="AmericanAirlines" portType="aln:FlightAvailabilityPT" operation="FlightAvailability" inputVariable="FlightDetails"/> <receive partnerLink="AmericanAirlines" portType="aln:FlightCallbackPT" operation="FlightTicketCallback" variable="FlightResponseAA"/> </sequence> <sequence> <!-- Async invoke of the DA Web service and wait for the callback--> <invoke partnerLink="DeltaAirlines" portType="aln:FlightAvailabilityPT" operation="FlightAvailability" inputVariable="FlightDetails"/> <receive partnerLink="DeltaAirlines" portType="aln:FlightCallbackPT" operation="FlightTicketCallback" variable="FlightResponseDA"/> </sequence> </flow> |
But we already have that too:
1 2 |
FlightResponseAA = AmericanAirLines.FlightAvailability() FlightResponseDA = DeltaAirlines.FlightAvailability() |
So it seems to me that BPEL and other workflow tools simply take standard programming language constructs, wrap them up in XML and call it something other than programming. All that engineering effort could have been thrown into interesting research to advance the state of our industry, instead we get this mess…
So, what have I missed? Are workflow systems some kind of amazing solution to a really hard problem, or solution in search of a problem?
Shoghi Effendi April 3rd, 2007 @ 05:09 PM
It is called abstraction. Pulling the workflow out of the code offers the following advantages:
1. You don’t have to touch your code to change your workflow.
2. You can depict as well as manipulate workflow using graphical tools built for the purpose.
3. Platform independence – you have BPEL engines on many platforms.
While the ruby-based approach you mentioned will also work, remember why you code in rails versus hacking a CGI script in Perl which would also work. Rails is more elegant and easier to maintain as applications get bigger and the original coders are not available.
Koz April 3rd, 2007 @ 07:27 PM
The thing is, it’s not abstraction. The markup language is expressing the exact same constructs as code would. So as far as I’m concerned it’s code. It may be xml, and it may be maintained in some funky gui tool, but it’s program-logic and you should be treating it the same way as your application code:
Platform and vendor independence is a nice side-benefit, but the reality is you can get that with J2EE. In fact it’s the same set of vendors!
I just can’t help but wonder if all the effort spent on bpel had instead been put into visual IDEs for an existing language, we’d all be much much better off.
Alan April 3rd, 2007 @ 08:30 PM
I have this fuzzy idea of some nirvana (no doubt fuelled by dimly remembered hype) that one day a business person will be able to draw some structured boxes and lines – BPMN – and it will come out somewhere as BPEL and magically get turned into code.
Yeah right.
These things seem to get so structured and abstracted from reality that the key participants either can’t/won’t understand their role in the development cycle or have to invest absurd amounts of time trying to learn the abstractions.
Give me developers that understand business, every time.
Meanwhile I’ve been using (a bastardised version of) BPMN to make nice process pictures. Most of the IT guys are blah about them; amongst the Business guys they’re a running joke. I don’t know why I bother… but maybe that says more about where I work than the quality of the output… I hope. :-)
Pointy Haired Boss April 3rd, 2007 @ 10:16 PM
http://www.dilbert.com/comics/dilbert/archive/images/dilbert2091641070403.gif
Say’s it all.
Zed A. Shaw April 4th, 2007 @ 03:32 AM
Shoghi,
It’s not abstraction, it’s indirection. Abstraction involves generalization and/or simplification (which is something this XML does NOT do). If the logic is the same, but involves even more syntactic elements then it can’t be general or simplified (as Koz demonstrates). This has been the pure mathematical definition of “abstraction” for centuries. Only programmers confuse indirection with abstraction.
Indirection is taking something and adding one or more links to get to it. In this case, rather than just calling the “biz logic class”, you have to call the BPEL engine, which calls the BPEL processor, which calls an XML parser, which calls probably a JIT compiler for speed, which THEN finally does the logic and returns the exact same result up this Rube Goldberg chain of events. Again, if the claim is abstraction, then it would simplify and generalize, which BPEL rarely does.
It’s also a huge myth that adding indirection gives you “firewall maintainability” in software. You almost always have to update one end of these kinds of indirections when you update the other. That’s why BPEL is bogus bullshit because it’s just moving the exact same logic out to another layer of indirection that has to be maintained with a more complex langauge. In addition, you don’t get the generalization for “free” like they claim because the interface to the BPEL processing engines isn’t normalized enough to be reusable without effort.
Now, if these damn BPEL systems used a nice DSL that implemented Petri nets and handled all the storage and concurrency for you, then they’d be worth it. See, that’d be a true “abstraction” since it’s remove the need to worry about concurrent coordination and time across business processes. BPEL promised that but did not deliver in any way. All BPEL did was invent YAXPL (Yet Another XML Programming Language).
Koz April 4th, 2007 @ 07:52 AM
@Zed: Exactly, if the server-side features like async invocation etc are really worth the effort, I can’t see why it couldn’t have been added to and existing programming language as a library.
Even if it needed some syntactic sugar, surely that would have been easier?
That’s the part I’m missing. What about these workflow languages makes them worthwhile, so far it just seems like utter junk.
Mike Woodhouse April 4th, 2007 @ 08:27 PM
I’m not sure that you should be talking like this: there’s a distinct Emperor’s New Clothes feel to some (unquantifiable but probably large) proportion of the effort going into XMLifying just about everything these days. And I’m just a (fairly) old fart, I know, but I continue not to get it in most cases. As a means of formatting data such that it can be passed between two systems without the need for lengthy file format negotiations, OK. (Although the arguments seem simply to move to DTD/XSD instead, but at least the range of specification alternatives is reduced). And that option includes (X)HTML, to my mind.
For most other uses, I have to admit to struggling with its value. And using XML so that you can process it with XSLTs is just madness. Or have I missed something and a way been found to remove XSL’s remarkable write-only quality?
Mark April 6th, 2007 @ 04:53 AM
When I look at that code, I pull out things like “switch”, “case”, “copy”, and “otherwise”, I ask myself “Why?” If they are going to make a “transparent” logic language, why does it need to be based on XML. If they just rewrote that entire thing to the ruby equivalent and dubbed it a new programming language, that’d be fine and sensible!
By using XML, they took out the all-encompassing nature of programming languages (which can be a good thing for what they’re trying to accomplish) and moved it into bloating the logic as markup. HTML/XML were created to NOT be logic/programming languages (read: markup language).
Let’s reinvent the wheel again, shall we?
bryanl April 18th, 2007 @ 01:47 AM
Not to nitpick because I mostly agree with your point, but:
the flow/sequence thing is not the same thing as…
FlightResponseAA = AmericanAirLines.FlightAvailability() FlightResponseDA = DeltaAirlines.FlightAvailability()unless you are somehow executing both of those actions at the same time.
Koz April 18th, 2007 @ 09:16 AM
Sure it is, there’s no reason the snippet I pasted above can’t immediately return a stub which is fetched in another thread.
Similarly, there’s no reason that the nice async nature of the workflow engines needs some XML thing as the programming language. The same functionality could have been provided with syntax additions to java, libraries for ruby or any other method of enhancement to any other language.
Frodo April 19th, 2007 @ 01:20 AM
BPEL is about managing the whole life-cycle of some business process
- analyse, design, deploy, execute, manage, monitor, optimise -and about about a chain of different tools used by different people over the course of that life-cycle.planetmcd April 25th, 2007 @ 02:28 AM
Thanks for writing this. I work in a bureaucracy and simple things have complicated workflow and I’ve been trying to figure out how to handle it in my applications. I looked to see what the Java world did and all I saw is this BPEL stuff. It seemed crazy and I’m glad to see I’m not the only one.
For simple workflows or workflows that don’t change often, the acts_as_state_machine plugin works nicely. It doesn’t handle dynamic workflow (as is) and thus requires a programmer to make changes when the bureaucrats change things up. I suspect this is the abstraction itch that BPEL is trying to scratch, but it doesn’t seem like it does.
Maybe this would make a good RailsWay subject…