Women in Technology

Article:		Flawed JDO Points the Way to the "Objectbase"
Subject:		Apples to Apples?
Date:		2002-04-26 05:43:44
From:		balesd
Response to: Apples to Apples?
First, UDTs (Oracle or not) are portable because they are part of the SQL:1999 standard which has been implemented by vendors other than Oracle. Second, the use of Java is no more portable that the use of Oracle. Both are portable only because implementations of the core software, the DBMS for Oracle and JVM for Java are provided for most operating systems. So there's nothing *non-portable* about UDTs of Oracle. Third, the lack of the ability to do navigational access only exists in the weakness of the SQLData interface. Oracle's ORAData interface provides this kind of capability. Most importantly though, you missed my point altogether. You seem happy to continue to use and object-oriented programming language to build software and to use relational technology to store data. That means you're not using the fundamental strengths of object-orientation to place both data and behavior together in a persistence layer where it is accessible to all programming languages. In effect, you're using a *non-portable* Java only solution to the business problems you're solving with the software you're writing. Continuing to use relational technology when mature object-relational technology exists is a disservice to the customers for which we are writing software.

Showing messages 1 through 4 of 4.

• Apples to Apples?
  2002-04-29 14:35:18  perrin [View]
  
  
  How can you store the behavior in the persistence layer? Writing it in PL/SQL? Using some kind of proprietary Oracle stored procedures in Java? The example in the article does not seem to be storing any behavior, just the current object state.
• Yes, Apples to Apples?
  2002-04-30 10:43:53  Donald Bales | [View]
  
  
  In the case of using Oracle as the persistence layer for SQL:1999 UDTs, behavior can be implemented as "stored procedures" that are part of the UDT written in Oracle's PL/SQL or written in Java. I did not show an example of this in the article because I was trying to limit the functionality as in the program that used JDO in the previous article by Dion Almaer. I do show an example using PL/SQL in my book and also show how to use Java.

• Apples to Apples?
  2002-04-26 18:56:39  Jonathan Gennick | [View]
  
  
  <blockquote>
  In effect, you're using a *non-portable* Java only solution to the business problems you're solving with the software you're writing.
  </blockquote>
  
  Ok, I have a question. If I'm using JDO, what happens when I need to access my objects from another language, say C++? With a UDT, the object definition is stored in the database where it is accessible from any language. Isn't that a good thing?
• Portability?
  2002-04-30 16:36:58  Donald Bales | [View]
  
  
  Entity behavior that exists only in Java classes is not accessible to anything but Java. So it follows that using JDO against a relational database limits the accessibility of behavior to Java programs only.
  
  My assertion is that having entity behavior exist in the objectbase will make it accessible to all languages that can access the objectbase. For the most part, I believe this is an unpopular idea because it is not a Java only solution. Instead it's a Java and SQL solution. SQL's non-procedural nature is its strength. If an objectbase existed where the definition language and access language was strictly implemented in Java, then many Java programmer's would be very happy. But that technology would be stricly procedural and lack the power of SQL.