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
(
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.
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
Making these connections incorrectly or inefficiently is the
leading cause of project failure with Java EE applications. Using
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
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
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
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
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
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
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.