IBM WebSphere Developer Technical Journal: Setting up a Remote WebSphere Application Server in WebSphere Studio V5

Elson Yuen (eyuen@ca.ibm.com), Software Developer, IBM Toronto Lab

Elson Yuen is a software developer in the IBM Toronto Lab working on the WebSphere Studio Application Developer. He is currently designing and developing the Server Tooling which includes the WebSphere Test Environment. Previously, he was the key developer on the VisualAge for Java WebSphere Test Environment JSP debugging support. Elson has a Bachelors degree in Electrical Engineering with Management Science options from the University of Waterloo, Ontario. You can contact Elson at eyuen@ca.ibm.com.

Summary: The remote application server support in WebSphere Studio V5 allows you to start a remote WebSphere Application Server from the workbench so you can test your application on a standalone WebSphere Application Server installed on a remote machine. This article will describe the different setup scenarios so you can decide the best configuration for your environment.

Tag this!

Date: 26 Mar 2003
Level: Introductory
Activity: 428 views

Introduction

The remote application server support in IBM WebSphere® Studio V5 allows you to start a remote WebSphere Application Server from the WebSphere Studio Workbench. This feature allows you to test your application on a standalone WebSphere Application Server that is installed on a remote machine. Since there are different configurations that you can use to run the remote server, this article will describe the different setup scenarios so you can decide which configuration would be best for your environment.

This article assumes that you are familiar with the WebSphere Studio Workbench and the server tools test environment.

Prerequisites

Remote application server support requires that the following be setup before you can run a remote WebSphere Application Server:

WebSphere Studio Application Developer (or Site Developer) Version 5.0 must be properly installed on a machine. This article will refer to the machine with WebSphere Studio installed as the local machine.
An appropriate version of WebSphere Application Server must be properly installed on a machine. This may be either WebSphere Application Server, Version 5.0 (base), or a standalone WebSphere Application Server, Version 4.0.x, Advanced Single Server Edition (AEs). The machine can be the same machine on which WebSphere Studio is installed, or it can be a different physical machine. Either way, this article will refer to the machine with WebSphere Application Server installed as the "remote machine".
IBM Remote Agent Controller Version 5.0 must be properly installed and started on the remote machine.
Hint:
Remote Agent Controller only needs to be installed on the remote machine. It does not need to be installed on the local machine to run the remote server. It is recommended that WebSphere Application Server be installed prior to installing the Remote Agent Controller. Otherwise, extra setup will be required to the Remote Agent Controller. See the product documentation for details.

Benefits of using the remote application server

Using a remote WebSphere Application Server in the test environment has some key benefits over using the application server shipped with WebSphere Studio:

The remote server support can provide an environment that is closer to an actual production server environment.
It allows you to develop your application on one platform, then test it on another, which is particularly useful when your development and production platforms are different.
You can test the remote server with the HTTP server.

The remote WebSphere Application Server also has some advantages over remotely attaching to a standalone server process running in debug mode with a Java debugger. In the standalone test environment, when you remotely attach to a server process to debug your application, you have to first export the modified application from WebSphere Studio, then manually redeploy the application to the remote server. With the remote application server support, you are provided with a round-trip debug environment that allows you to debug and then publish the changes on your Web applications from WebSphere Studio to the server without redeploying the application.

Setting up the remote application server

The settings of the remote server will depend on the environment. Remote WebSphere Application Server scenarios fall into three main categories:

Scenario1 - Same physical machine: WebSphere Application Server installed on the same physical machine as WebSphere Studio
Scenario2 - Different physical machines using Copy file transfer: WebSphere Application Server installed on a different physical machine than WebSphere Studio, using copy file transfer mechanism
Scenario3 - Different physical machines using FTP file transfer: WebSphere Application Server installed on a different physical machine than WebSphere Studio, using FTP file transfer mechanism

Details of each scenario are described below. Each scenario includes a real life sample to illustrate how to setup the remote server in each case. The steps in Scenarios 2 and 3 are built on the steps in Scenario 1. Therefore, be sure to start with Scenario 1 regardless of which scenario best fits your environment.

