WSO2 SOA Enablement Server is usually ported into J2EE environments by the J2eeIntegrate tool. While this is an easy, user-friendly means of preparing WSO2 SOA Enablement Server for deployment, it hides much of the porting process. You cannot see what you need to do to port WSO2 SOA Enablement Server, what parameters need to be set, which libraries are present in the classpath, etc.

The following is a guide for porting WSO2 SOA Enablement Server into an application servlet by hand. You may wish to do this if you need full independence from the type of application server or you need to customize the WSO2 SOA Enablement Server portation. It also allows you to create a standalone JSP/servlet-based Web services consumer application using a WSO2 SOA Enablement Server client.

	Note
	WSO2 SOA Enablement Server must be installed before it is ported.

WSO2 SOA Enablement Server can be ported into a servlet container as a servlet. This is the first step in creating a WSO2 SOA Enablement Server standalone servlet-based application. Contain the servlet a classic Web Application Archive (.war) file. The archive should have the following structure :

Figure 15. Web Application Structure

All JAR files are located in the WASP_HOME/lib directory except porting.jar, which is located in WASP_HOME/conf/porting/dist.

If you are creating a standalone application, the next step is to configure and create the WSO2 SOA Enablement Server application, which is described in the web.xml file.

The classpath of the application server must include:

The contents of the web.xml document :

<?xml version="1.0" encoding="UTF-8"?>

<web-app>

    <display-name>WSO2 SOA Enablement Server for Java Servlet</display-name>

    <context-param>
        <param-name>wasp.location</param-name>
        <param-value>E:\work\WASP_HOME</param-value>
    </context-param>

    <context-param id="wasp_config_include">
        <param-name>wasp.config.include</param-name>
        <param-value>conf/as-specific.xml</param-value>
    </context-param>

    <context-param>
        <param-name>wasp.config.location</param-name>
        <param-value>conf/jboss-servletconf.xml</param-value>
    </context-param>

    <context-param>
        <param-name>wasp.servlet.httpport</param-name>
        <param-value>8080</param-value>
    </context-param>

    <context-param>
        <param-name>wasp.servlet.httpsport</param-name>
        <param-value>8443</param-value>
    </context-param>

    <context-param>
        <param-name>wasp.servlet.hostname</param-name>
        <param-value>wileyecoyote.acme.com</param-value>
    </context-param>

    <context-param>
        <param-name>idoox.debug.level</param-name>
        <param-value>3</param-value>
    </context-param>

    <context-param>
        <param-name>wasp.servlet.context</param-name>
        <param-value>systinet</param-value>
    </context-param>

    <listener>
        <listener-class>com.systinet.transport.servlet.server.Initializer</listener-class>
    </listener>

    <servlet>
        <servlet-name>WSO2 SOA Enablement Server for Java Servlet</servlet-name>
        <servlet-class>com.systinet.transport.servlet.server.Servlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>WSO2 SOA Enablement Server for Java Servlet</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>

    <session-config>
        <session-time-out>30</session-time-out>
    </session-config>

</web-app>

In Example 5 , the class that implements the servlet is com.systinet.transport.servlet.server.Servlet. You can specify any context parameter in web.xml file that is acceptable for WSO2 SOA Enablement Server and it will be passed to WSO2 SOA Enablement Server initialization. For more information, please see WSO2 SOA Enablement Server Configuration.

There are two ways to set up properties for a WSO2 SOA Enablement Server application:

The following special context parameters can be specified in web.xml and will be accepted by our WSO2 SOA Enablement Server application:

Because the servlet request passed to the WSO2 SOA Enablement Server may contain an incorrect host name, we added the optional context parameter called wasp.servlet.hostname, which contains the server hostname.

You do not set the wasp.location context parameter when you port WSO2 SOA Enablement Server as a standalone web application because the final location depends on the portation process in the servlet container. Please see the J2eeIntegrate Tool chapter for details.

	Important
	The self-contained portation must have copies of the WASP_HOME/app and WASP_HOME/conf directories in the root directory of the web application.

If the property wasp.location is not set, WSO2 SOA Enablement Server tries to set it when the servlet starts by calling the servlet API's method getRealPath(/) on the servlet context. However, sometimes this method returns null when WSO2 SOA Enablement Server is ported as a WAR file. To avoid this problem, the servlet transport tries to get a temporary directory for its web application by calling getAttribute(javax.servlet.context.tempdir) on the servlet context.. This method must return a temporary directory for the web application (in accordance with the Servlet 2.3 specification). When wasp.location is not set, the com.systinet.transport.servlet.server.Initializer context listener is activated. Its job is to extract all files from the /app and /conf directories located in the root of the web application to this temporary directory. This context listener also sets up JVM properties if the wasp.set.jvm.properties context parameter is set (this parameter will be used mainly in self-contained client applications).

Some WSO2 SOA Enablement Server configuration parameters require an absolute path to the configuration files. This is a problem when the WSO2 SOA Enablement Server application is ported to the application server in the self-contained mode. For that purpose we support the special template string ${wasp.location} in our implementation. A param-value sublement can start with ${wasp.location}, which will be replaced with the real absolute path during WSO2 SOA Enablement Server application startup.

Sometimes it is necessary to move the WSO2 SOA Enablement Server servlet to a different location within the web application. For example, you may want to include custom JSP pages or Servlets within the WSO2 SOA Enablement Server web application. There is a special context parameter, wasp.servlet.mapping, intended for that purpose. To move the WSO2 SOA Enablement Server servlet to the path inside_web_app perform the following two steps:

After these steps the WSO2 SOA Enablement Server administration console (and other Web services too) will be accessible via http://localhost:some_port/systinet/inside_web_app/admin/console instead of http://localhost:some_port/systinet/admin/console.

Currently, HTTP transport is split between client and server side functionality. The server part of HTTP transport is the attribute http_server. The user should remove this instead of replacing com.idoox.transport.http.Http (please see HTTP in Built-in Transports).

You should remove the lines configuring the default server, HTTP transport, because the server-side HTTP connectivity provided by the application server is sufficient (it passes the HTTP requests to the WSO2 SOA Enablement Server servlet, which passes them to the WSO2 SOA Enablement Server). We do not recommend having both the application server and the WSO2 SOA Enablement Server listen for incoming requests. Remove the lines from the configuration file that contain a <transport> tag with the attributes defaultServer='true' and scheme='http'.

Do not alter the lines in the configuration file that configure the client transport. The client transport is needed by certain core services running in WSO2 SOA Enablement Server.

	Important
	You must not remove the client transport configuration.

WSO2 SOA Enablement Server servlet transport was retrofitted to enable truely self-contained web applications. Due to this fact current servlet implementation requires Servlet 2.3 specification implementation. Because of backward compatibility, it is possible to turn generated WSO2 SOA Enablement Server web applications into web applications compatible with Servlet 2.2 specification. The following steps are required: