The Path to Oracle Fusion
Fusion is the new hot topic in the Oracle community. Since 2005, Oracle has been on a $19 billion buying spree, acquiring some of the largest players in the enterprise application environment, including PeopleSoft (which had previously gobbled up JD Edwards), Siebel, Retek and others. As a group, these products represent a massive code base of some 200,000 database tables and several hundred million lines of code. If you are an Oracle Applications customer using the eBusiness suite, PeopleSoft, J.D. Edwards or Siebel, future releases of these applications will be built using Oracle Fusion Middleware. If you are not an Applications customer, Oracle Fusion Middleware is still likely going to be a significant part of your development environment.
I do want to be clear at the outset that Fusion Middleware represents the best development tools in the industry today. If used properly, the tool stack can be used to quickly and efficiently build web applications that are second to none. However, if used improperly, this same architecture can be used to waste millions of dollars and produce little to show for it.
In its quest to not impose a development philosophy on the user community, Oracle has left it up to each development team to determine the best way in which to use the available tools. Oracle is willing to provide tools to developers to enable them to build in ways that are very different from what I (or even anyone within Oracle) would recommend. This vast collection of tools makes it difficult to focus on and select a clear development direction.
At Dulcian, we have been building production applications with new release of JDeveloper. It has been amazing to observe the enormous advances in the tool over time. The newer core pieces of Fusion Middleware (like the BPEL engine) have been making similar progress. Other portions of the architecture (like the Oracle business rules engine) show promise, but should probably not be relied upon as mature products.
What exactly is Fusion?
“Fusion” is a word being used to describe a number of projects. When Oracle executives mention “Fusion” they might not even be referring to the same thing.
1. Oracle Fusion Middleware: Oracle has divided itself into three functional areas – the database, applications and the “middleware” which is everything else (application server and all development products). Fusion Middleware refers to the products that the Oracle development tools organization distributes. Therefore, the term “Fusion Middleware” includes the following:
· Oracle Application Server (OAS)
· JDeveloper product suite
· Additional technologies being used to assist with Oracle internal application development, specifically Oracle’s BPEL and its business rules engine.
· Support for mainstream development that Oracle will not use for internal development, such as Toplink and EJB3 support.
· Other tools that are still actively supported such as Developer and Designer
· Smaller niche products like Toplink/Spring Framework integration
Oracle Fusion Middleware is also a marketing term which refers to the tools Oracle is using to build internal applications (that is a much smaller subset of tools). The challenge for developers is to pick and choose the parts of Fusion Middleware that are relevant to their development and integrate them into a development architecture.
2. Project Fusion: This term refers to Oracle’s next generation of enterprise application software, drawing heavily on existing products and attempting to create the ultimate enterprise application product. Oracle recognizes that this effort will require a number of years to complete. This effort will use Oracle’s e-Business Suite as the core database design. Functionality from acquired products will be added to e-Business on a case by case basis. Once Oracle e-Buisiness suite is converted to the new development architecture (described below) and probably some critical functionality from PeopleSoft, JD Edwards and Siebel are added, then Oracle will be able to declare that V1 of Project Fusion is complete. It will then evolve in an orderly fashion as new features are added. The migration path from PeopleSoft, JD Edwards and Siebel will be impossible to automate, probably expensive and difficult, but ultimately organizations will be driven to migration. Oracle cannot apply the same resources to all of the different technology stacks indefinitely. The V1 release of Fusion is scheduled for 2008.
3. Fusion Versions of Existing Application Suites: As Fusion Middleware matures, Oracle will shift all new development into the Fusion Middleware technology stack. In the next 1-2 years, there will be significant new development in the PeopleSoft, JD Edwards and Oracle’s e-Business suite products using Fusion Middleware.
Fusion Development Technology
Fusion Middleware encompasses a number of products with two main goals:
1. To support Oracle’s internal development, both for Project Fusion and new development of Oracle’s core applications from e-Business, PeopleSoft and JD Edwards.
2. To support web developers, particularly (but not exclusively) those working in a Java/SOA environment.
To achieve the first goal, Oracle is evolving a particular development architecture and methodology, built to support a very large, complex development effort. Oracle must be able to build applications to support some of the largest and most complex organizations in the world, integrating software created by different teams over several decades. This includes several hundred thousand database tables, millions of lines of code and a few thousand developers.
The development architecture to support this project will have to be of the highest quality and sophistication but may not be as appropriate for smaller development projects. Specifically, Oracle must rely heavily on Service Oriented Architecture (SOA). SOA is designed to support integration between disparate systems connected through published APIs (services) which allow the systems to communicate and interact. SOA-based architectures typically produce systems that are slower than traditionally built systems because they are usually implemented using technologies such as Web Services, the use of which has some significant performance implications. Architectures that may be necessary and appropriate for Oracle’s internal use may add unnecessary complexity and overhead to more traditional applications.
It is important to understand what portions of Fusion Middleware are being used internally by Oracle Corporation. These technologies must function efficiently. Any bugs encountered will receive the highest priority. Oracle is relying too heavily on the success of its applications to allow major bugs to exist in its development technology stack.
Portions of Fusion Middleware that are not part of the internal development effort exist because there is a market for them. If the market for these products dries up because the industry moves in a different direction, Oracle’s support for these tools will be in direct proportion to the number of customers still using those products. Oracle’s treatment of the Designer and Developer technology stacks is illustrative of this situation. Although Oracle will continue to support users and fix critical problems in these products for the foreseeable future, there are few resources being applied to these products to create new functionality. A few years ago, Oracle dropped support entirely for client/server functionality in Oracle Forms in order to avoid the need to continue supporting both client/server and web deployment of the product.
Which portions of the Fusion technology is Oracle using?
What is the subset of the Fusion stack that Oracle is using internally for development? Answering this question is more difficult than you might think since the Fusion architecture itself is still evolving. The Oracle Applications development team is still working to create an architecture that will allow users to customize applications more easily over time. The solution to this problem is still in flux.
The technology Oracle will use to build “Project Fusion” includes:
1. The Oracle DBMS: It is clear that the Oracle DBMS will be a big part of Project Fusion. The application environment is so complex and there are such demanding performance requirements that it is not possible to build applications without some reliance on server-side code. Even within Oracle, the question of how much reliance should be placed on server-side code is still being debated. Many of the Fusion architects come from an OO environment which includes a bias against placing business logic in the database. Others who recognize that placing complex logic in the database provides much faster performance than placing this code in the middle tier want the large complex batch routines to be handled in the database. It is probably impossible for Project Fusion to be deployed in a completely database-independent way, which means that some significant portion of the logic must reside in the database.
2. The Oracle Application Server (OAS): OAS is not mandatory for running Fusion applications, but it makes doing so much easier. You can deploy Fusion Middleware applications to any Java EE (J2EE)-compliant server. Oracle certifies most of the more popular servers such as WebSphere. However, if you use other application servers, deploying applications can be more difficult since you may need to create ANT scripts by hand. Days, if not weeks, may be needed for debugging and ultimately deploying a system. If applications are built using JDeveloper, deployment is literally a one-button click operation. Therefore, unless there is a strong political motivation for using another server, OAS should be used as part of your Fusion solution.
3.
Oracle’s Application Development Framework (ADF). ADF drives the core application development
of UI screens and bolts them to the database. ADF Business Components (
4. The Oracle BPEL engine. BPEL is a Java-based process flow language. Oracle is using BPEL to help manage the SOA architecture of Fusion. Oracle has a very nice graphical tool set to support BPEL process implementation. However, BPEL itself has some problems as a technology. Because it is middle tier-based, each node will usually require a round trip to some data source (either through a database connection or a web service. This means that database-intensive BPEL processes can run hundreds of times slower than equivalent processes built in the database. Second, BPEL uses a state transition engine method of describing processes. As a result, there are single BPEL processes in production that have 5,000-10,000 nodes. A 5,000 node diagram makes for wonderful wallpaper, but is rather hard to read and maintain.
5. Oracle Business Rules engine. The Oracle business rules engine is still evolving and should not be considered production ready. It is not yet clear how this part of the architecture will be used.
Things that worry me about Project Fusion
We may not care very much about Oracle Project Fusion. After all, our main interest is that Oracle will be building tools for internal use that we can take advantage of. However, knowing about the development team debates that Oracle is currently having and the debates they are likely to have going forward may give us insights into how the Fusion Middleware tool suite will evolve.
Oracle really needs to build Project Fusion from scratch – but they won’t
The Oracle e-Business Suite is a bloated 12,000 table architecture built using circa 1985 thinking. However, compared to the even more bloated, poorly designed data architectures of JD Edwards and PeopleSoft, the e-Business suite looks fantastic. To be fair, the SAP architecture is probably the worst in the industry, so comparatively speaking, Oracle is not in bad shape.
Project Fusion will take the e-Business architecture and add functionality from PeopleSoft, Siebel, and JD Edwards. The basic data model for Fusion will use the e-Business data model as its starting point. All Oracle has to do is convert the applications to use Fusion Middleware technology and extend the tool suite to include key functionality from other products. Such a strategy guarantees success, but doesn’t mean that we are really getting a brand new product.
The irony is that working on such an antiquated architecture means that Oracle will probably spend more on “sprucing up” e-Business than they would spend if they threw it out and started from scratch using a smaller, more flexible data model that is built at a higher level of abstraction.
What this means to us is that Fusion Middleware is not going to focus on modeling and architecture tools. Notice that there is no data modeler that rivals Designer in the JDeveloper suite. It also means that the main focus will be on a code-driven development environment. If you are a modern OO shop and want a tool set to support Agile development, you will be thrilled with the tools. If you are a 100% Designer generation shop, you will be disappointed.
SOA Focus
Oracle has completely jumped on the SOA band wagon (at least publicly). This means that major system portions will be compartmentalized into services. For a huge code-based system, such compartmentalization is essential, as long as you can manage the number times such services are called. Even moving from server side code to a BPEL process flow means that processes will run about a hundred times slower. Calls to web services, and similar cross system communication can be orders of magnitude slower still. Taking a major system and using standard SOA technology can result in systems that work fine in a test environment, but do not scale to realistic production use.
SOA “thinking” means simply compartmentalizing the code and exposing functionality through APIs. No one will argue against such an approach, but structured programming (now called SOA) is not a new concept. However, placing program units all over the globe and expecting to be able to call from one to another thousands of times a second over a standard internet connection, is unrealistic with today’s technology.
What this means to us is that if we need to have major portions of our systems talk to each other, it will be easier than in the past, and performance will be better than what we currently experience. However, we need to be careful not to inappropriately use SOA tools for complex database routines. One organization that tried this approach ended up with a month end routine that took 26.5 years to execute on a 2-computer (UltraSparks with 64 CPUs each) RAC configuration. If Oracle “over SOAs” project Fusion, they will be doing lots of rewrites prior to delivery.
OO Architects seem to be running Project Fusion
OO architects view things differently from database-centric architects. OO people tend to think of the database as persistent storage. They do not lean towards server side code. For Project Fusion, there was actually discussion surrounding the feasibility of changing all PL/SQL to Java in the middle tier. The main reason the idea was rejected was that there exist millions of lines of PL/SQL code. Rewriting it all would have taken too long. The answer SHOULD have been that it was a stupid idea in the first place. Complex, data-centric code can run hundreds (if not thousands) of times faster in the database. Our experience across several projects has been that refactoring code from middle tier-centric to database-centric (place as much as possible in server-side code) results, on average, in the following advantages:
1) more that a 50% reduction of the total lines of required code
2) more than 10 times improvement in performance
3) more than a 99% reduction in network traffic
4) more than a 50% reduction in server-side activity (a few well written routines consume fewer resources than thousands of inefficient retrieves)
Many Oracle Corporation developers recognize that server-side development is critical to the success of Project Fusion (including Thomas Kurian), but there are others who would make Project Fusion database-independent, if given the opportunity.
What this means for the rest of us is that we will have great tools for placing logic in the middle tier, but probably only basic support for server-side objects. For example, if you want to use a server-side function that returns an object collection, there is no direct support. You have to wrap the function in a view. Writing the view is not a difficult task, but it does demonstrate the lukewarm support for server-side development.
It also means that Oracle’s tutorials do not demonstrate good server-side development practices. Everything highlights what can be done using a middle tier-centric approach. As a result, I believe that the tutorials don’t demonstrate the best practices that effectively use the database.
Oracle’s Application Development Framework
Oracle’s Application Development Framework (ADF) is a Java EE (formerly J2EE)-compliant development environment. It is the development core of Fusion Middleware. ADF is a very rich framework. It includes a wide variety of tools and libraries. Its origins can be traced back to 1999 with the first release of Business Components for Java (BC4J) in JDeveloper 2.0. BC4J set the logical foundation for what has become the richest data persistence framework on the market. Though its logical architecture has not significantly changed since the beginning, it has undergone several complete rewrites and has only now matured to the point where developers can feel safe that they will not need to rewrite their applications with the next release of JDeveloper.
BC4J eventually changed its name to ADF Business Components (
This is a complex, very rich environment that will take some getting used to. I strongly recommend that you start building some small applications using the framework to begin to explore its complexities.
ADF is not just for Fusion customers. This is the best persistence framework on the
market. Though OO professionals tend to
avoid it because it is produced by a database company and not open-source, it
is an extraordinary product. One of the main causes of Java EE project failure
is failing to build a good persistence framework. Many shops will insist on building their own
framework which usually performs poorly, doesn’t scale, and is difficult to
extend. Oracle has spent millions of
dollars making
Most recently, Oracle has turned its attention to user interface
development. The Java Server Faces (JSF)
architecture has been extended and seamlessly integrated with
Getting started with ADF is also much easier than it used to
be. There are lots of great resources
online and two books can help as well. The Oracle JDeveloper 10g Handbook
by Roy-Faderman, Koletzke and Dorsey is the best resource for learning the
depths of
Getting there: Project Fusion
If you are a current PeopleSoft, JD Edwards or Siebel customer, you don’t need to jump to Project Fusion. Oracle recognizes that they can’t easily migrate everyone to project Fusion. It is going to take a long time. As a result, Oracle is committed to maintaining each technology stack. At some point, more resources are going to be put into Project Fusion than the individual tech stacks and Oracle will gently encourage you to move to the new stack, but I sure that they will not pull the plug on you for many, many years.
However, Project Fusion will be the flagship product suite and, over time, a greater percentage of resources will be devoted to it. Eventually, you will find yourself on an ever-shrinking island with non-evolving software. I don’t think you will start feeling that pain for about five years, but the day will come.
In the meantime, there are changes you should make. First, if you are not already an Oracle shop, you should become one. Eventually you will need to be running on an Oracle database. Typically, it takes an organization many years to become a mature Oracle shop. Second, you should shift to the Oracle Application Server (OAS). This is less urgent than moving to the Oracle DBMS but will eventually make your life significantly easier. Finally, if you are getting new modules, you should try to invest in e-Business, if possible. Taking these steps will make the transition to Fusion much easier.
Conclusions
Fusion Middleware is a first-rate technology stack, enabling developers to quickly and efficiently build and deploy sophisticated web applications. Oracle has worked very hard to create the right development environment for Project Fusion. Project Fusion should start from scratch but will probably not use the database as well as it might, and may push the SOA direction farther than it should. This may impact the overall ability of Oracle to deliver “the ultimate Project Fusion” someday, but does not diminish the quality of Fusion Middleware as a development architecture. Fusion’s weakness in the architectural design/code generator tools may force Fusion Middleware to be an even better development environment than it would be if using a less developer-centric approach. For those of us building systems,the resulting web development environment is too good to ignore.
About the Author
Dr.