WebSphere Studio Site Developer


In this section, we will describe in more detail the tools and functions that are included as part of WebSphere Studio Site Developer. The purpose of Site Developer is to aid the creation of dynamic web sites, ranging from the creation of static HTML pages through to dynamic content using servlets, JSP pages, and web services. The Site Developer edition also includes the complete Unit Test Environment, and the design of the Test Environment is discussed below.

To highlight the critical pieces of the tool, we will develop a very simple application, which will be used throughout this chapter. The application itself is little more than a J2EE-based "Hello World" sample, but it will provide a consistent base to refer to as we explore Studio. The application is a simple phonebook application, consisting of a web page to input data, a CMP EJB to persist the data, and a JSP page to display the results. The basic flow of this application is a very common J2EE design, and it can be summarised as this:

click to expand

The nodes in the diagram represent the important objects in the flow of the application:

  • PhoneBook.html is a file used to prompt for data input. The file contains a form, which invokes a servlet when the data is submitted

  • NewEntryServlet is a servlet that is invoked when a new phone number is created

  • SearchServlet is a servlet that is invoked when the user wishes to search the phone book

  • PhoneBookEJBLocalHome, PhoneBookEJBLocal, and PhoneBookEJBLocalBean are the local home, local interface, and the enterprise bean itself, used to persist the data

  • Output.jsp is a JSP page used to dynamically construct the output of searches

We will now continue with our look at WebSphere Studio, but we will refer to this basic application as we do so.

Web Application Perspective

The primary view for a web application developer is the Web perspective, shown below. In this perspective, the Navigator view is replaced with a Web view, which combines parts of the Java Packages view with the base resources navigator. The Outline view is supplemented with a gallery, allowing the developer to select from many included pieces of clipart, scripts, and icons. There are also several new views added to the tasks area, including a summary of the contained properties and links, and a thumbnail view of the gallery contents:

click to expand

The centerpiece of the web perspective, however, is the HTML/JSP page editor. This editor offers three integrated views of the file being edited, shown as tabs at the bottom of the pane. They are:

  • Design
    This allows for the simple creation of even advanced pages. This is not browser specific, but a pseudo WYSIWYG view – it shows the basic structure of the page, but it also includes a visual representation of some data controls (such as JSP pages). The purpose of this view is to allow the rapid creation of web pages, leaving the fine-tuning to the Source view.

  • Source
    This can be used for verification of the content created in the Design view, and also to easily change any specific part of the file. The Source view can also be important when integrating business logic (such as JSP pages) into the page.

  • Preview
    This is generated by an embedded browser control giving the most accurate representation possible of what the static portions of the page will look like.

In these screenshots, the same page is displayed in both the Design and Source views; notice the tabs at the bottom of the pane:

click to expand

The editor contains a single edit model, meaning that any changes made in any view will immediately be reflected in all other views. There is full content assistance available in the Source view, offering all valid HTML tags based on the current position and context.

In the phonebook application we are developing, we need to gather input from the user. We do that via a form, defined in the PhoneBook.html page, as shown below. The form action posts the data to a servlet. Depending on the selected form this will be either the SearchServlet or (as below) the newEntryServlet. This logic is created in the Studio HTML editor, in the Source view as shown:

click to expand

JSP pages are used to display dynamic output, which is what we display after searching our phonebook application. A JSP page is a mix of HTML and Java that can dynamically generate HTML. As shown below, we define a table to represent the output and then use Java code to iterate through the results and populate the table.

The editor really shines when it is used to edit or create JSP pages. The same three views (as described earlier) are available, but the Source view now combines the function of the Java editor. The following screenshot shows two things: the x in the margin indicates the location of a Java syntax error, and the content assist window is showing the list of valid methods to invoke on the highlighted Java variable, and the javadoc for those methods. You would expect both these functions in a pure Java editor, but it is an extremely useful to find them in the HTML editor:

click to expand

Creating a New Web Project

There are wizards available to create new resources of almost every type in WebSphere Studio. The wizards range from creation of a single HTML file all the way up to a complete J2EE application consisting of multiple projects. Some creation wizards are available on the pop-up menu based on your current context, but you can always select Other from that list as well. This is the same as selecting the File | New menu item, and will result in a dialog allowing you to select from any of the creation wizards:

