Today, equipping your AS/400 system with the latest Java technology is easier than ever because IBM WebSphere Application Server for AS/400 (5769-AS1 on V4R4) is shipped free and installed optionally on your AS/400. WebSphere Application Server helps transform your simple Web site into a powerful e-business destination with platform- independent e-business applications built upon technologies such as Java servlets and JavaServer Pages (JSP).
Getting WebSphere Application Server on the AS/400
WebSphere Application Server 1.1 comes preloaded on your V4R4 system, but you really should upgrade to Version 2.0 (Standard Edition) via WebSphere Application Server Group PTF SF99027. The latest version available today is Version 2.031, and you can find the latest WebSphere Application Server Group PTF information by visiting www.as400.ibm.com/websphere and clicking PTFs from the navigation menu.
To take advantage of WebSphere Application Server, you need the AS/400 Developer Kit for Java (5769-JV1) and IBM HTTP Server for AS/400 (5769-DG1). Like WebSphere Application Server, these products are shipped free and installed optionally on your AS/400 as well. You should also install Qshell Interpreter (5769-SS1, option 30), which provides a UNIX-like command environment that allows you to use standard Java commands, such as java and javac.
Configuring and Administering WebSphere
AS/400 WebSphere Application Server 2.0 has the same install structure as other platforms. The only difference is the install root directory; in the case of the AS/400, the install root directory for WebSphere Application Server is /QIBM/ProdData/IBMWebAS/ under the AS/400 Integrated File System (AS/400 IFS).
You can easily enable your current HTTP configuration with WebSphere Application Server 2.0 on your AS/400. The easiest way to configure it is to go to the HTTP Administration GUI at port 2001. (Even if you have Version 1.1 configured already, it is still necessary for you to go through the same format to upgrade to the Version
2.0 directives.) The first panel at http://hostname:2001 is the AS/400 Tasks page. From
there, click IBM HTTP Server for AS/400 and then click Configuration and Administration. Now you can select your desired configuration from the Configurations drop-down list, where you will see a bullet for Java servlets. Click this bullet, and, as shown in Figure 1, the Java servlets Configuration and Administration screen will appear. Check both check boxes to enable Java servlets and JSP. Finally, click Apply. Now all you need to do to start taking advantage of WebSphere Application Server 2.0 is restart your HTTP server.
In WebSphere Application Server 1.1, jvm.properties, located in /QIBM/ProdData/IBMWebAS/properties/server/servlet/servletservice/, is one of the key properties files WebSphere Application Server uses to configure some of its information, such as the class path and name of the HTTP configuration file. Now, in Version 2.0, you no longer need to update jvm.properties to point back to the HTTP configuration. In fact, the jvm.properties file is no longer used; it has been replaced by bootstrap.properties, located in/QIBM/ProdData/IBMWebAS/ properties/.
Once your WebSphere Application
Server instance is started, you can run a simple shipped servlet, such as HelloWorldServlet, by typing the following URL on your browser to verify that everything has been set up correctly:
http://hostname:port/servlet/HelloWorldServlet
In this URL, hostname is the host name of your AS/400, and port is the port number configured for this instance. If you see Hello World, you have successfully configured your server.
WebSphere Application Server also ships with its own Application Manager GUI to allow you to administer and configure your WebSphere Application Server. To get to the Application Manager on your AS/400, type in http://hostname:9090. (Other platforms use port 9527.) This will bring up a typical sign-on panel asking for your user name and password.
The Application Manager enables you to customize settings for a variety of WebSphere Application Server components, to configure servlets and set up various attributes, and to collect data and monitor the WebSphere Application Server. One of the most common things you can use the Application Manager GUI for is configuring WebSphere Application Server so it knows where to find your servlets. By default, you can always place your servlets in the/QIBM/ProdData/IBMWebAS/ servlets directory, and, without any special configurations, WebSphere Application Server knows where to find your servlets when it is invoked. This directory is also known as a reloadable directory, meaning that, if you change your servlet, the directory automatically reloads the new class file so your changes are reflected the next time it is invoked. However, you might not want to put your servlets in this product directory, since it is part of the WebSphere product tree. In that case, you can pretty much put your servlets anywhere you want in the AS/400 IFS directory structure, but, as shown in Figure 2, you have to specify that in the Reloadable Servlet Classpath field in the Application Manager GUI.
Having the dynamic reload capability is helpful, especially when you are in the development phase of your applications. However, there is a price to pay for this feature. Review the AS/400 Java Virtual Machine (JVM) for a moment; the JVM is the key component that allows the AS/400 platform to interpret byte codes generated by Java. The JVM on the AS/400 uses something called a Java Transformer to create an optimized program object known as Direct Execution (DE) whenever your class file is run the first time. This object is persistent in the file system so it results in better runtimes on subsequent runs. However, this concept has one exception: When the user class loader loads the class file, DE resides in JVM memory instead of the AS/400 IFS.
The reload feature of WebSphere Application Server is implemented with the user class loader. Therefore, the DE object created for this class file persists not in the file system but only in your JVM memory. This means that, if you recycle your HTTP server (which, in turn, recycles the JVM that WebSphere Application Server is running), you will lose the DE associated with those reloadable servlets, and your first invocation of any reloadable servlet will take a hit on performance in order to create a DE. Because of this performance implication, you might consider putting your servlets in a nonreloadable class path. Furthermore, in a production system environment, you probably do not expect your servlets to change frequently. In that case, you can specify your servlets in the Application Server Classpath field shown in Figure 2.
One thing you will notice is that, in order to update the Application Server Classpath field, you have to toggle the Use System Classpath? field to No. (Make sure you toggle it back to Yes when you are done updating the class path.) All your servlets specified in this class path are loaded by the system class loader, and their DEs persist in the file system. You can even precreate the DEs if you want to avoid performance degradation when loading servlets the first time. Servlets loaded through this class path do not have the dynamic reload capability. No matter where you choose to put your servlets, you can always invoke them with the following format:
http://hostname:port/servlet/YourServletName
JavaServer Pages
Deciding where to put your JSP files is similar to deciding where to put your HTML files. For example, if you are going to place your .jsp files in the /myApp/jsp/ directory, you need a Pass directive in your HTTP configuration file that might look like this:
Pass /catalog/* /myApp/jsp/*
To be more specific, you could use this directive:
Pass /catalog/*.jsp /myApp/jsp/*.jsp
In both cases, you can invoke your .jsp file with this URL:
http://hostname:port/catalog/myJspApp.jsp
The technique shown masks the real AS/400 IFS directory name /myApp with the logical directory name /catalog. Masking real directory names with logical ones is a technique commonly used to hide the directory structure of your system from hackers for security. If you don’t want to hide the real name, you could use the following Map directive to enable JSP:
Map /myApp/jsp/*.jsp
WebSphere Technologies
WebSphere Application Server enables your IBM HTTP Server for AS/400 to run Java Web applications such as servlets and JSP. It also offers Extensible Markup Language (XML) Document Services, which allow you to implement server-side XML document processing.
Java servlets run on your server as Java applets do on your browser. Servlets do not replace applets but offer another solution. Imagine that you can have your server process your Java application logic instead of spending time to download classes to your client browser. Servlets output HTML so the actual transfer takes a small amount of time
and eliminates dependence on the browser. This technique provides functionality similar to cgi-bin programs. However, servlets are more portable and efficient because they are written in Java and can take advantage of threads.
JSP is a server-side scripting technology similar to Microsoft’s Active Server Pages (ASP). However, JSP has the advantage of being platform- and vendor-independent because of its Java nature.
Although Enterprise JavaBeans (EJB) is not available in WebSphere Application Server 2.0 Standard Edition, WebSphere Application Server will have EJB support through Version 3 of WebSphere Application Server Advanced Edition in the first quarter of 2000.
There Is No ‘I’ in Java
You might wonder which to choose for implementing Web applications: servlets or JSP. It turns out that it is best to create a robust Web application by using both servlets and JSP. The main reason is that JSP allows you to separate output from business logic. Therefore, you can focus your business logic via servlets and reusable JavaBeans while using JSP to implement your application-specific presentation logic.
References and Related Materials
• AS/400 information for Java: publib.boulder.ibm.com/pubs/html/as400/v4r4/ic2924/info/java/index.htm
• “Face-off: JSP vs. ASP,” Don Denoncourt, MC, October 1999
• IBM WebSphere site: www.as400.ibm.com/websphere
• ”Using JavaServer Page Syntax with WebSphere,” Lisa Wellman, AS/400 NetJava Expert (Web Edition), February/March 1999, www.midrangecomputing.com/anje/99/02
Figure 1: The Java servlets panel enables WebSphere Application Server
2.0.
Figure 2: The Java Engine configuration in the Application Manager GUI allows class path configuration.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online