The Service Project now contains the WSDL files, the generated Service proxy, and the command bean:

Unit-test service proxy

The generated proxy uses the Java API of the Web Services Invocation Framework (WSIF) to communicate with the CICS program. For the Web application, the proxy is seen as an enterprise service that it can execute. Before building the Web application that executes this service proxy, unit-test the enterprise service to make sure that the CICS program is correctly invoked and can send data back to the proxy.

Switch to the Java Perspective and open the class MyTradeProxy.java.

Go to the main() method and add code before and after the call to execute as shown below. I provide the user ID and the input parameters that the COBOL program expects: a request type = "Share_value" and a company name = "IBM". After the execute, we print out to the console some of the data returned by the COBOL program.

/** 
 * main method (for proxy unit testing) 
 * @generated 
 */ 
public static void main(String[] args) { 
	try { 
	    MyTradeProxy aProxy = new MyTradeProxy(); 
 
		// user code begin {set_inputs} 
		COMMAREABUFFER comm = new COMMAREABUFFER(); 
		comm.setUserid("F058971"); 
		comm.setRequest__type("Share_Value"); 
		comm.setCompany__name("IBM"); 
		aProxy.setCOMMAREABUFFER(comm); 
		// user code end 
 
		aProxy.execute(); 
 
		// user code begin {get_outputs} 
		COMMAREABUFFER result = aProxy.getCOMMAREABUFFER(); 
		System.out.println("1=" + result.getUnit__value__1__days()); 
		System.out.println("costbuy=" + result.getCommission__cost__buy()); 
		System.out.println("costsell=" + result.getCommission__cost__sell()); 
		// user code end 

Save the class, then from the menu select Run, Run as, Java Application. The output in the Console looks like this:

1=00163.00 
costbuy=010 
costsell=015 

Export service proxy as a JAR file

Select the project MyServiceProj, right click and then Export. Export as a JAR File and choose a destination directory on the file system.

Back to top

Generate the Struts-based middle tier

To generate the JSPs, Java classes, and configuration files that make up the middle tier we use Web Application Models. The procedure consists of:

1. launching the wizard and selecting a pattern
2. selecting the data from the Service proxy that we want to use
3. selecting some basic display properties
4. selecting generation parameters and generation
5. configure WebSphere Test Environment (WTE) and test

Launch and select pattern

To launch the wizard, go to File, New, Other, Web, Model-based Web Application. As in the image below you have to choose an application name. The application name is used to identify resources that will be generated from this model.

Select the technology identified as WSIF proxy. If you choose Relational Database technology, the wizard will ask you to connect to a relational database where you can select tables that will be used to create the Web pages. The VisualAge Pacbase technology consumes VisualAge Pacbase proxies that can access numerous back-end systems.

After clicking Next, the Select Patterns panel in Figure 8 is displayed. Browse the available patterns to get an idea of the different configurations. In this example, the COBOL program which we want to call displays a detail view of stock shares for a company.

Select service proxy

The second step in the wizard is to configure the data from the Service proxy that will be used with the pattern.

1. As shown in Figure 9, browse for and select the proxy JAR that was exported.
2. Then under Input parameters, select the proxy and the COMMAREABUFFER class.
3. Move the two input parameters that the COBOL program requires to do a read action, Request_type and Company_name from the left list to the right.
4. For this program the input and the output parameters are in the same class. Select output parameter fields and move them to the right list also. The fields you select here can be displayed to the end user.
5. You also have to configure the Update and Delete panels, even though in this case the read-only COBOL program can not do anything with the input.
6. Click Next to go to the Define Layouts panel of the wizard.

Configure display

In the Define Layouts panel shown below you can select a cascading stylesheet, select/de-select fields and actions, and modify field and action properties. You can also get a preview of the Web page by clicking on the button with the eye image. Static HTML is generated on the fly to give you an idea of how the Web page will look. Click Next to go to the last page of the wizard.

Generate the application

The image below shows the generation page where you configure generation parameters:

1. Change the name of the destination project to Company.
2. You can also change the name of the Java packages into which you will generate.
3. In the tree view you can change the names of the pages, views, and the data set. You can directly edit the default names by clicking on the name. As you change the names of these components, the file names in the list are also changed.
4. When you are ready to generate, click on the Finish button.

Back to top

Browse generated components

Generated Java classes

In this section we will give you a brief description of the generated components, starting with the common Java classes.

Figure 12. Generated Java classes

common.dab CommonLog defines Logging functions. It uses Jakarta LoggingFactory. The DataException class is used to handle errors. common.list MultipleSelectionListForm - this class manages the delete checkbox on each line of a list. SelectionListForm - this class manages the link on each line of a list to initiate navigation to a detail view. SelectionList - stores information in HTTP session: list paging information and keys for each row to allow navigation (zoom) to a detail page. SessionObject - used to store information about the detail page in the HTTP session common.logic AdditionalFieldChecks - this class performs some common field checks. CloseSession - closes the session and forwards to the SessionExpired page. CommonAction - a class where you can put logic to be executed on each call to an action; checks for a valid session. CommonFormatter - lets you set date and time formats. OpenSession - used to establish an HTTP session. wam.data DataSetDataAccessBean - this class calls the operations available for the data set and catches data exceptions. DataSetExtractObject - getters and setters for the extract criteria. DataSetSessionObject - contains key fields to be stored in HTTP session. DataSetValueObject - stores fields in the data set with their appropriate type wam.logic.sample CompanyDetail*Action - the Delete, Read, and Update classes invoke the action in CICS program. CompanyDetailForm - this class has attributes of the form plus a validate method. CompanyRefreshAction - this class refreshes the JSPs with data. Application resources ApplicationResources.properties - contains common labels and messages; ApplicationResources-sample.properties - contains model specific labels and messages.

Figure 13. Web content

common - Here you find a JSP that handles paging buttons and a SessionExpired HTML page. doc - Technical documentation in HTML form along with Web, sequence and class diagrams which are generated for each model. models - Models are generated and stored in XMI files. jca_sample - the result of the imported description of the proxy in the form of XMI files. DataSet.dsxmi - This XMI file contains the data set information that was configured in the wizard. The data set can be re-used with another pattern. sample.icxmi - This XMI file stores the model information - the pages, the content of the page views, their actions, the navigation links, and the data set that is presented. This file allows you to replay the wizard scenario. sample - JSP resources specific to the sample model. theme - cascading style sheets. WEB-INF - deployment descriptor, configuration files and binaries. Explained in more detail below. XML - files and stylesheets used in Extensible Stylesheet Language Transformations which will be discussed in Part 2 of this article. index.html - The test page and technical documentation entry point.

Figure 14. WEB-INF

classes sub-directory - the compiled Java binaries. lib sub-directory - jars for Struts 1.1, Web Services Invocation Framework, and the proxy jar. tag libraries have the .tld extension. document type descriptions have the .dtd extension. There are two Struts configuration files - struts-config.xml and struts-sample-config.xml where the following are declared. actions and their forward paths form beans a global forward to the sessionExpired.html file. this model's message resource file named ApplicationResources-sample.properties. the struts validator plug-in along with the files that contain the validation rules. The struts validator framework where common validation rules and validation specific to the sample model are found. You can add new rules to these files. validator-rules-wam.xml - This file has common validation rules like decimal and timestamp checks. If you have other common checks that are shared across models this is a good place to put them. validation-sample.xml - This is where the checks specific to the sample model are found. Included are max field length and format checks. If your rules are too complex to program in XML you can implement them with Java code in generated Form classes in the validate() method. web.xml - the Web deployment descriptor.

Back to top

Test the Web application

Configure server

1. Open a Server perspective,
2. create a new server project,
3. create a new server and WebSphere version 5.0 server configuration. If you have an existing server project go ahead and put the new server and server configuration in the existing project.
4. Ensure the resource adapter is declared in the server configuration by opening the server configuration file and going to the J2C tab of the default editor as is shown in the figure below.
5. Click on the Add button and select the CICS ECI resource adapter that was imported into the workspace earlier.
6. Close and save the server configuration file.

Run on server

1. Select the Company Web Project, bring up the contextual menu and click on Run on Server.
2. In the dialog box that displays, click on the Advanced button to select the new server that is now properly configured with the CICS ECI resource adapter.
3. Clicking Finish will Publish the Web application to the application server, then start the application server and the application. The Web browser will be launched and the test page displayed as shown in the figure below.

Browse documentation

Execute the application

From the test page click on the link that launches the application and the detail page as shown below.

1. Enter the input parameters Share_Value and IBM.
2. Click the Read button to call the servlet and the CICS program.
3. The CICS program sends back the information in the figure below.

Back to top

Conclusion

Part 1 of this article took you through the steps to create a Struts-based Web application that connects to an existing CICS program using a Java Connection Architecture resource adapter. First we used wizards in Application Developer to create an enterprise service. We imported the data description from a COBOL program to create the Web Services Description Language (WSDL). After configuring the connection parameters, we used the WSDL to generate a Java proxy and tested it to ensure we can send and receive data from the CICS program.

We packaged the proxy in a jar and used the jar as an input to the Web Application Models wizard. In the wizard we selected the fields to display and configured some basic presentation properties before generating the Struts Java classes and JSPs that communicate with the CICS proxy. We then configured the server and deployed, launched and tested the application.

The generated application conforms to the J2EE standard and can be deployed to an application server which can provide the reliability, scalability, and required performance. And although it has basic validation, error handling, accesses and displays data and takes care of other such mundane but necessary functions, it doesn't do a whole lot. What about more complex validation? What about business rules? What about integration with other Web pages? Security considerations? Where in the generated code do all of these specifics get implemented? The application doesn't look particularly attractive either.

Part of the answer to these questions is provided by generated code that is clear, well-documented, easily understandable and meant to be modified to handle the above functions. Web Application Models is not meant to produce out-of-the- box, ready-to-run applications, but rather, produce the basic building blocks which you can rearrange and use to construct real- world deployable applications.

Part 2 of this article addresses the task of providing a user interface that is ready for deployment. I will show you how Web Application Models uses Extensible Stylesheet Language Transformations (XSLT) at development time to incorporate common look and feel into the application.

Resources

• VisualAge Pacbase Product Overview
  
  

About the author

Kevin Griffith is an IBM Certified IT Specialist at the IBM Paris Software Lab. He specializes in IBM rapid application development tools such as VisualAge Generator Templates and Web Application Models, and helps customers worldwide improve their application development productivity. He is a graduate of the U.S. Military Academy at West Point, has a masters degree in civil engineering from Massachusetts Institute of Technology, and is a registered, but non-practicing Professional Engineer just for fun. You can reach Kevin at griffith.k@fr.ibm.com .

Rate this article

Comments

Back to top