Using Fusion for Custom Application Development
Dr. Paul Dorsey, Dulcian, Inc.
Yalim Gerger, Gerger Consulting
Oracle’s Fusion Middleware includes a variety of tools that
can be used to build systems. Fusion Middleware itself is a marketing term. A
coherent definition of what Fusion Middleware actually is might be “all
development-related products under the control of Oracle’s Development Tools
organization.” As a result, a wide range of tools were included, some of which may
not belong together such as JDeveloper and the legacy products Designer and
Developer. What comes to mind when discussing Fusion Middleware is all of the
“new stuff,” some of which is very new (like Oracle Business Rules) and some of
which has been around for many years (like
The Parts of Fusion
The Oracle development team is still refining its architectural vision. That said, there do seem to be some products within the Fusion stack that to which Oracle is committed, and that can be counted on as safe and appropriate for custom development. Which of the parts of the technology stack will actually be used, and how they will be used, is still in flux.
Simply because Oracle is using a tool for the massive internal Project Fusion development effort does not necessarily mean that your organization should use these same tools for development. Project Fusion is an atypical project. It is a larger, more complex development effort than any but the largest Fortune 50 or government organizations are likely to ever undertake.
Oracle’s entire architecture is built using a Service Oriented Architecture (SOA) backbone, designed to support inter-system connectivity which may not be appropriate for standard application development. Many people have the mistaken impression that because this SOA-related stack is being used by Oracle internally to build its own applications, they can therefore safely commit to it. Trying to apply SOA tools (such as BPEL) inappropriately to normal application development can lead to the creation of a system architecture that will not provide adequate performance for many systems.
There are several different parts of Fusion Middleware that Oracle will be using internally. These are discussed in the following sections.
1. The Oracle Application Server
Oracle’s Application Server (OAS) has been around for many years and has evolved from an enhanced version of the Apache application server into a fully robust Java EE application server. It is a solid enterprise application server that is appropriate for any organization’s use when working in the Java EE environment. There are competing application servers that have their proponents as well (e.g. IBM’s WebSphere), which may be equally suitable. What sets OAS apart is its integration with the Fusion Suite. This tight integration with the rest of Fusion Middleware is a huge benefit which can save an organization many thousands of dollars.
Building applications with JDeveloper using the Application Development Framework (ADF) allows you to deploy your system to OAS with a single button click. For organizations not yet working in a Java EE environment, it may be difficult to understand this huge benefit. Typically deploying to an application server is a project in and of itself. Developers may spend weeks building and debugging deployment scripts to support an application deployment. Furthermore, every time the application is significantly modified, the deployment script must be refactored, prior to redeployment. Using OAS and ADF eliminates most of these difficulties.
2. The Application development Framework – Business Components (ADF
BC)
One of the most problematic areas in Java application development is interacting with a relational database. It is this portion of the system that most commonly causes a project to fail. Most Java developers reject the idea of using anyone else’s framework and instead try to create their own. This usually results in a framework providing terrible performance that does not take database transactions into account. Even worse, such frameworks provide the illusion of project progress, allowing prototypes to be demonstrated early on in the development cycle. Only later does it become evident that the underlying architecture is unsound with respect to scalability and performance.
Oracle’s Application Development Framework – Business Components
(
For those coming “late to the party” the ADF BC framework is stable, mature, and not likely to be redesigned in the next several years. Object-Oriented developers are likely to resist using the ADF BC framework (mainly because they didn’t write it). It does require some study to understand and fully exploit its architecture. There is no more important decision that an organization can make with regard to a systems project than to build on a solid, stable, persistence environment. There should be compelling reasons for an organization not to choose the ADF BC framework. It is the best framework in the industry.
3. ADF Faces
ADF Faces are the user interface elements that appear in
applications. They consist of Oracle’s extensions to the basic 30 Faces
components. They are richer from a UI perspective (some are
A new area of the architecture that many initially overlooked is the WebCenter, which is an impressive architectural achievement. Oracle has made its own Oracle Portal product obsolete since any ADF Faces page can act as a portal and any portlet can be wrapped as an ADF Faces component. It is this level of architectural depth that Oracle continually demonstrates which should make everyone look very closely at ADF as a development framework. Oracle is allocating more resources to this framework than any competitor and, as a result, is expanding its functionality more rapidly than that of any other environment.
Although ADF faces is still somewhat immature and not without
its challenges to extend, using ADF Faces for development is a good choice. Any
of the core Faces components can be bound to
4. Business Process Execution Language (BPEL) & Service Oriented
Architecture (SOA)
Business Process Execution Language (BPEL) & Service Oriented Architecture (SOA) are some of the hot buzzword technologies du jour. BPEL is used to implement complex process flows with SOA architectures. Each node in the BPEL process has both the flexibility as well as the handicap of making a call to a web service. The problem is that web services or any services supporting calls from one system to another are inherently resource-intensive and usually slow. If the process has only a small number of nodes and does not require executing more than a few nodes at a time, BPEL architecture is fine. However, in a complex application with thousands of logical nodes that are database intensive (which is not unusual) and which could be implemented entirely within PL/SQL, using BPEL to implement this logic results in a routine that may run hundreds, if not thousands, of times slower. BPEL is popular with developers who do not understand the power of logic executed in the database.
Oracle’s implementation of BPEL is as good as any in the industry. A first rate drawing tool to describe the BPEL process is included. The execution is as efficient as possible, given the weakness of the underlying architecture, and is suitable for applications where a SOA orientation is appropriate. Oracle has delivered an excellent implementation of BPEL. The concern lies with the suitability of the BPEL architecture in general. Most systems do not have the luxury of ignoring performance considerations. Making hundreds or thousands of round trips between the database and server for a single transaction is usually enough to render a system unusable. The SOA suite is built around managing service-oriented processes.
Most systems neither need nor would they benefit from this type of architecture. Applying an enterprise solution to a database-centric application will result in spending more money for hardware and still getting inadequate performance. It is important to carefully evaluate to what extent a SOA architecture makes sense. If taking disparate systems and helping them interact in something other than an ad hoc fashion is the goal, then a SOA approach makes sense. In order to demonstrate the need for SOA and BPEL, typically vendors discuss applications for which these architectures make no sense (usually a sale or purchase order processing). Describing a system where a SOA architecture is appropriate is fairly complex and does not lend itself to a short conference paper. Frequently, people building SOA products are not, themselves, the same ones who build end user systems. As a result, they may not explain the best way in which to use the tools they are developing.
5. Oracle Business Rules
The Oracle Business Rules tool is considered a part of Fusion Middleware that Oracle will be using to develop its internal tools. It is still evolving and has not stabilized to the point where even Oracle has a clear idea of how this technology might be useful. The issue is that it is important to deliver an application that can be quickly and easily refactored when the business rules of the organization change.
Using a repository where rules can be changed and the applications immediately reflect those changes is the desired goal. There is no way that this vision can be achieved when the business rules are only a small part of the system. A change in business rules can mean a change to the current data structure, potentially requiring a core change to the business processes associated with a class of objects, change to the user interface, etc. Unless the business rules engine can drive changes to the entire system, there is no way that it can logically achieve its declared objective. Pulling out some portion of the logical business rules and placing them into a business rules tool begs the question: Which rules belong in the tool and which ones do not? This is a very difficult question to answer and Oracle is still grappling with it. It is not clear how, or if, the Oracle Business Rules tool fits into the broader Fusion Middleware scope.
Currently, Oracle Business Rules is an interesting development effort that has yet to be adopted or embraced by the Project Fusion development architecture. Organizations should adopt a “wait and see” attitude about this portion of the technology stack. It is possible to download and use this tool and provide Oracle with feedback about how it might be useful.
Concepts to Keep in Mind
To discuss how to use Fusion Middleware for Custom Application development requires understanding several important concepts:
1. Use a “thick database” approach. As stable as this architecture is, it is still evolving. Anything created anywhere other than the database is at risk of having the underlying architecture itself evolve, thus requiring changes. Software built in the middle tier may be architecturally out of date fairly quickly and need to be rewritten. The only defense against an evolving architecture is to use it as little as possible. Place as much of the business logic as possible into the database, thereby decreasing reliance on the evolving technology. Given the current state of this technology, you can expect the following benefits:
· Write half as much code.
· Have more efficient code.
PL/SQL that interacts heavily with the database is much more efficient than Java and will run much faster (10 times). Due to PL/SQL’s performance efficiencies, network traffic between the application server and the database will be reduced by 99%. The database itself will only be utilized half as much, even though there is more logic because it is so much more efficient to perform all of the processing within the database, rather than in many separate retrievals and updates of information from the application server. For more information about this see Paper #424: "Fusion Development: A Database Centric Approach"
2. Use ADF BC. If most of the system logic
is in the database with appropriate complex views, creating
3. Learn how to use ADF Faces appropriately. This is also a very large topic. See Kolezke & Mills Oracle JDeveloper 10g for Forms & PL/SQL Developers (2006, Oracle Press) and OTN white papers for more information.
The next section discusses the details of using ADF Faces components on a real project to create a high quality user interface for an ordering system.
Building a User Interface Using ADF Faces
Until recently, high quality user interfaces have been the exclusive domain of client/server applications. Web application user interfaces have traditionally been slower and of significantly lower quality than their client/server counterparts. JSP/Struts applications came nowhere near the quality of Oracle Forms or PowerBuilder applications, and things that could be done in C++ or Java (using Swing components) could not even be imagined on the web. What could be done, took much longer to do than in the client/server environment.
Oracle’s ADF Faces has significantly closed the gap between client/server technology and web technology. ADF Faces applications can easily rival Oracle Forms applications, both in quality of the user interface (UI) as well as in performance.
Perhaps more significant is that the “development gap” has also narrowed. It is now possible to build applications just as quickly in ADF Faces as it was in products such as Oracle Forms. If developers use a “thick-database” approach and place most of the logic in the database, then applications can actually be built faster than using a traditional client/server-based method.
This section describes a complex development effort using ADF Faces. The goal was to build a repository manager similar in scope to the Designer RON. The application required a sophisticated tree control and numerous, complex property screens. The underlying database was designed using a high level of abstraction and the core of the model was recursive. The application chosen would have been difficult to create in any development environment.
The Project
The client for whom the application described in this paper was developed is a factory. The order entry process for this factory is very complex. There are not many products, but each product has dozens of attributes that must be specified as part of the order process. These attributes have various dependencies among them. There are hundreds of business rules to validate/enforce when a customer is submitting a purchase order or asking for a quote. Each product is sufficiently unique that it requires its own dedicated entry form.
The customer has two options for placing an order. They can either call a sales representative or go online. If the customer orders through a sales representative, the sales person uses an Oracle Forms application to enter the specifications. If the customer places the order online, the specifications are entered using a web-based application. Since there are 13 different products, there are 26 different order applications. Thirteen are implemented in Oracle Forms (for internal use by sales representatives) and 13 in ADF JSP/Struts (for web access from customers).
The business rules for the applications, both in Oracle Forms and ADF JSP/Struts are exactly the same. To avoid coding the same business rules multiple times, a business rule repository was designed. Order entry applications access this rule repository in real time and execute the business rule logic within it.
The rules repository is a 15-table Oracle database that was designed and generated using Dulcian’s BRIM® tool. A repository of this size requires its own user interface to enter and maintain the business rules. Originally the Repository Manager to maintain the rules repository was built using Oracle Forms and it was functional, but not very intuitive or easy to use. Since the development team had identified ways in which the design of the repository could be improved, it was decided to upgrade the repository data model and rewrite the Repository Manager using ADF Faces. The revised data model for the repository is shown in Figure 1.
Figure 1: Rules Repository Data Model
The next section describes the construction of the new Repository Manager application in ADF Faces. It discusses the challenges encountered, mistakes made, and solutions found.
The Application: Repository Manager
The Repository Manager is used to enter and maintain the business rules. The UI is similar to the one built using Oracle Forms since there existed 13 applications implemented in Oracle Forms and users were already familiar with this tool. This reduced the amount of training required. All of the business logic can be represented nicely using a subset of Oracle Forms objects such as triggers, fields, blocks etc.
Some extensions and changes to the Oracle Forms UI were needed in order to make use of the repository. Figure 2 shows the Repository Manager user interface.
Figure 2: Repository Manager user interface
This application takes advantage of the sophisticated UI JavaServer Faces components shown here as two tree components.
JavaServer Faces Tree Components
In this application, it was necessary to ensure that the tree component could support all of the required functionality. Before making a decision to use the ADF Faces tree component several other options were evaluated:
1. Pure JavaScript tree running completely on the client machine
2. MyFaces tree component
3. ADF Faces tree
The following criteria were used to evaluate the options:
· How well does the component integrate with ADF? Are managed beans needed to feed the tree the nodes?
· How much custom coding is needed?
· How customizable is the component?
· Does it publish a rich set of events/methods that can be used to alter the behavior look-and-feel of the component?
The first option of the JavaScript tree was eliminated for a number of reasons. The look-and-feel was sub-par at best, and there was no out-of-the-box integration. It would be necessary to develop the beans that would supply the data to the tree and write custom code to synchronize the tree when the users edited repository objects which would affect the node displays or the tree status. Although it was highly customizable, the widget seemed more appropriate for simpler trees with more static data.
The MyFaces tree was a reasonable candidate. Its only true downside was that it did not automatically bind to ADF Business Components. Since JSF was new to the development team, it did not seem wise to try to integrate MyFaces components.
The ADF Faces tree component is a server-side component, meaning that the tree relies on the middle tier to handle its events and supply its data. It cannot be configured to run only on the client side. (This is not true for the MyFaces tree component). The ADF Faces tree binds seamlessly to ADF Business Components. This tree is also smart enough to detect changes to the rows in the database that it is displaying. Therefore, when the business layer updates a row in the database (through a separate view object/entity that does not bind to the tree) the changes are reflected in the tree with the next rendering. As predicted, the tree state (which nodes are expanded or not) did not always display the tree the way in which it should when users created a new repository object or changed its display. However, the tree state provided methods for customization.
Unfortunately, icon support for the ADF Faces tree nodes was completely missing, although a workaround was found to deal with this omission. Another problem with this option is that Oracle warns developers about possible performance issues with the tree component. Being a middle tier-driven component with no client-side caching makes this a valid warning.
After careful evaluation of the three options, the ADF Faces tree component seemed to be the best solution. The problems that existed with the component were either not relevant to this project or there were suitable workarounds.
ADF Tree: Developing the Appropriate Business Components
The tree on the left side of the screen shown in Figure 2 is used for navigation among the various objects in the repository. This tree should be familiar to Oracle Forms Developer users since it has a very similar structure and look-and-feel.
Construction of the tree started with building its model layer objects. After inspecting the JDeveloper Tree Binding Editor, it was observed that once the appropriate hierarchical relationships (view links) are defined in ADF Business Components, the Editor could be used to construct the tree based on these relationships.
There were two different possible approaches for building the model layer for the tree: middle tier-centric and database-centric.
The Middle Tier-Centric Approach
Using this approach, a view object is created for each node type in the tree. The view links represent the foreign key relationships in the database. Approximately 20 view objects were needed, along with the related view links among them. These view links must be referenced in the tree binding. (Note that the 20 or so viewobjects need to be created anyway so that the application can edit the row in the database.)
Although this implementation seems straightforward at first glance, it has some serious caveats. If a node representing a repository object is expanded, other repository objects are not immediately visible. Instead, classifications of them are shown. For example, under an expanded block node, the following groupings are shown: Events (Triggers), Fields, Buttons and Lists. Note that Forms groups the children of a block as triggers and items only.
The ADF Tree does not support the creation of “hard nodes” (for lack of a better term) as shown in Figure 3. Various options for handling this situation were considered including writing separate views in the database for each grouping, or creating view objects that are populated programmatically. To use either of these strategies, it would also be necessary to adopt polymorphic restriction functionality in the tree binding many times, which would add another level complexity to defining the tree. In the final analysis, the workarounds seemed clumsy at best and none of them presented a clear, simple solution for the desired navigation tree.
Figure 3: Examples of “Hard Nodes
Using a Database-Centric Approach
Using this approach, a database view is created in which each row represents a tree node. The hierarchical structure of the tree is preserved in a recursive relationship in the view. For example, the view has a column named ID as its primary key column. The view has a second column named ID_RFK which recursively references the ID column and is used to determine the parent-child relationships.
This approach required two view objects in the Model layer of the application: one for specifying the root node (The Application Area header) and one for specifying the rest of the tree nodes.
The database-centric approach seemed to be the better choice for the following reasons:
· Tree nodes are controlled with just one isolated view.
·
The number of view objects and view links needed
to manage the tree was significantly reduced. Experience shows that modifying
· The binding syntax of ADF has been changing with every release. Therefore, the less reliance on it, the easier it will be to upgrade to new versions of ADF.
· It just seemed to be a more clever way of defining the tree.
The following SQL code is an excerpt of the view used for the tree:
select 1,
'Application Area',
'Header_Apparea',
'1',
null,
null,
null,
null,
'Y'
from dual
union all
select aa.ar$apparea_oid,
aa.name_tx,
'Apparea',
''||rowid,
null,
'1',
null,
null,
'N'
from ar$apparea$v aa
union all
.
.
.
The following code is generated after creating the appropriate model layer objects and dragging and dropping them onto the JSP page:
<af:tree value="#{bindings.ArRmNavtree1RootView1.treeModel}" var="node">
<f:facet name="nodeStamp">
<af:ouotputText value="#{node}"/>
</f:facet>
</af:tree>
JSP Page Code for the Tree Tag
The generated code is simple enough. Later, new components will be added with the nodeStamp facet to allow navigation to the different property screens of repository objects. The code in Figure 4 shows the page definition XML displaying the tree binding.
Figure 4: Tree binding XML
Tree Definition XML
As shown above, JDeveloper generated the binding XML based on the rules entered in the Tree Binding Editor. The only time this XML may need to be edited without using the Tree Binding Editor is when applying the workaround to remove the + sign from the leaf nodes. As of this writing, the developers have not implemented the workaround yet. The blog entry on how to achieve this can be found at the following URL: http://technology.amis.nl/blog/?p=1298
Icons and links will be added to the tree at later stages.
Displaying the Property Palette for each Repository Object
The next step in developing the application is to build the various property sheets for each type of repository object: Application Areas, Applications, Blocks, Fields, Lists, Buttons etc.
In this application, the navigation tree is used to locate repository objects. When users click a node in the tree, the property sheet for the selected repository object is displayed on the right.
To achieve this functionality, the following had to be implemented:
· Detect the node that the user clicked on the tree
· Change the focus of the tree to the clicked node (highlight the selected node)
· Display the correct property sheet.
Detect a click on a node
The nodeStamp facet of the tree component is capable of displaying various JSF Components as shown in Figure 5:
Figure 5: Tree component facet
A commandLink tag was added to the nodeStamp facet and bound to a method named checkTransaction in a managed bean named MyTreeBean. This shows the use of a commandLink inside the nodeStamp facet to detect that the user clicked on a node.
Changing the focus in the tree
To capture which node in the tree is clicked, an attribute named “clickedRowKey” is created in the NavTree bean. (This managed bean stores the actual CoreTree object to which the <af:tree/> is bound, as well as other attributes to control the tree.) The focusRowKey attribute of the af:tree tag was modified in order to read its value from NavTree.clickedRowKey.
The commandLink was already added to the nodeStamp; however, the commandLink is already associated with an actionListener. It is possible to fire multiple actions when a commandLink is clicked using a SetActionListener tag inside the commandLink tag. The method specified in the setActionListener tag will execute before the method specified in the comamndLink as shown here:
<af:set.ActionListener from"#(ArNavtree1.tree.rowKey)"
To=#(ArNavtree1.focusRowKey)"/>
The setActionListener assigns the rowKey of the node that is clicked to the clickedRowKey property of the NavTree bean, which in turn is accessed by the focusRowKey attribute of the <aftree/> tag.
Displaying the correct property sheet
The property sheets resemble the standard edit forms that are created by dragging the corresponding data control from the JDeveloper Data Control Palette and dropping it onto the page. The code shown in Figure 6 is an example of the property sheet definition of a Button
Figure 6: Property Sheet definition of a button
A <af:switcher/> tag was used to toggle between the property sheets. When a user clicks a node in the tree, the type and ID of the repository object that the node displays are captured. Then the appropriate view object is queried to read the record from the database and the <af:switcher/> tag renders the correct property sheet. Some sample code to demonstrate how this tag works is shown in Figure 7.
Figure 7:af switcher tag
There are over 15 different types of nodes that display different screens. When a node is clicked, the type of node is stored in a bean property named “clickedNodeType.” Then the value of this property is used in the <af:switcher/> tag to determine which property sheet will be rendered.
Each possible value of the clickedNodeType property is handled in a facet. Facets of the <af:switcher tag/> can be seen as the elseif statements of an if block. Note that there is no else keyword for the switcher tag.
Important Note
One problem encountered in the development of this application that is worthy of note was the size of the JSP page. JSP pages do not function properly after they exceed a certain size (~1300 lines).
This problem was discovered when adding facets to the switcher tag. With the increasing number of facets, the JSP file became too big for the compiler to handle.
The workaround was to divide the page into multiple pages using jsp;include tags. In this case, new JSP pages were created for each property sheet and added to the main page using JSP include tags as shown here:
<h:panelGroup>
<jsp:include page=”/CreatePages/CreateAppArea.jsp”/>
</h:panelGroup>
This completed the steps to be able to display the desired screen when a node is clicked by the user.
Conclusions
Dealing with ADF Faces is not without its challenges. There are still significant bugs and workarounds that need to be accommodated. However, it is possible to build applications that are as rich as anything built using Oracle Forms. The result is a nicer looking application that takes no longer to create than it would have taken to build in Forms.
Adopting a thick database approach seems to be the critical success factor for using this technology, both from a performance perspective as well as for minimizing development costs.
This project demonstrated that ADF Faces could be used successfully for web development. Given a choice of technologies to build a standard OLTP system, we would choose ADF Faces.
ADF Faces is still nowhere near rich enough to support the kind of development possible with C++ or thick-client Java/Swing. Our web development environment of choice for the richest of applications (such as graphical data modeling or process flow tools) is Adobe Macromedia Flash. But for the applications built using Oracle Forms, that development environment can now safely be replaced with that of ADF Faces.
About the Authors
Dr.
Yalim K. Gerger is the founder and president of Gerger Consulting, a consulting firm specializing in J2EE application development using Oracle, ADF, JSF and Struts. Yalim has over seven years of experience in various technologies such as Oracle Database, Oracle Forms Developer, Oracle ADF, Struts, JSF, Java and FLEX. He has worked for various government and leading private industry institutions and completed various projects using these technologies.