WSA configuration and Web service deployment tools

The following figure shows OpenEdge tools used to configure and manage a WSA and to deploy and manage Web services.

The WSA is the central component for all aspects of Web service deployment, configuration, and run-time management. As Figure 24 shows, you can manage the entire WSA and Web service configuration using the Unified Broker framework, which accesses the WSA as an OpenEdge server to which Web services are deployed. For more information on the Unified Broker framework and how to work with OpenEdge servers, see OpenEdge Getting Started: Installation and Configuration.

Note: The AdminServer shown in Figure 24 can reside on the same machine as the WSA (local) or on a separate machine (remote).

On the Web server, the WSA is installed as a single JSE Web application for which you must create instances to do meaningful work. The dashed arrows in the Figure 24 indicate that each WSA instance is created from its definition in the ubroker.properties file, which is read by WSA to create the instance. When you deploy a Web service, you deploy it to a WSA instance, which defines the root Universal Resource Locator (URL) used to access the Web service and handles all of its client communications. Each WSA instance thus manages its own set of deployed Web services.

The WSA comes installed with a default WSA instance, wsa1, but no default deployed Web services. You can deploy sample Web services provided with the OpenEdge installation. For more information on these samples, see OpenEdge Development: Web Services.

To begin using the WSA, you must configure it using OpenEdge Management/OpenEdge Explorer or the WSAMAN command-line utility. (This assumes you already installed and configured the JSE to recognize the WSA as a Web application. For more information, see OpenEdge Application Server: Administration.) Similar to other OpenEdge servers, you can create one or more uniquely named WSA instances and set properties for each one in the WSA’s ubroker.properties file.

For each new WSA instance that you create, two files are created, default.props and DeployedServices.ds. The default.props file contains the default values to set for the run-time properties of each Web service that you deploy to the instance, and the DeployedServices.ds file contains the identity and deployment information of each Web service that is already deployed to that instance.

Note: Before using a WSA instance that is newly created using OpenEdge Management or OpenEdge Explorer, you must register the instance with the JSE as a servlet and restart the JSE to run it.

Once you have created and started up a WSA instance, you can deploy a Web service to it using OpenEdge Management/OpenEdge Explorer or the wsaman utility. Input for the deployment includes the WSM file generated for the Web service by ProxyGen (WorldWeather.wsm, in Figure 24) and additional deployment information that you specify, such as a friendly name (FriendlyName) for the Web service. The deployment output includes three files created in the context of the WSA instance:

FriendlyName.props — WorldWeather.props in Figure 24, the Web service properties file containing the Web service run-time property values, initially set to the values in the WSA instance’s default.props file.

FriendlyName.wsdl — WorldWeather.wsdl in Figure 24, the WSDL file that contains the Web service definition. This definition describes to a Web service client how to code and decode SOAP messages for the Web service, and specifies the interface for operations that the client must use to send these messages.

FriendlyName.wsad — WorldWeather.wsad in Figure 24, the Web services application descriptor (WSAD) file that defines the Web service to the WSA instance. This file describes the Web service to the WSA so that it can code and decode client SOAP messages for the Web service, and specifies how to access the AppServer application that executes SOAP requests.

Thus, Figure 24 shows the WorldWeather Web service deployed to the WSA instance, wsa1, and also another WSA instance, wsa2, that has no Web services deployed to it.