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 >> >> >> >> > > >
Jeff, The whole idea about this architecture, commonly call multi-tier or n-tier, this that there is a separation between client presentation logic, business logic and state persistence, in that order. So clients should deal only in presentation issues, and request business process execution of the server. It, in turn, validates and manipulates various objects and they persist their state to a store (typically an RDBMS). So, the answer is, clients should not access JDBC at all, never! If you really want to do that, its OK, its just you would be building a client-server ("2-tier") app, and that's not EJB territory. Regards, Peter Miller. I'm trying to figure out how application servers provide JDBC data sources to application clients. I'm hoping someone here can provide some insight. >From a client, I can use JNDI to get a reference to a data source and use it to make JDBC calls. How do these calls actually find their way to the database? Do the database-specific JDBC drivers get loaded into the client JVM (through packaging or http) so that the client can make "native" database calls into the database? This would require making the database publicly accessable and potentially adds complexity to the client packaging, but it would be the best-performing solution. Does the application server implement a proxy layer, so all calls to JDBC interfaces get translated into some sort of proprietary protocol which at the server gets translated back to JDBC calls on the real driver? This allows the database to remain hidden, and eliminates the need for drivers to be loaded into the client, but adds a level of complexity and a performance hit. Or is there some other approach? I imagine that different app servers take different approaches, so I fully expect the answer to be "it depends" :-) What do various app servers do? The j2ee spec doesn't seem to prescribe an answer to this. Thanks, Jeff Schnitzer [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ======================================================================== === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". ________________________________________________________________________ _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ======================================================================== === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Peter Miller wrote: > Jeff, > > The whole idea about this architecture, commonly call multi-tier or n-tier, > this that there is a separation between client presentation logic, business > logic and state persistence, in that order. So clients should deal only in > presentation issues, and request business process execution of the server. > It, in turn, validates and manipulates various objects and they persist > their state to a store (typically an RDBMS). > > So, the answer is, clients should not access JDBC at all, never! I'm not sure I agree with this statement. Before EJB a lot of people, including myself, were busy writing database gateways or brokers that allowed clients to obtain thin JDBC driver connections that were multiplexed by a central server.( 2-Tier was still king at that time and even Java-CORBA as in its infancy.) In other words the JDBC-broker ensured that JDBC connections were pooled and shared across clients, which make 2-tier systems more scalable. As a matter of fact, the Weblogic was originally an independent company that got its start (I believe) as a JDBC driver and JDBC-broker vendor. They provided a lightweight specialized JDBC driver that communicated client request over the network to a broker, which then redirected the requests native JDBC drivers. Anyway, using JDBC directly from clients in a 2-tier system is still a viable solution if you use the right technologies. 3-tier is great, but its not for everyone. Richard -- Richard Monson-Haefel Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000) Co-Author of Java Message Service (O'Reilly 2000) http://www.EjbNow.com ======================================================================== === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
