|
|
|
|
| Figure 3: UML Entity Model for an E-Commerce Order System |
With Oracle Business Components for Java, rather than coding business logic into each client application or servlet you write, you write it once in a reusuable, domain-specific business component which extends the basic Entity Object in the framework. For example, an Order Entity Object implementing the Order Entity from Figure 3 can encapsulate:
You write validation logic in your Entity Object's Java Implementation Class and the framework worries about coordinating when that validation logic is enforced. If an Entity Object is composed with other entities (as Order is with LineItem in Figure 3) the framework coordinates the validation of composed entities for you too.
Association
By creating an Association between two Entity Objects, you establish an active link between them. You get direct access to "walk" the links in your code through Association getter methods and direct access to assign related objects with Association setter methods. Since getter and setter methods are the coding pattern in Oracle Business Components for attribute access, in effect, the presence of Associations makes virtual attributes appear on your entities, allowing seamless access to related information.
|
| Figure 4: Attribute-level Validation Code in LineItem Leveraging Association Accessors to Traverse to the Customer Who Placed This Order and Call a Method on It |
Figure 4 shows how easy it is to write Java code using Oracle Business Components to enforce a business rule whose implementation requires looking up the Order for the current LineItem, then looking up the Customer who placed that Order, and then invoking a business method on Customer to check a maximum allowed discount. By leveraging Oracle Business Components Association accessors, business logic authoring is greatly simplified.
Associations indicate that one Entity references another. In addition, identical to UML, Associations can be flagged as being "Compositions", which indicate a stronger ownership or containership relationship between two components. For example in Figure 3, Order and Customer are related by an Association, as are LineItem and InventoryItem. This simply means that an Order is placed by a particular customer and that a LineItem places an order for a certain quantity of a particular item in the inventory. If an Order is deleted from the system, there is no implied impact on the existing Customer who placed that order or to the InventoryItems which had been requested on the deleted order.
On the other hand, Order and LineItem above are related by a composition (indicated in UML with the solid diamond on the Association line). Using Oracle Business Components, at runtime this means that:
So Associations and Compositions capture the web of relationships among your business entities and make the system smarter by knowing about them. As we've seen, using Association and Compositions in Oracle Business Components automates many common validation tasks for you.
Validation Rule
Validation Rules are JavaBeans which encapsulate reusable validation code for use across any Entity Objects where they might be useful. In contrast to the Java code-based validation you write in your Entity Object's Java Implementation Class, you attach Validation Rules to your Entity Object declaratively through its XML Component Definition.
|
| Figure 6: XML Metadata Indicating Use of a Validation Rule Bean for LineItem's Quantity Attribute |
Figure 6 shows the result of using the "Rules" tab of the Entity Object Editor in Oracle JDeveloper to attach a RangeValidationBean to the Quantity attribute of the LineItem Entity Object. Since Validation Rules are like little data-driven validation engines housed inside a JavaBean, they typically require a set of parameters to be supplied when they are used. These parameters are captured and represented in the XML Component Definition as XML attributes on the element representing the Validation Rule usage. This makes the values easy to set and easy to customize.
Validation Rules can be attached both to individual Entity Object attributes as well as to the Entity Object as a whole, and the framework supports a collection of zero or more Validation Rule at each place. Validation Rules work in concert with Java code-based validation so you can mix and match the approaches for your own validation.
While Oracle Business Components comes with a set of example Validation Rules, their real power lies in the fact that you can easily implement Validation Rules of your own. After all, they're just JavaBeans that implement a supplied Oracle Business Components interface! This lets you provide libraries of reusable Validation Rules to your development teams or to your end-customer for easy, declarative customization of your application's behavior.
Domain
When building real applications, you frequently find yourself writing little routines to check:
Domains contain a validation in the constructor which performs the check you need to do to make sure they are proper values. Once-constructed, instances of Domains can be freely passed around in a type-safe way as method parameters. In fact, Domains makes it easy to avoid the mistake of passing a Quantity to a method expecting a Price since the compiler will flag the error immediately.
Oracle Business Components lets you easily use Domains as the datatype of Entity Object and View Object attributes, which automatically enforces the Domain's built-in validation checks on any attribute values supplied by clients. Figure 7 shows an example of the constructor-time validation check for a WebURL Domain, the XML metadata representing the use of the WebURL Domain as the datatype of the Customer.WebSite attribute, and the type-safe attribute getter and setters generated which make use of the WebURL class.
|
| Figure 7: Example of a WebURL Domain and it's Use as the Datatype of the Customer Entity's WebSite Attribute |
| Technical Highlights | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
View Object
EJB Entity Beans support a feature called a "Finder Method" which allows the author of the bean to provide alternative "lookup" mechanisms for that Bean. For example, rather than finding an OrderBean by its primary key attribute OrderNumber, you can support looking it up based on some other parameters instead. Oracle Business Components In addition to these basic EJB "Finder Methods", Oracle Business Componentss in Oracle Business Components give you the ability to:
Since SQL has powerful calculation and aggregation capabilities built-in, View Objects can include calculated attributes which are computed by SQL expressions in the SELECT list, as well as transient attributes which are calculated by custom Java code in the View Object's Java Implementation Class. Pushing these calculation and aggregation operations into the SQL statement of a View Object allows the database to efficiently compute the answer, rather than having the application code do it. For real-world applications, the ability to hand-tune the data access to improve performance can make all the difference between sluggish and speedy response-time. The Oracle Business Components View Object architecture allows this.
Once defined, View Objects are reusable components that can be assembled as needed into Application Modules or be looked-up by name and instantiated on-demand at runtime.
Each View Object has related metadata in its XML Component Definition which tracks how the columns in its SQL query's SELECT list relate to individual Entity Object attributes. This information allows the framework to coordinate business logic enforcement with values changed by clients on any row queried into the View Object.
|
| Figure 8: View Objects Cooperate with Related Entity Objects for Business Logic Enforcement |
For example, Figure 8 above illustrates how two different View Object's EmployeeList and TopPerformers both reference attributes from the Employee Entity Object among their result set columns. If we assume the Employee's Sal attribute is included in both View Objects, then any validation rules on Sal will automatically trigger when either view tries to make modifications to it.
In fact, Sal need not even be included in the view at all. For example, assume that an Employee Entity Object has business logic which raises the employee's salary when she is promoted. And assume that the client is working with a View Object which only includes EmpNo, EName, and Level. If the client sets the value of an employee's level to a value which is higher than the current value (indicating a promotion), then if the promotion-related business logic causes the employee to have an invalid salary, the exception will be consistently raised back to the client.
View Object SQL queries often need to join many underlying tables to have just the right information available for the end-user's screen or web page. Look again at Figure 3 and think about the information that a user requires to complete the task of entering a new LineItem on an Order.
They need to see Price and Description information on the item from the InventoryItem as well as the Name of the Supplier at a minimum.
View Objects handles this easily. You simply let the View Object Editor build the join query for you. Then, you use the View Object Editor to specify how the columns selected in your query related to the appropriate attributes of the underlying Entity Objects involved. Typically join queries are not updateable, but with the Oracle Business Components framework, you can use the View Object metadata to make any join fully updateable for you.
Since sometimes fully-updateable is not what you need, you have full control over each attribute included in the View Object and can specify whether it is read-only, updateable, or updateable-only-when-new to ease the burden of having to code this into any subsequent user interface or web page that might make use of the View Object.
| Technical Highlights | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
One of the hardest tasks for developers building client applications is to provide end-users multiple, synchronized views of data. How many times have you seen applications that display summary information in a grid, then drill-down to details in a form, and maybe show the big picture by rendering the same information graphically as a chart? These are the kind of applications that end-users love but developers hate, since keeping the various views synchronized as the user makes changes or navigates through the data is non-trivial and hard to generalize. Oracle Business Components solves this problem by providing you framework components which automate all of the hard parts of doing this.
Oracle Business Components' View Objects cache their queried data intelligently by factoring each row into its constituent Entity Object parts, and caching each Entity Object instance only once in memory, regardless of how many View Objects may be referencing it. This fundamental processing behavior has the benefit of automatically keeping multiple views of the same data in sync. When any view makes a change to any attribute, the change is effectively and automatically made to the corresponding attribute on the unique cached instance of the Entity Object underneath. This lets all View Objects in the same session instantly see the change, eliminating the need to write any code manually to take advantage of this feature.
View Link
The next coordination challenge for developers is keeping master-detail queries synchronized. At design-time, you can define a View Link to establish a master-detail relationship between two View Objects. At runtime, the View Link automatically keeps a detail View Object resultset synchronized with the master View Object resultset. Of course, View Objects can be instantiated under the coordination control of an appropriate View Link as well as on their own, so reuse of View Objects is improved.
When a JFC/Swing-based user interface or JSP page works with information from two View Objects that are View Linked, it can simply make calls like masterVO.next() and the information in the master-detail View Objects is automatically kept synchronized without client code. This can significantly reduce the code required for sophisticated user-interfaces.
Another common task typically relegated to repetitive, unproductive client code is that of managing the retrieval of lookup values. If the user types in the ItemId of some InventoryItem on a form where they are typing in line items, the client code is usually responsible for looking up the InventoryItem by the supplied ItemId and retrieving its Description, Price, and Supplier Name.
With Oracle Business Components, since each View Object knows which Entity Objects it is using and since you've already specified how the Entity Objects are related using Associations, Oracle Business Components can keep the information together for you to save you from writing the common code to bring in reference information.
|
| Figure 9: View Object Attributes from Referenced Entity Object Usages LineItem and Supplier Are Automatically Retrieved When ItemId is Set to a New Value |
Figure 9 illustrates how the the act of setting the ItemId attribute on the current row in the LineItemsView causes the framework to automatically retrieve appropriate reference information from the InventoryItem and Supplier Entity Objects used by the View Object. The slanted-line pattern on the II and S Entity Usages indicates that they have been marked as participating in the View Object as reference information, rather than being updateable.
| Technical Highlights | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Application Module
To keep the client user interface code thin, you can pre-build the entire data model that the client application needs into an Application Module. This includes not only the View Objects which the application will make use of, but also any View Links which will establish the automatic master-detail coordination behavior the client may require. By setting this all up ahead of time, the client application can simply instantiate the application module it needs and immediately find all the appropriately-coordinated View Objects ready to go, saving network roundtrips and startup time.
Figure 10 shows the tree of the View Objects and View Links required to implement the OrderSystem Application Module from Figure 3.
|
| Figure 10: Data Model of the OrderSystem AppModule |
But thinking of the Application Module as only a data model for your application misses the other important role an Application Module plays in building an efficient, three-tier application: that of supplying server-side services which the application client may need.
Service methods defined on your Application Module can be made remotely accessible simply by selecting the ones you want in the "Exported Methods" panel of the Application Module Component Editor. When some custom methods on the Application Module are exported, Oracle Business Components automatically creates your remote interface containing the custom method signatures and automatically handles the runtime marshalling of method arguments, return values and exceptions back from the server-side method implementations. By moving code like a data-intensive calculation out of the client and into its Application Module counterpart in the application tier, the client can get the answer with a single network round-trip instead of unnecessarily pulling data to the client.
To support straightforward component assembly of applications, Application Modules can be composed of other Application Modules if required. As illustrated in Figure 11, if user interfaces forms or panels have been coded to work with a given Application Module, these self-sufficient UI panels can be reused and composed into compound user interfaces whose logical application layer can be a nested set of Application Module components.
|
| Figure 11: Assembling Application Module Components |
The developer can use an instance of the base Application Module component as a generic, initially empty container for dynamically loaded View Objects and Application Modules to support complex, role-based applications where a fixed set of the Application Modules required by the end user are not known in advance.
Oracle JDeveloper comes with a full set data-aware JFC/Swing controls which bind declaratively to data from database queries. In Oracle JDeveloper these controls enable the same declarative data binding for thin-client Java user interfaces working against the View Objects inside an Application Module.
|
| Figure 12: Declarative Data Binding to View Objects Using "InfoSwing" Controls Data |
Figure 12 shows the binding editor used to visually select the column or rowset to which an InfoSwing control is bound. In this case, it sets the Infobus "dataItemName" property on the text field control to Session1/Orders/TrackingNumber. At runtime, this means the control will display and can modify data from that column in the View Object automatically, without any manual coding from the developer.
Similar ease-of-use features exist for the JavaServer Pages for developer wanting to use View Objects and Application Modules. Oracle Business Components supplies a set of JavaBeans which can be used with the JSP <jsp:useBean> tag for full programmatic control over View Objects and Application Modules from within your JSP. In addition, Oracle JDeveloper provides WebBeans, which can be used to access values from the current row, scrolling, and setting View Object column values from HTTP request Form parameters automatically. Exceptions raised by the Entity Object validation behind the View Objects accessed by the JSP can be presented in a custom JSP Error Page with ease.
In addition, a set of pre-built, HTML generation beans is provided which derive from the Oracle Business Components DataWebBean framework class to automate common HTML presentation for View Objects like Web Forms, tables, etc. Of course, developers can use Wizards to create their own custom DataWebBeans as well.
Additional Oracle Business Components features of interest to JSP developers are the AppModuleRegistry and the forward-only mode for View Objects. JSP developers use the supplied AppModuleRegistry to automatically maintain pools of Application Module instances which are used to support large numbers of browser-based users. A benefit of combining the stateless use of a pool of Application Module instances that each retains some state is that frequently accessed data can stay cached in the View Objects of each Application Module for even faster response time.
By setting an instance of a View Object into forward-only mode, a web developer can consciously avoid all caching for View Object query results when she knows ahead of time that no scrolling and no updates will be made to the queried data through that View Object instance. Typically, this is the case when formatting query results for HTML or XML web documents. The same View Object can be instantiated multiple times, so the same View Object could be used in forward-only mode for fast web-page formatting, while another instance could operate in normal mode to accommodate updates and automatic business logic enforcement when a web user eventually submits an HTML form with pending changes to be made.
| Technical Highlights | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Oracle Business Components View Objects automatically cache their queried data factored into Entity Object parts using the metadata all View Objects components have about how their columns relate to one or more Entity Object Attributes. This technique allows the database to process the SQL query at full speed, while making the data returned more powerful once in the cache.
Since data is cached by Entity Objects, they can handle the interaction with the database when valid changes are made to any of their attributes. The first of this automatic behaviors is row-level locking.
Oracle Business Components supports a declarative setting for either pessimistic or optimistic locking. When an entity object is set for pessimistic locking, the first time one of its attributes is successfully modified (i.e. passes any validation), the Entity Object will attempt to lock its corresponding row in the database. If the Entity Object is part of a composition of Entity Objects, then the framework coordinates locking the parent Entity Object in the family before proceeding. If the lock cannot be acquired, exceptions can be trapped for the application to handle.
When new instances of Entity Objects are created, or existing instances are modified or deleted, the affected Entity Object instances automatically communicate the changes to the underlying database table at transaction commit-time. All of the pending changes made to Entity Objects occur in the context of the current transaction, which is associated with the root Application Module and shared by all contained Application Module components.
A critically important feature for application developers is that while changes are pending in the cache, Entity Object business logic can walk associations to check on the state of related objects. This business logic will correctly see any pending changes on the related objects so that business logic can be correctly enforced before committing the changes as a unit to the database.
When the client application or some code within the application-tier business logic calls getTransaction().commit(); all of the modified Entity Objects in the cache flush their changes efficiently to the database, again without developer-written code!
Of course, one of the key values of a Java-based application framework is that when you don't want the default behavior provided by the framework, you can override the framework in strategic places to get things to work as you need them to for a particular case. Overriding the default database interaction mechanism for an individual Entity Object is as easy as overriding a single method in that Entity Object called doDML(). Teams requiring custom storage implementations or, for example, requiring that the deletion of an Order actually update a Deleted column instead of physically removing the row, achieve their desired results quickly using this approach.
Figure 4 shows how you can use Associations to walk the web of relationships among your business objects. When you take advantage of this feature, you are actually saving the work of writing the mundane SQL lookups which would normally be required to lookup the related information by its foreign key values.
| Technical Highlights | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Oftentimes, an application developer can only know at runtime the exact application components that are required, based on the diverse roles and responsibilities of each user of the system. The Oracle Business Components framework caters to this need by allowing individual View Objects or entire Application Modules with pre-coordinated View Objects to be loaded on-demand by the client application at runtime.
By simply referencing the full package-qualified name of the
business component, the developer can easily instantiate an
application module in the current session, then find one of
its View Objects by name as shown in the following code example.
ApplicationModule theAM = createApplicationModule("oracle.apps.order.OrderSystem");
ViewObject theVO = theAM.findViewObject("LineItems");
|
ViewObject myVO = createViewObject("oracle.apps.order.UnpopularItems");
|
Once the application decides it no longer requires a
particular View Object or Application Module, it can simply call
theAM.remove(); myVO.remove(); |
Another feature which supports generic, data-driven application behavior is the ability to associate custom metadata properties with any business component built using the framework. You can associate arbitrary name-value pairs of information in any component's XML Component Definition, and a simple API makes this custom metadata available at runtime to drive dynamic decisions which can be made by generic code.
Custom properties can even be assigned to Domains as well as to each Entity Object or View Object Attribute. Oracle Business Components users may make clever, comprehensive use of custom properties on their
A final small, yet important, feature is the ability to track your own per-row application state on any View Object by adding dynamic columns at runtime. Since the Oracle Business Components framework is designed to keep the client memory and code footprint very thin by doing all of the hard work in the application-tier, you can have the application-tier cache and manage your dynamic state information in the middle-tier as well.
Simply call a method on the desired View Object to AddDynamicAttribute() and then proceed to get and set that new attribute with your own information. As with any View Object Attribute, the type of the dynamic attribute can be any Serializable object. The net benefit is that for a large View Object result set, your dynamic attributes are cached and managed in the same way as regular attributes on the View Object. This means that the bulk of their data is managed in the middle-tier, rather than hanging around en masse on the client.
| Technical Highlights | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
While developers can leverage Oracle Business Components for Java by working on the source of their components' Java Implementation Classes and XML Component Definitions in their favorite editor, Oracle JDeveloper provides integrated design-time support for the Oracle Business Components framework, which can automate many aspects of putting the framework to use for your application.
Figure 13 shows the Oracle JDeveloper Integrated Development Environment (IDE). The Oracle JDeveloper Project Navigator displays business components such as Application Modules, Entity Objects, and Associations. Key details of each business component appear for easy reference in the Oracle JDeveloper Structure Pane. Expanding any component's icon in the Navigator reveals the component's XML Component Definition as well as its Java Implementation Class which can be worked with in the IDE exactly like any Java file.
|
| Figure 13: Oracle JDeveloper IDE Offers Built-in Support for Oracle Business Components Framework |
Using integrated design tools such as the Oracle Business Components Wizards and Component Editors, you define the characteristics of all the domain-specific components you need for your application. After creating new components with the Wizards or changing any aspects of them using the Component Editors, the Oracle Business Components design-time system modifies any framework-related Java code in your Java Implementation Class and keeps your XML Component Definition file synchronized with your changes. Since all of the code in your components' Java Implementation Classes are domain-specific business logic and framework overrides, in practice the only code changes to these files that the editors need to make on your behalf are:
Figure 14 illustrates one panel of the Application Module Component Editor which allows you to define the tree of View Objects and View Links you need for your application with a few clicks of the mouse.
|
| Figure 14: Defining the Set of Master-Detail-Coordinated, Remoteable Collections in the Application Module Editor |
In practice, many application developers mix and match development approaches, using the Oracle Business Components Wizards and Component Editors in Oracle JDeveloper to set up the basic features of their components and their relevant XML Component Definitions, then using their favorite editors for marathon coding or bug-fixing sessions where they concentrate for days at a time on the implementation of their components' domain-specific business logic.
Oracle Business Components and Oracle JDeveloper support both forward-engineering for creating the database tables from Entity Objects, as well as reverse-engineering of all the basic framework components from the existing tables. For example, in Figure 15 the user has
|
| Figure 15: Using the Reverse-Engineering Wizard to Create Default Entity Objects, View Objects, and an Application Module in One Click |
When the OK button is clicked, the Reverse-Engineering Wizard automatically creates
One of the many benefits of cleanly separating the application business from the views of business data is that teams working on business logic can work independently of application teams reusing their Entity Objects in various applications. If creating user interfaces is neither your speciality nor strictly related to your job of writing business logic, you'll really like the built-in Oracle Business Components Tester. It gives you a productive way to test-out your business logic immediately and directly from the IDE by selecting any Package or Application Module in your project in the Project Navigator, and picking Test... from the right-mouse menu.
|
| Figure 16: Testing Business Validation on the LineItem Entity Object's Discount Attribute by Trying to Set an Invalid Value for Discount through the LineItems View Object in Oracle Business Components Tester |
The Oracle Business Components Tester, shown in Figure 16, is an example of a generic, thin Java client application. It uses the dynamic capabilities of the framework's client API's to interrogate the runtime metadata of any Application Module that you want to exercise, and presents a directory of the View Objects and View Links contained by the current Application Module. The Tester creates dynamic Swing-based forms for each View Object you want to browse, and dynamic master-detail forms for each View Link that you test out.
The Oracle Business Components Tester visually exposes all of the runtime features of the framework including:
Seeing the Oracle Business Components Tester's generic client in action working with the View Objects in your Application Module it becomes immediately clear how much of your application logic and coordination you can encapsulate into the logical application-tier using Oracle Business Components, without burdening the client with unnecessary complexity and without weighing down the client with unnecessary code. Finally, besides being a useful testing tool, the Oracle Business Components Tester is also a useful learning tool. The full source code for the Oracle Business Components Tester ships as a sample application with Oracle JDeveloper.
| Technical Highlights | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Based on the metadata in the XML Component Definition about how its columns relate to the attributes of one of more Entity Objects, the View Object partitions its queried data into appropriate row caches at runtime. This architecture enables many of the runtime benefits described in this paper.
As Figure 17 illustrates, when the client calls myEmployeeList.executeQuery() on the remote View Object in the Client Tier, the View Object implementation residing in the Application Tier sends its query directly to the database for immediate execution. The View Object fetches the database query results and does the following:
In stark contrast to the approach taken by nearly all object/relational mapping tools/layers, with Oracle Business Components you will never query 200 attributes of a complicated Order objects, just to reference its TotalAmount attribute on a user-interface.
|
| Figure 17: Partial Fetching and Application-Tier Caching |
This refreshingly pragmatic and powerful approach to combining arbitrary SQL views of data with well-defined, encapsulated business components enforcing the business logic keeps the Application Tier of your system running efficiently. However, this is only part of the mechanism implemented by Oracle Business Components for delivering very efficient, three-tier applications.
Look again at Figure 17. Notice that the caching of the data lies in the Application Tier, and not in the Client Tier. This means what the picture says: the bulk of the data in an Oracle Business Components three-tier application is kept in the logical application tier, managed by your coarse-grained Oracle Business Components Application Module. The client working remotely with the Application Module and View Objects over IIOP or RMI never needs to have more than a small amount of the data currently being displayed on screen down in the Client Tier.
The Oracle Business Components framework components and runtime remote client API provide the automatic management of these remotely-accessible SQL-based View Objects, including the local caching of the (developer-configurable) window of data onto the bulk of the rows kept in the Application Tier.
Over a standard CORBA and EJB remoting architecture, the Application Module implements additional optimizations to keep the number of network roundtrips between Client Tier and Application Tier to an absolute minimum. The network performance optimization delivered by the Oracle Business Components framework is particularly important for building scalable three-tier enterprise applications. This coarse-grained approach of delivering application services as EJB Session Beans which internally manage business entities, provides a solution to highly scalable applications.
When you deploy the Application Modules as CORBA Server Objects or as EJB Session Beans, by design you never need more than one single CORBA or EJB remote interface for your application component. This keeps the environment simpler by avoiding the explosion of classes and interfaces typically seen by using EJB Entity Beans for all services.
With Oracle Business Components you need just one remote interface for each coarse-grained Application Module you deploy as a CORBA Server Objects or EJB Session Bean. If your Application Module does not need to expose any remotely accessible business methods, then you don't need any extra remote interface for it. The default one provided with the Oracle Business Components framework will be sufficient. All of the Oracle Business Components features described in this section contribute to a simpler, more efficient, more network performant architecture for your distributed enterprise applications.
| Technical Highlights | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Oracle Business Components presents a productive programming model for distributed application development which is tier-independent and completely based on industry standards. Client applications (both visual or non-visual) use a simple set of common interfaces to remotely access all domain-specific framework components like Application Modules and View Objects. This encourages a strict logical separation of:
With Oracle Business Components any combination of physical deployment of these three logical layers is possible without modifying developer-written application code since the client code works against interfaces to work with the Application Module and any View Objects in it.
Figure 18 below illustrates the scenario where the client remotely accesses the Application Module component, either over CORBA IIOP or through EJB RMI-over-IIOP.
|
| Figure 18: Thin Java UI Client of an Application Module |
The figure is the same for any of the following cases where a remote Java application or applet accesses the Application Module deployed as:
If the logical client layer is physically co-located in the same Java VM as the application logic layer (i.e. the Application Module), no remote implementation is required beneath the consistent set of application interfaces used by the client. The application programming model is identical.
Figure 19 below represents the local client case which is identical for the following example architectures:
|
| Figure 19: HTML Servlet or JSP Client of an Application Module |
Figure 20 summarizes the three typical deployment configurations of an Application Module.
|
| Figure 20: Application Module Typical Deployment Options |
Instead of manually programming against individual remote interfaces which represent all of the different tables in your database as would be the case with an EJB Entity Bean style of remote application development, use Oracle Business Components to deploy an Application Module as an EJB Session Bean, which does all the work for you. The Oracle Business Components Client Service API offers a highly-productive yet simple set of interfaces used to remotely work with the Application Module, the View Objects and View Links inside it. It offers the client-side UI programmers an API that is just like working with JDBC ResultSets when they work with View Objects.
The key difference is that for no additional complexity in the programming interface over JDBC ResultSets, View Objects are fully-scrollable, fully-updateable, business-logic-enabled rowsets which automatically work across tiers, can be automatically master-detail coordinated, and effortlessly manage the bulk of the queried data in the Application Tier.
| Technical Highlights | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Once you've developed and delivered an enterprise application, the next step that typically happens is that the person or company installing the software needs to tailor it to fit their needs.
Oracle Business Components for Java offers a simple, innovative solution to these needs. Oracle Business Components was architected to support the customization of application functionality from day one. All framework components have their Java Implementation Class cleanly separated from their XML Component Definition. This allows the Java Implementation Class for a customized version of any domain-specific component to leverage the Java language's extend capability to inherit the base component's Java Implementation Class. This solves part of the problem.
The next part of the customization solution lies in the
Oracle Business Components framework's built-in support for the extension of
XML Component Definitions. A newly created domain-specific component like an
Entity Object, a View Object, an Application Module, etc., can simply extend the metadata
of another component declaratively. For example, to extend
an Order Entity Object from
Figure 3, use the Oracle JDeveloper IDE to build
a new Entity Object which extends from
demo.Order. Using the XML Component Definition Extension feature, the
user only needs to note what's new or different about the
CustomOrder. The resulting XML Component Definition for the new,
extended CustomOrder looks like this:
<?xml version="1.0" encoding='ISO-8859-1'?>
<!DOCTYPE Entity SYSTEM "jbo_01_01.dtd">
<!--
|
| XML Component Definition for the CustomOrder EO
| which extends the demo.Order EO, adding one
| additional attribute.
|
+-->
<Entity
Name="CustomOrder"
Extends="demo.Order"
DBObjectName="CUSTOM_ORDTABLE"
RowClass="demo.CustomOrderImpl" >
<Attribute
Name="MyCustomAttributeName"
Type="java.lang.String"
ColumnName="MY_CUSTOM_ATTR_COLUMNNAME"
ColumnType="VARCHAR2"
SQLType="VARCHAR"
Precision="30" >
</Attribute>
</Entity>
|
|
| Figure 21: Layered Customization of Oracle Business Components |
Optionally, the customizer can decide if the customized version of a component should completely and globally substitute the component from which it has extended. By making a metadata entry in the Oracle Business Components application's Project File, the customizing developer can assert that newpackage.CustomOrder should replace demo.Order. At runtime, any request made to work with an instance of demo.Order will instead be given an instance of the customized newpackage.CustomOrder Entity Object. This optional factory substitution works for all framework components.
The net result is that using a combination of component extension and factory substitution, you can tailor the behavior of any delivered component without modifying its source code (without even having the source code for it's Java Implementation Class!) and optionally replace the original version of the component with your customized version. If the factory substitution is used, then even the original application code which knew nothing of your customized component will use the customized version at runtime.
The implementation of the XML Component Definition Extension feature in Oracle Business Components is designed to allow new versions of the components which have been subsequently customized to be added, and other components which have made customizations to them will pickup their new features the next time the application is started.
In summary, Oracle Business Components for Java offers a pragmatic approach for developing, deploying, and customizing enterprise-scale applications in Java for delivery on industry-standard server environments like CORBA, EJB, and Java Servlets.
The Oracle Business Components application framework is familiar to Java developers and makes them more productive by handling all of the hard parts of building efficient, distributed business applications, allowing their coding skills to be focussed truly on the business at hand, and not on the "plumbing".
Finally, developers taking advantage of Oracle Business Components for Java with Oracle JDeveloper will be exploiting the same foundation technology currently being used by Oracle's own Application Development and Consulting divisions for a smooth-slope migration to a component-based Java architecture for enterprise applications.
|
Oracle Corporation
World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA http://www.oracle.com |
Worldwide Inquiries:
1-800-ORACLE1 Fax 650.506.7200 |
Oracle, JDeveloper, and Enabling
the Information Age are trademarks of Oracle Corporation.
All other company and product names mentioned are used for identification purposes only, and may be trademarks of their respective owners Copyright Oracle Corporation 1999 All Rights Reserved |
Bookmark
Entity Object