If BEA was anxious for a quick entry into the BPMS magic quadrant, this was probably a cheaper and faster way to check off all the features than building out WLI. Companies like IBM, Oracle, and Intalio have shown that you can build a complete BPMS -- with human workflow, business rules, BAM, and the rest -- on top of a unified service orchestration stack, so why would BEA want to go back to the old dual architecture approach -- workflow for the end-to-end process and BPEL just for system-to-system integration? That makes sense for a pureplay like Fuego, but not for a core platform provider like BEA.
calls to remote services, but user-defined ?methods? of the activity implementation written using Fuego?s VB-like FBL script. Architecturally, that puts it closer to a workflow engine than to a BPEL engine. What?s even stranger is that BEA already has what looks to be a fine BPEL engine and tool in WebLogic Integration 8.1. OK, that?s strictly J2EE, and AquaLogic is supposedly ?platform-independent? (can that be right?), but still? I?ve heard (but don?t actually know) that the AquaLogic ESB is really WLI.