click to expand

To create a web application, the first action required is to create a new web project. There are a number of creation wizards available, as shown above. One extremely useful option is the Java Bean Web Pages wizard, which will create a web project and populate it with a template web application. Forms are defined to input data, a servlet to gather the data, and a JSP page to display the results. If you are starting such a project from scratch, this application template can save you a lot of time.

Another option is to create just a web project, and provide the content yourself. As shown later, the wizard will prompt to allow creation of either a J2EE web project, or a static web project. The static web project does not add the web project to an enterprise application (and EAR project), and so is simpler, but more limiting. A better alternative is to select J2EE web project. There is limited increase in the complexity exposed to you, but significantly more flexibility in both the short and long term.

As a J2EE application server, all projects in WebSphere run in the context of an enterprise application. If one is not specified, a default enterprise application will be created for you at the application's install time. However, this deprives you of the option of modifying any of the configuration settings in the enterprise application project:

click to expand

You can also select a number of web project features from this wizard. None of the decisions you make here are irrevocable, but they provide an easy way to configure and populate your project with some common settings. Some options are trivial, such as the automatic creation of a Cascading Style Sheet (CSS) file in your project. Other options will result in additional pages appearing at the end of the wizard to allow you to configure them.

If the J2EE Web Project option is selected, the next page of the project creation wizard will ask you to select the enterprise project to be used. You have the option of creating a new such project, or of selecting an existing one. In either case, the newly created web project will be added to the application.xml file that is contained in the /META-INF directory of the application project, the same action that occurs when you run a normal application assembly tool. In other words, almost behind the scenes, you have already started assembling your resultant project, and are preparing it for execution:

click to expand

The next pages of the wizard are included based on the options you selected on the first page. All are optional, and in this example we did not select any options that require additional pages. After completing the wizard, the project will be created for you containing two folders, named Java Source and Web Content. The first is pre-configured to be included on the Java builder's classpath; any Java files you create in this directory will be compiled automatically. The Web Content folder represents the contents of the module that will be deployed on the server. It contains a WEB-INF directory, which in turn contains a classes directory where the results of the Java compilation will be placed, as required by the J2EE specification. This directory structure is shown below:

click to expand

You can store any file you wish in the web project, including requirements and design documents, test cases, and other development-related artifacts. The only files that will be exported into the WAR file, and therefore will be available on the server, are the files that are contained in the Web Content folder. Typically, this means that any development-time files (such as design documentation, and so on) would be located in a different folder. It also means that all content for your web site needs to be located in a directory that is contained in the Web Content folder. This is also true for Java code; you do not usually want to ship your source code, and so the Java Source folder is not contained in Web Content. However the results of the compilation do need to be shipped, and this is accomplished by the class files being placed in the /Web Content/WEB-INF/classes directory by default.

Validation

WebSphere Studio includes a number of validators to ensure the correctness of files against their respective specification (EJBs, EARs, DTDs, and so on). Each validator included in WebSphere Studio runs against different file types; in general the validators do not need to be manually configured or activated, as they are associated with the different project types. The two most common validators used in web projects are the HTML syntax validators and the JSP compilation validator. Both these validators are configured by default to verify the content of an HTML (or JSP) page is correct when the file is saved; any problems that are detected will be displayed both in the tasks list, and also with an x in the editor column when the file is opened.

The validation actions are optimized to only re-validate a file when it has been changed, but even that action can take a few seconds for large files, and so you may not wish to have the validation run on every save action. In this case, you can disable some aspects of the validation from the Preferences menu:

click to expand

The options include turning off one specific validator entirely, or just disabling the "validate on save" behavior. In the latter case, it is possible to validate a project from the context menu at any time.

WebSphere Studio Server Tools

The primary purpose of WebSphere Studio is to create server-side applications, while providing an easy way to test and debug your applications. VisualAge for Java included a "WebSphere Test Environment", but due to restrictions in the VisualAge infrastructure there were a number of limitations in that test environment, and subtle differences in behavior between the test environment and a production server. The WebSphere Studio test environment is entirely identical in function to a production server. This means that you can be confident about the results of your testing inside Studio; if it works there, it will work on a real server.

