Hello, my name is Eric Grancher, I am working with Sergio, Genny, Catherine, George and Nilo in the ASD-DB section of IT division. The purpose of my very short talk is to present the tools given by Oracle to give the opportunity of accessing you data stored in an Oracle database via the web.Here is the agenda of my presentation.The web server called (in the Oracle terminology) as the Oracle Web Application Server is the center of the architecture of the web products of Oracle, I will very briefly describe the architecture and the proprietary terminology.Then, I will present you the main available cartridges : - the PL/SQL cartridge which can be used using PL/SQL code typed by hand (cf. Josis application) or generated by the Designer/2000 web generator (or by Stephans WAW) - the perl and Java cartridges which are very similar in the way they work fill the need of using legacy code (perl from CGI-bin programs) or fashion code (Java) - the new cartridge (since the 3 others are available since many months) is the Web forms cartridge, it will permit to use Forms modules (version 4.5) on the web with MINIMAL changes (not NO changes as written in the advertising of Oracle). This is a very new product, it is not available for production at present time, but we will see that thinking about it NOW may help in the future.At the end of the presentation, I will present some advantages and drawbacks of all these solutions.There is nothing new in this area, just some points of terminology : - The architecture chosen by Oracle is called NCA (Network Computing Architecture), it is mainly a 3 tier architecture where cartridges can be used on each tier of the architecture. It is very expandable. - The client is composed of browser which has to be Java compatible for the use of web forms. The client can be of any type : workstation, PC, Macintosh, Network Computer (just a Java compatible machine) - The middle tier is called the application server, it will be responsible for running the application and maintaining the transaction pertinence. - The database tier is the place where data are stored, in the NCA it is naturally an Oracle database.Each of these tiers has basic functionality and can be extended by cartridges, lets have an example for each of these parts of the NCA : - for the client side, the cartridge can give possibility to the browser to produce live audio from the network (was called a plug-in) - for the middle tier, the cartridge can give possibility to run the forms module - for the database tier, the cartridge can give possibility to retrieve images which look like one other imageThe PL/SQL cartridge is the oldest cartridge available for the web application server (with version 1, it wasnt called a cartridge but functionality has not really changed).The main idea is that PL/SQL code is stored in the database, execution of this code produces dynamic HTML, it is clearly well integrated with the data handling and retrieving since you can use the OWA packages to produce the HTML tags and the PL/SQL functionality to retrieve the data :CREATE OR REPLACE PROCEDURE test1 IS DECLARE CURSOR cur1 IS SELECT ename FROM emp; v VARCHAR2(30); BEGIN htp.HtmlOpen; htp.BodyOpen; FOR v IN cur1 LOOP htp.p(v); htp.line; htp.BodyClose; htp.HtmlClose; END; /The big issue with this kind of code is that you have to manually handle the transactions which relatively hard to do (with OWAS 3.0 some help has been added).The other way is to generate the PL/SQL code using the Designer/2000 web generator, since 1.3.2 DML are possible (before only queries can be made) or the WAW.The idea of the perl and Java cartridge is mainly the same as the one from the PL/SQL cartridge except that the HTML is produced on the application server side. The HTML which will be displayed is just the standard output of the perl program or of the Java class.The Java virtual machine is running on the application server, currently, only version 1.0.2 is supported, the connection to the database can be made using JDBC or a set of classes provided by Oracle.Perl cartridge can use JDBC to access the database or a set of tool provided by Oracle to generate Java wrapper classes around PL/SQL packages.The Forms cartridge (which leads to the denomination of Web Forms) is a way to put forms on the web.The first thing that I have to say is that it is very new and not in production at present time, but it can have incidence on your work of today, so it may be interesting to understand and plan around it.The way that forms is working - NOW is : on client side is running the User Interface Layer + the Application Logic + the Data Manager & PL/SQL (v1) Engine, when it is needed a SQL*Net connection to the database is made to retrieve data. All the user interface (including triggers) run on the client - will be : the User Interface Layer runs on the client (it is a forms applet and can run on any browser capable of Java 1.1.2), it is responsible for drawing the items BUT every time validation, triggers, data handling has to be done, it will be done on the Application Server (the Forms cartridge) and (as in the client/server version) if needed a SQL*Net connection will be made to retrieve data.Of course this new way of deploying forms brings restrictions (it would too nice, wouldnt it ?), most of them can be understood since - the forms is running on a different machine than the client -> no client side feature - the platform of the application server is unknown -> no platform specific feature Some features are : - unsupported : platform specific (ActiveX, MDI window) or network intensive (When_Mouse_% trigger) - restricted : client side feature (Display in console, User_exit) will in fact run on the application server. GIF is the onlu supported format for icons - new critical areas appears : fonts (new platform to look at, conversion table is available on our web, see below), timers are allowed but they produce a network round-trip every time, the level of validation may be moved from item level to block level to avoid network load. - some features are not available in the current version : due to limits of Java (sic Oracle) bubble help, combo boxes and menu accelerators will be available in the next major release : Developer/2000 v2.0All this makes important to look at the future : it may be not a good idea to design today (or transform a Forms 3.0) forms with ActiveX, Mouse triggers,...Here I will try to present very shortly the status of web forms : the main idea is that even if it is nearly possible to have it now, lot of problems are given by this new architecture : - the browser should be Java 1.1.2 capable and actually no commercial browser are capable of it (at least on Nice & asis), so the use of the appletviewer or of patched version of Netscape Communicator is necessary - the Web Forms cartridge gives lots of problems : we dont have the production version for Solaris and the integration of the NT version is not suitable for production. Moreover a new architecture has to be thought : people have to generate their forms for the application server, CPU is needed to run the forms for the client We are thinking about it. Security issues (for example hiding the password) are also relevant and no correct solution is given by Oracle at present time.Our plan is to built a new architecture to permit CERN forms users to develop and to deploy their application on the web, but we have to admit that it is not possible at present time, a good estimation is production during Q1 1998.From your side, I think that it may be a good idea to look as soon as NOW on the restrictions and to understand what modifications you should do so that your forms can be deployed on the web.MINIMAL conversion.Here is (nearly) the end of my talk, the last thing that I had prepared is a comparison of the solutions that I have presented to you today : - first of all : Web Forms are FORMS so there is a big inheritance of already developed applications that it will possible to deploy on the web using this new possibility - on the interaction level, with the HTML solutions (PL/SQL, perl, Java), the interaction is on the character level whereas with web forms the interaction is at pixel level. - on the bandwidth side, the HTML solutions just make URL and HTML travel on the network, it is very low bandwidth whereas the web forms user interface has to communicate all the time with the forms cartridge on the application server. Moreover, a Java applet and several classes have to be transferred to the client (~600 kb). All of this makes the Web Forms solution working with intranet, but for inter-(extra-)net (including the whole HEP community) HTML solutions may be more adequate. - the transaction management has to be manually done with the HTML solutions (except Designer/2000) whereas all is done for you using Forms. - and the availability is OK for HTML solutions and we have to wait for the promising solution of Web FormsHere are some URLs that can be useful : - http://wwwinfo/~grancher/odf/ : this presentation, that will be I think also available on the ODF site (http://wwwlhc01/odf/) - the list of the restrictions of Developer/2000 v1.5 (first version of Web Forms) is available from our web site : http://oraweb01:9000/database/If you have some questions, Ill be glad to try to answer them now or by e-mail later (Eric.Grancher@cern.ch)I thank you a lot for your attention.