![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Developers should want to know about and contribute to the development of the object-oriented wireless model, including learning how the model is used to store and retrieve complex information about the conceptual design of a wireless infrastructure.
It is important for object-oriented wireless system designers to possess a working knowledge of how models for storage and retrieval systems have evolved -- from flat files to the Object-Oriented Database Management System (OODBMS) to the next innovation -- in order to maximize the productivity of their designs and to reduce the concept-to-deployment period.
In this article, I'll start with a short discussion on how storage and retrieval systems have evolved from flat file databases to object-oriented database management systems; then I'll cover the object-oriented wireless model basics by presenting the hierarchical structure of database objects representing the conceptual design. I'll discuss some shortcomings of the model and a solution or two for each of these limitations. I'll then wrap up by explaining how to prepare for the upcoming world of the object-oriented wireless model.
The evolution of storage and retrieval systems
Data storage and retrieval systems can be divided into four main types:
- Simple flat file databases.
- Relational database management systems (RDBMS).
- Object-relational database management systems (ORDBMS).
- Object-oriented database management systems (OODBMS).
Each is associated with a certain range of virtualization defined as the "ability to view data wirelessly from the client side without knowing the locations of the servers receiving and getting the data." (See "Wireless Virtualization Model" in Resources.)
Virtualization does not exist in flat file databases. Data virtualization actually started when the evolutionary path reached the RDBMS stage, the first of the commercial database management systems. As database management systems have evolved, the range of virtualization has grown.
Figure 1. Evolving virtualization
I'll discuss the various database systems on the evolutionary path.
A flat file database is a database that is self-contained in a single table. Because the database is limited to one table, it is not possible to create multiple tables with structured relationships to one another. Because this type of database is designed to run on a single client-side machine, it is not possible to virtualize data.
Another disadvantage to the flat file is the heavy computational time needed to store and retrieve complex design information. Imagine the flat file database as a single sheet where, when you add more data, it is placed even farther away from the starting point. The more data, the farther the "travel time" to retrieve it.
For these reasons, this storage type is not an option for the conceptual design of a wireless infrastructure.
The next step in the evolutionary path is the RDBMS (relational database management system), which uses a structured approach to store and retrieve data in traditional business applications such as banking transactions and inventory control. An RDBMS organizes a collection of information into interrelated tables of data. Now imagine not one of the single flat-file sheets, but a multitude of them, stacked atop one other. You have the ability to burrow through the sheets to make a quick retrieval trip instead of having to speed all the way to the edge of the single sheet. The same database table of well-structured and standardized data can be viewed in many different ways.
Another feature of this database system is its flexibility for posing queries (such as the Structured Query Language, SQL) on several databases of tables across multiple servers. It gives the user the option to view virtualized data wirelessly from, say, a handheld device.
One drawback is that a relational database system is not well suited for storing and retrieving the conceptual design. It cannot handle complex data structures and new data types for storing images and large textual items because the conceptual design does not have a standard structure.
Object-relational database management systems
The ORDBMS model extends the RDBMS model by superimposing the object-oriented database concepts of objects onto a relational database. Like the RDBMS, the ORDBMS (such as DB2) takes the bottom-up approach (or data/database-centric approach; for more on this read the "Object persistence in object-oriented applications" article in Resources). DB2 is the most scalable object-oriented database on the market running on devices from handhelds to Linux enterprise servers.
Developers can use the ORDBMS to manage object-oriented spatial data in DB2 and Informix. They also can integrate Java Data Objects (JDO) with DB2 (and WebSphere Studio). Through virtualization, developers can enter data objects into a database on a server without knowing its location.
One drawback to the ORDBMS is that it is not good for storing objects containing complex geometric data that developers would use to build the conceptual design. Another disadvantage is a possible loss of information when the system maps the objects to a relational database.
Object-oriented database management systems
At the current end of the evolutionary path is a DBMS system supporting the modeling, creation, and management of data as objects -- the object-oriented database management system. The OODBMS is quite useful for computer-aided design/computer-aided manufacturing applications (CAD/CAM) that emphasize complex navigational access, object versioning, and long transactions of task and system activities.
This database system takes a top-down approach, being application- or programming-language-centric. For instance, the free Objectivity/DB 8.0 download includes tools for transparent interoperability for C++, Java, Smalltalk, and SQL++/ODBC applications running on AIX and Linux.
The OODBMS is useful for retrieving complex objects and geometric data to assist developers in presenting the conceptual design in a feasibility study. This system involves a representation of previous and new subsystems, meaning that the objects in an inheritance hierarchy can reused -- an advantage over relational data that is not always reusable.
Another advantage is that an object contains information (such as data about a wireless handheld device and its uses). It is not necessary to break the information into discrete data (like owner's name or the different ways the device is used) in the way the developer would to store each piece of information in its own field in a relational database.
Developers can derive information blocks from data structures to create a hierarchy of discrete objects. The hierarchy begins with the main object at the top level and proceeds down to lower levels of database objects. Each object at one level inherits the properties of an object in a previous level. These objects can be virtualized across multiple servers.
The problems with the OODBMS, along with suggested solutions, are noted later in this article. For now, I'll discuss some of the basics of the object-oriented model.
Basics of object-oriented model
In this section I'll focus on the parallelism between the hierarchical structure of features in a wireless model and the inheritance structure of the object-oriented paradigm, presenting a picture of each to demonstrate the parallelism. Then, I'll briefly cover static object relationship in an application example.
This parallelism strongly supports entry of feature-based design information, such as the disks representing DB2 Everyplace Database and DB2 UBD Source Database, into an object-oriented database. The object-oriented database can be scaled dynamically.
The following figures contain examples of the dynamic database capability of the object-oriented database. On the right in each example is a menu of feature-based information objects. Its hierarchical structure is shown on the left with each object corresponding to an object in the menu.
First level of database objects.
The following figure shows three study objects on the right representing the top (first) level of database objects in the conceptual design on the left.
Figure 2. First level of database objects
Second level of database objects.
Now, I'll scale the hierarchy to include children objects in lower levels of database objects. For instance, a WLNetwork object in the second level of database objects (red) refers to a wireless network and is the only type of child object of a study object, as shown in Figure 3. The WLNetwork object inherits properties from the study object in the first level of database objects.
Figure 3. Second level of database objects -- children objects
Third level of database objects.
Additionally, the WLNetwork object can have multiple different children objects. They are server object, mirror object, client object, node object, cable object, and others, when put together in a hierarchy, represent an enterprise wireless network infrastructure. For brevity, an example of server, mirror, and client object children at the third level is shown in Figure 4.
Figure 4. Third level of database objects -- multiple children objects
Fourth level of database objects.
Going down one level, you see in the illustration a server object having database and application object children (green), a mirror object having an application object child (gray), and a client object having a wireless object child (red).
Figure 5. Fourth level of database objects -- children of children
Fifth level of wireless object.
The following demonstrates the fifth level of a wireless object having MobileDatabase as the object child called DB2 Everyplace Database.
Figure 6. Fifth level of wireless object
Sixth level of database object.
The following demonstrates the sixth level of the database object, the child of the server object, having SDatabase as the object child called DB2 UCB Source Database.
Figure 7. Sixth level of the database object, the child of the server object
To show how each database object is related to another, I'll indicate what the static object relationship between the objects is. It is not the same thing as the active, dynamic object relationship that typically involves a message being sent from one object to another.
As adapted from the "Remote Control" article (mentioned in Resources), the following table shows static object relationships between three database object children.
The source database object child, DB2 UBD Source Database, has a replication object relationship with the middle database object child, a mirror database, in both directions, and in turn, an update synchronization object relationship with the target database object child, DB2 Everyplace Database. DB UDB Source Database also has an e-mail notification object relationship with the target database object child, DB2 Everyplace Database.
Table 1. Static object relationships of database object children
| Source database object | Object relationship | Middle database object | Object relationship | Target database object |
| SDatabase (DB2 UDB Source Database) | Replication (bilateral) | Application (A2) | Update Synchronization (bilateral) | MobileDatabase (DB2 Everyplace Database) |
| Notification e-mail (forward) |
Now, look at the limitations of the OODBMS model.
Model limitations (and solutions)
As promised, the following table describes some of the limitations of the OODBMS model and provide a solution for each restriction.
Table 2. Limitations (with solutions) of the OODBMS model
| Limitation | Solution |
| Discreteness. Objects are discrete and not continuous. | Determine which objects begin and which others end. |
| Non-representation. Objects do not represent easily identifiable discrete entities in the real world. | Modify objects to make a better representation of the real-world entities. |
| Ambiguity. The meaning of an object depends on the context and might yield contradicting interpretations. | Clarify meaning of the object and develop an Object Dictionary. |
| Inadequacy. Plans for a hierarchy of objects are inadequate. | Develop plans in terms of scope, budget, and delivery time. |
| Difficulty. Once an inheritance hierarchy is in use, it can be difficult to adjust it with, say, new category of objects. | Ensure the hierarchy is well-constructed. |
Preparing for the object-oriented future
The evolutionary path for the object-oriented wireless models does not end here. It will continue to evolve to include a new storage and retrieval system for say, meta-objects. This continual upgrade will be possible as long as technologies of the future provide us with more memory and more speed at greater disk capacities.
- "Working with the Geodetic and Spatial DataBlade Modules" presents an interesting usage of Informix's ORDMBS.
- "Object persistence in object-oriented applications" illuminates ORDBMS and OODBMS models.
- "Integrating JDO with DB2 and WebSphere Studio" is a tutorial that provides a basic understanding of Java Data Object technology and how it integrates with DB2 and WebSphere Studio Application Developer.
- "Remote Control" explores the small fingerprint relational and synchronization architecture DB2 Everyplace database.
- The PartnerWorld Linux Lens explains DB2's role as a scalable object-oriented database.
- The JSR 12: Java Data Objects (JDO) Specification provides for interface-based definitions of data stores and transactions, and selection and transformation of persistent storage data into native Java programming language objects.
- The About.com database guide is a good roundup of database basics.
- The author's book, Enterprise Systems Integration, provides the business insight and the technical know-how to ensure successful systems integration (Auerbach Publications, 2001).
- A handy guide that demonstrates how various object-oriented development methods can be combined into an overall approach is Mainstream Objects: An Analysis and Design Approach for Business by Edward Yourdon, et al (Prentice Hall, 1995).
Judith M. Myerson is a systems architect and engineer, a freelance writer, and a robotics columnist. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, distributed systems, wireless technologies, robotics, component-based technologies, security, cryptography, object-oriented technologies, and project management. She is the editor of the Enterprise Systems Integration Handbook, Second Edition (Auerbach). You can contact her at jmyerson@bellatlantic.net.