One of the most significant features of the new test environment is that multiple server configurations can be defined and stored in the workbench and the underlying configuration system. This provides for a robust test experience. It is possible to ensure that the server configuration used on a tester's machine is exactly the same as that on a developer's machine. Another usage pattern for this support is for testing multiple server configurations. Since the files that form the configuration are saved, and even available via the configuration system to the entire team, even complex differences in configurations can be repeatedly selected.

In addition to supporting multiple configurations of a single server, it is often useful to represent multiple servers, each with a unique configuration. This capability is provided in Studio with the introduction of a server instance object. A server instance represents a specific server with the following information:

  • The identification of the server type

  • The location of the server on the network

  • Information about how to publish files to that server

    click to expand

The Studio "server instance" concept should not be confused with the clustering and multiple server support that is available with advanced WebSphere application server editions. The WebSphere run-time clustering support is designed to ensure a scalable, robust, well performing environment. The WebSphere Studio server instance support is designed to provide an easy mechanism to test an application on different servers, ensuring repeatable testing across a variety of server types and scenarios. Server instances are also saved as files in the workbench, and available to multiple users via the configuration system.

Different server instances can represent more than just different physical machines. One of the critical attributes of a server instance is the identification of the server itself. This support is exploited in WebSphere Studio version 5.0, as both WebSphere version 4.0 and version 5.0 servers can be represented in the workbench, configured, started, and used to test code.

The identification of a unit test server, run locally in WebSphere Studio using the embedded server (or a remote server, run remotely on any existing WebSphere installation), is also made via the server instance. Tomcat servers can also be represented as server instances, although Tomcat itself is not included with WebSphere Studio. A project can be associated with one or more server configurations, and a configuration is associated with one or more server instances. The server instances and configurations are stored in a server project.

The usage of server configurations and server instances provides a very flexible test environment, but with this support comes the inherent complexity of having multiple servers, server configurations, and associated projects. Rather than force you to learn the entire structure just to test a simple application, there is a staged introduction to the server environment that starts with a very simple menu click from a web or EJB project to configure and start a server.

All such projects have a Run on Server menu item on their context menus. If the project is not associated with a server configuration, a new configuration will be created containing the project. If the configuration is not associated with a server instance, a new instance will be created. Finally, the server will be started with the configuration, and the result displayed with an embedded browser displayed in the editor pane. The net result of this design is a comprehensive test infrastructure that is also easy to use.

Continuing with the phonebook application, the initial page we wish to display is the PhoneBook.html. To start the server and execute the application, all that is required is to locate this file, bring up the pop-up menu, and select the Run on Server menu action. You do not need to separately define a server project, server configuration, or server instance, as that will be done automatically for you. You do not need to export the project either, or create a WAR or EAR file, as the WebSphere Unit Test Environment will be configured to load the application directly from the workbench. The following screenshot shows the results of the Run on Server action:

click to expand

WebSphere Unit Test Environment

The WebSphere Unit Test environment is a specific configuration of the server tools described above. There is an unmodified copy of the WebSphere runtime contained within Studio. The server is run in an external process, using the correct JVM. It is both possible and supported to apply eFixes and formal PTFs to the WebSphere runtime and the WebSphere JVM, further maintaining compatibility between the test environment and the production environment, without impacting on the behavior of Studio.

The other distinguishing feature of the Unit Test Environment is how the server locates the applications being developed. Typically, you would need to publish an application to the server before it could be started and tested. However, the Unit Test Environment generates a specific configuration file for WebSphere, allowing the server to load the various projects directly from the Studio workspace directories.

This eliminates the need for a publishing step, as the files are being developed in the same location as that in which the server requires them. Changes to static files, such as HTML pages and graphics, are therefore automatically picked up when the server next uses them. Any changes made in the Studio Java editor to Java code is automatically re-compiled by the incremental compiler when the file is saved, and the updated class file(s) are then written to disk.

