- OSB to expose services and to create composite services
- BPEL for process and orchestration logic and for composite services
- Mediator to route and transform messages
- BPMN for process logic
- Human Task Service for human interaction
- Business Rules for (reusable) business logic outside your components
- Spring Context for programming logic in Java
In our project we were moving a composite service from OSB to BPEL because the code became too complex and too difficult to understand and maintain in the OSB flow. The service consisted of numerous calls to other services, loops, several transformations and relatively complex XPath expressions and a java call-out.
I did not want to put a java call out in my BPEL process, I rather have the Java code as a first class citizen in my sca composite. This way it is clear that there is java code in the composite and it can be traced in the console.
Moving the Java from OSB to the Spring context was very easy.
- First I removed all the static methods and refactored the Java class into a proper bean
- Then I renamed the methods, so I did not have overloaded operations in the web service and ran the unit tests again
- I created a Spring Context as described in the Oracle Documentation here
- Finally I wired the BPEL component to the SCA context
- I created assign and invoke activities in BPEL
- I ran the deployment scripts that I created for SCA composites
This whole exercise took me about 10 minutes. Granted it was a very simple Java class. There are numerous advantages of Java code: I can test the Java class without deploying it. Refactoring of methods, variables etc support in the IDE (JDeveloper) makes changing the Java code very easy.
I need to move more BPEL logic into Java code. This will improve my productivity, increases the testability of the service and makes it much easier to read, compared to the combination of XSLT transformations with XPath and assign statements. I tweeted about this notion and Demed L'Her warned about the lack of runtime visibility of Java code.
Java in SCA Spring context versus BPEL
Let's compare different requirements for both the implementation of the SCA component in Java or in BPEL:
| Feature | Java | BPEL | Explanation |
|---|---|---|---|
| Productivity | High | Medium | Refactoring is not supported in BPEL, if you want to change the name or namespace of the process, this is a lot of work. There is code completion for XPath in BPEL, this increases productivity considerably. |
| Maintainability | High | Medium | XML code is hard to read, the visual designer hides the implementation of assigns and transformations. |
| Testability | High | Low | BPEL can only be tested after deployment, Java can be tested outside the container. |
| Runtime visibility | Low | High | BPEL has flow and audit trail, so you can see exactly what happened in your process |
| Recoverability | Low | High | BPEL has a fault management framework that allows you to recover activities |
| Configurability | High | High | Configuration plans and properties for both SCA Spring Context and BPEL |
| Calling services | High | High | SCA offers easy access to services, no matter what the implementation of the component is, both Java and BPEL can easily call services |
Unfortunately there is no single good answer for all your problems. It really depends on the service and the logic that you need. In other words, it depends on the requirements you have with regards to functionality, visibility and recoverability whether OSB, BPEL or Java in a Spring context is the best solution for your composite service. But the SCA context makes calling services and thus creating composite services in Java a lot easier than it used to be.
Of course, the evaluation of the requirements is subjective: I have been programming Java since 1997 and am very used to the testing and refactoring capabilities Java tools offer. People with a more declarative coding background might prefer BPEL for that reason. I am very interested in other peoples' experiences with these aspects.
