Administering SAS BI Web Services

Additional Administrative Tasks for SAS BI Web Services for Java

Enabling Java2 Security is not recommended due to significant degradation in performance. However, if you must enable Java2 Security, then you should familiarize yourself with how the Axis2 engine loads Web services.

For example, when the Axis2 engine deploys a Web service, it explodes the service archive in a temporary directory designated by the application server's JVM and loads service classes using its own URL class loader. This is important to WebSphere administrators because they might think that codeBase permissions can be added to the was.policy file for Axis2 Web service classes. This does not work because classes that are not loaded by the WebSphere WAR class loader are not part of that protection domain. In this case, codeBase permissions regarding these service classes must be placed in a protection domain that covers these classes. A WebSphere administrator can use the app.policy file because it covers all classes in the cell, or the administrator can use the JVM java.policy file because it covers all classes in the JVM.

Running Exploded in the WebLogic Application Server

In order to support hot deployment, Axis2 requires the archive (sas.wip.services9.2.ear) to be deployed in exploded format. Because the WebLogic deployer does not automatically explode its archives like other containers do, the SAS Deployment Wizard manually performs this operation during configuration processing.

Hot deployment enables SAS BI Web Services for Java to dynamically generate new Web services and make them immediately available for consumption without having to stop and restart the server. Axis2 hot deployment is enabled by default. To configure SAS BI Web Services for Java in this manner, see the Deployment method configuration property for more details.

Java Development Kit (JDK) Requirement

Because SAS BI Web Services for Java must compile generated code while running in the application server, it requires access to a JDK at run time. Therefore, a Java Runtime Environment (JRE) is not sufficient. Normally, the application server is executed with a JDK and as a result SAS BI Web Services for Java has access to that JDK. However, in rare circumstances when the application server is executed with a JRE instead, it is necessary to configure SAS BI Web Services for Java to use a different JDK. For more information, see the JavaHome advanced SAS BI Web Services for Java configuration property.

Setting Up Clustering

Clustering is not automatically enabled for SAS BI Web Services for Java because hot deployment is not supported in this type of configuration. A more likely scenario is to install SAS BI Web Services for Java in a non-clustered environment to develop new Web services. After these new Web services have been iteratively tested, modified, and retested, they can be promoted to a system that is can be clustered. Because all SAS BI Web Services for Web services that are generated by Java are stateless, no additional Axis2-specific clustering needs to be configured other than making the Web services available to all nodes in the cluster. This can be accomplished in one of the following ways:

Duplicate the Web services (and modules) in the Axis2 repository on each node.
Use an Axis2 URL-based repository so that Web services (and modules) can be configured in a central location. To configure a central repository for Axis2, follow these steps:
1. In the Axis2 configuration file (sas.biws.war/WEB-INF/conf/axis2.xml), comment out the following configuration parameters:
```
<parameter name="ServicesDirectory">...</parameter>
<parameter name="ModulesDirectory">...</parameter>
```
2. In the Web application deployment descriptor file (sas.biws.war/WEB-INF/web.xml), specify the axis2.repository.url AxisServlet initialization parameter as follows:
```
<servlet>
   <servlet-name>AxisServlet</servlet-name>
   ...
   <init-param>
      <param-name>axis2.repository.url</param-name>
      <param-value>http://host:port/axis2repos/</param-value>
   </init-param>
</servlet>
```
  where axis2repos is a reachable path on a Web server that has been set up.
3. In this example, a new Web application is created with a context root of axis2repos. This application contains the Axis2 static services (and modules) configuration data that needs to be accessible from the previous step. The following illustrates the layout of the application:
```
axis2repos.war/
   modules/
      addressing.mar
      rahas.mar
      rampart.mar
      sas.biws.security.mar
      modules.list
   services/
      myService1.aar
      myService2.aar
      ...
      services.list
```
  The modules.list file specifies the names of the modules in that directory. For example, it contains the following content:
```
addressing.mar
rahas.mar
rampart.mar
sas.biws.security.mar
```
  The services.list file specifies the names of the services in that directory. For example, it contains the following content:
```
myService1.aar
myService2.aar
...
```
4. After the static files (services and modules) described in the previous step are accessible, clustered instances of SAS BI Web Services for Java (sas.wip.services9.2.ear/sas.biws.war) application can access them from this central location.

For more information about clustering applications in your particular environment, see the application server-specific documentation.

Enabling Application Scope

Web services are generated with the default request session scope. This enables clients to generate a Web service, remove that Web service, and regenerate that same Web service after making changes to it without having to worry about old classes that Axis2 might have cached. However, when a Web service is created with application session scope, the service's class is never unloaded even if the service is deleted or removed. In order to avoid this problem, new Web services are generated with request session scope so that a service's class is loaded on each request and classes are not cached. However, after a service is stabilized and is not changing, you might want to manually change the service's session scope to application to gain performance throughput. For example, you might change the service.xml deployment descriptor as follows:

<serviceGroup>
   <service name="myService" scope="application">
   ...
   </service>
</serviceGroup>

Using the Deploy As Web Service Wizard to Overwrite an Existing Web Service

When deploying a Web service with a name that already exists, the user is asked if the original Web service should be overwritten. In this case, the user should cancel this request and instead, delete the original Web service as a separate operation. Choosing to overwrite the existing Web service might not yield expected results if hot update is not enabled, because the Axis2 engine might not detect that the original Web service was actually deleted. The Axis2 engine assumes that hot update is being requested, not hot deployment. The Axis2 engine reads the repository contents every 10 seconds for any changes to its state.

Note: It is not recommended to enable hot update in a production environment because it could result in the system leading to an unknown state. [cautionend]

Top of Page