The server configuration ensures that the class files are loaded directly, and do not need to be packaged into a physical JAR. The WebSphere classloader can be configured to automatically detect and reload changes to class files, via an extension in the containing EAR projects' deployment descriptor. The editor for this is shown opposite; the Reload interval text field defines how often the file timestamp should be checked. Note that when a class file changes, the entire module is reloaded:

click to expand

The result of these interactions is a model that allows developers to make changes to all resources under development, while the server is running, and have those changes reflected immediately in the server without an intervening publishing step. WebSphere Studio version 5.0 includes two WebSphere instances for use in the unit testing environment; one version 4.0 AEs server, and one version 5.0 base server.

WebSphere Remote Test Environment

The Remote Test Environment refers to the ability of Studio to publish to, configure, start, and interact with a server defined on a remote system. This capability should not be confused with the production system management function; rather, it is intended to allow testing to proceed on any server other than the one included as part of WebSphere Studio. Examples of this usage would include testing a server on another platform, testing another edition of WebSphere, or just broader system testing performed by a wider audience.

The cost of this additional flexibility is that a publishing step is required before changes made in Studio can be reflected on the server, although this step is automated. In addition, the initial generation of the server configuration, and even the activation of the server process on a remote machine, can be completed by the server tools infrastructure. The first step in defining a remote server includes identifying the server's IP address, and providing some basic information about the server installation (where on the remote system the server was installed, and so on):

The next part of the configuration is to define how the publishing action will proceed. Studio introduces an abstraction of the publishing step, called a Remote File Transfer (RFT). This abstraction allows for different file transport mechanisms to be defined, including FTP, native LAN file copying, or any other pluggable technique, and then reused in several different scenarios:

click to expand

The server definition and RFT information are all saved as part of the server instance. As with all other Studio resources, it is saved to the source configuration system, and therefore broadly available to your entire development team; this file is part of the workbench.

Once the remote server instance has been defined, it can be associated with a project – or more accurately, a project can be added to a server configuration, and then that configuration is associated with a server instance. A remote server is started from within Studio in exactly the same way as the unit test server is started; it can be explicitly started from the server perspective, or implicitly by selecting Run on Server for a project that has been associated with it. If a project is associated with multiple servers, you will be prompted for which one should be started.

The mechanics of starting a remote server require that the Remote Agent Controller (RAC) be installed on the remote machine (which is included with WebSphere Studio, and also with the runtime on the Application Server Tools CD). This is a service that is used by a number of Studio components to facilitate tracing, logging, and server startup on remote machines. The RAC is typically not installed on a production machine, and must be configured to ensure secure access before it can be used at all, but once activated it allows easy activation and test of remote servers.

Web Services Support

Web Services are an extremely flexible way to create business logic methods (or services) that can interoperate across the web, without regard to the language or platform the service is implemented in. WebSphere Studio includes the ability to consume, or generate code that interacts with an existing web service, as well as the ability to create a new web service. We will describe the function of web services in detail in Chapter 8, and just provide an overview of the support provided by WebSphere Studio here.

The interface to a web service is primarily defined via a Web Services Definition Language (WSDL) file. The consumption, or use of an existing web service involves the creation of a Web Services client. This primarily consists of importing a WSDL file, and generating the Java code that is required to invoke the Web Service. A wizard is available that will guide you through this process. The client code will be created in the Web Project that will be used invoke the web service.

Important

Note that the client creation wizard will not create a new Web Project. You must have an existing target project before you start the wizard.

click to expand

The WSDL file used to create the client can exist within the workspace, but it can also be loaded via any URL, or located via the built-in UDDI browser. The client wizard always generates the required proxy, but it also has the option of generating a sample JSP page that will interact with the proxy. Depending on the state of the application you are writing, the following four JSP pages can provide a quick start to the actual code. The following table describes them:

File Name

Description

TestClient.jsp

The main frame for the test client, run this to use

Input.jsp

Referenced by the TestClient.jsp to gather input fields

Method.jsp

Referenced by the TestClient.jsp to invoke the method

Result.jsp

Referenced by the TestClient.jsp to display the result

When creating a web service, the development flow is to create the application that is being exposed first, and then create a new web service for that application. Many different applications can be used as input to this process, ranging from a simple JavaBean to an EJB:

click to expand

