Oracle Fusion Middleware - Tales from The Trenches

 

The Oracle Fusion Technology stack is large and complex, encompassing many components. Some parts are free or nearly so such as JDeveloper, whereas other portions carry large licensing fees (WebCenter). What portions of the Fusion Middleware stack are organizations really using? How have their projects fared so far? This presentation will discuss the results of a number of projects from organizations that are using one or more parts of the Fusion Middleware technology stack.

For this paper, I conducted a semi-formal survey by talking to various project managers, system architects and developers about their use of Oracle Fusion Middleware technology and their current projects.

Introduction

All over the Oracle community, there are anecdotes of both wild successes and horror stories of unsuccessfully attempted Fusion Middleware projects.  Fusion Middleware is a very large and complex technology stack. It includes many components, some of which compete with products outside of the Fusion Middleware space and, in some cases, even with each other. There is also some confusion about what exactly “Fusion” or “Fusion Middleware” is. A few years ago, I coined the term “Fusion Development Technology” (FDT) to refer to the parts of Oracle Fusion involved in application development. Some of the core portions of Fusion Middleware are now stable, such as the Application Development Framework - Business Components (ADF BC) while others have still not stabilized, such as the core ADF Faces Controller which has been replaced in the JDeveloper 11g release. There is also a great deal of uncertainty about how the Oracle acquisition of BEA will affect the Fusion technology stack.

What exactly is this technology stack? How can you leverage its advantages? As it matured, JDeveloper has tried to support a wide view of building applications. Although Fusion uses Oracle’s ADF BC to support connections to the database, JDeveloper also supports TopLink (another Oracle acquisition) as well as Enterprise JavaBeans (EJBs) and EJB3.

Given all of the parts of Fusion Middleware, what environment should you use to build web applications? Is it a good idea to build in exactly the same way as Oracle is building its internal applications? The simple answer is “Yes.” However, this development environment has a very steep learning curve if you need to go beyond the framework’s standard capabilities.

Background

Over the last few years, Oracle has been on a buying spree, acquiring some of the largest players in the enterprise application environment. As a group, these products represent a massive code base of database tables and several hundred million lines of code. As first written in the 2007 Q1 issue of Select, “Fusion” is a word being used to describe a number of things:

Oracle Fusion Middleware: Oracle has divided itself into 3 functional areas – the database, applications and the “middleware” which is everything else (application server and all development products except Application Express). Therefore, the term “Fusion Middleware” includes:

·         Oracle Application Server (OAS)

·         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

 

Project Fusion: This was the original term referring to the next generation of enterprise application software, which encompasses the ground-up development of an entirely independent suite of applications, drawing heavily on existing products and attempting to create the ultimate enterprise application product.

Fusion versions of existing application suites: As Fusion Middleware matures, Oracle is shifting all new development into the Fusion Middleware technology stack. In the next few years, there will be significant new developments in the PeopleSoft, JD Edwards, Siebel, and Oracle’s E-Business suite products using Fusion Middleware.

Oracle is clearly relying heavily on Fusion technology for its future success. Oracle has determined that creating a first rate application development environment is its core critical success factor. This decision has tremendous impact. For two decades, the development side of Oracle has always taken a back seat to the DBMS in terms of resources. 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. Nevertheless, it will still take several years for Fusion to get up to speed, even with unprecedented support for the Oracle Fusion technology stack.

Challenges to Using Fusion Middleware

In response to my ODTUG 2008 Fusion Symposium keynote presentation, three attendees commented that I was too much of a blatant “rah rah” supporter of Oracle ADF. In response, I would point out that even though Oracle’s ADF framework is indeed the best Java EE framework in the industry today, for many system development teams, it is still impossibly complex. 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. These organizations failed to achieve reasonable levels of productivity over the last year and were actively looking for options other than ADF. The APEX Symposium at ODTUG Kaleidoscope 2008 conference attracted more attendees than the Fusion Symposium. Even though ADF is better than anything else 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 likely to get worse before it gets better. Oracle is still adding functionality and components to the Fusion Middleware technology stack. Until all core functionality has been completed, Oracle will not turn its primary attention to significantly simplifying the overall system development experience. In the meantime, 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.

Despite the confusion, complexity and disparity of results, Fusion Middleware continues to evolve rapidly. For the last five years, we have lived in interesting times, are still living in interesting times, and will continue to do so for the foreseeable future. This article attempts 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.”

What do developers using Fusion Middleware think about it?

In preparation for this article, I interviewed a number of thought leaders in the industry about their experiences with Fusion Middleware. The feedback I received is probably somewhat more optimistic than the views of typical development teams trying to build applications in this environment. There was 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.

