Oracle Fusion Middleware - Tales from The Trenches
Dr. Paul Dorsey, Dulcian, Inc.
The Oracle Fusion Technology stack is large and complex, encompassing many components. What are the most widely used portions of this technology stack? How successful have organizations been in bringing Fusion Middleware projects to production? A year ago, I interviewed various senior developers who were attempting to work with Oracle Fusion Middleware. This paper is a follow up to document what (if any) changes have taken place and what progress has been made since my original interviews in the Spring of 2008. I have attempted to summarize the experiences of some of the thought leaders in the Oracle community who have been working with Oracle Fusion Middleware “in the trenches.”
Introduction
Oracle has continued its acquisitions adding other pieces to the Application Development Framework (ADF) technology stack. After a year, JDeveloper has continued to mature. The 11g version is complete and near production as of this writing. So the questions remained:
· Is ADF maturing into a stable environment?
· Can we see the light at the end of the tunnel with respect to a productive Java EE environment that will not change drastically in the short term?
The people I spoke to last year have another year’s worth of experience so one would expect some level of optimism with respect to the future. Unfortunately, this was not the feedback that I received from the users. Rather than a consistent message of optimism and satisfaction with a rapidly maturing environment, there is a sense of frustration with an environment that is too complex. Unless you are very careful, it is difficult to ensure project success. As a consensus became clearer during the interviews, I explicitly asked interviewees about their confidence in ADF as a framework. Putting the responses together led me to conclude that if you had the “dream team” of noted experts working on the project, you would have a high probability of project success, but for organizations with rank and file developers, the chances of success were not good. Most of the people I interviewed agreed with this overall assessment.
Even my own organization’s experiences with ADF have been less than wildly successful. As data volumes keep increasing, we have needed to go back and refactor applications or they begin to experience terrible performance problems. As powerful as ADF BC is, it is possible for even experienced developers to inappropriately architect applications. This causes significant amounts of data transfer between the application and the database servers, resulting in unacceptable performance.
These problems should not be blamed on ADF. At the core of the problem is complexity of the Java EE technology stack. This environment evolved out of a culture of OO iconoclast expert developers insisting on open source alternatives and maximum flexibility of the architecture. This flexibility is also the greatest challenge associated with all Java EE-based architectures. Even though there are many different alternatives that can lead to developing a successful application, there are many more that can lead to failure. The entire Java EE environment is still the “Wild West” in terms of development.
Background
The Oracle environment can be grouped into three broad areas: the database, applications, and “middleware,” which includes the application server and all development products except Application Express. The tools included in the Fusion Middleware technology stack are as follows:
· Oracle Application Server (OAS) – being phased out in favor of WebLogic
· JDeveloper
· Oracle WebCenter
· Oracle Business Rules
· Oracle Business Process Execution Language (BPEL) and Business Activity Monitoring(BAM)
· Additional technologies being used to assist with development
Focus at Oracle has shifted somewhat from heavy reliance on the database technology alone to creating a first-rate application development environment. This change in direction has tremendous impact. For many years, the development side of Oracle has always taken a back seat to the DBMS. Many products have come and gone through Oracle’s lifetime occasionally having resources suddenly pulled from them leaving the user community completely bewildered. Oracle’s support for Forms and Reports was maintained as long as they served as the development tools for Oracle Applications. Since Applications are now shifting to the J2EE-based Fusion technology stack, support for Developer is quickly waning and has all but disappeared entirely for Designer. Thus organizations are encouraged to begin contemplating the use of the Fusion Middleware technology stack to support and maintain their Oracle-based systems.
Challenges in Using Fusion Middleware
In talking to many people from a variety of large organizations with very experienced IT professionals, retraining traditional Oracle developers or bringing in outside expertise to build on the ADF platform is very difficult and still often results in project failure. Even after several years of experience, many organizations failed to achieve the desired levels of productivity and were exploring options other than ADF. Oracle Application Express (APEX) continues to gain popularity because of its much lower learning curve. Although ADF is still better than anything else currently available in the Java EE environment, it still comes with a very steep learning curve making it a daunting prospect for organizations to use to develop their projects. At its current level of usability, for an organization to make the transition to ADF without significant onsite expertise or mentoring is a high-risk proposition at best.
The situation is not likely to change in the near future. Oracle continues to add components to the Fusion Middleware technology stack. Users transitioning into ADF should limit themselves to a small number of Fusion Middleware component products. Getting adequate support and mentoring is critical in successfully making this transition.
What do developers using Fusion Middleware think about it?
In preparation for the revision of my 2008 paper, I re-interviewed many of the same Oracle professionals about their experiences with Fusion Middleware after another year of working with it (or trying to). There was still general agreement from these experts, most of whom are consultants, that though the Fusion Middleware technology is of very high quality, organizations trying to build systems using it without some mentoring would be unlikely to succeed.
ADF BC was still favored over alternatives such as Hibernate or EJB3. Oracle’s overall offerings were viewed as significantly superior to those of its competitors. For IT professionals coming from Object-Oriented (OO) backgrounds, although they may not be happy with all of the available Oracle tool features, they were reasonably happy adopters of the technology and did not consider abandoning it in favor of any open source alternatives.
Fusion Middleware Component Usage
What is currently being used to develop applications? Last year, ADF BC, ADF Faces, BPEL, and OAS were the most widely used components of Fusion Middleware. JHeadstart, Oracle Business Rules and WebCenter were less popular. This year, WebCenter seems to have gained in popularity (it is widely perceived to be a much better product this year). Many people are using BI Publisher (but only because it was bundled with their application suite – no one seemed to think the high retail price tag was worth it). Interest in BPEL seems to have declined due to other products added that do some of the same tasks, providing further evidence of the continuing evolution of ADF.
Oracle Application Development Framework – Business Components (ADF
BC)
This is the most mature portion of Fusion Middleware. ADF BC provides the middle tier bindings that connect Java applications to the database. Some shops that have attempted to use ADF BC have either given up entirely or are looking for other alternatives. After listening to the experiences of others with ADF, some organizations have avoided even attempting to use this architecture and instead have built custom applications using architectures such as Oracle’s Application Express (APEX).
Oracle’s ADF BC has lent some amount of structure to the
chaos of Java EE.
ADF Faces
Those experimenting with JDeveloper 11g beta releases are quite happy with it and waiting for it to go production. Building rich UI web pages with 10g was difficult and 11g seems to have satisfied this need. This includes new components that extend those in ADF Faces.
Oracle Application Server (OAS)
The big news with the Oracle Application Server (OAS) is that BEA WebLogic is going to ultimately replace it. No one seems to be in a hurry to jump on this bandwagon. Most organizations are still staying with their OAS installations. Only one organization was using ADF with WebLogic and their experience was less than optimal. There were many bugs and Type 1 fixes needed since they were likely one of the first organizations to attempt this.
JHeadstart
Those using JHeadstart last year are still using it this year but I do not see any additional interest in using this approach among those not already familiar with the tool.
Oracle Business Rules
Last year, only one person I spoke to has attempted to use Oracle Business Rules and the project failed after a number of months. This year, I found one person successfully using Oracle Business Rules in a very unique application.
WebCenter
WebCenter users seem to be happier this year than last year. Although it is a very expensive product, organizations with licenses acquired as part of an Oracle Applications purchase seem to be satisfied with the tool.
BI Publisher
BI Publisher is still a very expensive product. Even those wanting to use it are not always willing to pay the high licensing costs.
Other Tools
Universal Content Manager (UCM) was being used by one of my interviewees but was not mentioned by anyone else.
Many were interested in learning more about the Identity Management Suite but I am not aware of any organization using this in development as of this writing.
What is the Overall Fusion Middleware development experience?
Whether you are an experienced Oracle Forms/Designer user or OO developer, the Oracle Fusion Middleware technology stack still involves a steep learning curve. After two years, some progress is being made. We may not yet be at parity with the productivity and speed of the old Oracle Forms development environment, but that gap is narrowing. Using an experienced team, familiar with the Fusion Middleware tools, will they be successful? The answer is a qualified “maybe;” however, the blame for this should not be placed on Oracle, but on the entire Java EE and Service Oriented Architecture (SOA) framework.
Application Performance
Application Server-to-client performance depends upon the amount of information moving back and forth. JavaServer Faces and ADF Faces are not always successful at minimizing the amount of information being transferred. For example, using ADF Faces, the first time that a page loads, a JavaScript library is also loaded. Each individual Faces page is not very small (50-500K without images). Increased use of AJAX-like components, logic, and validation, all running on the client result in larger and larger pages. For a high-efficiency web application, 10-second page refreshes are unacceptable.
Complex sets of AJAX components within a screen can also cause performance bottlenecks on the client side. Too much JavaScript in Faces components can have significant memory impact and consume sufficient CPU cycles to degrade performance. One of the interviewees mentioned this as an issue with the JDeveloper Faces 10.1.3 components.
If the bottleneck is being caused by the amount of information being transmitted over the Internet and the user has a slow connection, there is very little that can be easily done to fix this problem. In order to decrease the amount of information being transferred, it is necessary to re-architect the application, decrease the functionality, and remove many visual components to reduce the page size. The ADF Faces architecture may result in pages that push a lot of information to the client machine. If you are working in an environment where all of the client machines are equipped with high speed broadband Internet access, page size may not be an issue. However, in slower Internet environments, particularly worldwide, the performance may not be adequate.
ADF developers must be careful about limiting network traffic between the application server and the database. Using a “thick database” approach can help. Building applications the obvious way with ADF may result in performance statistics that often require additional application server hardware or refactoring. The thick database approach is still a hotly debated topic. Some organizations push as much logic as possible into the database, whereas others follow a database-independence approach, placing as much logic as possible into the middle tier. Although there are successes and failures using either approach, the thick database approach provides some protection against performance and scalability issues.
Care must be taken when using
The large number of network round trips between the
application server and the database is the main cause of performance problems.
When writing Java code, it is important to be fully aware of how
StateFUL or StateLESS Applications?
Traditional client/server systems involved a single database session per user and employed packaged variables for stateful development. Building stateful applications means that they can only scale to hundreds of users by buying additional hardware. Last year, most organizations were still building stateful applications. The industry has matured to build more stateless applications. High-performance web applications must be stateless, meaning that every request is completely independent.
Stateless applications built for thousands of users can be run using one database and one application server because sessions are only active while a user is performing a UI operation. Even with 1000 users, the actual number of simultaneous operations is usually no more than 10-20. A comparable application built using a stateful approach would require multiple databases (or one very large one) or at least a 2-node RAC. It would also require several application servers to handle the application overhead.
There is nothing inherently stateful or stateless about ADF technology. ADF supports either approach, but for web applications, the overhead associated with stateful applications must be taken into consideration in order to provide adequate performance. Using ADF BC to support logical UI transactions in a stateless environment entails additional round trips in order to have modified data persist in the database after each UI operation.
Hardware Requirements
The hardware requirements for Java EE (and ADF specifically) can be prohibitively expensive. A scalable application for many OO architects often means one in which performance problems can be solved by adding additional hardware. Even systems with 1000 users or less may require multiple servers to support this environment. One of the recent trends is to use a middle tier deployed on Virtual Machines (VM). This results in some cost savings and easier maintenance.
Using Service Oriented Architecture (SOA)
Some organizations attempting the Service Oriented Architecture (SOA) route have been successful in partitioning IT functions into Services. However, there is usually some amount of pain and suffering associated with the SOA approach. Many of the problems encountered seem to be political rather than technical. The ability of organizations to publish or consume Web Services can vary widely, even within the same organization. Individual IT groups are not always careful when acting as providers of Services. Firewall acceptances, business rule changes, and changed locations may occur without notifying all of the Service consumers. These changes can cause serious problems. Organizations using only a small percentage of SOA solutions may consume copious resources trying to maintain these systems in comparison with the rest of the organization’s IT structure.
Are Organizations Using Fusion Middleware?
The Oracle web development environment is still severely fragmented. No one solution, framework, direction, or architecture seems to have captured the imagination of large numbers of system architects, designers and developers. There is still not significant usage of Fusion Middleware (mainly ADF BC) in the broader Oracle community. In contrast, the APEX product, which has a significantly less steep learning curve continues to attract a large following, in spite of some of its functional and architectural limitations.
Although it is still maturing, Fusion Middleware is still very difficult to learn and use productively. Some components are significantly more expensive to use than others (WebCenter, BI Publisher) compared with the old Forms environment with much lower licensing costs and a more manageable learning curve. Initially, building an application in JDeveloper took about four times as long as in Oracle Forms but this gap is closing as we become more experienced with the new tools. ADF is a much more expensive environment within which to build and involves more complex debugging and deployment.
On the plus side, we can do things in ADF that were not possible in Forms. Users expect a much higher quality look-and-feel with customizable size, shape, color, etc. of screen elements and applications can interact with a host of external Web Services.
Despite these advantages and another year of experience, not only are most organizations not using Fusion Middleware, some looking at it decided not to even try and some who had been using it have abandoned it.
Conclusions
After a year, the overall picture of Fusion Middleware is disturbing. Organizations are frustrated, confused and unsure about which direction to take. Even though I stand by my conclusion that ADF is the best Java EE architecture available, it is still very difficult to learn, use and maintain. Organizations without expert help are likely to fail but ADF still seems to be a better alternative than total open source. ADF is becoming richer and more capable and with JDeveloper 11g , easier to build with. It still remains sufficiently complex that most organizations should be justifiably worried when contemplating using ADF for the first time on a project. ADF and Fusion Middleware still have a long way to go before it becomes the development environment for the rest of us.
About the Author
Dr.