|
Oracle® Application Development Framework Development Guidelines Manual
10g Release 2 (10.1.2) Part No. B14362-02 |
|
 Previous |
 Next |
|
Oracle® Application Development Framework Development Guidelines Manual
10g Release 2 (10.1.2) Part No. B14362-02 |
|
|
Previous |
Next |
Business services are behind-the-scenes components that mediate between an MVC application and a data source (usually a database). Business services are responsible for the following:
Retrieving data requested by the rest of the application
Representing this data as Java objects usable by the rest of the application (object-relational ["O/R"] mapping)
Persisting changes made by the rest of the application
Implementing business rules, such as validation logic, calculated attributes, and defaulting logic
Providing services that can perform large-scale batch operations on data upon request
Business services segregate the persistence and business logic of an application from the logic that governs the application's UI and control flow. Keeping persistence and business logic separate allows you to reuse them in multiple MVC applications.
This chapter provides an overview of the business service technologies that work out of the box with the Oracle Application Development Framework.
Detailed Comparison of Business Service Architectures
How ADF Business Components Technology Provides Persistent Business Objects
How ADF Business Components Technology Provides Data Access Components
How ADF Business Components Technology Provides Service Objects
How Enterprise JavaBeans Technology Provides Persistent Business Objects
How Enterprise JavaBeans Technology Provides Data Access Components
How Enterprise JavaBeans Technology Provides Service Objects
How OracleAS TopLink Technology with POJO Provides Persistent Business Objects
How OracleAS TopLink Technology with POJO Provides Data Access Components
How OracleAS TopLink Technology with POJO Provides Service Objects
How Enterprise JavaBeans Technology with TopLink CMP Provides Persistent Business Objects
How Enterprise JavaBeans Technology with TopLink CMP Provides Data Access Components
How Enterprise JavaBeans Technology with TopLink CMP Provides Service Objects
JDeveloper provides tools to develop business services using multiple technologies. You can usually choose a business service technology independently of the design of the rest of your application: the Oracle ADF Model (described later) provides a common interface for all business services, allowing your view and controller to access business services almost interchangeably. All of the following technologies are supported out of the box by the ADF Model; you can also support additional business service technologies by creating your own data control classes.
ADF Business Components technology is a fully-featured, XML-based framework for creating business services. ADF Business Components evolved from the Business Components for Java (BC4J) technology distributed with Oracle9i JDeveloper and earlier releases. The ADF Business Components runtime library handles most business service functionality, which you can customize declaratively (by changing the XML files using JDeveloper's RAD tools) or programatically (by extending library classes). Oracle ADF Business Components technology:
Automatically handles O/R mappings and persistence for instances of its own library classes
Allows you to make complex requests for data retrieval using SQL
Automatically handles transaction management, including optimistic or pessimistic locking
Provides a framework for implementing complex business logic
Automatically implements many J2EE design patterns
Has a powerful caching and data passivation system for increasing the performance and scalability of applications
All of the above functionality is fully customizable: if you do not like the way ADF Business Components handles O/R mappings, for example, you can override it.
Enterprise JavaBeans technology is an alternative for creating business services without a framework. While EJB execution depends on an EJB container (which is part of any J2EE-compliant application server), running EJB beans requires no Oracle-specific runtime library or other Oracle-specific technology.
Enterprise JavaBeans technology:
Generally relies upon the application server to handle O/R mappings and persistence (this is called "container-managed persistence," or CMP), although experienced EJB developers can override the application server and code persistence logic themselves ("bean-managed persistence," or BMP)
Requires requests for data to be made using Java APIs or an EJB-specific query language called "EJB QL"
Generally relies upon the application server to handle transaction logic (this is called "container-managed transactions," or CMT), although experienced EJB developers can override the application server and code transaction logic themselves ("bean-managed transactions," or BMT)
Requires you to implement your own business logic
Requires you to implement J2EE design patterns, if desired
Relies on the Java object caching capabilities of the application server
OracleAS TopLink is a technology for providing complex mappings between Java objects and a relational database. TopLink POJO uses ordinary JavaBeans as the Java objects. Unlike users of ADF BC, users of TopLink POJO do not extend a framework; instead, they create their own object model and allow the TopLink runtime to integrate it with the database.
TopLink technology with POJO:
Automatically handles O/R mappings and persistence logic for arbitrary Java objects
Allows you to make complex requests for data retrieval using SQL, EJBQL, or TopLink's own expression language
Automatically manages transactions
Requires you to implement your own business logic
Requires you to implement J2EE design patterns, if desired
Has a powerful caching and data passivation system for increasing the performance and scalability of applications
Like ADF Business Components, TopLink mapping technology is highly customizable.
You can also use TopLink mappings to provide container-managed persistence for EJB entity beans. Doing so will override the CMP behavior of your application server.
Enterprise JavaBeans technology with TopLink CMP:
Uses TopLink technology to handle complex object-relational mappings and persistence
Allows you to make complex requests for data retrieval using SQL, EJBQL, or TopLink's own expression language
Automatically manages transactions
Requires you to implement your own business logic
Requires you to implement J2EE design patterns, if desired
Relies on the Java object caching capabilities of the application server
Web services are a special case. Rather than a technology for implementing business services, web services use XML-based standards to enable application-to-application interaction across the Web regardless of platform, language, or data format. An MVC application can use web services as a wrapper for business services in any format deployed anywhere on the Web.
For example, a web service can wrap Enterprise JavaBeans, ADF Business Components, stored procedures in a database, or other business services written in a Java or any other language. MVC applications can access the service's API using XML messages sent over the Web.
Because of this, web service technology does not itself handle O/R mappings, persistence, data validation, or caching, instead leaving these to the underlying classes.
Oracle ADF also allows you to use any JavaBeans-compliant Java objects as business services for your application. If you choose to go this route, you will need to implement your own framework for data retrieval, persistence, and manipulation. Usually, this involves:
Retrieving data from the database using JDBC
Implementing your own O/R mapping framework
Persisting data to the database using JDBC
Manually coding transaction management using JDBC
Adding your own business logic to the getters and setters for your classes
Creating your own caching mechanism or sacrificing scalability
For the vast majority of users, this option is not recommended. It is intended primarily for users who have already created their own complex framework for business services.
There is no single answer to the question of which business services technology is the best. The right choice of a business services technology depends on your needs, your background, and your priorities.
|
Note: Web services are not included in the following discussion. They have a very specific purpose: providing very loose coupling between an MVC application and its business services. In cases where you need such loose coupling, web services are the only choice; in other cases, they are not an appropriate choice. |
OracleAS TopLink POJO can provide O/R mappings and caching for arbitrary Java objects. For this reason, OracleAS TopLink is generally the best alternative for developers and organizations who have a Java object framework in place or who wish to create one. If you have your own systems or requirements for representing business objects, implementing business logic, and shaping and aggregating the data for clients, TopLink POJO is most likely the best option for your projects. EJB technology requires that your components match EJB specifications, and ADF BC component classes must extend ADF BC framework classes, but TopLink will work with any object model to provide O/R mapping, data retrieval and caching, and transaction functionality.
If you are creating a completely new application, with no existing application infrastructure, Oracle ADF Business Components technology is the most productive option you can choose. ADF Business Components technology handles all aspects of application plumbing completely automatically: O/R mapping, data retrieval and caching, transaction management, and integration with the ADF data binding layer. In addition, ADF Business Components automatically implements key J2EE design patterns to improve performance and scalability; it provides a framework for creating validation rules and other business logic; and it includes base classes to represent your entities and views.
Oracle ADF Business Components and OracleAS TopLink are both 100% J2EE-compliant technologies that will run on any J2EE-compliant application server. Neither of these technologies requires you to use an Oracle database or application server, nor do they in any way restrict which technologies you can use for the view or controller layer of your application.
Both of these technologies, however, make use of some Oracle runtime classes on the application server. If you use ADF Business Components, your business services will extend the ADF Business Components base classes. If you use OracleAS TopLink, your business services will rely on the TopLink runtime to provide O/R mappings and caching.
If you have requirements that prevent you from using any Oracle classes at runtime, you will need to choose a different business service technology: either EJB with CMP provided by the application server, or entirely hand-coded JavaBeans-based business services.
All business services must have a way of handling three main tasks:
Representing data
Retrieving and shaping data for clients to use
Presenting data and specific services to clients
Each of these tasks is accomplished by a separate layer of components: persistent business objects, data access objects, and service objects, respectively.
|
Note: "Components" and "objects" are here being used in a logical, rather than programmatic, sense. While some business service technologies use Java objects for their persistent business objects, data access objects, and service objects, others may use methods, queries, or other logical constructs. |
In general, your business services should always have a layer of persistent business objects, which are based on the most logical representation of the data. If you already have a well-designed data source, the structure of your persistent business objects should reflect the structure of that data source. This practice allows you to write business rules in the most logical way, expressing the properties and requirements for the actual entities your application must represent.
If your application needs to work with customers, orders, and order items, for example, it will generally need to have persistent business objects representing customers, orders, and order items, respectively. You will write business rules on these objects, expressing the properties and requirements for customers, orders, and order items.
Persistent business objects provide a logical representation of your data, but they do not always provide exactly the data your application needs. Data access components organize and shape data to match the needs of a particular application.
For example, your application might need to work with the specific data returned by the following SQL query:
SELECT * FROM ORDER_ITEMS WHERE PRODUCT_ID = 501;
or even the more complicated query
SELECT CUSTOMERS.CUSTOMER_ID, CUSTOMERS.FIRST_NAME, CUSTOMERS.LAST_NAME, ORDERS.ORDER_ID FROM CUSTOMERS, ORDERS WHERE CUSTOMERS.CUSTOMER_ID=ORDERS.ORDER_ID;
Retrieving this information would be handled by data access components. The power of data access components depends on the particular business services technology: some can handle queries of arbitrary complexity; some can only retrieve collections of persistent business objects (the equivalent of queries that start with SELECT * and have only one table in their FROM clause).
Any business services technology must have a way of implementing the three business service layers.
|
Note: Web services technology and Java objects with hand-coded persistence are special cases. In the case of web service technology, the web service itself provides the service object, but the implementation of persistent business objects and data access objects is up to the developer who writes the web service. In the case of Java objects with hand-coded persistence, implementing persistent business objects, data access components, and service objects is also entirely up to the developer. |
The following table shows how the other business services technologies implement persistent business objects, data access components, and service objects.
ADF Business Components technology uses ADF entity object definitions as persistent business objects. As with persistent business objects in all technologies, a single entity object maps to a single entity in the data source (in the vast majority of cases, these data sources are tables or views in a database).
An entity object definition is the template for entity object instances, which are single Java objects representing individual rows in a database table. For example, an entity object definition called "Departments" could provide a template for entity object instances that represent individual rows of the DEPARTMENTS table.
An entity object definition can have up to four parts:
An XML file, which represents the portion of the entity object definition that can be developed declaratively. Most of the information is that needed for O/R mapping, but it can also contain simple validation rules, called validators. For many entity object definitions, the XML file by itself is sufficient.
An entity object class, which represents individual entity object instances. Entity object classes allow you to write complex business logic in Java, when using XML validators is not sufficient. Entity object classes extend the class oracle.jbo.server.EntityImpl. If you do not need custom Java business logic, you need not generate an entity object class—ADF can use oracle.jbo.server.EntityImpl directly to represent rows of the data source.
An entity definition class, which represents the data source object in its entirety. Entity definition classes act as Java wrappers for the XML file, so if you need special handling of the metadata (for example, if you need to change it dynamically), you can add this code in the entity definition class. Entity definition classes extend the class oracle.jbo.server.EntityDefImpl. If you do not need custom handling of your metadata, you need not generate an entity definition class—ADF can use oracle.jbo.server.EntityDefImpl directly to wrap the metadata.
An entity collection class, which represents the cache of rows (instances of the entity object class) held in memory for a single user. The vast majority of developers do not need to generate an entity collection class: you should do so only if you want to override ADF Business Components' default caching behavior.
When entity object definitions are based on database objects, columns in the database object map to a single entity object attribute in the entity object definition. The definitions of these attributes (reflected in the entity object definition's XML file) reflect the properties of these columns, such as the columns' data types, column constraints, and precision and scale specifications. When entity object definitions are based on objects from other data sources, entity object attributes map to "columns" from those objects, as defined by the developer. If you generate an entity object class, attributes will also be represented as fields in that class.
As mentioned previously, you can declaratively add validation logic to entity object definitions or attributes in the form of validators. JDeveloper comes with four simple validators:
CompareValidator, which compares an attribute to a value (either a literal value or a value drawn from the data source).
ListValidator, which checks to see whether an attribute is in a list of values (either a literal list or the results of a query).
RangeValidator, which checks to see whether an attribute is between two literal values.
MethodValidator, which can invoke any method which returns a boolean value. Validation is passed if the method returns true.
In addition, you can create your own custom validators. These require coding to create initially, but once created, they can be applied declaratively in many different projects.
If the default validators do not meet your needs, and you do not want to create your own validators, you can also put validation code in the entity object class: in the setter methods (for attribute-level validation) or in a method called validateEntity() (for multiattribute validation).
Entity object classes also provide hooks for other business logic, including the methods create(), which is called whenever a new row is created, and remove(), which is called whenever a row is deleted. By adding business logic to these methods, you can ensure that the logic is invoked whenever rows are created or deleted.
Finally, although ADF Business Components technology automatically handles DML operations for you (by issuing INSERT, UPDATE, and DELETE commands to the database), you can also override this behavior by overriding the doDML() method in the entity object class—if, for example, you want to use stored procedures in the database to handle DML operations.
Relationships between entity object definitions are handled by Oracle ADF associations, which define a relationship between two Oracle ADF entity object definitions based on sets of entity attributes from each. These can range from simple one-to-many relationships based on foreign keys to complex many-to-many relationships. For example, associations can represent:
The one-to-many relationship between a customer and all orders placed by that customer
The one-to-one relationship between a product and its extended description (if these are represented by separate entity object definitions)
The many-to-many relationship between products and the warehouses that currently stock them
ADF Business Components technology uses ADF view object definitions as data access components. ADF view object definitions collect data from the data source, shape that data for use by MVC applications, and allow those applications to change the data in the Oracle ADF Business Components cache.
A view object definition can have up to four parts:
An XML file, which represents the portion of the entity object that can be developed declaratively. This information consists of the mechanism (usually a SQL query) that the view object uses to retrieve data from the data source, and the way in which the columns of the SQL query map to entity attributes (which handle actual O/R mapping). For many view object definitions, the XML file by itself is sufficient.
A view object class, which represents an individual instance of the query result set, called a view object instance. Different users will always use different view object instances, but the same user may also use multiple view object instances. View object classes allow you to write custom methods that affect multiple rows in a query. View object classes extend the class oracle.jbo.server.ViewObjectImpl. If you do not need to write custom view object methods, you need not generate an entity object class—ADF can use oracle.jbo.server.ViewObjectImpl directly to represent instances of the query result set.
A view row class, which represents individual rows of the query result. View row classes allow you to write custom methods that affect a single row of data, and they provide typesafe accessors to retrieve and change data. View row classes extend the class oracle.jbo.server.ViewRowImpl. If you do not need custom row-level methods or typesafe accessors, you need not generate a view row class—ADF can use oracle.jbo.server.ViewRowImpl directly to represent rows of the data source. (ViewRowImpl contains the getAttribute() and setAttribute() methods, which allow you to retrieve and change data, but these methods are not typesafe.)
A view definition class, which represents the query itself. View definition classes act as Java wrappers for the XML file, so if you need special handling of the metadata (for example, if you need to change it dynamically), you can add this code in the view definition class. View definition classes extend the class oracle.jbo.server.ViewDefImpl. If you do not need custom handling of your metadata, you need not generate a view definition class—ADF can use oracle.jbo.server.ViewDefImpl directly to wrap the metadata.
Columns in the query map to individual view object attributes in the view object definition. The definitions of these attributes (reflected in the view object's XML file) reflect the properties of these columns, including data types and how, if at all, they should be mapped to entity object attributes. If you generate a view row class, attributes will also be represented as fields in that class.
A view object definition can be based on a query of arbitrary complexity: joins, calculated attributes, and even group functions can be represented within a view object definition.
As mentioned previously, view object definitions handle the mapping of query columns to entity object attributes. There is no requirement that attributes of a single view object all map to attributes of the same, or even any, entity object. The view object handles reading from the data source, and the entity object definitions (if any) handle DML. This operation of the ADF Business Components cache is one of its most powerful features.
Among Sun's J2EE BluePrints design patterns is the "fast-lane reader" pattern. Rather than search through persistent business objects for needed data, a fast-lane reader queries the data source directly. This is a much faster operation than searching the persistent business objects, but has the disadvantage of being read-only, since persistent business objects handle updates to the data source.
View object definitions are an improvement on the fast-lane reader pattern. Like the fast-lane reader, they query the database directly, but they optionally store the results in entity object instances and maintain pointers to those instances. Therefore, they can query the database with fast-lane reader speed but avoid the read-only disadvantages of standard fast-lane readers.
Relationships between view object definitions are handled by Oracle ADF view link definitions, which define a relationship between two Oracle ADF view object definitions based on sets of entity attributes from each. Like associations, these can range from simple one-to-many relationships based on foreign keys to complex many-to-many relationships.
Individual view object instances can also be related by individual view link instances, which create a master-detail relationship between the query result sets. For example, suppose that you have view object definitions representing a query for department information and a query for employee information, and a view link between the view object definitions representing the relationship between a department and its employees. If an instance of the former view object definition, allDepartments, is related to an instance of the latter, employeesInDepartment, by an instance of the view link, those instances will be synchronized: whenever a particular row of allDepartments is selected, employeesInDepartment will only display details of that row.
ADF Business Components technology uses ADF application module definitions as service objects. ADF application module definitions serve as a single point of contact between MVC applications and the business services layer; they manage transactions; and they provide a container for view object and view link instances.
An application module definition can have one or two parts:
An XML file, which represents the portion of the application module definition that can be developed declaratively: the view object and view link instances that the application module definition contains and the way in which they are related. For many application module definitions, the XML file by itself is sufficient.
An application module class, which lets you write custom code such as service methods that an MVC application can invoke for batch data handling. Application module classes extend the class oracle.jbo.server.ApplicationModuleImpl. If you do not need to write custom service methods, you need not generate an application module class—ADF can use oracle.jbo.server.ApplicationModuleImpl directly.
The most important feature of an application module definition is its data model—the view object and view link instances it contains. These specify what data the client will have access to, and what relationships hold within that data.
You can use application module definitions in two different ways:
As a service object, in which case each instance of the MVC application has access to one instance of the application module. These root-level application module instances control ADF BC transaction objects, which in turn control the entity and view caches.
As a resusable object for nesting, in which case you can create a data model and service methods on it and then nest one of its instances in other application module definitions. Those application module definitions can, in turn, access the nested module's methods and data model. Nested application modules share the root-level application module's transaction.
Application module instances are elements in an application module pool, a configurable resource manager that automatically decides whether an instance needs to be maintained, with its caches, in memory, whether it can be serialized to the database to save memory, or whether it can be removed altogether. Application module pooling can greatly increase the scalability of your application.
Enterprise JavaBeans technology uses EJB entity beans as persistent business objects. As with persistent business objects in all technologies, a single entity bean maps to a single entity in the data source (in the vast majority of cases, these data sources are tables or views in a database). For most purposes, applications should use container-managed persistence (CMP), which allows an external container (such as an application server or the TopLink runtime) to handle O/R mappings. The alternative is bean-managed persistence (BMP), which shares many disadvantages with Java classes that use hand-coded persistence: to use BMP entity beans, you must handle O/R mappings, persistence, and data retrieval yourself. BMP beans are mostly useful for applications that need to use a data source other than the database.
EJB CMP entity beans can have up to six parts:
An element in the EJB deployment descriptor, an XML file that describes all aspects of a set of EJB beans. This entry describes the bean's metadata, such as how its fields are mapped to database columns.
A bean class, which is an abstract class listing the fields of the bean.
A local home interface, which contains methods that create instances of the bean class, for use by other beans in the same container.
A home interface, which contains methods that create instances of the bean class, for use by classes outside the container.
A local interface, which is how other EJB beans interact with the entity bean.
A remote interface, which is how Java objects outside the EJB container interact with the bean.
Note that a CMP entity bean does not have any parts that can be directly instantiated: it consists of an XML element, an abstract class, and three interfaces. The CMP provider will automatically extend the abstract class to create an implementation class, which is directly instantiated to create entity bean instances, which represent single rows in the database. Similarly, the CMP provider automatically implements the home and/or local home interfaces. You will never need to work with the implementation classes directly: your application will always refer to entity bean instances through the local or remote interface, and to the home through the home or local home interface.
Columns in the database object map to single fields in the entity bean class and single subelements of the XML element. The attributes of the XML subelements reflect the properties of these columns, such as the columns' data types, column constraints, and precision and scale specifications.
Unlike ADF entity object definitions, EJB entity beans do not provide hooks for business logic. You cannot implement business logic in accessor methods because the implementation of those methods is left to the CMP provider (in the bean class, the methods are abstract). However, JDeveloper can automatically generate a data transfer object for an entity bean. The data transfer object is an implementation of a J2EE Blueprints design pattern and serves as an intermediary between MVC applications and the entity bean. Data transfer objects expose some or all of the entity bean's attributes, and have getters and setters that you can modify to implement business logic. They do not, however, provide a convenient way to implement multiattribute logic. If you use EJB technology, you must implement multiattribute logic in the controller layer or write your own framework code to create it.
Relationships between entity beans are handled by container-managed relationships (CMRs), which define a relationship between two entity beans based on sets of fields from each. These can range from simple one-to-many relationships based on foreign keys to complex many-to-many relationships. For example, associations can represent:
The one-to-many relationship between a customer and all orders placed by that customer
The one-to-one relationship between a product and its extended description (if these are represented by separate entity object definitions)
The many-to-many relationship between products and the warehouses that currently stock them
Unlike ADF Business Components technology, Enterprise JavaBeans technology does not use actual objects to provide data access components. Instead, EJB applications use EJB finder methods as data access components.
EJB finder methods are methods on the EJB's home interface. When you create a finder method, you can specify a query in a specialized query language called EJBQL. The query will get added to the deployment descriptor, and the CMP provider will use it to generate code to search among the entity bean instances for those matching the query conditions.
Unlike ADF view object definitions, EJB finder methods have limits to their complexity. Since they simply return collections of entity beans, they cannot implement joins or calculated attributes. Also, because EJB finder methods query the entity beans instead of the database, they do not provide the efficiency of the fast-lane reader pattern. You can, of course, implement the fast-lane reader pattern yourself, but since this pattern does not create a collection of entity beans (but rather simply a list of data), you cannot use it to perform DML operations. For optimal performance, you should create and use a fast-lane reader whenever read-only data is sufficient, and use EJB finder methods in other cases.
Enterprise JavaBeans technology uses EJB session beans as service objects. Session beans serve as a single point of contact between MVC applications and the business services layer, and provide access to entity bean home and local home interfaces.
As with entity beans, there are two types of session beans: for most purposes, applications should use container-managed transactions (CMT), which allows an external container (such as an application server or the TopLink runtime) to handle transactions. The alternative is bean-managed transactions (BMT), which requires you to write code to handle transactions yourself, and is useful only if you have specialized requirements for transaction handling.
An EJB CMT session bean definition can have up to six parts:
An element in the EJB deployment descriptor. Unlike the elements for entity beans, this element contains only the bean's name.
A bean class, which lets you write custom code such as service methods that an MVC application can invoke for batch data handling. Unlike bean classes for CMP entity beans, this class is not abstract.
A local home interface, which contains methods that create instances of the bean class, for use by other beans in the same container.
A home interface, which contains methods that create instances of the bean class, for use by classes outside the container.
A local interface, which is how other EJB beans in the container interact with the session bean.
A remote interface, which is how Java objects outside the EJB container interact with the bean.
Unlike ADF application module definitions, a session bean does not contain a complete data model. Instead, it has EJB local references to the local home interfaces of the "master" entity beans. Detail entity beans are accessed from the masters through container-managed relationships.
The ADF model layer can currently use only stateless session beans. These are beans that do not maintain any state in between client access—they simply serve as immediate intermediaries between the client and the database. The MVC application sends one request to the bean to retrieve data, caches the entity bean instances, and sends another request to the bean to post the data and commit. JDeveloper allows you to create stateful session beans as well, but you cannot create data controls from them.
TopLink technology with POJO uses ordinary JavaBeans classes as persistent business objects. You create the classes yourself, implementing everything except their interaction with the database. This interaction is handled by the TopLink runtime, which uses a descriptor—an element in the TopLink deployment descriptor, an XML file that describes all aspects of TopLink mappings for a set of JavaBeans classes. The descriptor describes the way in which the classes map to database columns, as well as providing information on keys and sequences.
One of the most important features of TopLink is its automation of complex O/R mappings. TopLink technology provides these O/R mappings to allow you to map database objects to arbitrary Java objects, even Java objects that have a substantially different structure than the objects in the database.
TopLink provides the following mappings between fields and database columns:
Direct-to-field mappings, which are the simple mapping between one field and one database column.
Type conversion mappings, which allow more complex conversions between the datatype of the field and that of the database column (for example, a String to a NUMBER or DATE).
Object type mappings, which allow the data stored in the Java objects to be fundamentally different from the database data (for example, you could require a value of "M" in the database to map to a value of "male" in the field, and a value of "F" to map to a value of "female").
Serialized object mappings, which help you to efficiently map large data objects like BLOBs and multimedia files.
Transformation mappings, which allow you to map several database columns onto a single field.
Array mappings, which map VARRAYs and nested tables into Java arrays.
Structure mappings, which map database structures onto Java classes.
Unlike ADF Business Components, TopLink technology is specifically intended to manage the interaction between an existing Java object framework and the database. For this reason, TopLink does not provide validation or other business rules functionality; such functionality is left up to your object model.
Relationships between JavaBeans classes are handled in the deployment descriptor by Java object mappings. As it does with O/R mappings, TopLink has a very flexible system of relationships, allowing you to relate Java objects based on a wide variety of relationships in the database:
Simple one-to-many relationships, such as that between a customer and all orders placed by that customer
Simple one-to-one relationships, such as that between a product and its extended description (if these are represented by separate entity object definitions)
Many-to-many relationships, such as that between products and the warehouses that currently stock them
One-to-many relationships between mapped objects and unmapped objects (such as Strings)
Aggregate object relationships: one-to-one relationships between JavaBeans classes that require them to map to the same database row
Aggregate collection relationships: one-to-many relationships that can be programmatically defined (as opposed to one-to-many relationships based on attribute matching or foreign keys)
Variable one-to-one relationships, which can relate interfaces (with variable implementation classes) as opposed to JavaBeans
Relationships based on REFs
One-to-many or many-to-many relationships based on nested tables
Like Enterprise JavaBeans technology, TopLink technology with POJO does not use actual objects to provide data access components. Instead, it uses TopLink queries as data access components.
TopLink queries are elements in the JavaBeans descriptors. When you create a TopLink query, you can specify it in SQL, EJBQL, or TopLink's own structured expression language. The TopLink runtime will use it to search in the TopLink cache for objects matching the query.
Like EJB finder methods, TopLink queries have limits to their complexity. Since they simply return collections of JavaBeans classes mapped to database tables, they cannot implement joins or calculated attributes. They also do not provide the efficiency of the fast-lane reader pattern, although TopLink does have a separate sort of query, called a report query, which does. The results of report queries, however, cannot be used to perform DML operations.
OracleAS TopLink technology does not provide true service objects. The TopLink deployment descriptor serves to aggregate all the JavaBeans classes, which the MVC portion of the application works with directly.
There is no fixed data model in TopLink. Applications can dynamically traverse Java object mappings to get detail or other related objects from their source objects.
TopLink does maintain a cache. Unlike ADF Business Components or standard EJB technology, the TopLink cache, and a single database transaction, is shared across users. The TopLink runtime automatically merges data to maintain consistency. The cache and transaction are accessed through a Java object called a TopLink session.
The TopLink runtime can also act as a CMP provider for EJB entity beans. Using TopLink as your CMP provider has the advantage of automating far more complex O/R mappings. Direct-to-field, type conversion, object type, serialized object, and transformation mappings are all available for EJB entity beans using TopLink CMP.
Like other entity beans, TopLink entity beans are related through CMRs.
Like other CMP providers, the TopLink runtime uses EJB finder methods as data access components. However, the TopLink runtime allows you to specify queries in SQL, EJBQL, or TopLink's own structured expression language.