There was a general consensus that, in comparison to other Java EE offerings, the parts of Oracle Fusion Middleware being used are clearly best-of-breed. ADF BC was favored over alternatives such as Hibernate or EJB3. Similarly, ADF Faces was preferred to standard Faces as Oracle’s implementation of BPEL was highly praised. 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 would not consider abandoning it in favor of any open source alternatives.

Fusion Middleware Component Usage

There are so many parts of Fusion Middleware that few organizations have the expertise or need to use all of them. From my interviews, the parts being used most frequently and successfully are as follows:

·         ADF BC

·         ADF Faces

·         BPEL

·         Oracle Application Server (OAS)

 

Other parts of Fusion Middleware that are less frequently used include:

·         JHeadstart

·         Business Rules

·         WebCenter

The feedback for each will be discussed in turn.

ADF BC

Oracle’s original Business Components for Java (BC4J), first released in 2001, is now called ADF BC. This is the most mature and stable portion of Fusion Middleware. It has been rewritten several times since its release and is now an excellent product. ADF BC provides the middle tier bindings that connect Java applications to the database.

Making these connections incorrectly or inefficiently is the leading cause of project failure with Java EE applications.  Using ADF BC helps to significantly reduce the chance of project failure.

ADF Faces

ADF Faces is Oracle’s implementation of Faces components. It is one of the newest and most rapidly evolving parts of the Fusion technology stack. With ADF Faces in JDeveloper version 11g, Oracle has added true Ajax functionality.  The Controller layer is being completely replaced in the 11g release.

A number of the people to whom I spoke are using it despite its continued rapid evolution. This should give us some confidence that ADF Faces is becoming a very good, productive development environment. Developers tend to quite satisfied with this part of the Fusion Middleware technology stack.

Oracle Application Server (OAS)

This is the oldest and most stable portion of the Oracle architecture. It has been widely used. However the recent BEA acquisition by Oracle raises many questions about the future of this technology.

Business Process Execution Language (BPEL)

Oracle’s implementation of BPEL is also quite well appreciated by the relatively small number of people using it. It seems to display a maturity beyond what would be expected of such a new technology.

JHeadstart

This product is still used mainly by Oracle Consulting; however, there are a few independent users, particularly those with Oracle Forms and Designer generation experience. IT professionals used to using Oracle Forms and Designer are often comfortable with JHeadstart’s features and capabilities and are able to be productive quite quickly. The downside to using JHeadstart is that reliance on this tool tends to preclude learning about the entire Java EE framework. Organizations that relied heavily on Designer generation frequently had poor Oracle Forms development skills which made any post-generation modifications very difficult. These same weaknesses may persist when using JHeadstart.

Oracle Business Rules

Only one person I spoke to has attempted to use Oracle Business Rules and the project failed after a number of months. I was unable to get any other feedback about this tool. My preliminary review of the product did not inspire me to look further.

WebCenter

Early releases of this product were not well received. The tool was missing significant functionality and was buggy and inconvenient to use. Other, better open source utilities were available. Currently, the product seems to have overcome these issues and those using it are quite satisfied. The biggest drawback currently seems to be the hefty price tag (up to $50,00/CPU). However, many government and educational institutions with large Oracle contracts may be able to negotiate a better pricing model, making WebCenter an attractive product for their organizations.

BI Publisher

There is a lot of interest in BI Publisher, particularly from organizations still using Oracle Reports. However, there is some concern that it is a less capable alternative. Some users needing extensive reporting systems are turning to other open source alternatives. Also, like WebCenter, the significant licensing costs of BI Publisher (up to $30,00/CPU) make it an unappealing option for smaller organizations.

What is the Overall Fusion Middleware development experience?

Whether you have an Oracle Forms/Designer or OO background, the Oracle Fusion Middleware technology stack still involves a steep learning curve. Without some type of expert mentoring, it is very difficult to build successful production systems. The development environment is not likely to get any simpler going forward. Although the ADF framework is better and more stable than previous incarnations, some system architects felt deceived by promises of an easy transition from previous environments. However progress is being made and, although most users report that we are not at parity with the productivity and speed of the old Oracle Forms development environment, that gap is narrowing.

If you have a senior 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. Little attention has been paid to the issues of making web services work effectively and the overall network performance of systems deployed over the Internet.

Using Web services in a production environment often requires overcoming some significant political and technical challenges with regard to firewalls and network overhead, resulting in performance problems. In my experience, even though a particular Web service may execute consistently in under one second (at the service provider’s location), the total time for the Web service call may take up to one minute. Somewhere in the depths of the Internet, there is a delay. When creating applications in the Fusion Middleware space, performance considerations are critical success factors.

