Re: Java and NC

"John H. Frantz" <frantz@centrum.is> wrote: :I had the impression that the NC-java solution had the possibility of :saving bandwidth in comparison to the fat client solutions today. :Consider the following three scenarios: : :1. PC fat client. All the code stored on a file server and loaded to the :PC over the net. The PC runs a bunch of SQL commands over ODBC. If a :report is run then possibly huge amounts of data are sent to the PC from :the database server where it is formatted and sent over the net to a :laser printer. : :2. Java machine with fat client. This is similar to 1 except that the :not-so-small java applets are sent over the net requiring even more :bandwidth. JDBC is used instead of ODBC and the administration :advantages of the NC apply. The Java applets can be cashed on the client or on very simple proxy servers so the bandwith requirements from loading them may be reduced to next to nothing. :3. Java very thin client. The grunt of the application runs on a server :(same or close to the database server). The applets that the NC runs are :only the user interface portions. In other words, application :partitioning (3-tier c/s) along with minimum administration and machine :independence. There may be database servers, printer servers, communication servers+++ spread all over the place. Multi tier applications possibly with CORBA for administration. :Now, scenario 2 with JDBC is the easy way to go and I'm sure it has it's :place, but isn't scenario 3 the *real* thing for database applications, :in terms of bandwidth, cost and security? : :Do I see this the wrong way? I'd love to hear comments about these :issues, like what tools do this kind of thing. The issues are more or less true with the exception that you shouldn't expect the "very thin client" of scenario 3 to be all that thin. As we probably all know software have a tendency to grow in size. Still this is the way to go and the way that can support large number of users, large databases and reduces hardware cost the most. All this can of course be done without Java as well. Ref. the SAP/Informix/Windows NT test of 1000 users running off a database on a single machine with the database server on it. (Yes it was *one single 4 processor PC* for the database running OLTP services for the 1000 users.) They use several other machines for application servers and have "thin" clients. All implemented in their own language ABAP/4. The big advantage with Java is it's a standard language, the tools are cheap and multi tier application programming is planned from the start. As to tools Java has RMI built in. That's Remote Method Invocation so you can invoke methods of objects that run on a server. This can be used with nothing but the Java language and TCP/IP protocol available. Of course you can use socket connections and other direct communication as well. The basic Java language compiler is available for free from Javasoft (www.javasoft.com) for a range of OSs. An IDE type tool can be bought from many companies at very reasonable prices. For larger systems you might want to use CORBA. The problem to date have been exorbitant prices so only a few large coorporations could afford it. That has change with several developments lately. Netscape is including CORBA with their products now. Full developer funtionality and all runtime included. No hidden costs I know of. If you don't need a web server IONA (http://www.iona.com) is selling their Java ORB (the OrbixWeb product) at very attractive prices. I haven't studied CORBA enough yet, but it seems you want an ORB (Object Request Broker - the name sais much about what it is) more or less as soon as you start creating your third tier - the bussiness logic server in most database applications. At least when it's reasonably priced. There is more CORBA info at http://www.omg.org (or www.corba.org). To create your bussiness logic you can write your objects yourself on top of JDBC access to the database. Thought Inc. claims their technology save you a lot of work. I have had some discussions with them but don't know the answers yet. They will also announce major developments in about two weeks at some conference then. Check their web page at http://www.thougthinc.com. You still need JDBC on the server though for database access. All this becomes a long list of suppliers where examples may be: DB - Informix JDBC - OpenLink Middle tier - Self made or Thought Inc. CORBA - IONA Application - Dev.tool - Symantec Visual Cafe IFC class library from Netscape Possibly other class libs./JavaBeans At least 6 suppliers. It becomes quite clear that someone like Informix could do something intelligent to alleviate this situation. That's however also hard due to the extremely rapid develpments. JDBC, CORBA and some class libraries (server and GUI) would of course be natural candidates. A dev.tool might also be ok. They would have to buy them though. It's too late for Informix to develop all this for themselves. This is particularly true at the JDBC/CORBA level. The IFC or better alternatives, will be included with the dev.tool so the list may hopefully be reduced to 2 or 3 suppliers if Informix is doing their homework. I have not actually used any of these products, just studied the issues involved. I would appreciate to here from anyone who have actually used any of them or other products for Java development of multi tier applications. Please post your experiences. Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org