A B C D E F H I J M N O P Q R S T U V W X
A |
This setting appears in the Attribute Settings page of the View Object Wizard and Editor and in the Attribute Editor. For a view object attribute, the alias becomes part of the view object's SQL statement when it is different from the attribute name (the default); for example, if you enter myEname as the alias for the Ename attribute, the SQL statement will contain the clause Emp.Ename as myEname. An alias is useful if you have two attribute names that are the same, such as the primary and foreign keys in a join, and you need to make their names unique.
The business logic tier has one or more application modules that the other tiers — clients and the database — interact with. An application module performs a specific application task, for example, handling online orders or processing salary increases. An application module has these main characteristics:
It represents the data model that your client uses. To create the data model, the application module contains business components, including instances of view objects and view links. (This containership is similar to how a Java frame can contain instances of components, such as a list box and a grid control.)
It can contain other application modules, called nested application modules. One application module can contain a variety of simpler application modules that together provide complex functionality. For example, an OnlineOrders application module could contain an AddNewCustomer application module.
It keeps track of all changes that affect data in the database. The top-level application module provides a transaction context for the view object instances it contains, including those in all nested application modules. This is an important consideration when deciding what application modules your application needs. For example, you could combine creating an order and adding a customer into the same transaction.
It provides remotely accessible methods, which implement the application module behavior. You can add custom methods and selectively export those public methods you want clients to use. For example, an application module that processes employee salary increases might export methods for finding employee salary information and adding the raise.
A top-level application module has one connection to the database.
You can deploy the same application module in multiple configurations, such as CORBA, EJB, or locally, without changing its code. Also, the same application module can be used in a physical one-tier, two-tier, or three-tier application (tiers on one, two, or three computers) without code changes. You are not tied to a particular deployment platform after development is complete.
As discrete units, application modules are easily reused in the business logic tiers of other applications.
When programming your business logic tier, business logic is placed at different levels to make business components easily reusable:
An entity object contains business logic pertaining to a single business entity. All view objects based on the entity object share the logic. At the entity level, calculations are performed in Java code.
A view object contains logic pertaining to a view, which is defined by a SQL SELECT statement. This can include SQL-calculated expressions, joins, unions, nested subselects, and so on. You can also add code to the Java source, for example, you can propagate events to the UI, or create a method that calls an entity method that you want to expose for this view.
An application module's source files can contain logic specific to the task it performs — logic not appropriate to put in an entity object or view object, which multiple application modules performing different tasks can use. If two applications use the same view, you would put logic specific to one of the applications in its application module source files instead of in the entity or view object source files. As a general guideline, if you have one form per task, you could structure your application so there is one application module per form. An application module represents a data model for a task that is accomplished within one transaction.
An application module lets you gather data tailored to a client interface (such as a form), so data can be retrieved in one network roundtrip instead of multiple trips. You can also perform calculations in the business logic tier through remotely accessible methods, reducing client overhead. For bulk operations on application data, you can perform the operation in the business logic tier without downloading all of the data to the client; changes to the data the client is currently viewing is automatically synchronized.
To create and edit an application module at design time, use the Application Module Wizard and Editor. You can also create a default application module by using the Business Components Project Wizard and Package Wizard.
At runtime, a client creates an instance of an application module for its use. It can create an instance of an application module you created at design time, or an instance of the base application module class, called a generic application module. You can use a generic application module when you want a container for dynamically created view objects, view links, and application modules. For example, if you have a complex application with a client menu containing many tasks, you might decide to create a generic application module that instantiates application modules as needed, based on the menu choice, within the same transaction.
A client can use application module instances in a pool. For example, in the case of a web application, you may have 1,000 users but you know that only 100 will be using a certain application module at one time. So you keep 100 application module instances in a pool. When a client needs an application module instance, it takes a free one from the pool and releases it to the pool after either committing or rolling back the transaction. Because the instance is precreated, end users are saved the time it takes to instantiate the application module when they want to perform a task. Typically, web-based JSP clients use pools.
A Java class extending directly or indirectly from oracle.jbo.server.ApplicationModuleImpl. The Application Module Wizard, Business Components Project Wizard, or Package Wizard can generate this class. You can add custom code to the source file, such as methods specific to the application module task but not appropriate to place in a view object or entity object class.
You can optionally specify that this class extend from a custom class (which must directly or indirectly extend the ApplicationModuleImpl class and be in the project classpath); for example, you might do this if you want to reuse code that's already been written or if your organization decides to customize the business components framework to meet specific needs.
These tools let you create and edit application modules. You can also create a default application module by using the Business Components Project Wizard and Package Wizard.
While the business components project is open, to create an application module with the Application Module Wizard either:
Choose File | New, click the Business Components tab, and double-click Application Module.
In the Workspace view of the Navigator, right-click a business components package and choose Create Application Module.
To edit an application module, in the Workspace view of the Navigator, right-click the application module and choose Edit module.
When creating an application module, the wizard lets you specify the following information, listed by panel:
Name panel. An application module name (perhaps ending with the string "Module"), and the package the application module should be placed in, and optionally the class the application module extends (which must extend directly or indirectly from from oracle.jbo.server.ApplicationModuleImp).
Data Model panel. Specify which view objects and view links will be included in the application module. View objects in the application module's project appear in the Available list: master views appear directly beneath the package, while detail views (related by view links) appear beneath the master view. To include a master view, select AppModule in the Data Model list, then shuttle a view object from the Available list to the Data Model list. To include a detail view, while the master is selected in the Data Model list, shuttle the detail view over from the Available list. If a view object is used in the data model more than once, the instances must have a different member names to prevent naming conflicts.
Application Modules panel. When application modules are nested, the outer-most (top-level) application module provides the transaction context for the others. The Available list displays all application modules in the project; if you shuttle an application module to the Selected list, it becomes nested within the application module you are defining in the wizard. Optionally supply a member name that identifies an instance of an application module; if an application module is used more than once, member names can help you distinguish between the instances. When you nest an application module within another, the parent application module can use the objects and code in the child application module.
Java panel. If you want to customize the application module behavior by adding code, you can specify that the wizard generate a Java file for the application module class.
When editing an application module, the editor lets you specify the following information, in addition to the previous panels (except for the Name panel):
Remote panel. When you are ready to deploy, select Remotable Application Module to generate proxies, stubs, and skeleton classes. You must select this option to create a physical three-tier application (with each tier on a different computer). For each distributed object deployment type you select, you can specify the client projects where you want the files to be generated. Three types of files are created for your target platform: files that are only used by the business logic tier (located in the server subpackage), files that are used in both the business logic and client tier (in the common subpackage), and files that are used only in the client tier (in the client subpackage).
Client Methods panel. Select methods to export, so a client can use them in a tier-independent manner. Methods you've written in the application module class file appear in the Available list; to appear in the list, they must be of a data type that implements the Serializable interface. To export them, move them to the Selected list. Before you can use this panel, in the Java panel, you must select Generate Java File(s). When you click Finish, an export interface file, directly or indirectly extending oracle.jbo.ApplicationModule, is created. You need to do a few other things before the client can use the methods, including importing the interface in the client code and invoking the method properly in the client code, as described in the Business Components for Java online help.
Property panel. To add a property, type a property name and value, then click Add. You can also add and edit values for existing properties, and delete properties.
Defines a relationship between two entity objects based on common attributes. The relationship can be one-to-one or one-to-many; you can use two one-to-many associations to implement a many-to-many relationship. The association allows entity objects to access the data of other entity objects through a persistent reference. Although the same type of relationship can also exist at the table level through a foreign-key relationship or object REF, an entity object only needs an association to access the data of another entity object. You can create associations regardless of whether the database has the corresponding referential integrity constraints.
An example of a relationship is a one-to-many association between departments and employees; they might have a relationship where the Dept entity object has a Deptno attribute that is related to the DeptNo attribute of the Emp entity object.
You can define and edit associations in the Association Wizard and Editor. You also can generate default associations, based on referential integrity constraints in existing tables (reverse generation), by using the Business Components Project Wizard and Package Wizard. For forward generation, creating associations can optionally add foreign-key constraints to the tables you generate. If you add referential integrity constraints to tables after you've already generated entity objects, you can simply go into the Entity Object Editor and click Finish to create the new association.
Through optional association accessors in the entity objects, you can access data on the other side of the association. For example, inside the Dept entity object, you could call the getEmps method and retrieve a row set of Emp entity objects that reflect the employees working in the current department; the next time you call getEmps, it returns the same row set. Your code can traverse associations in either direction (master to detail, and detail to master). An entity object can traverse multiple associations to get the data it needs.
An association can be a composition, where the source entity object "owns" the destination entity object: no destination entity object can be created without the owning entity object existing first.
A business component association is an implementation of the UML association concept.
These tools let you create and edit associations. You can also create default associations, based on referential integrity constraints in existing tables (reverse generation), by using the Business Components Project Wizard and Package Wizard.
For forward generation, creating associations can optionally add relationships to the tables you generate; for example, you might want other applications (that don't use Business Components for Java) to have access to the same relationships. You create tables from entity objects by using the Create Database Objects Tool.
While the business components project is open, to create an association with the Association Wizard either:
Choose File | New, click the Business Components tab, and double-click Association.
In the Workspace view of the Navigator, right-click a business components package and choose Create Association.
To edit an association, in the Workspace view of the Navigator, right-click the association and choose Edit association.
When creating an association, the wizard lets you specify the following information, listed by panel:
Name panel. An association name (pick something that describes the relationship, perhaps ending with the string "Assoc" to make it easy to identify) and the package the association should be placed in. Ideally, the association resides in the same package as the entity objects it associates, but this is not required.
Association Entities panel. Select the entity objects you want to associate. After the association is defined, the entity objects can use the association to transparently traverse to the other side of the association in a predefined manner. For example, the employees of a department might be accessed through a department by issuing the call deptImpl.getEmps().
Role Attributes panel. Select the attributes that define the relationship between the entity objects of an association. (You must specify the same number of attributes for each entity object, in the proper order.) You can optionally specify all attributes that define a key: when you shuttle a key to the Selected Attributes list, the attributes associated with that key automatically appear. Also, if you select a key in the source page, the matching key (if applicable) will be included by default on the destination page.
Association Properties panel. Specify behavioral aspects of the association, including cardinality, whether to expose association accessors that return data from the other side of the association, the names of the accessors, whether to generate key constraints during forward generation, and whether the association is a composition. The accessors are placed in the entity object class.
When editing an association, the editor lets you specify the same information, except it excludes the Name panel.
If you add referential integrity constraints to tables after you've already generated entity objects for them, you can simply go into the Entity Object Editor and click Finish to create the new associations.
A characteristic of an entity object or view object, implemented as a JavaBean property of the object class. An attribute can correspond to a database column, or be independent of a column. There are five kinds of attributes:
|
Attribute kind |
Defined where? |
Value derived from a database query? |
Persisted in the database? |
|
persistent |
entity or view object level |
yes |
yes (the value outlives the class that created it) |
|
transient |
entity or view object level |
no |
no |
|
entity-derived |
view object level |
no |
no |
|
SQL-derived |
view object level |
yes |
no |
|
dynamic |
view object level, at runtime |
no |
no |
Entity objects can have the following kinds of attributes:
Persistent. A entity object attribute that is persisted in the database (the Persistent attribute setting is selected).
Transient. A entity object attribute that is not persisted in the database (the Persistent attribute setting is deselected).
When you first create an entity object using reverse generation, a persistent entity attribute is created for each table column. After, if you change the table, you need to manually change the attribute.
View objects can have the following kinds of attributes:
Persistent. A view object attribute based on a persistent entity attribute. The data is cached at the entity object level.
Entity-derived. A view object attribute based on a transient entity attribute. The data is cached at the entity object level.
Transient. A view object attribute that is not based on an entity attribute and does not contain a SQL expression. The data is cached at the view object level.
SQL-derived. A view object attribute that is not based on an entity attribute and does contain a SQL expression. The data is cached at the view object level.
Dynamic. A view object attribute that is created with the addDynamicAttribute method. You can use it to store information created at runtime that you want to store with the row data. It is used only by the view object that created it. Dynamic attributes are handled the same way as design time attributes. Attributes can be any Serializable object. The data is cached at the view object level.
The value of a SQL-derived attribute is the result of a SQL statement. For example, a YearsOfService attribute might be the difference between an employee's hire date in the database and the current date. Alternatively, you could create a transient attribute and write code to perform a calculation in a Java file to set its value. In general, using SQL-derived attributes is more efficient than performing data-intensive calculations in Java.
In Business Components for Java, the term attribute is based on the UML definition, not the XML definition. In UML, an attribute is a named property of a class that describes a range of values that instances of that class might hold.
The Attribute Editor lets you edit entity and view attributes. To access the editor, in the Workspace view of the Navigator, select an entity object or view object, then right-click an attribute in the Structure pane and choose Edit attribute. The Attribute Editor lets you specify properties at the attribute level.
When editing an attribute, the wizard lets you specify the following information, listed by panel:
Entity Attribute panel. Settings include attribute and column name, attribute and column type, default value, whether it is updateable always, when new, or never, whether to refresh after update or insert, whether it is used to indicate the row has changed, and whether it is a primary key, mandatory, persistent, queriable, and unique. In general, if you are performing reverse generation, you don't want to change the primary key, mandatory, database column name, column type, and unique settings that were received from the table. For forward generation, the primary key, mandatory, persistent, database column name, column type, and unique settings are used to generate tables.
View Attribute panel. Settings include attribute and alias name, attribute type, default value, SQL expression, whether it is updateable always, when new, or never, and whether it is queriable. (view attributes only)
Validation panel. Add, edit, or remove validation rules. New rules can be applied at the entity object level, attribute level, or both. Rules can be reordered within a level, which is useful when you have multiple validation rules per attribute and want to control the order of rule firing. (entity attributes only)
Property panel. To add a property, type a property name and value, then click Add. You can also add and edit values for existing properties, and delete properties.
Attributes can have the following settings. For entity object attributes, the settings can affect forward generation or the settings can be derived from an existing table (reverse generation).
|
Attribute Setting |
Forward Generation |
Reverse Generation |
Persistent Attribute |
Transient Attribute |
Persistent Attribute (view level) |
Transient Attribute |
SQL-Derived Attribute |
Entity-Derived Attribute |
|
N/A |
Default based on column name; you can change it to any Java identifier name. |
Required |
Required |
Default based on entity attribute name |
Required |
Required |
Default based on entity attribute name |
|
|
N/A |
Default based on column data type; you can choose another type in the list. |
Required |
Required |
Not modifiable; uses entity attribute setting |
Required |
Required |
Not modifiable; uses entity attribute setting |
|
|
N/A |
N/A |
Optional |
Optional |
N/A |
N/A |
N/A |
N/A |
|
|
Becomes the table's primary key, or part of it if you specify multiple primary keys for a table (a composite key) |
From the table; it must match the table. |
Selectable |
Selectable, but you should leave it deselected in most cases |
N/A (the entity attribute setting applies) |
N/A |
N/A |
N/A (the entity attribute setting applies) |
|
|
Becomes a mandatory column in the table (a NOT NULL constraint is generated for that column in the table). |
From the table; this value must match the table, or you might get problematic runtime behavior or an exception. |
Selectable |
Selectable |
N/A (the entity attribute setting applies) |
N/A |
N/A |
N/A (the entity attribute setting applies) |
|
|
Only persistent attributes are added to the table. |
All attributes derived from the table are persistent; if you change it, this column does not get populated through the business components framework. |
Selected |
Deselected |
N/A (the entity attribute setting applies) |
N/A |
N/A |
N/A (the entity attribute setting applies) |
|
|
N/A |
N/A |
N/A |
N/A |
When selected, this attribute appears in the view object's SQL Select statement. |
When selected, this attribute appears in the view object's SQL Select statement. |
When selected, this attribute appears in the view object's SQL Select statement. |
When selected, this attribute appears in the view object's SQL Select statement. |
|
|
N/A |
N/A |
Selectable |
Selectable |
Based on entity attribute setting; can make setting more restrictive. |
Selectable |
Selectable |
Based on entity attribute setting; can make setting more restrictive. |
|
|
N/A |
N/A except when the java.sql.type for this attribute is CHAR, then all Refresh After checkboxes are selected. |
Selectable |
N/A |
N/A (the entity attribute setting applies) |
N/A |
N/A |
N/A |
|
|
Becomes the table's column name |
From the table; it must match the table. |
Required; it must match the table. |
N/A |
N/A (the entity attribute setting applies) |
N/A |
N/A |
N/A |
|
|
Becomes the table's column data type |
From the table; it must match the table. |
Required; it must match the table. |
N/A |
N/A (the entity attribute setting applies) |
N/A |
N/A |
N/A |
|
|
N/A |
N/A |
Selectable |
N/A |
Selectable |
N/A |
Selectable |
N/A |
|
|
If selected, the column has a unique constraint. |
From the table; it must match the table. |
Selectable |
N/A |
N/A (the entity attribute setting applies) |
N/A |
N/A |
N/A |
|
|
N/A |
N/A |
Selectable |
N/A |
N/A |
N/A |
N/A |
N/A |
|
|
N/A |
N/A |
N/A |
N/A |
Default based on entity attribute name; optional, but can use to prevent name conflicts |
Optional |
Optional, can use to prevent name conflicts |
Optional |
|
|
N/A |
N/A |
N/A |
N/A |
N/A |
N/A |
Required |
Optional |
B |
An application-specific component derived from the business components framework:
It is implemented as an XML metadata file and possibly one or more Java files.
The XML file stores metadata: the descriptive information about features and settings of an application that you can declare with the Business Components for Java wizards and editors during design time. Some examples of metadata are names and types of attributes, a SQL query, and validation rules. The Java file(s) store the component’s custom code, which implements application-specific behavior. Information that is descriptive in nature is stored as XML while programmatic information is in Java.
Business components are organized into a standard Java package structure. For example, if a view object named DeptView is in the package MyDept, then the MyDept directory would contain the files DeptView.xml and DeptViewImpl.java. You specify the package while creating a component in a wizard and it places the files in the correct locations for you.
The XML description might have:
<ViewObject
Name="DeptView"
...
ComponentClass="MyDept.DeptViewImpl">
The Java code might have:
package MyDept;
...
public class DeptViewImpl extends
oracle.jbo.server.ViewObjectImpl {
...
}
A programming framework, implemented in Java and XML, that enables productive development, deployment, and flexible customization of multi-tier, database-savvy applications from reusable business components. These three-tier applications are made of a client, a business logic tier containing the business logic and database views, and a database server containing tables with the data the application uses. You can use the Business Components for Java wizards and editors to build the business logic tier based on your specifications; you can create both Java and JSP clients using the JDeveloper development environment; Oracle 8i or Oracle 8i Lite provides the database server. Because business rules, views, and custom code are stored in a separate tier, clients can be "thin" so they are easier to install and maintain: changes in the business logic tier often require no modification to the clients that use it.
The business logic tier is made of one or more application modules that contain view objects, representing views of data and optionally including calculations. View objects can use entity objects, representing business entities and mapping to database tables, to enforce business logic. View links represent master-detail relationships between view objects and are also contained in an application module; associations represent bidirectional relationships between entity objects. These modular components are easy to customize, maintain, and reuse in other applications. The component-based framework handles many repetitive coding tasks, including master-detail coordination, locking, and transaction management, including changes in the business logic tier’s data cache and posting changes to the database.
By using the Business Components for Java design-time wizards and editors, you can build business logic tiers by defining the characteristics of components: their attributes, relationships, and business rules. Business Components for Java generates Java source code and XML metadata to implement the behavior you have specified. Because the code inherits from a framework, the Java source files are concise and do not contain large amounts of generated code, so it's easy to see where to add your custom code. You can use JDeveloper to add the Java code to enhance or change the behavior, and easily test the application services, independently of the deployment platform. Business Components for Java then helps you deploy application modules (without modification) to an Oracle 8i JServer environment as Oracle 8i CORBA server objects (physical two-tier), Visibroker CORBA server objects (physical three-tier), OAS EJB session beans (physical three-tier), or Oracle 8i EJB session beans (physical two-tier), or in local mode (physical one- or two-tier).
This wizard appears automatically after creating a business components project in the Project Wizard. Alternatively, you can choose Wizards | Business Components while a project is selected. The wizard helps you specify
the connection to the database for development
the package name
for reverse generation, the tables (and views, synonyms, and snapshots) used to create default entity objects, as well as associations, which are based on referential integrity constraints already in these tables (optional)
default view objects, based on the entity objects, and view links, based on the associations (optional)
a default application module (optional)
You can also create and edit entity objects, associations, view objects, and view links by using the Entity Object Wizard, Association Wizard, View Object Wizard, and View Link Wizard.
To edit an existing business components project, right-click a business components project and choose Edit project to access the Business Components Project Editor. It lets you view and specify connections, specify whether to generate Java and XML code or just XML code, and view and specify registered validation rules. A few benefits of generating Java code are that you have access to strongly typed accessors instead of just having to use the generic getAttribute and setAttribute methods that return an object, and you can write code in the setter method.
If you select a business components project in the Navigator and choose Wizards | Business Components, the wizard that appears is called the Package Wizard; it provides the same functionality as the Business Components Project Wizard, except omits the Connections panel.
Business logic includes validation logic, default value logic, deletion logic, and calculations, which you should implement at the entity object level. Some examples of business logic are tracking why a customer returned a product, or bidding rules between potential suppliers to choose the best deal.
A basic business logic tier contains one or more application modules that provide access to view objects and view links, which in turn rely on entity objects and associations. You can test your business logic tier in the Tester.
C |
Helps define the relationship between objects by setting the minimum and maximum number of members that may participate in an association:
0..1 indicates that a single value is allowed, but not required
1 indicates that exactly one value is required
* indicates that there are many values allowed, but none required
1..* indicates that at least one value is required, but many are allowed
This setting appears in the Attribute Settings page of the Entity Object Wizard and Editor and in the Attribute Editor. For a persistent entity object attribute, selecting this setting means that the attribute is used to determine whether any persistent attribute in the entity object has changed. The first time the user changes the value of an attribute in a row, the business logic tier attempts to lock the row (pessimistic locking mode) or tries to commit (optimistic locking mode); at this time, it checks whether the data values in its cache match the database. The Change Indicator attribute setting determines whether the business logic tier checks a single attribute or multiple attributes, which involves more overhead. So, a change in the attribute value between when the data is first brought into the entity object instance in the cache and when the data is first modified is used to indicate that the entire row has been changed by another user. Only one attribute in an entity object can have this setting. Often, the attribute is a time stamp column or a sequence number.
A software application that requests the service, data, or processing of another application, which can be on a local or remote computer. See also thin client.
An association in which a parent entity object "owns" a child entity object: the parent object is a container for one or more child objects. If a child entity object is modified, the child entity object is validated; in addition, this relationship triggers validation of the parent entity object.
For inserts, updates, and deletes, the child entity object is considered part of the parent entity object. A parent entity object containing valid child entity objects cannot be deleted until all of the contained child entity objects are deleted. When attempting to change a child entity object, the business logic tier attempts to lock the parent entity object; the owning parent entity object must be successfully locked or the change will not be allowed. For example, if you make an airline reservation, you cannot reserve a seat on a flight if there already exists a reservation in your name.
A child entity object cannot exist without its parent. When a child entity object is created, the foreign key assignments are made, and the parent entity object must have non-null values for the primary key. At runtime, if a child entity object changes, the parent is marked as needing validation. During a commit, the parent entity object is validated, then the child entity object is validated.
To connect to a database during development, you define a Connection object, including a connection name (used by JDeveloper), username, password, role (a named group of privileges that a database administrator can create, required for IIOP), and driver. When you are ready to deploy, you can switch to the deployment database, if you developed using a different database. You can connect using JDBC or IIOP.
In version 3.2 of Business Components for Java, connection pooling is the new default behavior. Instead of one JDBC connection being created for each application module instance, and being destroyed when the instance disconnects, application modules can now reuse a pool of connections. There is one connection pool for each JDBC connection URL, including the username and password.
Opening a connection to a database is a time-consuming process that can sometimes take longer than getting the data itself. The advantage of connection pooling is that clients can have faster response times, because they are saved the time of creating the database connection. Instead, they can reuse a connection created by another application module instance.
In addition to using the default connection pooling behavior, you have these options:
You can set the maximum number of connections in a pool.
You can disable connection pooling.
You can create and use a custom connection pool manager.
The Common Object Request Broker Architecture (CORBA) is an Object Management Group (OMG) specification. It defines the framework used to create distributed object computing systems, including definitions for static and dynamic invocation interfaces, an interface repository, and an object request broker (ORB).
Lets you create database tables based on the information in entity objects and, if specified, their database constraints as specified in the Entity Constraint Wizard. This is called forward generation. To access the tool, in the Workspace view of the Navigator, right-click a business components package and choose Create Database Objects.
D |
This setting appears in the Attribute Settings page of the Entity Object Wizard and Editor and the Domain Wizard and Editor, and in the Attribute Editor.
For an entity object attribute, this setting is an optional default value. When the business logic tier creates a new row containing that attribute, the attribute gets this value by default.
For a domain, this default value is inherited by all attributes of this domain type and cannot be changed in the Entity Object Wizard or Editor or in the Attribute Editor.
A domain defines the type of values an attribute can have. A domain object is a developer-defined data type, an immutable Java class encapsulating a scalar value or a structure, with simple validation built into the constructor of the domain. The validation check occurs when an object of that domain type is created. The advantages of creating domains are:
Simple validations are performed once, against the domain definition, when the data is created. Then, the data object can be passed between the tiers without the need for reconstruction or revalidation.
You can define settings and then share them with all attributes that are based on a given domain.
JDeveloper provides a Domain Wizard and Editor for defining domains. You can use the resulting class on the thin client as well as the business logic tier to hold values of a specific type, such as a social security number. You can write code to format or validate the input string in the domain's validate method, which is called by all constructors. Domain classes can be associated with each field in a form. The form could directly instantiate an instance of the domain class with the field's given input string.
In the Domain Wizard and Editor, you can specify settings so that all attributes of that domain type inherit those settings. Attributes may further restrict domain settings, but may not make them less restrictive. For example, a domain could be marked Persistent, meaning no transient attribute can be of that domain type.
After you have created a domain object, you can use it as a data type for an attribute. For example, you could create a domain named SSNumber, and write validation code for it that ensures that the resulting data type is a string of nine characters.
Domains are always serializable Java objects. In the business components framework, it is recommended that domains have a constructor that can accept at least one of the native Java types, like String, byte[], Integer, and so on.
The business components framework also provides some predefined domains.
These tools let you create and edit domains.
While the business components project is open, to create a domain with the Domain Wizard either:
Choose File | New, click the Business Components tab, and double-click Domain.
In the Workspace view of the Navigator, right-click a business components package and choose Create Domain.
To edit a domain, in the Workspace view of the Navigator, right-click the domain and choose Edit domain.
When creating a domain, the wizard lets you specify the following information, listed by panel:
Name panel. A domain name (pick something that describes the relationship, perhaps ending with the string "Domain" to make it easy to identify when you are choosing data types in a wizard) and the package the domain should be placed in.
Domain Settings panels. Specify attribute settings, including attribute and column type, default value, whether it is updateable always, when new, or never, whether to refresh after update or insert, and whether it is a primary key, mandatory, persistent, queriable, and unique.
When editing a domain, the editor lets you specify information in the Domain Settings panel, and also provides the following panel:
Property panel. To add a property, type a property name and value, then click Add. You can also add and edit values for existing properties, and delete properties.
You can write validation code in the domain's Java file (which was created by the wizard). For example, you could make sure a data type is a string of nine characters.
E |
The Enterprise JavaBeans standard specifies a cross-platform component architecture for the development and deployment of multi-tier, distributed, scaleable, object-oriented Java applications. Also known as a Server Bean.
In UML terms, a domain-specific noun, such as a customer, order, or item.
Lets you add constraints, which are used when you generate tables with the Create Database Objects Tool (forward generation). To access the wizard, in the Workspace view of the Navigator, right-click an entity object and choose Create Entity Constraint.
You can also create constraints while you define associations. In the Association Properties panel of the Association Wizard and Editor, select Use Database Key Constraints to automatically create a constraint based on the association.
An entity constraint is a business logic tier object that represents a key constraint in the database. An entity constraint describes, in terms of entity objects and attributes, the database-level relationships between tables and columns. You select the entity object's attributes and define the constraint in terms of database integrity constraints such as primary, foreign, check, or unique. When you create a database object based on an entity object, the definition of the entity constraint is used to detect associations between tables, create the specified key constraints in the database, and ensure that data in the database is valid and conforms to the key constraints.
A class extending directly or indirectly from oracle.jbo.server.EntityDefImpl. It stores runtime metadata describing the entity object, including attributes, events, validators, associations, and properties. When instantiated, it describes all instances of the entity object class. A client can call methods to find information about the entity object, such as the attribute names and types, database source, and so on. There is one entity definition class instance per entity XML file.
You can use the Entity Object Wizard and Editor to generate this Java class for an entity object when you need custom create and find methods. This class is a good place to group together methods that are used by all entity object instances. For example, you can optionally modify the createDef method to use properties from another source (in addition to or instead of the XML) when the entity definition is instantiated.
If an entity object publishes or subscribes to an event (as specified in the Publish and Subscribe panels of the Entity Object Wizard and Editor), most of the event code is generated in the definition files of the entity objects that publish and subscribe.
You can specify that this class extend from a custom class (which must directly or indirectly extend the EntityDefImpl class and be in the project classpath); for example, you might do this if you want to reuse code that's already been written or if your organization decides to customize the business components framework to meet specific needs.
In general terms, entity objects encapsulate the business policy and data for
the logical structure of the business, such as product lines, departments, sales, and regions
business documents, such as invoices, change orders, and service requests
physical items, such as warehouses, employees, and equipment
Specifically, an entity object stores the business logic and column information for a database table (or view, synonym, or snapshot). You can create entity objects from existing database tables (reverse generation) or define entity objects and use them to create database tables (forward generation).
When you use a Business Components for Java wizard to create entity objects from existing tables, each column in the database table becomes an entity object attribute, which can have the same name as the column or a different name that is more meaningful to your business application; an entity object can have an attribute for each column or use a subset if a table contains information for more than one entity. The attributes of an entity object store data type information as specified in the database table they were derived from, including primary and foreign key relationships, the number of characters allowed, precision and scale specifications, and object REFs.
You can create and edit entity objects by using the Entity Object Wizard and Editor. Usually, you have one entity object per table. If you have multiple entity objects per table, make sure that each updateable attribute appears in one entity object only; otherwise, you could make changes in a row that are not reflected in the other entity object.
During runtime, each entity object instance represents a row in the database table and stores its data. There is only one instance per row, and all instances of the same entity class are cached together. Multiple view object queries returning the same row refer to the same entity object instance, so updates are visible to all view objects; one entity object can be used by multiple view objects.
Entity objects are not exposed to clients. Instead, clients access an entity object’s data through one or more view objects. In the view row class, you can expose entity object methods to a client by writing a view object method that calls the method you want to expose.
Relationships between entity objects are expressed through associations; they match attributes, typically key fields, from source and destination entity objects. Methods that return rows and row sets through the association are available on the entity object class.
You implement the majority of your business logic in entity objects. For example, validation rules (such as "sal > 700") can ensure that the values returned by a query are valid or that users do not enter invalid data into a table. Business logic is defined and updated in one place, with the benefit that multiple clients can use it and be instantly updated when changes are needed.
To decide what entity objects your application needs, you usually use UML object-oriented modeling techniques.
A class directly or indirectly extending from oracle.jbo.server.EntityImpl. When it is instantiated, it becomes one row. You can use the Business Components Project Wizard, Package Wizard or Editor, or Entity Object Wizard or Editor to generate this Java class for an entity object if you want to customize methods, such as add custom validation logic code to the validateEntity method or attribute setter methods, or calculate attribute values in the getter methods. You can specify that this class extend from a custom class (which must directly or indirectly extend the EntityImpl class and be in the project classpath); for example, you might do this if you want to reuse code that's already been written or if your organization decides to customize the business components framework to meet specific needs. In the wizard, you can optionally generate
accessor methods (for example, getJob and setJob), which provide type-safe access to the corresponding attribute fields and a place to add your own custom code for validation
data manipulation methods, including lock, which you can modify to customize the entity object's locking behavior, and doDML, which you can modify to customize its update, insert, and delete logic. The lock method is called by the framework whenever an entity's row in the database is locked for modifications. The doDML method is called by the framework with appropriate DML command, to insert, update or delete the row corresponding to the entity instance during the Transaction-Commit cycle. This method can be overridden to modify the update behavior. For example, instead of directly updating through a SQL statement as the framework does, update through a procedure call to the database.
create method, which you can modify to customize or add additional initialization features to the entity object's create logic, for example, setting default values for attributes
remove method, which you can modify to customize or add clean-up code to the entity object's remove logic, for example, you might need to delete child objects in a composition
These tools let you create and edit entity objects. You can also create default entity objects in the Business Components Project Wizard and Package Wizard or Editor. The entity objects can be based on existing tables (reverse generation) or be used to create database tables (forward generation).
While the business components project is open, to create entity objects with the Entity Object Wizard either:
Choose File | New, click the Business Components tab, and double-click Entity Object.
In the Workspace view of the Navigator, right-click the business components package and choose Create Entity Object.
To edit an entity object, in the Workspace view of the Navigator, right-click the entity object and choose Edit object.
When creating an entity object, the wizard lets you specify the following information, listed by panel:
Name panel. The name of the entity object (which can be the same as a table name, or different if, for example, the table name doesn't adequately reflect what you're using the entity object for or you want to use a different language), the package the entity object should be placed in, and the class the entity object extends (it must extend directly or indirectly from oracle.jbo.server.EntityImpl). Optionally specify the database table (or view, synonym, or snapshot) used to create an entity object, as well as associations, which are based on joins already in these tables.
Attributes and Attributes Settings panels. Remove attributes you want to exclude from the entity object (for example, if they are in the database table but you don't want them in the entity object), change the attribute order (useful for forward generation — the order of the attributes will be the order of the columns in the table), and define new attributes (for example, a transient attribute that has a value you calculate in the Java file or if you are defining columns for forward generation). Usually, you have one entity object per table; if you have multiple entity objects, make sure that each updateable attribute appears in one entity object only. Settings include attribute and column name, attribute and column type, default value, whether it is updateable always, when new, or never, whether to refresh after update or insert, whether it is used to indicate the row has changed, and whether it is a primary key, mandatory, persistent, queriable, and unique. In general, if you are performing reverse generation, you don't want to change the primary key, mandatory, database column name, column type, and unique settings that were received from the table. For forward generation, the primary key, mandatory, persistent, database column name, column type, and unique settings are used to generate tables.
Java panel. If you want to customize an entity object, you can specify that the wizard generate a Java file for the entity definition class, the entity object class, or both. By default, the wizard generates the entity object class, but not the entity definition class.
Finish panel. Optionally create a default view object containing the attributes you specified in the entity object. You can edit the view object in the View Object Editor.
When editing an entity object, the editor lets you specify the following information:
Attributes, Attributes Settings, and Java panels. The same as when you are creating an entity object.
Validation panel. Add, edit, or remove validation rules. New rules can be applied at the entity object level, attribute level, or both. Rules can be reordered within a level, which is useful when you have multiple validation rules per attribute and want to control the order of rule firing.
Publish and Subscribe panels. Use the Publish panel to define, edit, or remove events to be published by the entity object; the wizard generates event code in the Java files for the entity object class and the entity definition class. You can specify attributes that are delivered with the event. To send an event, call the method of the same name. Use the Subscribe panel to select the events (defined in the project) that the entity object will listen for. When the event is triggered, the entity object responds by calling the specified method. You can specify how the event will be delivered: deliver the event to the instances of the entity object as subscribed in program logic (addListener), or to those entity objects that are associated to the publisher, by the selected association.
Property panel. To add a property, type a property name and value, then click Add. You can also add and edit values for existing properties, and delete properties.
If you add referential integrity constraints to tables after you've already generated entity objects for them, you can simply go into the Entity Object Editor and click Finish to create the new associations. For other database table changes, you can make the change manually in the Entity Object Editor. For example, you can add attributes corresponding to new columns.
This setting appears in the Attribute Settings page of the View Object Wizard and Editor and in the Attribute Editor. For a SQL-derived view object attribute, a valid SQL expression is used to define the value of the attribute.
F |
If a user of a client enters a value that causes the business logic to ask for the value of one of the excluded attributes in a view object, then the business logic tier uses the primary key value to go to the database and retrieve all of the attributes for the row (including the excluded ones). This is called "fault-in:" the client's attempt to access an entity object attribute that is not included in the view causes the entity object to retrieve all of the remaining attributes. Fault-in occurs on the entity object instance level; only the effected rows are faulted in. After the fault-in, the cache contains one fully populated row that was the result of the fault-in. This on-demand faulting prevents request failure.
For example, if you have a view object that includes the employee level and name, and when you change the level to 3 from 4 the entity object checks the salary, then you are attempting to read an attribute not included in the view. To avoid fault-in and two trips to the database, you can include the salary in view.
When you design a view object, consider the following:
Faulting can be avoided by making sure the view object includes the attributes that the entity business logic makes reference to. This is particularly important if you query and modify a large number of rows.
When optimizing performance, remember that fault-in incurs a memory and performance cost. Too many fault-ins will lower performance significantly. It is important to fine tune the view object attribute list, particularly for entity objects that include many attributes.
You first define your entity objects in the Entity Object Wizard and Editor, then use them to create your database tables and optionally constraints with the Create Database Objects Tool. See also reverse generation.
You can use the setForwardOnly method in a view object to prevent data from entering the entity object cache. Only one row is worked with at a time, and the data cannot be changed. If you won't be changing data and there is not a lot of repeated data, using forward only mode can save memory resources and time, because fewer objects are created. Forward only mode is useful when you are fetching data and reading it once, such as formatting data for a web page, or for batch operations that proceed linearly.
A class library with built-in application functionality. Using a framework involves specializing base classes to introduce application-specific behavior, allowing the framework to coordinate many of the basic interactions between objects.
For the business components framework, the classes are in oracle. jbo.*.
H |
The Hypertext Markup Language is a non-proprietary language for publishing hypertext on the World Wide Web. It is based on SGML. HTML uses tags to structure text into headings, paragraphs, lists, hypertext links, and so on, which you can display in a web browser.
I |
Internet Inter-ORB Protocol, the protocol used for communication between Object Request Broker (ORB) clients and servers. It is used with CORBA.
Each view object provides a default iterator (through the oracle.jbo.RowIterator interface) that a client can use to navigate through its result set. A view object does not execute a query until its iterator requests data. The iterator can enumerate the contents of a row set, including providing forward and back navigation, and next and previous navigation. The row iterator can be used with ranges to iterate over a range of rows in a UI more easily, including letting you use relative navigation within the range. Range-aware row iterators are useful for grid controls.
J |
JavaServer Pages technology provides a fast way to create dynamic web pages by using XML-like tags and scriptlets written in Java. It lets you rapidly develop server- and platform-independent web-based applications. JavaServer Pages are an extension of the Java Servlet API.
Java Database Connectivity is an API specification for retrieving and manipulating data in a database from Java code. Requests are in SQL. A JDBC-ODBC bridge lets you access databases through ODBC.
M |
This setting appears in the Attribute Settings page of the Entity Object Wizard and Editor and the Domain Wizard and Editor, and in the Attribute Editor.
When selected, each entity object row must have a non-null value for this attribute. If it does have a null value, the row is considered to be invalid when you navigate away from it or try to commit.
If an entity attribute is of a domain type, and the Mandatory attribute setting is set in the domain, you cannot override the setting in the Entity Object Wizard or Editor or Attribute Editor.
Data about another set of data (your application data), such as how it should be formatted. Business Components for Java represents metadata as XML definition files, containing information about the structure and behavior of your business components. It contains descriptive information about the features and settings of an application that you can declare with the Business Components for Java wizards and editors during design time. Some examples of metadata are the names and types of attributes, a SQL query, and validation rules. Information that is descriptive in nature is stored as XML while programmatic information is in Java.
N |
This setting appears in the Attribute Settings page of the View Object Wizard and Editor and the Entity Object Wizard and Editor, and in the Attribute Editor.
The required attribute name setting specifies the name that the attribute is referenced by in the Business Components for Java wizards, the Java source code, and the XML files.
O |
Open Database Connectivity is a standard API for accessing a database. Applications can use SQL requests to access databases, and ODBC converts it into a request that this database understands. ODBC was created by the SQL Access Group. A JDBC-ODBC bridge allows applications using JDBC to reach ODBC-accessible databases.
When an entity object uses optimistic locking, at commit time, the entity object attempts to lock its corresponding row in the database. If the entity object is part of a composition, the framework first tries to lock the parent entity object. If the attempt to lock is unsuccessful, an exception is thrown. Also see pessimistic locking. Locking is defined in the oracle.jbo.Transaction interface through the setLockingMode method.
P |
In a business components project, you need to decide what business components you want to group in the same package, so they have access to package private methods and variables, and which business components should be in different packages. Business components in separate packages can interact through public methods and variables; you can also reuse the packages in other projects as needed. As a general guideline, you can create the following packages in your business components project(s) for each application:
business logic package, including entity objects and associations as well as view objects used for filtering and validation
presentation package, including the application module as well as view objects and view links that project and filter data for the UI
client package
interface and domain package, which are common to both tiers and you might want to upgrade it separately
You need to functionally decide what objects to put together in packages according to what methods you want internal team members to use versus what you want external teams to use. If it gets delivered together as a component, put it in one package. Different application feature teams might need to be able to work independently on their functionality.
These tools let you create and edit packages. They provide some of the same functionality as the Business Components Project Wizard.
While the business components project is open, to create a package with the Package Wizard, do one of the following:
Choose File | New, click the Business Components tab, and double-click Package.
In the Workspace view of the Navigator, right-click the business components project and choose Create Package.
In the Workspace view of the Navigator, select the business components project and choose Wizards | Business Components.
To edit a package, in the Workspace view of the Navigator, right-click the package and choose Edit package.
The wizard and editor help you specify
the package name
tables (and views, synonyms, and snapshots) used to create default entity objects, as well as associations, which are based on referential integrity constraints already in these tables (optional)
default view objects, based on the entity objects, and view links, based on the associations (optional)
a default application module (optional)
You can also create and edit entity objects, associations, view objects, and view links by using the Entity Object Wizard and Editor, View Object Wizard and Editor, Association Wizard and Editor, and View Link Wizard and Editor.
This setting appears in the Attribute Settings page of the Entity Object Wizard and Editor and the Domain Wizard and Editor, and in the Attribute Editor.
For an entity object attribute, select this setting to make the attribute persistent (the entity saves it in persistent storage — the database). Deselect it for a transient attribute.
If an attribute is of a domain type, and the Persistent attribute setting is set in the domain, you cannot override the setting in the Entity Object Wizard or Editor or Attribute Editor. So for transient attributes, Persistent should be not selected in the domain.
When an entity object uses pessimistic locking, the first time one of its attributes is successfully modified, including passing any validation, the entity object attempts to lock its corresponding row in the database. If the entity object is part of a composition, the framework first tries to lock the row for the parent entity object. If the attempt to lock is unsuccessful, an exception is thrown. Also see optimistic locking. Locking is defined in the oracle.jbo.Transaction interface through the setLockingMode method.
This setting appears in the Attribute Settings page of the Entity Object Wizard and Editor and Domain Wizard and Editor, and in the Attribute Editor. For an entity object attribute, when selected, this attribute is (or is part of) the entity object's primary key. (More than one attribute can make up a primary key.)
If an attribute is of a domain type, and the Primary Key attribute setting is set in the domain, you cannot override the setting in the Entity Object Editor.
After choosing File | New Project, the Project Wizard appears, which lets you create a new project. You specify
the name of the project file (JPR)
the type of project (such as a project containing business components)
the default package for the project
the source path(s) under which all source files must be placed
the directory where JDeveloper places compiled files
project information, including the project title, author, copyright, company, and description, which the wizard can place in an automatically generated HTML file entitled "Project Notes" (optional)
If you create a business components project, the Business Components Project Wizard appears after you click Finish.
In a business components project, properties are name/value pairs of type string that you can use as metadata to drive runtime behavior. (Do not confuse them with JavaBean properties: they're different.) Domains, entity objects, view objects, application modules, and entity and view object attributes can have properties. The properties are stored in the component's XML file.
You can define any properties you need in the appropriate Property panel of a wizard or editor, such as the Entity Object Wizard and Attribute Editor. Some uses of properties are
in application modules, to indicate what style of generic user interface template to use; to provide runtime hint information to control the style of display for information in the application module
in domains, to globally set default display style hints and format masks for certain attribute types
in entity and view objects, as needed, to override default hints provided by domains
For example, an attribute could have a Label property that specifies what the label should be when the attribute is displayed in the UI. Another example is when you are laying out a presentation space and want to use a mask (or picture string). To define properties for a string that represents a social security number, you could create a SSN-MASK property with a value of 000-00-0000. At runtime, you could evaluate the property name and apply the proper formatting when appropriate.
Attribute and domain properties can be overridden to be more restrictive. Following is the hierarchy, from least restrictive to most restrictive:
domain property
entity attribute property
view attribute property
For example:
|
nameLength domain |
Dept entity object |
DeptView view object |
|
type String length property has the value 20 Designed to limit the length of a department name to a string of 20 characters |
Dname attribute of nameLength type length property of the attribute has the value 15 |
Dname attribute of nameLength type length property of the attribute has a value of 10 |
The length property on the entity object's Dname attribute overrides the domain character limit of 20 characters; so a department name can be 15 characters. The length property on the view object's Dname attribute overrides the department name limit; so a department name can be 10 characters.
You can get and set properties at runtime by using methods defined in the NamedObjectImpl class, such as getProperty, setProperty, getProperties, and getPropertiesAsStrings. Other classes extend this class, including EntityDefImpl, ViewObjectImpl, ApplicationModuleDefImpl, and AttributeDefImpl. Clients can query properties and make decisions based on property values, but cannot set properties.
Q |
This setting appears in the Attribute Settings page of the View Object Wizard and Editor, the Entity Object Wizard and Editor, and the Domain Wizard and Editor, and in the Attribute Editor.
For an entity object attribute, when selected, the attribute can participate in a view object's query condition. If not selected, the information cannot be queried (BLOB types, for example).
For a view object attribute, when selected, the attribute can participate in a query condition. For a persistent attribute, if the columns (to which attributes of this type are mapped) can be part of a query filter (a WHERE clause), then this setting should be selected. For example, this property should be selected for NUMBER column types, but not set for BLOB types. This attribute will be suppressed from Query by Form interfaces.
If an attribute is of a domain type, and the Queriable attribute setting is set in the domain, you can override the setting in the View Object Wizard or Editor, but not in the Entity Object Wizard or Editor.
R |
This setting appears in the Attribute Settings page of the Entity Object Wizard and Editor and the Domain Wizard and Editor, and in the Attribute Editor.
A persistent entity object attribute can optionally have one or both of the following settings:
Refresh After Update — After the entity object performs an update (the data in an entity object instance is placed in an existing row in the database), the entity object retrieves the value of the attribute from the corresponding database field. So the effect of any database triggers will be reflected back in the entity cache. For example, if you have a Date Updated field, after a row update, the database adds the new update date to the field, so the entity object instance needs the new value.
Refresh After Insert — After the entity object inserts a new row in the database, the entity object retrieves the value of this attribute from the corresponding database field. For example, you can use this feature to assign primary key values from a sequence in a database trigger (after insert, the database generates the sequence number and the entity object retrieves the new attribute value).
If an attribute is of a domain type, and the Refresh After attribute setting is set in the domain, you cannot override the setting in the Entity Object Wizard or Editor.
You first define your database tables (and views, synonyms, and snapshots), then use them to create entity objects in the Entity Object Wizard or Editor, Business Components Project Wizard, and Package Wizard or Editor. See also forward generation.
Discards the changes made in the current transaction. The second half of the recovery procedure. After the roll forward, any changes that were not committed must be undone. After the redo log files have been applied, the rollback segments are used to identify and undo transactions that were never committed, yet were recorded in the redo log. Oracle completes this step automatically.
Any object that implements a oracle.jbo.Row interface. When a view object query fetches one or more result rows, individual rows are represented by Row objects. Each column value in the result row is accessed through an attribute of a row interface. The row interface has methods like getAttribute and setAttribute.
S |
This setting appears in the Attribute Settings page of the View Object Wizard and Editor. When selected, the attribute appears in the view object's SQL Select statement; otherwise, it doesn't.
The provider of services requested by a client. A single machine can be both a client and a server depending on the software configuration.
A unique name for an Oracle database instance. To specify a connection to a database, users must specify the desired SID.
A read-only copy of a master table located on a remote node. A snapshot can be queried, but not updated; only the master table can be updated. A snapshot is periodically refreshed to reflect changes made to the master table. In this sense, a snapshot is really a view with periodicity.
An alias for a table, view, snapshot, sequence, procedure, function, or package. It is another name assigned to a table for easy identification. For example, if you refer to tables residing in other accounts or databases, you may find it convenient to define a synonym for the long string of identifiers. If a table name changes, you can simply redefine the synonym rather than rewrite all related queries. Synonyms are used to mask the real name and owner of an object, provide public access to an object, provide location transparency for tables, views, or program units of a remote database, and simplify the SQL statements for database users. A synonym can be public or private.
T |
To access the Business Components Tester (also called the Business Components Browser), in the Workspace view of the Navigator, right-click an application module and choose Test.
The Oracle Business Components Tester is an example of a generic, thin Java client application. It uses the dynamic capabilities of the framework's client APIs 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 want to test.
The Oracle Business Components Tester visually exposes all of the runtime features of the framework including:
view objects, which can be executed, scrolled, and have the values in any of their columns changed,
entity object business logic, which will be enforced when changes to related view object columns are made so you can verify that domains are set up properly, that default value logic functions correctly, that validation code is working, and that association lookups do what you expect,
multiple view objects, which include the same entity attributes stay synchronized when changes are made through any of them,
view linked view objects are automatically master-detail coordinated as you scroll through master records to any level of depth,
application modules can be tested in any supported deployment configuration from a single application: Local, Remote CORBA/EJB in a physical middle-tier, as well as Remote CORBA/EJB inside of Oracle8i.
When you commit, all pending changes are communicated to the database by the underlying entity objects in the cache.
A client that retrieves only the data necessary for display, while business logic is performed in another tier.
A transaction is an interface to manage database operations. All operations to modify data in a transaction must succeed before the server will accept the changes. These operations include methods that set attribute values, standard SQL calls (such as INSERT, UPDATE, and DELETE), or more specialized calls such as calling Java stored procedures or SQL packages. A transaction is an atomic unit; the effects of the operations in a transaction can be either all committed (saved to the database) or all rolled back (undone).
For example, when a client using a banking service transfers money from a savings account to a checking account, the transaction consists of three separate operations: decrement the savings account, increment the checking account, and record the transaction in a transaction journal. If all three operations are performed to maintain the accounts in proper balance, the transaction is committed and the effects of the operations applied to the database. But, if something (such as insufficient funds, invalid account number, or a hardware failure) prevents any of the operations from completing, the entire transaction must be rolled back so that the balance of all accounts is correct.
Transactions also provide multi-user consistency to a shared store of data. When a client changes data, locks ensure that other clients don't make other changes until the first client is finished. When a transaction is committed or rolled back, the locks are released.
Business Components for Java application modules provide default transaction and concurrency support. No coding is required unless you want to customize the default behavior.
When programming with business components, the principles of transaction management are the same from the business logic tier as from a client:
Create an application module that connects to the database and establishes a context for the transaction.
Execute a query.
Manipulate the result set (set attributes, validate values).
Commit changes to the database (making the new data available to other application modules) or roll them back, as appropriate.
The business components framework uses a batch-oriented (as opposed to a change-oriented) approach to synchronize changes in any cached state with the database state. This approach provides the following benefits:
Changes are buffered in an in-memory cache.
Changes in the cache are synchronized with the database using a series of database manipulation operations. This series of operations is typically referred to as posting. (In Business Components for Java, posting is performed in the commit cycle, or by specifically calling postChanges on the Transaction interface.)
Validations occur on some combination of each state change made and just prior to posting because individual changes may have left the cache in an invalid database state.
This setting appears in the Attribute Settings page of the View Object Wizard and Editor, the Entity Object Wizard and Editor, and the Domain Wizard and Editor, and in the Attribute Editor. All Java variables have a type, and the type restricts the kinds of objects that can be assigned to it.
For an entity object attribute, this setting is the Java data type or domain type of the attribute. You can also specify a Database Column Type, which is the SQL datatype of the database column; it is used to derive the default Java JDBC type at runtime. The SQL data type must correspond the Java data type, or you can get runtime exceptions, particularly for string conversions. During forward generation, the Database Column Type becomes the column type in the database.
For a view object attribute, this setting is the Java data type or domain type of this attribute. For persistent and entity-derived attributes, you can't change the type from that specified in the corresponding entity attribute.
For a domain, this setting is the Java type of the domain's mdata field.
If an attribute is of a domain type, and the Database Column Type attribute setting is set in the domain, you cannot override the setting in the Entity Object Wizard or Editor.
U |
The Object Management Group's (OMG) Unified Modeling Language is a general, notational language, based on earlier standards like Booch, OMT, and OOSE, for specifying and visualizing complex software. It is ideal for large object-oriented projects.
This setting appears in the Attribute Settings page of the Entity Object Wizard and Editor and the Domain Wizard and Editor, and in the Attribute Editor.
For a persistent entity object attribute, when this setting is selected, there can be only one row with a certain value (each row has a unique value in this column). During forward generation, the corresponding not null database constraint is created.
If an attribute is of a domain type, and the Unique attribute setting is set in the domain, you cannot override the setting in the Entity Object Wizard or Editor.
This setting appears in the Attribute Settings page of the View Object Wizard and Editor, the Entity Object Wizard and Editor, and the Domain Wizard and Editor, and in the Attribute Editor. This setting determines whether you can call a setAttribute method on an attribute. An attribute must have one of the following Updateable settings:
Always — The selected attribute may be updated in the business logic tier's cache.
While New — The attribute can be updated only while the object is new: before the first time it is committed. After it is committed to the database, this attribute becomes read-only.
Never — The attribute cannot be updated using the framework. Tip: you might want to consider removing the setter methods.
For a persistent or entity-derived view attribute, the updateability of the attribute can be restricted further than that of the corresponding entity attribute, but it can't be made "more updateable." So if the entity attribute setting was Never, but the view attribute setting was Always, the setting would remain Never. The same principle applies if an attribute is of a domain type.
V |
Business Components for Java provides a framework for defining, implementing, and executing validation logic in the business logic tier. The validation framework provides a consistent programming model that hides internal implementation details. It frees you to focus on rules that prevent users from entering invalid values into the database.
Note that validation is different from an integrity (or "database") constraint. An integrity constraint is a declarative way to define a business rule for a column of a table. Integrity constraints are defined with a table and are stored as part of the table's definition, centrally in the database's data dictionary, so that all database applications adhere to the same set of rules. You can use integrity constraints (in addition to validation) when some clients do not use Business Components for Java.
You can define and apply validation logic in the following ways, either using a programmatic (Java) or declarative (XML) technique. If you have multiple levels of validation, the validation will trigger in this order, from first to last.
Using domains as data types for entity object and view object attributes. (Programmatic) A domain object validates data in its constructor. You can also apply rules and add code to a domain object's validate method to further refine the business logic. A domain lets you share attribute-level validation across entities, views, or both. Depending on how you program your client, the validation can be triggered at the client or at the business logic tier. For example, you might create a Price attribute of a Currency domain type; if the domain is downloaded onto the client, the moment a user clicks out of a field, they get feedback if they didn't enter the currency correctly. Domains are reusable among attributes. For example, a CreditCard domain would be very reusable — you wouldn't have to add this code in every entity object that needs it and you could update it in one place.
Editing entity validation methods. (Programmatic) The business components framework can generate setAttribute methods for entity objects (for example, Dept.setLoc). Here you can add validation that occurs before or after the attribute is set. In setter method, you would add rules that are affected only by that attribute value and that do not need to be reused often.
Adding code to the validateEntity method. (Programmatic) The base entity class provides a validateEntity method that your entity objects can override. Entity validation occurs before moving from one row to another. It is useful for validating values of two or more attributes; for deferring validation of individual fields until values for the entire row have been entered; for validating values in separate entity objects that are associated. For example, a Salary attribute may need to check other field values, such as job title, currency, and so on. Another example is a date range, where the begin date must be less than the end date.
Applying validation rules to entity objects and attributes. (Declarative) Validation rules encapsulate reusable patterns of validation that you can use by supplying appropriate parameter values. You can use the Entity Object Wizard and Editor and Attribute Editor to define and apply simple rules without writing code. When you use the wizard (as opposed to writing code by hand), it generates XML, enabling you to customize rules without recompiling Java code. You can use predefined validator types or define your own. You could implement more complex rules in your own custom validation classes; then you can register the classes as validator types and apply them, the same as the predefined rules.
Defining a composition. (Programmatic) A composition provides parent and child hierarchic validation on the view object level. The validateEntity method of the parent validates the children. For example, there should be no line item unless it's in an order.
The business components framework supports various validation levels: you can validate attributes, entities, and the logical business objects. JDeveloper invokes validation logic at the appropriate level when data is created or changed, and assumes that data already in your tables is valid. So a query could return a result set that contains invalid values (for example, from legacy data entered before the validation logic was applied), but a user cannot enter an invalid value into the table. The framework invokes rules on contained objects before invoking rules on top-level objects.
In entity objects, you can use validation rules to ensure that the values returned by a query are valid or that users do not enter invalid data into a table (for example, that an employee's salary must be greater than 700). Validation rules are JavaBeans that encapsulate reusable validation code for use across entity objects.
In the Validation panel in the Entity Object Wizard and Editor and Attribute Editor, you can specify validation rules and validation levels, and an execution order within the same level. A validation level indicates whether the rule is applied to the attribute level or the entity object level, depending on which you select. Applying validation rules involves attaching XML metadata to an entity object. When you use the wizard (as opposed to writing everything by hand), it generates XML, enabling you to customize rules without recompiling Java code.
At runtime, attribute-level validation rules are invoked when the attribute value is modified through a generated setter method, or by the setAttribute method called on the entity object. The entity-level validation rules are invoked when the current row in the client's iterator changes from this entity object to the next; or during the commit cycle if an entity object is invalid; or by an explicit validate method call on the entity object.
Business Components for Java provides predefined rules, and you can create your own.
In the Registered Rules panel of a Business Components Project Editor, you can create and register a custom validation rule, implemented in a validation class that is in your project. Either click New to create a new class, then customize it, or register a class you've already customized. Registered validation rules are stored as a list with the project's XML definition (JPX file). You can apply registered rules to an entity object or attribute the same as you would one of the predefined validation rules.
A datasource made up of columns from one or more database tables, combined into one logical table. It is a custom-tailored presentation of the data in one or more tables. Also known as a stored query. Views are a kind of virtual table — an object that acts like a table when you execute a query, but is really a pointer to either a subset of a table, a combination of tables, or a join of two or more tables.
In UML, a view is a projection of a model. A projection is a mapping from a set of elements to a subset of itself. A projection of a model, which is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective.
Defines a relationship between view objects, which represent views of tables. The relationship can be one-to-one or one-to-many, and you can use multiple view links to create a many-to-many relationship. The View Link Wizard and Editor lets you specify source and destination view objects, and links them using attributes selected from the view objects.
An example of a one-to-many relationship could be a DepartmentView view object linked to a EmployeeView view object in a master-detail relationship. With this view link, you could efficiently look at information about employees in a particular department.
An example of a more complex one-to-many relationship could be a CustomerView view object linked to an OrderView view object in a master-detail relationship, and the OrderView view object linked to an ItemView view object in a master-detail relationship. So a user could quickly look at the items in a particular customer's order in one form.
View links can be created based on associations, but an association is not needed to use a view link. View links are navigable in one direction (master to detail, not detail to master), while associations are bidirectional. So if you want to traverse both directions between two view objects, you need to create two view links. If the default relationship does not provide adequate functionality, you are able to create complex relationships through the Association SQL panel of the View Link Wizard or Editor.
If a view object is specified as a detail view in a link, the view object restricts the data to the detail information (like adding a WHERE clause to the SQL statement that defines the view object); otherwise, view objects provide unrestricted views, with all data available. In other words, a view link selects a correlated view of underlying data based on bind values supplied by the master view.
When two view objects are linked in a master-detail relationship in an application module, the default (or first) iterator for the master view object fires events to refresh the detail view object. When the detail view object is created, the business component framework registers it as an event listener for the master's iterator. So, when the iterator moves to another row in the master view object, the contents of the detail view object are refreshed automatically.
You can reuse view links in application modules. You can also create view links dynamically at runtime using the Business Components API.
Note that if a view link is based on an existing association, and the association has been defined as a composition, then when creating a detail view row, the master view row must exist and have non-null key values. If the association has not been defined as a composition, no such restriction applies.
In UML terms, a link is an instance of an association that represents a connection between two or more objects.
These tools let you create and edit view links. You can also create default view links, based on existing associations, by using the Business Components Project Wizard, Package Wizard, and Entity Object Wizard.
While the business components project is open, to create a view link with the View Link Wizard either:
Choose File | New, click the Business Components tab, and double-click View Link.
In the Workspace view of the Navigator, right-click a business components package and choose Create View Link.
To edit a view link, in the Workspace view of the Navigator, right-click the view link and choose Edit link.
When creating a view link, the wizard lets you specify the following information, listed by panel:
Name panel. A view link name (pick something that describes the relationship, perhaps ending with the string "Link" to make it easy to identify) and the package the view link should be placed in.
Association Views panel. Select the source (master) view object and the destination (detail) view object, and specify a name for the destination view link accessor, and optionally generate accessors if you want to traverse the relationship in code. After the link is defined, the source view object can use the link accessor to traverse to the destination side of the link. For example, the employees of a department might be accessed through a department by issuing the call getEmps. (For default view links, the source view object contains the primary key and the destination view object contains the foreign key.)
Role Attributes panel. Select the attributes that define the relationship between the source and destination view objects of a link. (There is a separate panel for source and destination; you must specify the same number of attributes in each panel, in order.) You can optionally specify all attributes that define an association: when you shuttle an association to the Selected Attributes list, the attributes associated with that association automatically appear. Also, if you select an association in the source, the matching attributes (if applicable) will be included by default on the destination panel. These attributes are used to formulate a SQL snippet, which you can modify, if needed.
Association SQL panel. Examine the default SQL expression used to filter the records in the destination side of a view link and optionally modify it to perform any additional valid SQL restrictions. You can click Test to make sure the SQL statement is valid.
When editing a view link, the editor lets you specify the same information.
If you add an association after you have created a view object, you can manually add the link in the wizard.
Uses SQL queries to specify filtered subsets of attributes from entity objects. The views of data are SQL-based and separate from the underlying entity objects, enabling flexible data retrieval to support the required UI. In other words, you can query a set of data exactly as you want to show it in the display. View objects provide clients with row sets they can scroll through and update without concern for or knowledge of the underlying entity objects. Clients manipulate data by navigating through the result set, getting and setting attribute values; changes are made to the data in the underlying database when the transaction is committed. Relationships between view objects are expressed using view links. Each view object provides a default iterator that you can use to navigate through its result set.
View objects are often used to:
Provide an additional level of security by restricting access to a predetermined set of rows and columns. For example, you could create a view object where columns containing sensitive data (such as salaries) are not selected.
Hide data complexity. For example, a view object can display columns or rows from multiple entity objects. Such a view object hides the fact that the data is coming from several tables.
Customize presentation. Using a view object, you can rename columns without affecting the entity objects on which the view object is based.
Store complex queries. A query could perform extensive calculations on table data. By saving this query in a view object, the calculations are performed only when the view object's query is executed. The calculation is executed before the data is retrieved from the database.
Improve efficiency of the application by using fast-executing, optimized SQL, selecting only the data you need.
You can define multiple view objects per entity object, and a view object can select data from multiple entity objects. Data is cached at the entity object level and all view object references within the same transaction share the cache, so changes made through one view object are immediately available to other view objects in the same transaction.
When you define a view object, you can specify which underlying entity objects are read-only and which support read/write operations on participating attributes in the view object's attribute list.
In the Application Module Wizard and Editor, you can choose the view links that you want to use to link view objects in master-detail relationships. View links can also be specified in code that executes at runtime. Detail view objects are automatically synchronized with their respective master view objects.
An application module can use the same view object more than once, such as an unrestricted view and a detail view; you can specify aliases to represent the various usages of a given view object.
A class extending directly or indirectly from oracle.jbo.server.ViewObjectImpl. You can use the Business Components Project Wizard, Package Wizard or Editor, or View Object Wizard and Editor to generate this Java class if you want to customize methods, such as an overridden create method so you can dynamically modify aspects of the view definition for that view object instance; for example, automatically setting bind variables in the Where clause or automatically adding Where clause criteria for security or filtering. You can also verify client IDs so they can only query their own information from a multi-client table, instead of having each form add this Where clause. You put methods in the view object class rather than in the view row class if they operate on the default rowset and are not specific to a row but are specific to that view object.
You can specify that this class extend from a custom class (which must directly or indirectly extend the ViewObjectImpl class and be in the project classpath); for example, you might do this if you want to reuse code that's already been written or if your organization decides to customize the business components framework to meet specific needs.
These tools let you create and edit view objects. You can also create default view objects in the Business Components Project Wizard, Entity Object Wizard or Editor, and Package Wizard or Editor.
Default view objects are very simple in their definition. Use the View Object Wizard and Editor to create and edit view objects so they are tailored to your needs. This might include a view object that uses
a subset of an entity object's attributes
attributes from more than one entity object
special SQL-derived or transient attributes
non-default storage and updateability features
The ability of a view object to use multiple updateable entity objects enables one of the key features of Business Components for Java: a single view object can update multiple entity objects.
While the business components project is open, to create view objects with the View Object Wizard either:
Choose File | New, click the Business Components tab, and double-click View Object.
In the Workspace view of the Navigator, right-click a business components package and choose Create View Object.
To edit a view object, in the Workspace view of the Navigator, right-click the view object and choose Edit object.
When creating a view object, the wizard lets you specify the following information, listed by panel:
Name panel. The entity object(s) used to create the view object (if any), the name of the view object (which could be entityView), an alias for the view object (to prevent naming conflicts and distinguish detail views from unrestricted views, for example), whether attributes in each entity object are read-only to this view object, whether a change to a foreign key means it should refer to a different field or to update that field value (for example, in an order entry application, whether a change to an item ID means you are ordering a different inventory item or changing the inventory item's item ID), and the package the view object should be placed in. If you are performing updates, you need to specify an entity object; also, if you are retrieving a join of information, it is best to have entity objects. However, if you are querying data for read-only purposes, no entity object is needed. Entity objects enable unpdateability and validation, keeping rows uniquely in memory.
Attributes and Attributes Settings panels. Specify attributes you want to include from the entity object, define new attributes (you can define transient or SQL-derived attributes), and specify attribute settings. Settings include attribute name, attribute type, alias, SQL expression, whether it is updateable always, when new, or never, and whether it is selected in the view object's query and queriable. You want to include only the attributes you need for a form in the client UI, to save memory and improve performance, but avoid fault-in. You must include primary key(s) if the underlying entity objects are updateable; this is enforced by the wizard.
Query panel. Optionally customize the view object's SQL statement. You can add WHERE and ORDERBY clauses. Click Browse to select attributes by which to order the query results. If you want to modify the query in other ways, such as the automatically generated SELECT and FROM clauses, you can select Expert Mode. Click Test to verify that the SQL statement is syntactically correct.
Attribute Mappings panel. If you selected Expert Mode, you can map query result columns to view object attributes. You need to remap these items if you deleted, added, or switched positions of columns in your custom SQL query, because the mappings will no longer be correct.
Java panel. If you want to customize a view object, you can specify that the wizard generate a Java file for the view object class, view row class, or both. By default, the wizard generates the view object class, but not the view row class.
When editing a view object, the editor lets you specify the following information, in addition to the previous panels:
Exported Methods panel. Select methods to export, so the client can use them remotely. Methods you've written in the view object class file appear in the Available list; to appear in the list, they must be of a data type that implements the Serializable interface. To export them, move them to the Selected list. Before you can use this panel, in the Java panel, you must select Generate Java File for the view object class. You need to do a few other things before the client can use the methods, including making the application module remoteable, importing the package in the client code, and invoking the method properly in the client code, as described in the Business Components for Java online help.
Property panel. To add a property, type a property name and value, then click Add. You can also add and edit values for existing properties, and delete properties.
If you change a database table after you have created a view object and you need to modify the view object, you can make the change manually in the View Object Editor. For example, you can add attributes corresponding to new columns in the entity object.
A class extending directly or indirectly from oracle.jbo.server.ViewRowImpl. You can use the View Object Wizard or Editor to generate this Java class if you want to customize methods, such as implement custom logic for calculating values for this view (in attribute getter methods). This class can hold methods acting on row; methods that need the data in one row to operate. In the view object class, you can add methods that operate on row set. In addition, you can expose entity object methods to clients by creating row class methods that call a method in an entity object.
You can specify that this class extend from a custom class (which must directly or indirectly extend the ViewRowImpl class and be in the project classpath); for example, you might do this if you want to reuse code that's already been written or if your organization decides to customize the business components framework to meet specific needs. In the wizard you can optionally choose to generate accessor methods (for example, getJob and setJob), which provide type-safe access to the corresponding attribute fields and a place to add your own custom code for validation.
W |
Business Components for Java provides the following wizards, editors, and tools:
Deploy Tools
X |
The Extensible Markup Language defines a universal standard for electronically exchanging data. XML specifies a rigorous, text-based way to represent the structure inherent in data so that it can be authored and interpreted unambiguously. Its simple, tag-based approach leverages developers’ familiarity of HTML but provides a flexible, extensible mechanism that can handle the gamut of "digital assets" from highly structured database records to unstructured documents and everything in between.