Tim,

It never ceases to amaze me how useless vendor reps. can be. He had it totally
backwards. It was originally Oracle's own implementation and they completely
replaced it with Orion about a year or so ago. I could be mistaken, but I don't
think they've done much more than wrapping it and renaming the jar. Like you
said, they didn't even bother to rename the jar at first.

Are the development tools and the technical rep. worth whatever Oracle charges
over Orion's $1500/server (note server as opposed to CPU)? ;) What does Oracle
charge anyway?

I'm working at OCI now. I'm out at A. G. Edwards with Mark Volkmann and Pat
Niemeyer on the Enterprise Services team. Basically we're just mapping their
relational database to the mother load of data transfer objects which will be
used in all of the other AGE applications.

I think my design is actually pretty cool. They originally started out with a
Custom Data Transfer Object pattern (EJB Design Patterns) where they would
create variations on the object maps to service different clients' needs. For
example, Type A references collections of type B and C. Client 1 primarily
accesses A and B, client 2, A and C. They would create two variations on type A,
one with accessors for the B collection and the other with accessors for the
type C collection. This is a common practice. In rare situations where Client 1
needed to access collection C, the client would have to take the ID from A and
query for the C collection separately. The incentive for doing it this way is
that you don't transfer the entire object map which could be very inefficient or
even impossible (in cases where fulfilling every possible relationship would
return the entire database, exploding the heap in the process ;)).

The problems with this typical approach is that one, the number of classes and
services you must implement grows exponentially. Two, it's very difficult to
automate the generation of the code. Three, should the client's needs change,
it's very difficult to modify the implementation and deploy the changes. Four,
it's very difficult to reuse code between the clients. Five, in cases where you
do reuse code, you end up with fragile dependencies. Six, the interface is not
very consistent; sometimes the client calls a getter, sometimes they get the
objects via another service. etc.

My approach is to refactor the code that builds the relationships on the server
side, and the code that manually completes the relationships on the client side,
into the bean implementations themselves. EJB's location transparency makes this
possible. It doesn't matter whether the bean fulfills the relationship on the
client or server side.

Basically what you end up with is lazy-loading getters. When the client calls
the get method, the bean checks to see if it already has the data. If it
doesn't, it queries for the data through the data access service. If you want to
cache up data on the server side (this is equivalent to implementing the
mappings in the first place), all you have to do is invoke the methods before
you return the object to the client. The data will get cached up and sent along
with the response. You can even configure this declaratively using reflection.

You end up with identical performance to the original approach, however you only
have a single implementation class for each bean type. If the client only
accesses collection C 5% of the time, don't preload the data on the server side.
The getter for collection C will automatically go back to the server if it needs
to. You can tweak performance post-deployment without any modifications to the
code or client.

EJB also makes it really easy because the client doesn't have to look up the
data access service. You can simply store the data access service's remote stub
in the bean before you send it back. Given XML descriptions of the beans'
fields, their relational mappings, and their relationships, it is very easy to
autogenerate this code.

It looks like it's going to work. I'm keeping my fingers crossed. I'm also
coauthoring a book with Bruce Tate. It's called "Bitter EJB" and is the sequel
to his best seller "Bitter Java". I'm using Custom DTO's as an AntiPatterns and
the pattern I just laid out as the refactored solution.

There are some potential security issues if the client can just send arbitrary
queries. I think keeping the queries on the server side and having the client
pass in a query ID and the parameters should be sufficient. This will allow me
to limit access to given queries based on user roles. This puts me on par
security-wise with the rest of the EJB architecture and it will be easy to
implement and configure declaratively. I'm not too worried about it though
because this is for internal use behind other AGE applications.

Bob
----- Original Message -----
From: Tim Burns
To: stlroundtable@yahoogroups.com
Sent: Saturday, September 21, 2002 11:38 AM
Subject: Re: [stlroundtable] Meeting?



Hi Bob!
Well I flew in but no one was there. :( Glad to hear from you.
So what have people been up to?
I'm right now working on a Struts app and getting ready to port a tomcat
version to Oracle's app server. I spent a good part of my week this week
fighting with the very painful install. Anyways, the app server is reall Orion,
which I think is really funny. I asked the Oracle rep about this and he said it
was originally Orion, but they replaced it a long time ago. This was the guy
that, "worked on the project and knew everything about the server." I looked at
the jars for the server, and all they did was change the name from orion.jar to
oc4j.jar. Oh well, for the Oracle "consultant".
All that matters though is that it works, and Orion is a great app server.
Oracle did put some nice web deployment wrappers around it though.
I've been working a little perl script to synchronize files between a very
slow vpn link and my home computer. I'll post it when I get a few more bells
and whistles on it.
Tim
Bob Lee <crazybob@...> wrote: Who's up for a meeting for old time's
sake? It's getting to be about
that time of year. I know it's short notice, but I can go for tomorrow
if anyone's interested, or next Sat., or both. Tim, Louis, is that
enough notice for you to fly in? ;)

It's been a while; where are you all at, what are you up to? Will, you
outta school yet?

Bob



To unsubscribe from this group, send an email to:
stlroundtable-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



[Non-text portions of this message have been removed]


Yahoo! Groups Sponsor
ADVERTISEMENT




To unsubscribe from this group, send an email to:
stlroundtable-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]