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,
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:
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
is a servlet that is invoked when the
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.
The primary view for a web application developer is the Web perspective, shown below. In this perspective, the Navigator view is
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:
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.
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.
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:
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:
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
in the margin indicates the location of a Java syntax error, and the content assist window is showing the list of valid
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:
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
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:
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.
J2EE Web Project
option is selected, the
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
. 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
folder represents the contents of the module that will be deployed on the server. It contains a
directory, which in
You can store any file you wish in the web project, including requirements and design documents, test cases, and other development-
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
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:
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.
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
The Studio "server instance" concept should not be
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
menu item on their context
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:
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
The other distinguishing feature of the Unit Test Environment is how the server
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
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
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:
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
Web Services are an extremely flexible way to create business logic methods (or services) that can
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.
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.
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:
The main frame for the test client, run this to use
Referenced by the TestClient.jsp to gather input fields
Referenced by the TestClient.jsp to invoke the method
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:
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:
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
Once the wizard is completed, all required files would be generated into the selected project. The wizard can also
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
pane. The schema definition is
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 VARCHAR s. To further simplify the application, the name is being used as the database key:
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:
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.