Scenario 1: Same physical machine

The simplest case involving minimal settings is when WebSphere Application Server is installed on the same physical machine as WebSphere Studio. Apart from the simplicity of the setup, publishing the Web application and server configurations from WebSphere Studio to a local machine is more efficient than publishing to a remote machine. Use this kind of setup whenever possible.

Sample setup:

The application server is installed under the directory d:\apps\WebSphereV5\AppServer on the local machine. Follow these steps to setup the remote server:

Step 1:

To run a remote WebSphere Application Server, you have to create a remote server using the workbench. Switch to the Server perspective on the workbench by selecting Window => Open Perspective => Other... => Server => OK (Figure 1).

Figure 1. Select perspective

Step 2:

Select File => New => Server and Server Configuration.
In the Create a New Server and Server Configuration wizard dialog (Figure 2), fill in the server name and folder, than select the type of server that matches the standalone WebSphere Application Server on the remote machine. The server types that will be listed will depend on which version of WebSphere Studio is installed and the selection during the installation.
Click Next.

Figure 2. Create a new server and server configuration

Step 3:

Enter the host name or the IP address in the Host address field in the WebSphere Remote Server Settings dialog (Figure 3). The default setting will be correct if WebSphere Studio and WebSphere Application Server are installed on the same machine.
When you click Next, the tools will attempt to detect remote server information from the remote machine, such as the WebSphere installation directory and the remote platform. This new feature of WebSphere Studio V5.0 simplifies the remote server setup. However, since the tools use the Remote Agent Controller (RAC) to query the remote machine information, the RAC needs to be started before you click Next.

Figure 3. Enter host address

Step 4:

The next WebSphere Remote Server Settings dialog (Figure 4) asks for information that is required to start the remote server. Since the information on this page is used for starting the server from the remote machine, all the path settings on this page should be the path seen from the remote machine, not the path as seen from the local machine through share drives. The WebSphere installation directory is the path where WebSphere is installed on the remote machine. The WebSphere deployment directory is where the published server configuration and Web application are located on the remote machine. By default, all the information should be detected properly for you in this scenario. You may simply accept all the default values and click Next.
Hint:
The default WebSphere deployment directory points to the same directory as the WebSphere installation directory. This default setting will cause the original server configuration to be replaced on the remote server. A backup copy of the original server configuration will be created in a directory config/wasTools_bkup under the deployment directory. You can replace the published server configuration with the original one if you want to revert to the original server configuration.

Figure 4. Settings for the remote server
Specify the settings for the remote server

Step 5:

The settings in the next two dialogs are used for creating a Remote File Transfer (RFT) instance. RFT is the mechanism that is used by the remote server to publish the server configuration and the Web applications it contains to the remote machine. There are two main RFT methods:
- Copy file transfer mechanism transfers files using direct file copy on the file system.
- FTP file transfer mechanism transfers files using FTP (file transfer protocol).
It is recommended that the Copy file transfer mechanism is used wherever possible, since it requires a less complex setup and is generally more efficient than the FTP file transfer mechanism.
Select the desired RFT method (Figure 5). For this scenario, you can accept the default (Copy file transfer mechanism) and click Next.

Figure 5. Assign remote file transfer instance
Create or select a remote file transfer instance

Step 6:

RFT instance settings are defined in the next dialog (Figure 6). These settings are used for publishing the Web applications and the server configuration from WebSphere Studio to the remote machine. The values on this page will depend on the RFT method selected in Step 5, above. All paths on this page should be the paths as seen from the local workbench machine since it is used for publishing to the remote machine.
For this scenario, you can accept the default values and click Finish to create the server and server configuration.
Hint:
Make sure you have both read and write permission to the remote target directory.

The newly created server will be added to the server configuration view.

Figure 6. Remote file transfer settings

Summary of Scenario 1

