Yep, the very same. He reads the ejb-interest list and frequently posts
very informative missives there. In fact, an excellent education can be
obtained simply by searching the archives for his name. Seriously.
Jeff
-----Original Message-----
From: Kemp Randy-W18971
Sent: Thu 2/8/2001 6:05 AM
To: Orion-Interest
Cc:
Subject: RE: Orion-console in 1.4.7 supports DataSource
properly... now what!!!
Is this the same Richard who heads www.openejb.org? Their site
mentions:
OpenEJB is the brainchild of Richard Monson-Haefel, author of
Enterprise JavaBeans, 2nd Edition (O'Reilly 2000). The core development
team for OpenEJB is Mr. Monson-Haefel and David Blevins.
-----Original Message-----
From: Jeff Schnitzer [ mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 8:22 PM
To: Orion-Interest
Subject: RE: Orion-console in 1.4.7 supports DataSource
properly... now
what!!!
I posted this question to the ejb-interest list, and got back
the two
attached responses. The one from Richard Monson-Haefal is most
interesting, because it pretty much confirms that WebLogic uses
a JDBC
proxy.
I agree, being able to communicate with the database behind a
firewall
means there must be some sort of proxy implemented by Orion.
It's not
just a simple question of putting an RMI proxy on the Connection
(and
Statement, DatabaseMetaData, etc), though... you certainly
wouldn't want
the ResultSet to be remoted otherwise you would suffer worse
performance
than plain EJB calls. And if you returned the ResultSet as a
single
object you would have serious problems with large queries.
Interesting.
Why again aren't you implementing this logic server-side? :-)
Jeff
>-----Original Message-----
>From: Daniel Cardin [ mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 07, 2001 5:37 AM
>To: Orion-Interest
>Subject: RE: Orion-console in 1.4.7 supports DataSource
properly... now
>what!!!
>
>
>Jeff,
>
>>Are you sure that the JDBC driver isn't finding its way into
the
>>classpath? Did you try the console remotely from a machine
that you
>>know doesn't have the JDBC driver?
>
>Honestly, I haven't. But I still fail to see why it would be
needed.
>If the data access was done using the "real" JDBC driver on
>the client,
>the connection to the database would have to be opened there...
>It's not the case. Running tests at home allowed me to prove
that the
>Connection must be proxied through Orion because my client
could not
>see the SQL server. The only conclusion is that Orion opens a
>connection
>
>locally, pools it, and on demand gives a proxy to it allowing
all
>database access to go through the App Server...
>
>>You may already know this, but just in case: Almost all of
the orion
>>tools (including orionconsole.jar) are simply empty jar files
with a
>>manifest that sets the Class-Path to include orion.jar and
defines the
>>appropriate Main-Class. You're still loading the orion.jar
classes,
>>potentially activating whatever classloader loads jars
(especially the
>>JDBC driver) out of the lib directory. Did you take this into
account
>>in your tests?
>
>I know about the way orionconsole works, thanks :) I've
actually spent
>quite
>some time analysing com.evermind.gui.server and
com.evermind.server to
>figure
>out exactly what's going on. So far, I believe DataSource
access goes
>through
>another JNDI bound object the ApplicationAdministrator. I
>still have to
>test that avenue fully.
>
>>We now have four different theories about how
application-client JDBC
>>works in app servers:
>
>>1) Database-specific JDBC driver gets packaged with the
application
>>client and loaded into the client VM.
>>2) Database-specific JDBC driver gets http-classloaded into
>the client
>>VM.
>>
>>3) Serialized classes come from JNDI. Actually, I think this
is just
>>another way of saying #2, because java RMI uses http
classloading to
>get
>>the class definitions to a new client.
>
>>4) App server provides a JDBC proxy which implements a
proprietary
>wire
>>protocol (or at least RMI "object protocol") to communicate
with the
>>server. Note that this is not just simply a matter of
remoting the
>>implementation of the Connection interface; you would have to
remote
>the
>>implementations of ResultSet, Statement, and any other
interfaces
>>associated with JDBC. And you have to be pretty smart about
>how you do
>>it, otherwise it's going to perform a lot worse than EJB
methods.
>
>I tend so far to go for 4, just because it is impossible that
my client
>running
>from home had access to the server. No direct TCP/IP route from
my
>subnet to the company's 192.168.1.111/24 No way around that
limitation
>:)
>
>My understanding... please all feel free to add to this,
especially
>Orion's
>developpers !!!
>
>A DataSource is a mechanism used encapsulate access to JDBC
>connections.
>Orion
>manages Connections with the ConnectionDataSource objects. In
"theory",
>a client
>uses JNDI to lookup the DataSource object, gets an RMI proxy,
and
>retrieves a
>Connection object. the way I see it, the DataSource
implementation on
>the server
>side HAS to return a proxy to the Connection, which only
resides on the
>server.
>
>I don't see any other way around that explains why I could use
the
>console from
>home and still get to the data.
>
>Now, I think that the current DataSource lookup does not work
as I
>understand it
>should. Maybe I'm not proceeding properly. But now that I have
seen it
>work in the
>console, I will not stop until it works in my client
application! :)
>
>>Does anyone out there *know* what Orion does?
>Anyone? :)
>
>Daniel
>
>>-----Original Message-----
>>From: Daniel Cardin [ mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, February 06, 2001 1:17 PM
>>To: Orion-Interest
>>Subject: Orion-console in 1.4.7 supports DataSource
properly... now
>>what!!!
>>
>>
>>Hi everyone!
>>
>>I'm progressing... Orion 1.4.7 has support for DataSources in
the
>>orion-console application.
>>If you select a DataSource, you will see a new panel allowing
you to
>>enter SQL commands that will
>>be sent directly to the database through the DataSource +
connection.
>>
>>it WORKS in the console. So this implies that :
>>
>>1. the concept is valid : you don't need to use a driver
>>instance on the
>>client side, contrary to what
>> some of you stated. No JDBC download, nothing... just a
proxy
>>instance implementing the Connection interface
>>2. the client doesn't need to see the database server on the
same
>>network
>>3. my datasources are configured PROPERLY on the server
side... (I was
>>always doubting that
>> but normal DS, pooled DS, EJB DS etc. all work from my
client
>>(actually only XA won't work now))
>>
>>SO: since I get perfect access through the console, either
>>
>>a) I can't do a JNDI lookup! (I doubt that)
>>b) the DataSource lookup is not working (yet) in 1.4.7
>>c) OrionConsole uses another method than a simple lookup to
get the
>>DataSource object.
>>
>>Please everyone, realize this is important for performance
issues and
>>let's try to make it work!
>>
>>Thanks for your help
>>
>>Daniel
>>
>>
>>
>>
>
>
>
winmail.dat