The use of a JavaBean is the simplest form of web service, even though it clearly does not provide the qualities of service that more advanced applications require. EJBs can also be used to implement a web service, and result in a much more robust application. Public methods on the bean are introspected, displayed in the wizard, and can be exposed as methods on the web service. The same structure is followed when creating a web service from a stateless session EJB after prompting for details such as the bean's JNDI name, methods on the remote interface are displayed and can be selected for inclusion on the web service:

click to expand

In all cases, the encoding method for the parameters and the return type of each method is selectable; the standard encoding of SOAP and Literal XML are available as radio buttons. However, if you wish further customization, you can select the Show server (Java to XML) type mappings checkbox. This will add an additional page to the wizard, allowing the specific mappings to be defined for each method. Although it is neither required nor recommended for general use, this customization can extend to the provision of your own serialization code, allowing unlimited flexibility for mapping incoming data types to those required by your application:

click to expand

Once the wizard is completed, all required files would be generated into the selected project. The wizard can also optionally generate the same client application described above for a new web service, to facilitate easy testing.

Data Tools

The Studio database support includes the ability to import and export schema definitions via a live database connection, as well as a comprehensive series of editors for all parts of a schema model. There is a data perspective that can be used to consolidate these functions into a single place, but as with all Studio tools, the capability is available from almost every view.

Importing a schema definition from a database connection is best accomplished from the data perspective in which the navigator pane is supplemented with views: DB Servers and Data Definition. In the DB Servers view, the New | Connection menu action will allow the definition of a connection, ranging from the database name and vendor to the JDBC driver and class. Once a connection has been defined, schema definitions can be imported from and exported to the database.

Editing a schema definition is likely the most common database function that will be performed in Studio, and this is best accomplished in the Data Definition pane. The schema definition is persisted as a series of XMI files in the workspace, and these files can be located in any folder, and any project. In an EJB project for example, they are located in the /META-INF/Schema folder. There is a schema editor that can be used to edit or browse the content of these model files, but the Data Definition view also provides an overview in the main pane. There are four unique file types: one each for databases, schemas, tables, and views. When the file is located in any perspective, double-clicking on it will open the correct editor.

In the following screenshot, we are editing the schema definition for the phonebook application. The requirements for this application are very simple; we need a name and a phone number. Both these fields are being defined as VARCHARs. To further simplify the application, the name is being used as the database key:

click to expand

XML Tools

With the ever-increasing importance of XML, it should come as no surprise that WebSphere Studio includes a full complement of XML creation, manipulation, and viewing tools. In addition to a base XML editor, there are editors included for XML Schema, DTDs, and XSL, and also wizards that generate DTDs, XML files, XSL files, code to both read and write XML files from the file system, and JDBC code to both read and write XML data from a database.

The XML editor provides a structured view of any XML file, displaying all current elements and attributes as distinct nodes, and allowing the addition of new elements or attributes. Although all J2EE-defined XML files have their own editors in Studio, the XML editor can also be used to edit them at any time:

click to expand

All changes made to the XML file can be are constrained by the file's schema or DTD. Selecting the constraint icon in the toolbar can toggle this behavior.

This icon indicates that constraints are currently on, and changes to the file must conform to the schema or DTD. Clicking the icon will turn constraints off.

This icon indicates that constraints are currently off, and any changes at all can be made to the file. Clicking the icon will turn constraints on.

If unconstrained changes are made to an XML file, the Create new DTD wizard (or Create new schema, if desired) can be used to generate a new DTD reflecting the current content and structure of the XML file.

The JavaBean to XML/XSL wizard will take a JavaBean as input, and can generate several different types of XML files. Some of the most useful are a selection of XSL stylesheets, used to dynamically generate a variety of web pages from a passed JavaBean using XSL transforms. The wizard will display the public methods on the bean, allowing you to select which ones should be displayed on the web page for both input and output pages. Upon completion of the wizard the desired XSL stylesheets will be generated, along with servlets that can be used to invoke them. The resulting files can of course be edited by any means, but they provide a great starting point for creating simple dynamic web pages.




Professional IBM WebSphere 5. 0 Applicationa Server
Professional IBM WebSphere 5. 0 Applicationa Server
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 135

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net