Reviewing the above steps, it's clear that setting up a remote server in Scenario 1 is relatively easy. Once the server and server configuration are created, the remote server works very similarly to a test environment server; you can add EAR projects to the remote server, and start and stop it the same as a test environment server. The major difference is that you have to explicitly publish changes to the remote server if the server has already started. To do this, simply right click on the remote server on the Servers view and select Publish from the pop up menu.

Scenario 2: Different physical machines using Copy file transfer

When WebSphere Application Server is installed on a different physical machine than WebSphere Studio, there are two available methods for transfering the Web applications and the server configuration to the remote server: Copy file transfer mechanism and FTP file transfer mechanism, as mentioned in Step 5 of Scenario 1, above. In this scenario, we will setup the remote server using the Copy file transfer mechanism.

Sample setup:

Before you can use the Copy file transfer mechanism, you need to map a network drive to the remote machine (or mount a directory on Linux). In this sample setting, WebSphere Application Server is installed on the directory C:\WebSphere\AppServer on the remote machine. The network share drive X: on the local machine is mapped to the WebSphere installation directory C:\WebSphere\AppServer on the remote machine.

Hint:
Make sure you have both read and write permission on the share drive.

Steps 1 and 2:

Same as Scenario 1.

Step 3:

Enter the host name or IP address of the remote machine (Figure 7). If you are using the host name, you can omit the domain name if the local machine and the remote machine are on the same domain. In this example, the full host name of the remote machine is eyuen.torolab.ibm.com.
Click Next. The tools will attempt to detect the remote server information from the remote machine, such as the WebSphere installation directory and the remote platform.

Figure 7. Enter host address

Step 4:

In the next WebSphere Remote Server Settings dialog (Figure 8), the WebSphere installation directory should already be detected for you. The default WebSphere deployment directory points to the directory where WebSphere is installed. In the example, the remote WebSphere Application Server is installed under the directory C:\WebSphere\AppServer on the remote machine. In this scenario, you can accept the default settings.
Click Next.
Hint:
All the path information input on this page should be the directory as seen from the remote machine.

Figure 8. Settings for the remote server
Specify the settings for the remote server

Step 5:

Select Copy file transfer mechanism and then click Next (Figure 9).

Figure 9. Assign remote file transfer instance
Create or select a remote file transfer instance

Step 6:

In the next dialog (Figure 10), set the Remote target directory to the directory where the Web applications and server configuration are to be published to. You may either use the absolute path, or you can specify the Universal Naming Convention (UNC) path in this field.
The Remote target directory and the WebSphere deployment directory (in Step 4) should be pointing to the same physical location, since the Remote target directory (defined on the local machine) is where the Web applications and server configuration are published to, and the WebSphere deployment directory (defined on the remote machine) is where the remote server will look to load the Web applications and server configuration. In this scenario, WebSphere deployment directory is set to the WebSphere installation directory, and the Remote target directory is set to the mapped drive X:\, which is the location of the WebSphere installation directory, as seen from the local machine.

Figure 10. Remote file transfer settings

Summary of Scenario 2

The setup steps and the operation of the remote server in this scenario are very similar to Scenario 1. The important difference in Scenario 2 is in understanding the relationship between the WebSphere deployment directory and the Remote target directory fields in the RFT. Once created, the remote server works the same as it does in Scenario 1.

Scenario 3: Different physical machines using FTP file transfer

As in Scenario 2, the WebSphere Application Server here is installed on a different physical machine than WebSphere Studio. In this scenario, however, will use the FTP file transfer mechanism. This method can be used provided that an FTP server is already setup and started on the remote machine.

Sample remote machine setup - Windows:

In a Windows® scenario, the WebSphere Application Server is installed in the directory C:\WebSphere\AppServer on the remote machine. The remote machine is using the FTP server that is shipped with Windows. A virtual directory remote is setup to point to the WebSphere installation directory C:\WebSphere\AppServer, i.e. once logged in to the FTP server, the WebSphere installation directory on the remote machine can be accessed by changing the directory to /remote (Figure 11).

Figure 11.
Computer Management

Sample remote machine setup - Linux:

For a Linux scenario, the WebSphere Application Server is installed on the directory /opt/WebSphere/AppServer on the remote machine. An FTP server is already installed on the remote machine. Once logged in to the FTP server, the user can access all the directories on the remote machine's file system by changing to the appropriate directory, such as /opt/WebSphere/AppServer.

Hint:
Make sure you have both read and write permission on the remote target directory with the given FTP user access, regardless of the setup you are using.

Steps 1 and 2:

Same as Scenario 1.

Step 3:

Enter the host name or IP address of the remote machine (Figure 7). If you are using the host name, you can omit the domain name if the local machine and the remote machine are on the same domain. In this example, the full host name of the remote machine is eyuen.torolab.ibm.com.
Click Next. The tools will attempt to detect the remote server information from the remote machine, such as the WebSphere installation directory and the remote platform.

Figure 12. Enter host address

Step 4:

In the next WebSphere Remote Server Settings dialog (Figure 13), the WebSphere installation directory should already be detected for you. The default WebSphere deployment directory points to the directory where WebSphere is installed. In this scenario, you can accept the default settings:
- Windows: the remote WebSphere Application Server is installed under the directory C:\WebSphere\AppServer on the remote machine, as in Figure 13.
- Linux: the WebSphere installation directory will be set to /opt/WebSphere/AppServer.
Click Next.
Hint:
All the path information input on this page should be the directory as seen from the remote machine.

Figure 13.
Specify the settings for the remote server

Step 5:

Select the FTP file transfer mechanism and then click Next (Figure 14).

Figure 14.
Create or select a remote file transfer instance

Step 6:

In the next dialog (Figure 15), set the Remote target directory to the directory where the Web applications and server configuration are to be published to.
The Remote target directory and the WebSphere deployment directory (in Step 4) should be pointing to the same place, since the Remote target directory (defined on the local machine) is where the Web applications and server configuration are published to, and the WebSphere deployment directory (defined on the remote machine) is where the remote server will look to load the Web applications and server configuration. In this scenario, then:
- Windows: The WebSphere deployment directory is set to the WebSphere installation directory. Therefore, the Remote target directory will be set to the FTP server virtual directory /remote (the location of the WebSphere installation directory seen from the local machine through the FTP server). Figure 15 illustrates these settings.
- Linux: The WebSphere deployment directory is set to the WebSphere installation directory. Therefore, the Remote target directory will be set to the directory /opt/WebSphere/AppServer (the location of the WebSphere installation directory seen from the local machine through the FTP server).
Hint:
Make sure you have both read and write permission on the remote target directory with the given FTP user access. If in doubt, try to access the FTP server with the information from the Remote file transfer settings dialog (Figure 15), and create a dummy directory under the remote target directory. If this simple test fails, adjust the FTP server setup accordingly.

Figure 15.
Remote file transfer settings

Summary of Scenario 3

The setup steps and the operation of the remote server in this scenario are also very similar to Scenario 1. In addition to understanding the relationship between the WebSphere deployment directory and the Remote target directory fields in the RFT, it's also critical to make sure the FTP server is setup properly. Once created, the remote server works the same as it does in Scenarios 1 and 2.

Conclusion

The remote server support in WebSphere Studio allows you to start a standalone WebSphere Application Server that is installed on a remote machine. Although this article described three different scenarios for setting up a remote WebSphere Application Server in WebSphere Studio, it is recommended that the application server be installed on the same machine as WebSphere Studio whenever possible, and that the Copy file transfer mechanism, rather than FTP, be used to establish a simpler and more efficient Web publishing setup. Once the server and server configuration are created, the remote server will operate in the same manner as the test environment server, regardless of the scenario followed.

Download

Name	Size	Download method
RemoteWebSphereServer_20030124b.zip	0.8 MB	FTP\|HTTP

Information about download methods

About the author

Comments (Undergoing maintenance)

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=WebSphere

ArticleID=14326

ArticleTitle=IBM WebSphere Developer Technical Journal: Setting up a Remote WebSphere Application Server in WebSphere Studio V5

publish-date=03262003

author1-email=eyuen@ca.ibm.com

author1-email-cc=