Following common Software Engineering practices in Oracle SOA products
When working with “traditional” 3rd Generation Languages, there are lots of tools and frameworks that help you refactor, test, and analyze your code. Following best practices like Continuous Refactoring, Unit Testing/Test Driven Development (TDD), Root Cause Analysis, and Static Code Analysis is supported very well.
But when you work with SOA products like Oracle SOA Suite or Oracle Service Bus, following such best practices is harder. You don’t use 3GL code for all the aspects of your software. Instead, you create specialized (XML) artifacts for the different aspects, often using graphical editors. Still, these artifacts have internal structures and dependencies that need care (refactoring). And still, you create software that is supposed to fulfill requirements (so you want to test and analyze it). But the tool support in Oracle SOA Suite and OSB is very limited. In this post, I will analyze the current situation.
Continuous Refactoring means to continually restructure your code and adjust your design to keep it maintainable (readable, testable, evolvable). Unfortunately, Oracle SOA products only have very limited refactoring capabilities. You can hardly even change the names of variables and services without breaking dependencies. Let alone more complex modifications like extracting parts of your BPEL process into a separate process.
SOA Suite features built-in support for unit tests, while OSB doesn’t. The SOA Suite unit test framework is helpful, but is limited in its assertion capabilities. For example, you cannot assert that a references service is not called, and you cannot use dynamically calculated values in your assertions. TDD is hardly possible because you need to deploy your composite application in order to run its unit tests, which is very time-consuming.
Root Cause Analysis
If there is a problem, you should not just fix its symptoms, but analyze and remedy the root cause. Debuggers are a valuable tool to do just that. The SOA Suite doesn’t come with a debugger, while OSB does. Both feature message tracing.
If you use Static Analysis, your code is automatically checked for potential problems. Such problems can range from simple style violations to real bugs. Both SOA Suite and OSB have only rudimentary support for analyzing your code, not much more than syntax checking. If you want to enforce development guidelines, you need to employ custom solutions (like my Schematron-based approach I will explain in a different blog post).
While type safety is a built-in feature of strongly-types languages like Java, you don’t have much support when you work with XML messages. Even though interfaces based on WSDL and XML schema have well-defined input and output parameters, the design-time tool support for ensuring correct parameter values in Oracle SOA products is rather poor. If you change the signature of a method or the package name of a class in a 3GL, the compiler will tell you which dependencies you need to adjust so things don’t break. If you change an operation name or a namespace in a WSDL (remember, we don’t have refactoring capabilities), you don’t have much support either. You need to be very careful and manually adjust many places, for example in your OSB proxy flow. If you are not, your XQuery expressions might just stop returning the desired values. Because you don’t have anything like a compiler, good runtime test coverage is essential. Using Validate actions you can assure that messages comply with a certain XML Schema.
Much room for improvement
Here’s the result of my little non-scientific evaluation:
To sum up, my top three wishes for future Oracle SOA products are:
- Support for fast and more flexible (unit) tests,
- Improved Refactoring capabilities (supporting renaming of things like service operations or namespaces would be a good starting point)
- Design-time support for type safety
Picture: Some of my real-world Tools.