The DML privileges

For object tables, the traditional SELECT, INSERT, UDPATE, and DELETE privileges still have some meaning. A user with only SELECT privilege on the object table may retrieve any relational columns in the base type on which the table is defined, but cannot retrieve the object-as-object. That is, VALUE, TREAT, REF, and DEREF are not available. Similarly, the other DML privileges, INSERT, UPDATE, and DELETE, also apply only to the relational interpretation of the table.

In the same fashion, the grantee will not have permission to use the constructor or other object methods unless the object type owner has granted the user EXECUTE privilege on the object type. Any columns defined on subtypes will be invisible.

21.5 Pontifications

I have to confess that I started programming before object approaches made any kind of inroads into business application development. I think I'm still waiting for that to happen.

Over the years, I've seen no compelling evidence that any particular programming style has a monopoly on the fundamental things we care about—fidelity to requirements, performance efficiency, developer effectiveness, and system reliability. I have seen a lot of fads, bandwagons, hand-waving, and unsupported assumptions (OK, I'm probably not entirely innocent myself), and object-oriented programming seems to attract quite a lot of it. That isn't to say that OOP fails to help you solve problems; it's just that OOP is not the magic bullet that many would have you believe.

Take, for example, the principle of object-based decomposition, particularly as it tends to generate inheritance hierarchies. By accurately modeling objects as they exist in the real world, software artifacts should be easier to comprehend, faster to assemble, and more amenable to large-scale system development. Sounds fabulous, doesn't it? Well, there are a lot of different ways to decompose something drawn from the real world.^[13] It is a rare taxonomy that can exist in a simple hierarchy. My library catalog hierarchy could have been decomposed according to, say, media (print versus audio tape versus digital format . . . ). And, although Oracle provides wonderful tools for type evolution, it may still be so painful to make sweeping changes in a type hierarchy that it will never happen. This isn't really the tool's fault; reality has a way of circumventing even the best-laid plans.

^[13] See "Object Oriented Programming Oversold!" by B. Jacobs, http://www.geocities.com/tablizer/oopbad.htm.

Nor is it even clear that co-locating the programming logic (methods) with the data (attributes) in an abstract datatype yields any measurable benefits. It looks reasonable and makes for some great sound bites, but how exactly will coupling data and behavior be better than keeping data structures (logical and physical table design) separate from processes (procedures, functions, packages)? Many development methods acknowledge that an organization's business data structures have a much slower rate of change than do the algorithms that manipulate them. It is a design truism (even for OOP) that the more volatile elements of a system should be kept separate from the more stable elements.

There is considerable inconsistency on this last point. Rich and famous object evangelists, while emphasizing the value of bundling data with behaviors, simultaneously promote a "model-view-controller" approach that "separates business logic from data." Are these emperors wearing clothes, or not?

Many OOP proponents have argued for years that its greatest benefit is the reuse of software. It has been said so many times that it must be true! Unfortunately, few observers have hard evidence for this,^[14] in part because there is no consensus on what constitutes "reuse." Even object apologists began promoting higher-level "components" (whatever those may be) as a preferred unit of reuse precisely because objects proved very difficult to fit into situations beyond those for which they were designed. My sense is that OOP results in no more code reuse than well-designed subroutines.

^[14] See "So Much OO, So Little Reuse," by Lawrence Finch, Dr. Dobb's Journal, May 7, 1998.

It is certainly possible to use object-oriented approaches with PL/SQL and achieve reuse of software. Fellow author Don Bales, an accomplished object-oriented programmer, has been using PL/SQL packages as "types" for about a decade, and he says that he has been able to take entire packages (and any accompanying tables) and drop them into new software development projects without modification. He believes that the missing ingredient in most object approaches is an accurate model of the person who is actually executing the software—the user—whom Don models as an object with behaviors implemented in the actual program that is run.

Regardless of development method, some of the critical ingredients of software success are having prior expertise with similar problems, being able to employ seasoned project leaders, and incorporating a conscious software design phase. Introducing object methods or any other approach is likely to produce more positive results than an unplanned, organically grown system.

A few final thoughts on when to best use Oracle's object features:

· If you use the Oracle Call Interface (OCI), it's possible that the client-side cache and complex object retrieval would tip the scales in favor of heavy use of Oracle's object features. I'm not an OCI programmer, though, so I can't speak from experience in this regard.

· If your organization already uses object programming across the board, Oracle's object features will probably make it easier and more graceful to introduce database technology into your systems.

· Don't throw the collections baby out with the objects bathwater. Remember that you don't need to use object types or object views to take advantage of collections.

· If you've never used OOP before, these object features may seem quite complicated. I would encourage quite a bit of playing around before committing to an object approach. In particular, try out object views in conjunction with an existing system.

· I would caution against rejecting object types and object views on a vague performance argument. Oracle has made continuous progress in reducing overhead. If you perform some actual measurements, you might find OOP within acceptable bounds for your application.

· It turns out that Oracle delivers some of its built-in functionality (in features such as Oracle9i Advanced Queuing and Oracle Spatial) using object types. Using these features will require you to understand something about the object features even if you don't want to create your own custom types.

Chapter 22. Calling Java from PL/SQL

In this chapter, I explore an exciting feature introduced in Oracle8i that allows a developer to call Java stored procedures ( JSPs) from within PL/SQL. Java is a very powerful language, more robust in many ways than PL/SQL. Java also offers hundreds of classes that provide clean, easy-to-use Application Programming Interfaces (APIs) to a wide variety of functionality.

22.1 Oracle and Java

Beginning with the Oracle8i release, Oracle includes a product called JServer, which consists of the following elements:

· Oracle's Java Virtual Machine ( JVM), called Aurora; the supporting runtime environment; and Javaclass libraries

· Tight integration with PL/SQL and Oracle RDBMS functionality

· An Object Request Broker (the Aurora/ORB) and Enterprise JavaBeans (EJB)

· The JServer Accelerator (native compiler)

The Aurora JVM executes Javamethods (also known as Java stored procedures, or JSPs) and classes if they were stored in the database itself.

Java in the Oracle database is a big topic; Java programming all by itself is an even bigger topic. Complete treatment of either is outside the scope of this book. My objectives for this chapter are limited to the following:

· Providing the information you need to load Java classes into the Oracle database, manage those new database objects, and publish them for use inside PL/SQL

· Offering a basic tutorial in building Java classes that will provide enough guidance to let you construct simple classes to access underlying Java functionality

To access Java class methods from within Oracle, you must take the following steps:

1. Create the Java code elements. You can do this inOracle's JDeveloper or in any other Java Integrated Development Environment. (In a pinch, notepad.exe will also do the trick!)

2. Load the Java classes into Oracle using the loadjava command-line utility or the CREATE JAVA statement.

3. Publish the Java class methods inside PL/SQL by writing wrapper programs in PL/SQL around the Java code.

4. Grant privileges as required on the PL/SQL wrapper programs and the Java class referenced by the PL/SQL wrapper.

5. Call the PL/SQL programs from any one of a number of environments, as illustrated in Figure 22-1.