Handling Application Server to Client Network Traffic

Application Server-to-client performance depends upon the amount of information moving back and forth. JavaServer Faces in general, and ADF Faces in particular, are not especially careful about minimizing the amount of information being transferred. For example, using ADF Faces, the first time that a page loads, a 200K library is also loaded. Each individual Faces page is not very small (50-500K without images). The more Ajax-like components that are included, as well as more logic and validation running on the client, the larger the pages become. We have all encountered slow downloads from Internet websites; however, in a high-efficiency web application, 10-second page refreshes are unacceptable.

It is also possible that complex sets of Ajax components within a screen can 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 does not limit the information that is pushed 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.

Handling Application Server to Database Network Traffic

When using the Oracle Application Development Framework, developers must be careful about limiting network traffic between the application server and the database. It is possible to minimize this traffic using a “thick database” approach. Building applications the obvious way with ADF may result in performance statistics that often require additional application server hardware or refactoring.

Care must be taken when using ADF BC to craft complex application components. Using the example of a tree control, if not carefully architected, the resulting application can encounter severe performance problems because of the individual population of each ADF BC component. In my organization, our first attempt to create a tree component without carefully managing the underlying queries resulted in a 17-minute tree refresh time.

In general, the leading cause of poor performance in web applications is the large number of network round trips between the application server and the database. When writing Java code, it is important to be fully aware of how ADF BC activity can generate database round trips. These round trips must be minimized in order to achieve good performance results. ADF BC can be helpful in doing this if developers are skilled. However, unskilled developers attempting to create their own frameworks outside of ADF BC tend to be sloppy about minimizing these round trips. ADF BC can be used, in large part, to manage the middle tier automatically and make it easier to create good functioning production applications.

Developing StateFUL or StateLESS Applications

Traditional client/server systems involved a single database session per user and employed packaged variables for stateful development. High-performance web applications must be stateless, meaning that every request is completely independent. Based on my interviews, the majority of web applications are still being built as stateful. It is surprising that many OO developers are building stateful applications since they should be more aware of potential performance issues. Building stateful applications means that they can only scale to hundreds of users by buying additional hardware.

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. Oracle’s ADF BC does not automatically help to reduce network traffic between the application server and the database. 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.

Are Organizations Using Fusion Middleware?

The Oracle web development environment is severely fragmented. There seems to be no single framework, direction, or architecture that is capturing the imagination of large numbers of system architects, designers and developers. The IT professionals interviewed seemed to confirm my sense that 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 and is attracting a large following, in spite of its functional and architectural limitations.

Organizations that are using the core parts of Fusion Middleware are building applications successfully and more easily than those using any other alternatives in the J2EE environment. 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. This gap is closing and my sense is that we are now at about a 2-1 ratio of productivity per screen in JDeveloper vs. Forms. ADF is a much more expensive environment within which to build and involves more complex debugging and deployment.

We are now able to 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. Also, applications are now expected to interact with a host of external Web Services.

Conclusions

The Java EE environment is both enormous and complex. It encompasses many components, any one of which, if not properly handled, can cause catastrophic project failures. Fusion Middleware including ADF is currently by far the best alternative for building systems in this environment. Oracle has made great strides in lowering the barrier for entry, improving the functionality and development efficiency possible. The main remaining downside is the management of network traffic and database roundtrips. Once this hurdle is overcome, we will be well on our way to creating web applications with full functionality quickly and efficiently.

About the Author

Dr. Paul Dorsey is the founder and president of Dulcian, Inc. an Oracle consulting firm specializing in business rules and web-based application development. He is the chief architect of Dulcian's Business Rules Information Manager (BRIM®) tool. Paul is the co-author of seven Oracle Press books on Designer, Database Design, Developer, and JDeveloper, which have been translated into nine languages as well as the Wiley Press book PL/SQL for Dummies.  Paul is an Oracle ACE Director. He is President Emeritus of NYOUG and the Associate Editor of the International Oracle User Group’s SELECT Journal.  In 2003, Dr. Dorsey was honored by ODTUG as volunteer of the year, in 2001 by IOUG as volunteer of the year and by Oracle as one of the six initial honorary Oracle 9i Certified Masters.  Paul is also the founder and Chairperson of the ODTUG Symposium, currently in its ninth year.  Dr. Dorsey's submission of a Survey Generator built to collect data for The Preeclampsia Foundation was the winner of the 2007 Oracle Fusion Middleware Developer Challenge and Oracle selected him as the 2007 PL/SQL Developer of the Year.