Re: Does Oralce 9 supports Java Objects ?

On Tue, 4 Sep 2001 23:03:23 +0200, etechweb_at_yahoo.com (Sebastiano Pilla) wrote:

>
>results could still be used as instances of Java Beans by Java
>developers, who may not need to be intimately familiar with the
>underlying data model (although familiarity with the data model makes
>them work better, but then I digress...).
>

This is an issue that was hotly debated where I'm working. The Java people seemed to think that having direct access to the low-level database model was an advantage. We thought it wasn't. Due to the nature of the applications and their life cycle, the design keeps changing. Bad nees for hard-coded database access layer.

I've left them access the low level model for the first iterations, so they could fully realize what the problems would be if they had to go and change their SQL all over the place due to a change in data model. It's happened, and they now turned around and agreed with us that it's better to have the thing hidden from them.

What we are doing now is providing them with a similar thing to this ACS. We have our low-level tables/indexes/RI etc. On top of this, we build a logical model based on views and packages that fully insulate the Java guys from the intricacies of how the data is actually stored.

Basically, we map their object model to our physical relational model through a middle layer that hides all the details. They are happy little fellas now: we can change the physical model at will (within limits!) and they don't have to care about it.

The key factor to make this work is to have the business analysis pinned down to the business function/use case level before anything is written/designed/created. Once we can identify the main business use cases, we can easily map them to a relational design that can be stored and managed easily. The Java people still can do queries against the data through the view abstraction (which we can modify/optimize/manage independently) and data changes are handled by packages that map strictly to the use case functionality.

Beans were intended to provide this abstraction, but unfortunately problems in their portability and feature-set have made them mostly irrelevant for this level of abstraction. We still use them but more to enable a mapping of Java object to the API and its packages. Once we iron out a few problems we have with JDBC compatibility, we'll be bringing them in only for connection pooling and session control.

>Perhaps the ACS system is a little immature, but I'm confident that
>it'll grow in robustness in the following months. If everything goes
>well I'll be able to make some experiment with it in the near future.

Yeah, looks good. I'm glad you gave me the chance of looking at it. It's very similar to what we've been doing here and reinforces my belief we're on the right track. Thanks a lot.

Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam Received on Wed Sep 05 2001 - 06:09:34 CDT