|
|
The following sections describe how to use WebLogic SIP Server application composition features:
| Note: | The application composition strategy described in this section is applicable only to WebLogic SIP Server 3.1. Application composition techniques will likely change in future versions of the SIP Servlet specification, rendering the current composition techniques obsolete. |
Application composition is the process of “chaining” multiple SIP applications, such as Proxies, User Agent Servers (UAS), User Agent Clients (UAC), redirect servers, and Back-to-Back User Agents (B2BUA), into a logical path that processes a given SIP request. The sections that follow describe an application composition programming model that can be deployed to WebLogic SIP Server. By using this programming model, you can define a set of applications responsible for processing a given initial SIP request, as well as the logic for how and when each application should modify the request. The WebLogic SIP Server container ensures that each application remains on the call path for subsequent message processing requests.
The basic WebLogic SIP Server application composition model involves creating a main “composer” application that examines initial SIP requests to determine which deployed applications should process the request. For example, a composer application may examine the user specified in the Request-URI header and select applications based on the user’s subscription level.
The composer application should insert one or more Route headers into the request, with each Route header specifying the name and location of a deployed SIP application that should process the request. Application names are defined similar to user addresses, using the format:
application@address
where application is the deployment name of the SIP application and address is the address of the load balancer used to contact the WebLogic SIP Server installation, the cluster address, or the listen address of the server itself (for example, proxyapp1@mycompany.com). The order of the Route headers in the message should dictate the required order of application execution. The Request-URI header of the initial request should remain unchanged.
After inserting Route headers to chain the required applications, the composer application then proxies the message using the original Request-URI. The container examines the contents of the initial Route header in the request. If the user name portion of the route header matches a deployed application name and the address matches a configured server address, then the container delivers the request to the named application.
After each application processes the request, the top Route header is removed the message is then proxied to the next application as shown in Figure 4-1.
If a request is proxied to another server, the SIP Servlet container inserts the session IDs of chained applications into the Record-Route header of the message. The session IDs ensure that each server hosting a chained application remains in the call path for subsequent requests.
Listing 4-1 shows the organization of a simple composer application.
package example;
import javax.servlet.sip.SipFactory;
import javax.servlet.sip.SipServletRequest;
import javax.servlet.sip.SipURI;
import javax.servlet.sip.SipServlet;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import java.io.IOException;
public class Composer extends SipServlet {private SipFactory factory;
private static final String CLUSTER_ADDRESS = "example.com";
public void init(ServletConfig sc) throws ServletException {super.init(sc);
factory = (SipFactory)
getServletContext().getAttribute("javax.servlet.sip.SipFactory");}
protected void doRequest(SipServletRequest req)
throws ServletException, IOException { if (!req.isInitial()) {super.doRequest(req);
return;
}
SipURI[] routeSet = getRouteSet(req);
for (int i = 0; i < routeSet.length; i++) {req.pushRoute(routeSet[i]);
}
req.getProxy().proxyTo(req.getRequestURI());
}
/*
* Returns application route set for specified request. Ideally, this route
* set should be based on the requesting user's subscribed services. In
* this example, it is fixed for all users.
*/
private SipURI[] getRouteSet(SipServletRequest req) { return new SipURI[] { createRouteURI("app1"), createRouteURI("app2") };}
private SipURI createRouteURI(String appName) {SipURI uri = factory.createSipURI(appName, CLUSTER_ADDRESS);
uri.setLrParam(true);
return uri;
}
}
WebLogic SIP Server examines the first Route header in a message to determine two things:
Both of these conditions must be met in order for the SIP Servlet container to route a request to an application specified in the Route header. When both conditions are met, the SIP container checks the mapping rules to verify that the designated application is capable of handling request. If either condition is not met, Weblogic SIP Server uses the default Servlet mapping rules defined in the Servlet’s deployment descriptor to process the request.
For example, if the username portion of the first Route header does not match a deployed application name, default Servlet mapping rules are used to process the request. Always ensure that the composer application embeds the correct application names into Route headers when chaining applications together.
Even if the username matches a deployed application, the address portion must also match one of the configured addresses for the WebLogic SIP Server instance:
To ensure that the address of an application matches the server address, ensure that the composer application is embedding the proper address string in Route headers. Also ensure that the server instances are configured using the same address string. See loadbalancer and Configuring WebLogic SIP Server Network Resources in Configuring Network Resources.
When using this application composition model, please keep in mind that the order of deployment for composed applications is significant and the composer application must be deployed before all other applications. Because redeployment changes the deployment order, use application upgrade mechanisms instead of redeployment to update the composer application. Alternately, you can configure the Servlet mapping rules of all other applications in such a way to insure that they are never invoked first (without coming through the composer Servlet).
|