With the advent of SOA and SOA -related technologies and standards, such as WSDL , BPEL, and, more recently, SCA and SDO, more and more application metadata (and just plain data) is externalized into XML . XML is used for:

• Flow definitions (BPEL).
• Interface definitions (WSDL).
• Component and assembly definitions (SCA).
• Data (SDO).

Business logic, however, largely remains written in Java. For many people, key strength of Java and Java IDEs has been very strong support for refactoring (other languages support refactoring as well, but in this blog I focus mostly on Java). In fact, in my view, refactoring made agile development possible; it finally combined design and coding activities into one continuous process.

Unfortunately, with more and more information going into XML files, benefits of pure Java refactoring are diminishing.

For example, with SOA technologies, an interface name could be used in several different places:

• WSDL file (probably in multiple places if we want to use naming conventions, e.g., in “portType“ and “service“ elements).
• BPEL (multiple places, e.g., in “import“ and “portType“).
• SCA component definition file.

So what happens if I want to change the name of an interface or rename an operation? Personally I am not aware of XML refactoring support in BPEL products (obviously, I have not tested all of them, so I might be wrong here) and I don‘t expect the situation to improve when SCA /SDO are added to the mix. For example, is SDO property renaming going to be supported? How will it work if I use XPath expressions against XML -backed SDO in BPEL ?

Now, dynamic APIs are nothing new, we‘ve been dealing with XML for quite some time now. However, the approach in Java has always been to map XML to statically defined classes and so the ripple effect from, for instance, renaming was somewhat contained (I know that I‘m simplifying here). With BPEL and SCA , the problem becomes more widespread.

Also, tools for working with these technologies are supposed to rely mostly on visual modeling and so their users are not necessarily J2EE developers. In fact, the idea of BPEL is to be able to change business process-related logic quickly and easily. The idea of SCA (among other things) is to be able to easily wire and assemble components together. I think that without refactoring, the ability to accomplish these goals could be impaired.

I just hope that tool vendors realize this risk; otherwise we‘re in for another round of “XML hell”.

BPEL can be used to implement workflow and business processes. In theory, BPEL is not tied up with Web services or SOA since all J2EE BPEL vendors support callouts to EJB , JMS or even POJOs in their BPEL implementations (BPELWS, BPELJ ). BPEL has some interesting capabilities, such as the support for asynchronous and long-running processes, transaction compensation, and integration with UI for human activities. But the main point of BPEL is really its visual nature, the fact that the BPEL flow can be modeled in a visual designer tool. If not for that, it would’ve been more efficient to provide the aforementioned capabilities in the form of yet another Java API . The fact that BPEL is “visual” should make it easier to gather requirements and communicate changes to business stakeholders. Some vendors even go as far as proclaiming that now a business analyst can change and optimize a business process without requiring the involvement of a software developer.

However, for any real-life system some logic would still remain in the Java code. At the very least, the Java code would have some kind of persistence support for data transferred by the BPEL flow. More likely, complex business rules, the ones that would be too unwieldy to implement in BPEL will also be coded in Java. Also, since BPEL does not have the reuse capabilities of an OO language, anything reusable will probably be coded in Java (although, a piece of reusable logic could also be implemented as a reusable BPEL subprocess).

So on one hand, BPEL should be pretty high level and the business process‘ activities (and, therefore services APIs) should be coarse-grained. But this will externalize only the most rudimentary logic of the system. Granted, this high level flow could still be useful if the goal is to integrate different (probably heterogeneous) systems, but if we want to use BPEL for its process modeling capabilities, this may prove insufficient. Devil is always in details and so most likely in real life business process changes or optimization will require changes to these complex business rules implemented in Java. In other words, no matter how we try, business people still need to work together with the developers, make sure that the use case are right, changes are thoroughly tested and so on.

On the other hand, implementing very complex detailed business processes in BPEL is probably difficult at best. Visual modeling approach has its natural limits and so at some point it will become much easier to fire up a Java IDE . I guess it is also possible to hand-edit BPEL XML code, although this probably won‘t be pretty either, using XML as a procedural programming language has its limits too.

So what is the right usage of BPEL ? Is just a Web services orchestration language or a general purpose business modeling environment?