In a previous blog post (http://ig.obsglobal.com/2013/09/mind-shift-necessary-when-adopting-oracle-fusion-middleware-part-1/), I talked about the how, with a slight adjustment, we can apply most SOLID principles to Oracle Fusion Middleware design and development. I also alluded to a third hurdle, which is working with limitations.
Working with Limitations
Oracle Fusion Middleware is a package of technologies packaged together into a product. The primary technologies in this package are ADF (Oracle’s implementation of Java Server Faces) and SOA, which incorporates the XML based Business Process Expression Language (BPEL). ADF is traditional Java development and, like with any framework, there are limitations, so there is no real mind shift necessary here if you are used to a traditional development language such as Java. SOA, on the other hand, is not a traditional development language; in fact, I’ve heard some describe it as a configuration script. That’s a little harsh and the reality is that it lies somewhere in between, but a knowledge of the underlying technologies used to implement BPEL definitely helps. This would include XML, XML Schema’s, Java, JDBC, JCA, and Queues to name a few. I’m not going to talk about all the limitations, but I will talk about two that had an impact on our initial designs.
Transactions and Parallelism
Those familiar with multi-threaded development will understand the advantages of breaking up a large unit of work into smaller parallel units of work. One of the limitations of the Oracle Fusion Middleware technology in the BPEL layer is that while parallel processing is possible, that ability is not feasible when transaction support is required. This caused a fundamental issue with our initial design that necessitated a redesign of the entire solution. One option is to use compensation handlers to effectively create your own transaction and rollback logic. Unfortunately this can be prohibitively expensive from a development effort perspective. Another more practical solution is to re-evaluate why you are attempting to process such a large unit of work. This really speaks to an application design issue. Much like designing a method, an application shouldn’t be designed to perform large units of work.
Process/Thread Configuration and Limitations
Above we talked about multi-threaded development and the desire to have parallel units of work. The SOA framework includes a configurable limit on the number of threads available to all instances. However, what is not immediately clear is that synchronous instances take precedence over asynchronous and, therefore, any expectations of performance in asynchronous instances cannot be guaranteed. Understanding these limitations and the requirements for configuration of the maximum thread pool can and will influence design decisions. Units of work with expectations for minimum performance guarantees shouldn’t be performed in an asynchronous manner and the decision to do so should be re-evaluated.
I hope that I’ve provided a few examples in these blog posts of how a traditional developer can, with a small shift in thinking, comfortably develop Oracle Fusion Middleware applications. Viewing services as objects, understanding and working within the limitations of the framework, including the effects on design, are critical to success. The seemingly daunting process of adopting to a new and complex technology represented by Oracle Fusion Middleware is a lot simpler with a slight change to the way we think about them.