 |
 |
 |
 |
 |
|
|||||
|
| VBSF Product Overview |
| Contents
1. Introduction Object-oriented systems have gained widespread popularity in the last few years. Software designed using an object-oriented approach is more maintainable, reusable, and reliable than software designed using the procedural approach. Objects are commonly used in the graphical user interface (GUI) part of software in the form of windows, icons, and other components. Another area of widespread object-orientation is in systems programming. Although objects are now a part of almost every piece of contemporary software, object-oriented programming is not fully exploited. Specifically, objects are not widely used to represent the business entity itself. A business entity can be modeled in terms of business objects. A business object is modeled after a business concept, such as a person, place, event, or process. Business objects represent real world things such as employees, products, invoices, or payments. A business object can also represent an event such as a transaction. Applications designed from the ground up using the business object model are better suited to meet the requirements of rapidly evolving businesses. Visual BSF ™ (VBSF) is an all Java object-relational framework that enables Java objects to be persisted to relational databases. Although Java is truly an object-oriented language, applications that access relational databases must work with tables, rows, and columns. This is true regardless of whether JDBC, or any other third party Java database library is used. This has the unfortunate side effect of forcing a developer to switch between the application's object model and relational model. Because Java objects cannot be directly saved to or retrieved from relational databases, developers working on Java applications that access relational databases are forced to write massive conversion routines using two different languages, SQL and Java. In addition, they have to worry about the database driver's API (e.g. JDBC). VBSF overcomes the impedance mismatch between Java objects and relational databases by solving the complex issues involved in the translation. VBSF contains an object/relational mapping engine that allows a programmer to stay focused on the object model. Java objects can be easily saved and retrieved by simply calling update() and get() methods. It supports loading and saving collections of objects as well as complex queries. VBSF is made up of two components: a GUI based Mapping Tool and a Persistence Layer library that provides the runtime persistence services. The mapping tool allows you to visually map business classes to database tables and columns, and to specify object relationships. It can also be used to define server side custom SQL, validity checks, and customized database configurations. Mappings are saved in XML format. If necessary, mappings can also be defined entirely in code (or modified in code) without using the mapping tool. The VBSF persistence layer can deploy persistent objects in a a local (1-tier, or 2-tier) configuration or in a multiple tier configuration. A multiple tier configuration divides the user interface (client), application logic (middleware), and data storage (back end) into three (or sometimes more) distinct layers. Each layer or tier usually resides on a different machine, but that is not a requirement. A distributed application allows the implementation of thin clients (e.g. applets), and is much more flexible and easy to maintain than a two or one-tier application. Powerful applets that access databases can be created without the need to import any database drivers. The client communicates only with the middleware layer and does not know or care about database issues. For example, in a 3-tier architecture the database server can be replaced without having to change a single line of code at the client side. The middle layer handles the application processing logic and communicates with the data storage layer (e.g. SQL server), which stores and retrieves the actual data.
VBSF provides the following benefits:
Non-intrusive and Dynamic VBSF is totally transparent to your persistent classes. Most object-relational products in the market must intrude into your persistent classes one way or another. Some common ways that persistence frameworks intrude into your code is by pre-processing code, post-processing byte code, forcing the use of a base class, extending your persistent classes, or requiring the use proprietary types. Sometimes you must also define or use additional classes (such as object factory classes) for each of your persistent classes. VBSF is based on a completely dynamic architecture and does not have any of the previously mentioned drawbacks. All you have to do to your business classes in order to persist them with VBSF is compile them. That's it! At runtime you only have to deal with a Database or PersistenceManager object which provides all the persistent services for your classes. A persistent class is never hard-wired to a specific database table or tables, and mappings can be changed on the fly at runtime. In addition database connections can be opened and closed at will while objects are loaded in memory. This allows client applications to work with objects off-line (i.e. while not connected to a database), and connect only when is necessary to send the updates back to the database. Fast Performance VBSF includes many performance enhancing features such as global shared object caching, connection pooling, and SQL statement caching. VBSF also provides a powerful query mechanism named In-Memory Queries. In-memory queries are queries that are processed directly from the object cache without accessing the database. Queries processed in-memory are executed many orders of magnitude faster than equivalent database queries. Standards Based The VBSF persistence layer API supports the two most important industry standards for object persistence: Sun's Java Data Objects (JDO) and ODMG 2.0 Java Binding. These API standards are being adopted by many O/R mapping tool and object database vendors. In addition, VBSF provides full and transparent support for XML. Persistent object graphs can be automatically converted to XML for transport to another system and XML documents received from other systems can automatically update persistent object graphs and subsequently the database. VBSF can also act as a conversion tool between XML and an RDBMS. The XML format is fully customizable to any format required by external systems. Open Architecture VBSF provides an open architecture that can be easily extended via Database Service Plug-ins. A Database Service Plug-in is small class library (only 7 classes) made up of adapter classes that can be dynamically loaded into VBSF at runtime. Multiple database services can be running at the same time within a server process. This allows clients to access multiple databases that require different drivers at the same time. VBSF supplies a JDBC standard Database Service Plug-in. You can easily implement your own custom Database Service (or we can develop it for you) based on a vendor's native library for legacy databases that do not support JDBC. Complete Object Modeling Part of the object-relational impedance mismatch revolves around the difference in the ways relationships are maintained. In the relational model a row references a row in another table by means of a lookup key. To retrieve the referenced row a database join must be performed. In the object model an object can access another object by direct reference. VBSF allows you to keep your object model intact by automatically translating between the two models so object relationships can be maintained using direct references. All three types of relationships-one to one, one to many, and many to many (with automatic join table maintenance)-are fully supported using direct object references. VBSF distinguishes the difference between aggregation and association and allows you traverse an aggregation hierarchy from owner to owned, or vice-versa (e.g., query for all owned objects matching a query specification regardless of owner and then retrieve each owner). See section Object Relationships for details on implementing object relationships. Legacy Database Integration VBSF is designed to easily integrate with most existing legacy databases. All SQL sent to the database is SQL-89 or entry level SQL-92 compliant. VBSF also provides specific support for many major database products (including Microsoft Access, Microsoft SQL Server, Oracle, Sybase Adaptive Server, Sybase SQL Anywhere, Informix, DB2, CA-OpenIngres, Borland InterBase, and Solid), and is very flexible in the way it can map business classes to relational data. See section Object-Relational Mapping for details. Security VBSF can help ensure the security of your data by fully encapsulating the database. This ensures that clients only see the object representations of the underlying data and only the operations defined in the business classes can be performed. A client cannot execute arbitrary SQL commands that could potentially retrieve or alter sensitive data. In addition, clients are not required to log into the database using database level username and passwords which further conceals the underlying database implementation details. See section Security for details. Powerful Query Capabilities One of the main strengths of a relational database resides in its powerful querying capabilities. Object models based on VBSF can take advantage of sophisticated relational query engines without leaving the object model. VBSF provides a query mechanism that enables ad-hoc access to objects. Queries can be issued that support the specification of logical operators, comparison operators, nested parenthesis, and sort orders. See section Queries for details. 3. Creating Persistent Business Classes VBSF achieves object persistence by saving the state of an object (the value of its attributes) to a relational database table. As a result, each business class must be mapped to a corresponding database table, and for each object attribute there must be a corresponding column in that table. There are three types of attributes that can be defined in a VBSF business object class:
Simple Attributes A Simple attribute holds a value of a specific type such us an integer or a date. You can define simple attributes using Java standard primitive or object types. If you need the ability to distinguish between zero and null values in numeric attributes, you should use Java object wrapper types instead of primitive types (e.g., use java.lang.Integer instead of int). A Simple attribute can also hold an embedded Java object of an application specific type. Object Reference Attributes In addition to simple attributes a persistent class can define attributes that reference other persistent objects. Object reference attributes can be declared as the referenced type, an interface implemented by the referenced type, or as the VBSF attribute type OReference. The OReference attribute type provides the functionality required to automatically retrieve and store object references in the database. A reference attribute can point to a superclass or an interface, in which case the actual type of the referenced object could be any of all possible types that extend the superclass or implement the interface. A reference to another object can also be retrieved using methods of the Database class. This method does not require defining an attribute in the persistent class in order to maintain references to other objects. Collection Reference Attributes Collection reference attributes hold a collection of objects of the same type or of
multiple types. This allows an object to directly reference a collection of objects.
Collection attributes can be declared as
VBSF supports homogeneous (one class) and heterogeneous (multiple class) collections. Heterogeneous can be based on a superclass (in which case objects from any of its subclasses can be part of the collection), an interface (objects from any classes that implement that interface can be part of the collection), or on multiple unrelated classes (objects from any of the named classes can be part of the collection). There are no restrictions on how classes that belong to a heterogeneous collection must be mapped to the database. Each class could be mapped to a different database table, or the classes could share a common table by means of filters. Examples The example below shows how a simple Contact business class that maintains a listing of phone numbers can be defined under VBSF: import com.objectmatter.bsf.*; public class Contact { //attributes public Contact() { //accessor methods public String getLastName() { public String getFirstName() { public java.util.Date getEntryDate() { //mutator methods public void setLastName(String newLastName) { public void setFirstName(String newFirstName) { public void setEntryDate(java.util.Date newEntryDate) { //Collection methods public PhoneNumber[] getPhoneNumbers() { public void addPhoneNumber(PhoneNumber phone) { public void removePhoneNumber(PhoneNumber
phone) { } VBSF also supports declaring a collection as an array of the referenced type. In the example above, the phoneNumbers attribute can also be declared as shown below: public PhoneNumber[] phoneNumbers; Below are some examples of how a client can manipulate the Contact class at runtime using the persistence layer API. Starting a database session in an n-tier application: Server server = new Server("contactdemo.xml"); Saving a new contact object: Contact contact = new Contact(); Retrieving a contact object and its phone numbers from the server: long idNumber = 7; Issuing a query for contacts with FirstName = 'ROGER': OQuery qry = new OQuery(Contact.class); VBSF always returns persistent objects as castable arrays. That is why in the above example you can simply cast the Object[] return value to the expected type of Contact[]. VBSF can also maintain relationships between classes without the need for the classes involved in the relationship to actually declare object and collection reference attributes. The Contact class in the above examples can be implemented without the phoneNumbers attribute. In that case, we can use the statements below to retrieve the phone numbers associated with a Contact object: long idNumber = 7; VBSF includes a mapping tool that allows you to visually map business classes to database tables and columns, and to specify object relationships. It can also be used to define server side custom SQL, validity checks, and customized database configurations. VBSF is designed to easily integrate with most existing legacy databases. The mapping tool can jump start application development by reading the structure of existing Java classes, or of existing database tables, and generate a default mapping strategy. This default mapping strategy can then be visually modified for further customization. If there are no existing classes and/or tables, a mapping strategy can be defined from scratch. From a mapping strategy, the tool can generate based Java source code for business classes and DDL scripts for target databases. Because source code and DDL script generation is based on templates, they can both be generated in any required format. Java business classes can be generated as Java Beans so they can be visually manipulated and connected to GUI controls in IDEs, and DDL scripts can be customized for specific target databases. The mapping strategy is saved to a central repository that is used by the supporting core library at runtime. The following mapping options are supported:
4.1. Class to Table Mappings VBSF supports the ability to define how a business class maps to one or more database tables. The following mapping types are supported:
4.2. Object ID Generation Persistent objects must be identifiable by a unique object ID which is mapped to one or more columns in the database table. The object ID column is mapped to a table's primary key, or to any other column with a unique index defined. Under VBSF object IDs can be of any data type and can be mapped to more than one column. This is fully supported across all types of object associations. VBSF allows object IDs to be generated by any of the following sources:
Database Engine ID Generation VBSF supports object IDs that are generated by the database engine using any of the methods below:
Business Object ID Generation Although this approach is not recommended, some applications generate the object ID according to a business rule. For example, a customer ID could be generated by concatenating the first three letters of the first name with the last name of the customer. VBSF fully supports this model, but the burden of generating the object ID falls on the business object itself. Sequence Table ID Generation Some database engines such as CA-OpenIngres cannot automatically generate the value of the object ID column using any of the methods described above. In that case VBSF can still generate an ID value using a database sequence table. A sequence table is a one row table with one or more integer type columns. Each column holds the next ID value to be assigned to the object ID of an instance of a persistent class. When a new object is saved to the database, VBSF automatically reads the next ID value from the sequence table, assigns it to the object ID, and increments the ID value in the sequence table. ID Generator Objects VBSF also supports the ability to plug-in your own ID generator object. This can be useful when none of the methods above are suitable. VBSF supports ID generator objects that create IDs of type long and String.
4.3. Inheritance Tree Mappings The three most common methods to map a class inheritance tree to a relational database are:
A combination of mappings may also be used within an inheritance tree. VBSF fully supports all three types of inheritance tree mappings. Part of the object-relational impedance mismatch revolves around the difference in the ways relationships are maintained. In the relational model a row references a row in another table by means of a lookup key. To retrieve the referenced row a database join must be performed. In the object model an object can access another object by direct reference. VBSF automatically translates between the two models so object relationships can be maintained using direct references. Below is a short description of how three different types of relationships between two business classes are implemented in VBSF:
6. Queries One of the main strengths of a relational database resides in its powerful querying capabilities. Object models based on VBSF can take advantage of sophisticated relational query engines without leaving the object model. Properly designed and indexed relational models can provide fast ad-hoc access to objects. VBSF also provides a powerful query mechanism named In-Memory Queries. 6.1. In-Memory Queries In-memory queries are queries that are processed directly from a collection cache without accessing the database. Queries processed in-memory are executed many orders of magnitude faster than equivalent database queries. In-memory queries are automatically enabled for all collection attributes that are cached. VBSF contains a powerful query engine used to process in-memory queries. 6.2. Issuing Queries VBSF provides a class named OQuery that is used to issue queries to the database. This class allows performing complex queries without specifying any SQL or OQL. To issue a query an OQuery object is created, query parameter values, class joins, and sort orders are added to the OQuery object, and the query is executed. The OQuery class also provides support for retrieving distinct objects and for restricting the maximum number of objects returned. An OQuery object can be executed by invoking its execute() method, or by passing it as an argument to a collection's get() and list() methods. For root classes both ways are identical. For owned classes the method in which the query is executed determines whether the query is constrained or ad-hoc. If a query object is passed as an argument to a get() or list() method of an owned collection, then the query is constrained by the set of owned objects (i.e. the query is used to further limit which objects are returned from the set of objects that are owned by a particular object). If a query is executed via its execute() method, an ad-hoc query is performed. Ad-hoc queries performed on owned classes are not restricted by ownership constraints. In other words, it is possible to formulate queries that return objects owned by different objects. Query Parameters Each query parameter added must include the attribute name, the search value, and optionally a comparison type, logical operator, and grouping type. The comparison type specifies how the value stored in the database table is to be compared with the search value supplied. Valid types are: EQUAL, LIKE, GREATER, LESS, GREATER_OR_EQUAL, LESS_OR_EQUAL, IN, NOT_EQUAL, NOT_LIKE and NOT_IN ( defaults to EQUAL if not specified ) The logical operator describes the type of logical operation to be performed between any two comparisons. Valid operators are: AND, OR, EQV, and XOR. ( defaults to AND if not specified ) Grouping types are used to specify a specific order of evaluation for attribute comparison expressions. Valid types are:
Sort Order A sort order includes the attribute name to sort by and an optional sort order. A table field name can be specified instead of the attribute name if a result set is to be ordered by a field that has no corresponding attribute in the business class. The sort order can be either ascending or descending. If no sort order is specified, an ascending sort is performed. Examples The code below issues a query that retrieves all contacts with a Category whose ID = 3 and a first name >= 'ROGER', sorted by last name ascending. The query returns only the first 50 objects matching the query specification: Server server = new Server("contactdemo.xml"); After the query object is created, query parameters and sort orders are added to the query using the add and addOrder methods. The query object is then executed and returns an extent of the objects matching the query parameters. Below is an example of a join query that retrieves all customers who have purchased any edition of the product named 'VBSF' and paid at least one thousand dollars for it. The query is formulated by joining three classes: Customer, Order, and Product. The Customer.fID (i.e. the object ID) attribute is joined with the Order.myCustomer attribute (of type OReference), and the Order.myProduct attribute (of type OReference) is joined with the Product.fID attribute (i.e. the object ID). The results are then sorted by Customer.fLastName. The argument to the addOrder method is not qualified by a class name because ordering is automatically performed on the class being queried. OQuery qry = new OQuery("Customer"); 7. Security One of the advantages of implementing a middleware based application is that client-wide security measures can be implemented at the application server level. A major security risk of using type 3 and 4 JDBC drivers from applet clients is that the database must be exposed to the client. This might not be a problem in an intranet application, but could pose major security risks in an internet application. If a database is exposed to the world there is always a chance that someone could guess or deduct a database level password and gain access to the database. This means a client could retrieve sensitive data, or worst, issue destructive SQL. VBSF, on the other hand, allows you to create applications that fully encapsulate the underlying database. Clients are not required to log into the database using database level username and passwords. A server object can log-in and obtain a connection for the client under a predefined username and password with access restrictions at the database level. VBSF also supports establishing a dynamically growable connection pool upon startup, which has the added benefit of improved performance. More importantly, all object-relational mapping schema is defined at the server. Clients only see the object representations of the underlying data, therefore only the operations defined in the business classes can be performed. A client cannot execute arbitrary SQL commands that could potentially retrieve or alter sensitive data. VBSF stills allows you to predefine named custom SQL statements and stored procedures which a client can execute by supplying the command name. An attribute validity check allows you to set and enforce a set of parameters that define the validity of an attribute value. The following validity checks may be defined:
VBSF supports both manual transaction control and automatic transactions. When a database update method is called, the persistence layer checks to see if a transaction is in progress. If no transaction is in progress, then it starts one automatically. If the persistence layer started the transaction, it will automatically commit it once the database update is complete, or roll it back if an error occurs. Automatic transactions can also be disabled if desired. VBSF supports two ways of providing explicit transaction control:
The example below demonstrates explicit transaction control using a Transaction object by posting changes made to two objects to the database within the context of a transaction: Server server = new Server("contactdemo.xml"); 10. Custom SQL and Stored Procedures One of the primary goals of VBSF is to combine the strengths of object and relational technologies. SQL statements and stored procedures are relational tools that do not integrate well with the object model. However, both tools can provide ways to accomplish tasks that might otherwise be difficult or too slow to implement in the object model (e.g. a posting procedure that updates hundreds of rows in batch mode). For this reason, VBSF supports the ability to send custom SQL statements to the database and to execute stored procedures-with support for input parameters and/or output parameters. VBSF fully supports two types of SQL statements and stored procedures:
In addition VBSF provides mechanisms to specify input parameters in both SQL statements and stored procedures, and to retrieve output parameters from stored procedures. 11. Object Caching When retrieving objects you have the choice of storing them in the object cache after they are retrieved from the database. The object cache is maintained internally in one or more optimized map and balanced tree data structures to support quick retrievals. VBSF supports both Static and Dynamic caching. Dynamic caches may be defined as Soft or Weak, which allow the garbage collector to reclaim memory in use by the caches according to the collector's policy in regards to the cache type. Using the object cache can dramatically improve performance in subsequent retrievals. VBSF automatically enables in-memory queries when objects are present in the cache. VBSF™ is developed by Objectmatter, Inc. To contact Objectmatter visit our web site at http://www.objectmatter.com, or by electronic mail at sales@objectmatter.com. |
© 1997-2005 Objectmatter, Inc. All rights reserved. |