3-6 Oracle WebLogic Server SIP Container Developers Guide
3.3.3 Obtaining a Reference to SipServletSnmpTrapRuntimeMBean
Any SIP Servlet that generates SNMP traps must first obtain a reference to the SipServletSnmpTrapRuntimeMBean.
Example 3–2 shows the sample code for a
method to obtain the MBean.
Example 3–2 Sample Method for Accessing SipServletSnmpTrapRuntimeMBean
public SipServletSnmpTrapRuntimeMBean getServletSnmpTrapRuntimeMBean { MBeanHome localHomeB = null;
SipServletSnmpTrapRuntimeMBean ssTrapMB = null;
try {
Context ctx = new InitialContext; localHomeB = MBeanHomectx.lookupMBeanHome.LOCAL_JNDI_NAME;
ctx.close; } catch NamingException ne{
ne.printStackTrace; }
Set set = localHomeB.getMBeansByTypeSipServletSnmpTrapRuntime; if set == null || set.isEmpty {
try { throw new ServletExceptionUnable to lookup type
SipServletSnmpTrapRuntime; } catch ServletException e {
e.printStackTrace; }
} ssTrapMB = SipServletSnmpTrapRuntimeMBean set.iterator.next;
return ssTrapMB; }
3.3.4 Generating an SNMP Trap
In combination with the method shown in Example 3–2
, Example 3–3
demonstrates how a SIP Servlet would use the MBean instance to generate an SNMP trap in
response to a SIP INVITE.
Example 3–3 Generating a SNMP Trap
public class MyServlet extends SipServlet { private SipServletSnmpTrapRuntimeMBean sipServletSnmpTrapMb = null;
public MyServlet { }
public void init ServletConfig sc throws ServletException { super.init sc;
sipServletSnmpTrapMb = getServletSnmpTrapRuntimeMBean; }
protected void doInviteSipServletRequest req throws IOException { sipServletSnmpTrapMb.sendInfoTrapRx Invite from + req.getRemoteAddr +
with call id + req.getCallId; }
}
Requirements and Best Practices for SIP Applications 4-1
4
Requirements and Best Practices for SIP Applications
This chapter describes requirements and best practices for developing applications for deployment to WebLogic Server. It contains the following sections:
■
Section 4.1, Overview of Developing Distributed Applications
■
Section 4.2, Applications Must Not Create Threads
■
Section 4.3, Servlets Must Be Non-Blocking
■
Section 4.4, Store all Application Data in the Session
■
Section 4.5, All Session Data Must Be Serializable
■
Section 4.6, Use setAttribute to Modify Session Data in “No-Call” Scope
■
Section 4.7, send Calls Are Buffered
■
Section 4.8, Mark SIP Servlets as Distributable
■
Section 4.9, Use SipApplicationSessionActivationListener Sparingly
■
Section 4.10, Session Expiration Best Practices
■
Section 4.11, Observe Best Practices for Java EE Applications
4.1 Overview of Developing Distributed Applications
In a typical production environment, SIP applications are deployed to a cluster of WebLogic Server instances that form the engine tier cluster. A separate cluster of
servers in the SIP data tier provides a replicated, in-memory database of the call states for active calls. In order for applications to function reliably in this environment, you
must observe the programming practices and conventions described in the sections that follow to ensure that multiple deployed copies of your application perform as
expected in the clustered environment.
If you are porting an application from a previous version of WebLogic Server, the conventions and restrictions described below may be new to you, because the 2.0 and
2.1 versions of WebLogic SIP Server implementations did not support clustering. Thoroughly test and profile your ported applications to discover problems and ensure
adequate performance in the new environment.
4.2 Applications Must Not Create Threads
WebLogic Server is a multi-threaded application server that carefully manages resource allocation, concurrency, and thread synchronization for the modules it hosts.
Kategori