内容


IBM WebSphere 开发者技术期刊

WebSphere Application Server V6.1 中的会话发起协议——第 1 部分

SIP 简介

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

此内容是该系列的一部分:IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

摘自 IBM WebSphere 开发者技术期刊

引言

互联网工程工作小组(Internet Engineering Task Force,IETF)于 1999 年将会话发起协议 (SIP) 批准为正式的 RFC(Request for Comments)。SIP 最初的用途是作为协商视频和音频媒体流的中介,但目前已在更多的领域中得到了应用,已发展为能处理所有类型的富协作、移动性和媒体流。SIP 正逐渐成为使用最广泛的标准协议之一。本文介绍了 SIP、SIP Servlet 1.0 (Java™ Specification Request (JSR) 116) 编程模型,并对 IBM WebSphere Application Server V6.1 中现在提供的功能进行了简要小结。

本文的目标受众是对网际协议 (IP) 上的协议(特别是 HTTP 和 SIP)有基本了解的人员。Java Platform Enterprise Edition (Java EE) 和 HTTP Servlet 的背景知识对帮助理解此处讨论的所有概念都有帮助。

SIP 摘要

会话发起协议 (SIP) 是互联网工程工作小组 (IETF) 的标准协议,在 RFC(Request for Comments)3261 中定义,并正迅速成为很多领域的首选协议。SIP 已被作为下一代网际协议 (IP) 技术、即时消息传递、交互式网络电视(Internet Protocol Television,IPTV)和很多实时协作活动的控制层面。此协议属于针对电信运营商的第三代合作伙伴计划(3rd Generation Partnership Project,3GPP)/IP 多媒体子系统(IP Multimedia Subsystem,IMS)解决方案的一部分。同时,目前还在评估 SIP 作为很多在线游戏引擎和其他协作应用程序的控制层面的情况。

人们经常谈到 Telecommunications-Meets-Enterprise 领域的三重或四重播放。三重播放 是讨论网际协议上聚合的音频、视频和数据网络时常用的术语。将移动性作为另一个因素添加到其中,就使其成为了四重播放。因为所有这些网络都聚合到 IP 上,因此 SIP 已成为用于进行聚合的一项非常受欢迎的协议。通过使用 SIP,您能以崭新的非常令人惊喜的方式与其他网络实现互连。

在以下各个部分中,将概要介绍 SIP 的内容,并通过一些示例对其加以说明。另外,还将讨论 SIP 的扩展,这些扩展有助于增强该协议的功能。

SIP 简介

SIP 是 1996 年通过一份 SIP 契约提出的,于 1999 年在 RFC 2543 中正式确立。设计 SIP 时,清楚地考虑了流行的 HTTP 和简单邮件传输协议(Simple Mail Transfer Protocol,SMTP)的优点和缺点。根据这些考虑,将 SIP 作为基于文本的协议进行制定,以帮助协商从一个对等系统或用户到另一个对等系统或用户的交互通信通道。除了连接协商之外,SIP 还用于在控制层面中引入新的令人兴奋的功能。

其中一些新功能对目前很多 SIP 的使用至关重要。经过 SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) IETF 工作组的努力,SIP 现在已具有了显示存在情况和进行即时消息传递的新功能。为了在网络上发布用户访问点和在每个存在点发布用户所需的功能,必须具有显示存在情况的功能。用户和服务可以订阅另一个用户或用户组的存在情况和功能。通过这些订阅,可以基于功能通过正确的媒体向正确的访问点发起通信。

对于核心 SIP 功能,最常用的是与 INVITE 方法相关的流,因此可能也对基础产品最为重要。其想法是这样的,一个实体希望发起与另一个实体的通信,并向通信会话发送一个 INVITE(图 1)。

图 1. 用于发起通信的 INVITE 方法
图 1. 用于发起通信的 INVITE 方法
图 1. 用于发起通信的 INVITE 方法

通过 SIP 消息,两个对等体可发起通信会话。通常,这些会话将使用 RFC 2327 定义的会话描述协议(Session Description Protocol,SDP)等语法协商另一个协议连接。SDP 并不是一个协议,而是可以描述另一个协议连接的消息语法。例如,在 IP 电话等语音应用程序连接中,在 SIP 消息中使用 SDP 协商的协议通常是实时协议(Real-Time Protocol,RTP),而此协议在 RFC 3550 中定义。

SIP 消息将通过用户数据报协议(User Datagram Protocol,UDP)、传输控制协议(Transmission Control Protocol,TCP)或流控制传输协议(Stream Control Transmission Protocol,SCTP)进行传输。根据协议本身的特征以及所需的可靠性和速度不同,将使用不同的传输协议。通常,会选择让应用程序使用作为其事实标准的特定传输协议。例如,IP 电话应用程序通常使用 UDP 传输,而即时消息传递则通常使用 TCP。

基本 SIP INVITE 流

为了更好地理解此协议,最好能了解以下基本 INVITE 流,以确定消息如何在基础设施内来回传递。

基本 INVITE 流(图 2)让 user@ibm.com 发起对 user@example.com 的呼叫。每个 SIP 请求(如 INVITE)都包含一个 SIP 地址(或统一资源定位符 (URL)),以作为发送 INVITE 的目的地。该 URL 是消息的主要路由路径。对于此示例,SIP 地址为 user@example.com。SIP 地址在创建通信会话期间唯一地对用户进行标识。此地址通常与电子邮件地址类似,且包含 sip: 前缀。例如,在前面所示的 INVITE 消息中使用的实际 SIP 地址为 sip:user@example.com。

图 2. INVITE 流
图 2. INVITE 流
图 2. INVITE 流

为 user@ibm.com 发起此会话的设备称为用户代理客户机。用户代理客户机(User Agent Client,UAC)在 SIP 中被正式定义为能创建和管理 SIP 会话的端点。用户代理 (UA)(客户机 (UAC) 或服务器 (UAS))可以为事务中某处的 SIP 电话或服务器,也可以独立协商会话功能。UAC 发起会话,而 UAS 将接受会话。

SIP 消息将传递给 ibm.com 的本地 SIP 代理。ibm.com 的 SIP 代理必须定位 example.com 服务器,以将请求转发到 example.com。进行此任务的首选方法请参见 RFC 3263 的“Locating SIP Servers”中的描述。在此标准中描述了使用 Domain Name System (DNS) Naming Authority Pointer (NAPTR) 记录来定位 SIP 服务器的一种方法,此方法与使用 SMTP 路由邮件的方法类似。ibm.com 服务器将查找 example.com 的 NAPTR 记录,并将 INVITE 消息转发给 example.com 服务器。

ibm.com 代理发送了 INVITE 后,代理将发送一个临时响应或信息响应。在此场景中,服务器可以发送响应代码为 100 的 Trying 响应。在这种特殊的情况下,Trying 响应向客户机指示 ibm.com 代理已接受连接,将尝试把请求发送到下一个位置。服务器使用这些 1xx 响应(称为临时响应)来指示 SIP 事务的进度。在 RFC 3262 中,开发了一项机制来确保可靠地发送消息,且仅为确认目的而发送,以便在使用 UDP 之类的传输协议时不会丢失呼叫状态。

example.com 代理接收到 INVITE 消息后,example.com 服务器通常会使用整个统一资源标识符 (URI) 来查找用户所在的位置,或查找提供用于发起连接的准确 IP 地址的注册中心。在此例中,user@example.com 定义了要邀请到此会话中的特定用户。当用户位于网络地址转换(Network Address Translation,NAT)防火墙后时,通常使用 Simple Traversal of UDP through NATs (STUN)、Traversal Using Relay NAT (TURN) 和 Interactive Connectivity Establishment (ICE) Firewall 遍历机制来创建从 example.com 服务器到客户机的连接。建立了到客户机的连接后,服务器将向客户机发送 INVITE 消息,并向发送该消息的客户机回发一个临时响应 (Trying)。

如果所联系的 user@example.com UAS 正在尝试更改用户,UAS 通常会使用响应代码为 180 的临时响应来响应 INVITE 要求,以指示正在进行此工作。此响应通常会一直回发到发起 SIP 事务的客户机,还可能由 user@ibm.com UAC 用于启动本地回铃 (Ringback)。

当 user@example.com UAS 接受呼叫后,将发送响应代码为 200 的最终响应,以通知 user@ibm.com 呼叫已被接受。此消息将通过初始 INVITE 所经过的每个网络元素。

user@ibm.com UAC 接收到 200 OK 响应后,UAC 会向 user@example.com UAS 发回一个确认信息,以使其知道已接收到 200 响应。如果初始事务流中的代理服务器通过请求将自身添加到了事务中来记录路由,确认信息将通过这些服务器发送。

通过使用 SDP 之类的协议,两个客户机彼此协商了一个成功的会话,以在另一个协议上进行通信。协议会话完成时,用户代理将关闭彼此间的 SIP 会话。UAS 将通过确认信息所经过的相同路由发送一个 BYE 消息,从而发起关闭操作,另一个用户代理将发送一个 200 OK 响应来确认此消息。

SIP Servlet 1.0 (JSR 116) 简介及其与 HTTP Servlet 的比较

SIP Servlet 1.0 规范通过 Java Specification Request (JSR) 116 进行了标准化。该规范的基本思想是,提供一个与 HTTP Servlet 类似的 Java 应用程序编程接口(Application Programming Interface,API),从而提供一个易于使用的 SIP 编程模型。与流行的 HTTP Servlet 编程模型类似,有些灵活性仅限于优化易用性和缩短价值实现时间。

不过,SIP Servlet API 在很多方面都与 HTTP Servlet 不同,因为协议差别很大。虽然 SIP 是请求-响应协议,但每个请求不一定只有一个响应与之对应。这种复杂性以及对高性能解决方案的需求意味着更容易实现 SPI Servlet 本机异步执行。另外,与 HTTP Servlet 不同,SIP Servlet 的编程模型力求能方便地随编写的其他逻辑一起创建客户机请求,因为很多应用程序都会充当其他服务器或代理的客户机或代理。

SIP Servlet

和 HTTP Servlet 不同,每个 SIP Servlet 均对一个 javax.servlet.sip.SipServlet 基类进行扩展。所有消息都通过 service 方法传入,可以对此方法进行扩展。不过,由于 SIP 中没有请求与响应的一对一映射,因此建议对 doRequest 或 doResponse 方法进行扩展。扩展 doRequest 或 doResponse 方法时,务必调用经过扩展的方法,以完成处理。

和 HTTP 一样,每个请求方法(规范必须支持)都有一个 doxxx 方法(图 3)。在 HTTP 中,GET 和 POST 请求具有类似于 doGet 和 doPost 的对应方法。在 SIP 中,每个 SIP 请求方法都具有对应的 doInvite、doAck、doOptions、doBye、doCancel、doRegister、doSubscribe、doNotify、doMessage、doInfo 和 doPrack 方法。

图 3. HttpServlet 和 SipServlet 的比较
图 3. HttpServlet 和 SipServlet 的比较

SIP Servlet 包括 doProvisionalResponse、doSuccessResponse、doRedirectResponse 和 doErrorResponse 响应。具体来说,临时响应(1xx 响应)用于指示状态,成功响应(2xx 响应)用于指示成功完成事务,重定向响应(3xx 响应)用于将客户机重定向到已移动的资源或实体,错误响应(4xx、5xx 和 6xx 响应)用于指示失败或特定错误条件。这些响应消息类型与 HTTP 类似,但由于 SIP Servlet 编程模型包括客户机编程模型,因此有必要也采用编程方式对响应进行处理。

SipServletRequest 和 SipServletResponse 类

SipServletRequest 和 SipServletResponse 类与 HttpServletRequest 和 HttpServletResponse 类相似。每个类都提供了访问 SIP 消息中的 Header 并对其进行操作的功能。由于请求和响应的异步本性,此类还要为请求创建新响应。扩展 doInvite 方法时,只会将 SipServletRequest 类传递给该方法。要将响应发送给客户机,必须对 Request 对象调用 createResponse 方法,以创建响应。例如:

protected void doInvite(SipServletRequest req) throws
 javax.servlet.ServletException, java.io.IOException {
	
	//send back a provisional Trying response
	SipServletResponse resp = req.createResponse(100);
	resp.send();

由于其异步本性,SIP Servlet 可能看起来有些复杂。不过,像前面代码示例一样简单的代码也能向客户机发送响应。

下面是一个更为复杂的 SIP Servlet 示例。通过使用 SIP Servlet 中包括的以下方法,Servlet 将阻止来自 example.com 域之外的所有呼叫。

protected void doInvite(SipServletRequest req) throws
 javax.servlet.ServletException, java.io.IOException {

	//check to make sure that the URI is a SIP URI
	if (req.getFrom().getURI().isSipURI()){
            SipURI uri = (SipURI)req.getFrom().getURI();
            if (!uri.getHost().equals("example.com")) {
               //send forbidden response for calls outside domain
               req.createResponse(SipServletResponse.SC_FORBIDDEN).send();
               return;
            }
         }
         //proxy all other requests on to their original destination
         req.getProxy().proxyTo(req.getRequestURI);
   }

在前面的示例中,将对传入的 INVITE 请求进行检查,以确保这个请求来自 example.com 域。如果不是,将返回一条错误消息,指示禁止此请求。如果请求来自 example.com 域,会通过代理将请求发送到下一个应用程序或主机。

在前面的示例中要认识到的另一个要点是,SIP Servlet 可以选择对请求进行代理转发,而不必进行响应或创建新请求。当尝试在不大幅度改变行为的情况下快速进入消息流时,此选项就非常重要。

SipSession 和 SipApplicationSession 类

SIP Servlet 1.0 规范中最复杂的部分可能是 SipSession 和 SipApplicationSession 类。这两个类都非常有用,可作为存储用于分布式或高可用性环境的应用程序中的数据的主要场所。

SipSession 类是两个实体间具体的点到点通信的最佳代表,与 HttpSession 对象最为接近。由于以前 HTTP Servlet 中并没有针对 HTTP 请求的代理或分叉 (Forking),因此并不存在对超过单个点到点会话的需求。不过,甚至 HTTP 用户都看到了对这种功能的需求的增长,因为 Portlet 已开始对 HTTP 请求进行实际分叉操作了。SIP 用户预计会遇到需要多层 SIP 会话管理的代理和分叉活动。SipSession 类是最低的点到点层。

SipApplicationSession 类表示更高层的 IP 会话管理。一个 SipApplicationSession 类可以有一个或多个 SipSession 对象。不过,每个 SipSession 类仅能与一个 SipSession 对象相关。SipApplicationSession 类还支持附加任意数量的其他协议会话。当前,只有 HTTP 会话受到所有实现的支持。SipApplicationSession 类具有一个 getSessions 方法,该方法以所请求的协议类型作为参数。

您会发现很多应用程序可使用这个类来组合 HTTP 和 SIP。SIP Servlet 1.0 规范的制定者认识到了这种组合的优势。例如,您可以使用这种方法来将 HTTP 和 SIP 会话绑定到一起,以监视电话呼叫或启动富 HTTP 图形用户界面(Graphical User Interface,GUI)。

有关 SIP Servlet 规范的更多内容

SIP Servlet 1.0 规范包含大量内容,根据应用程序开发人员的目标不同,会各有用处。其中一些部分包含了应用程序组合、SipFactory API 和用于在协议处理中处理事件的很多事件侦听器。

应用程序组合是 SIP Servlet 1.0 规范中的一个复杂部分,允许对相同的请求消息运行多个应用程序。和 HTTP Servlet 模型类似,SIP Servlet 包含部署描述符,用于针对要在其中运行 Servlet 的容器定义 Servlet。不过,由于应用程序并不映射到明确的 URI,因此可以对一个请求消息运行多个 Servlet。每个初始消息(容器之前不知道的消息)将根据部署描述符中的规则集进行匹配,并基于这些配置的规则调用应用程序。响应和后续请求将遵循与初始请求相同的路径。

SIP Servlet 规范中另一个有价值的 API 是 SipFactory API,用于从 Servlet 内提供创建更多请求和会话的访问权。此 API 在编写 Back-to-Back User Agent (B2BUA) 之类的功能时非常有用。与转发请求的代理不同,B2BUA 同时充当进一步参与 SIP 事务的用户代理服务器 (UAS) 和用户代理客户机 (UAC)。UAS 部分可以接收和处理请求,而 UAC 则确定如何发起一个或多个关联的出站呼叫。

SipFactory API 还可用于通过另一种类型的服务进行访问时在容器外调用新请求。尽管 SipFactory API 当前有一个限制,即仅能在 ServletContext 对象中使用,但仍然可以使用 SipFactory API 来作为 UAC 执行各种功能,如建立第三方呼叫等。由于 SIP Servlet 容器通常驻留在 Java EE 环境中,因此可以编写使用 SipFactory API 的 Web 服务或企业 Bean 来创建应用程序会话和对其他 SIP 实体的请求。

AIP 的其他部分包括:

  • ServletConfig:容器用于在初始化时将配置信息传递给 Servlet 的机制。

  • ServletContext:用于与容器通信和存储 Servlet 的属性的主要机制。另外,当前访问 SipFactory API 也要通过此机制。

  • SipAddress:来自 SIP From and To Header 的地址。

  • Proxy:尝试查询或更改容器如何对 SIP 请求进行代理操作时非常有用的 API。

SIP Servlet 示例

SendOnServlet 类

此类是一个简单的 SIP Servlet,将对每个 INVITE 执行基本功能,并从该处转发请求。可以在此处方便地插入特定函数,以基于某个特定条件记录此 INVITE 请求或拒绝 INVITE。

package com.example;
import java.io.IOException;
import javax.servlet.sip.*;
import java.servlet.ServletException;
public class SendOnServlet extends SipServlet {
  public void doInvite(SipServletRequest req) 
       throws ServletException, java.io.IOException {
     //send on the request
     req.getProxy().proxyTo(req.getRequestURI);
  }
}

可以对 doInvite 方法进行修改,以进行特定操作,如根据特定标准直接拒绝 INVITE。在下面的示例 doInvite 方法中,example.com 外的域发出的所有请求都将被拒绝,并发出 Forbidden 响应。

public void doInvite(SipServletRequest req)
	throws ServletException, java.io.IOException {
	if (req.getFrom().getURI().isSipURI()){
	   SipURI uri = (SipURI)req.getFrom().getURI();
	   if (!uri.getHost().equals("example.com")) {
		//send forbidden response for calls outside domain
		req.createResponse(SipServletResponse.SC_FORBIDDEN,
			"Calls outside example.com not accepted").send();
		return;
	   }
	}
	//proxy all other requests on to their original destination
	req.getProxy().proxyTo(req.getRequestURI());
   }

SendOnServlet 部署描述符

<sip-app>
    <display-name>Send-on Servlet</display-name>
    <servlet>
        <servlet-name>SendOnServlet</servlet-name>
        <servlet-class>com.example.SendOnServlet</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>SendOnServlet</servlet-name>
        <pattern>
              <equal>
                <var>request.method</var>
                <value>INVITE</value>
              </equal>
        </pattern>
    </servlet-mapping>
</sip-app>

Proxy servlet

此类是一个简单的 SIP Servlet,将执行基本的代理功能,并在初始 INVITE 请求后包含在调用路径中。完成初始 INVITE 后,将针对每个后续 SIP 消息调用此应用程序。对于每个请求和响应,此类将直接打印操作及其发出者或接收者。

package com.example;
import java.io.IOException;
import javax.servlet.sip.*;
import java.servlet.ServletException;
public class ProxyServlet extends SipServlet {
  public void doInvite(SipServletRequest req) 
       throws ServletException, java.io.IOException {
     //get the Proxy
     Proxy p=req.getProxy();
     //turn on supervised mode so that all events come through us
     //The default on this is true but it is set to emphasize the function.
     p.setSupervised(true);     
     //set record route so we see the ACK, BYE, and OK
     p.setRecordRoute(true);
     //proxy on the request
     p.proxyTo(req.getRequestURI());
  }
public void doRequest(SipServletRequest req)
     throws ServletException, java.io.IOException {
   System.out.println(req.getMethod()+ 
	"Request from "+req.getFrom().getDisplayName());
   super.doRequest(req);
}
public void doResponse(SipServletResponse resp)
     throws ServletException, java.io.IOException {
   System.out.println(resp.getReasonPhrase()+ 
	"Response from "+resp.getTo().getDisplayName());
   super.doResponse(resp);
}
}

Proxy 部署描述符

<sip-app>
    <display-name>ProxyServlet</display-name>
    <servlet>
        <servlet-name>ProxyServlet</servlet-name>
        <servlet-class>com.example.ProxyServlet</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>ProxyServlet</servlet-name>
        <pattern>
              <equal>
                <var>request.method</var>
                <value>INVITE</value>
              </equal>
        </pattern>
    </servlet-mapping>
</sip-app>

带 SIP 支持的 WebSphere Application Server V6.1

WebSphere Application Server V6.1 是行业领先的 Java Enterprise Edition (Java EE) 应用服务器,具有在 Java SE 5 上构建的基于标准的开放扩展。这些扩展包括 Portlet (JSR-168)、服务数据对象(Service Data Object,SDO)、JavaServer Faces (JSF)、异步 Bean、缓存支持和很多其他能提供基本 Java EE 环境之外的其他价值的 API。另外,还包含了 IBM 对很多特定规范的行业领先的 Web 服务的支持,如 WS-Security、WS-TX AT、WS-N 和 WS-BA。WebSphere Application Server 还支持 IPv6 和公共标准 (Common Criteria)。

WebSphere Application Server V6.1 将 SIP 功能集成到了基础系统中,从而提供了行业领先的聚合应用程序支持。如前一部分所述,WebSphere Application Server 中的 SIP 应用程序支持是通过 SIP Servlet 1.0 规范的一个实现提供的。在 WebSphere Application Server 中,Web 容器和 SIP 容器合并到了一起,能够共享会话管理、安全机制和其他属性(图 4)。在此模型中,包含 SIP Servlet、HTTP Servlet 和 Portlet 的应用程序可以无缝地进行交互,而不会受到协议的影响。

图 4. 处理 HTTP Servlet、Portlet 和 SIP Servlet 的 WebSphere Application Server 聚合容器
图 4. 处理 HTTP Servlet、Portlet 和 SIP Servlet 的 WebSphere Application Server 聚合容器
图 4. 处理 HTTP Servlet、Portlet 和 SIP Servlet 的 WebSphere Application Server 聚合容器

WebSphere Application Server Network Deployment 所提供的聚合应用程序高可用性通过基础应用服务器中 HTTP 和 SIP 的紧密集成得到了实现。需要在集群应用程序前设置代理服务器,以便管理与容器的 SIP 和 HTTP 通信的流量和工作负载。此代理服务器是无状态 SIP 代理和 HTTP 反向代理的组合,可在必要时使用统一集群框架和 Network Deployment 的高可用性来无缝地监视服务器的运行状况和故障转移工作(图 5)。当没有 HTTP 通信时,代理服务器还可以在应用服务器的 SIP 容器前充当独立无状态 SIP 代理。

图 5. WebSphere Application Server 代理服务器处理 SIP 和 HTTP
图 5. WebSphere Application Server 代理服务器处理 SIP 和 HTTP
图 5. WebSphere Application Server 代理服务器处理 SIP 和 HTTP

有了聚合代理和聚合容器,可通过应用程序关联性实现会话故障转移,从而使得 HTTP 和 SIP 会话能够自动绑定到一起。WebSphere Application Server V6.1 解决方案在聚合环境中略胜一筹的另一个要点就是,可让 SIP 和 HTTP 会话自动从代理的容器绑定到一起。

对于代理服务器中的 SIP 功能,务必了解它是无状态的。SIP RFC 定义了两种类型的代理服务器,有状态代理服务器和无状态代理服务器。通常,SIP 代理是有状态实例,而无状态代理是指定为无状态的代理。有状态代理按照我们在 SIP 概述部分的示例中看到的方式参与呼叫流。可以使用 SIP Servlet 实现有状态代理,如 SIP Servlet 部分中的基本示例中所示。

代理服务器中的无状态 SIP 代理功能允许代理处理复杂性较低的 SIP 容器的工作负载、路由和会话关联性需求。如果是无状态的,可以在代理服务器前放置一个简单 IP Sprayer,如 WebSphere Application Server Network Deployment 中包含的 Load Balancer 组件(图 6)。如果代理服务器失败,关联性是与容器的关联性,而不是与代理本身的关联性,因此关系流中少了一个潜在的故障点。

图 6. 无状态 SIP 代理功能
图 6. 无状态 SIP 代理功能
图 6. 无状态 SIP 代理功能

WebSphere Application Server 开发工具

WebSphere Application Server 包括一个基于 Eclipse 的 Application Server Toolkit (AST),用于满足 Java EE 应用程序的所有基本开发需求。V6.1 版本中的 AST 包含了对开发 SIP Servlet 应用程序的支持。此工具包提供了图形部署描述符编辑器和基本向导,用于帮助您开始编写 SIP Servlet(图 7)。

图 7. AST 6.1 中的 SIP Servlet 开发支持
图 7. AST 6.1 中的 SIP Servlet 开发支持
图 7. AST 6.1 中的 SIP Servlet 开发支持

AST 还包含可在 WebSphere Application Server 部署中良好集成的其他部分,包括 Unit Test Environment(提供用于在产品的开发阶段运行 SIP Servlet 的 WebSphere Application Server Servlet 容器)和用于进行服务器自动化和应用程序打包的其他工具。

结束语

自从 1999 年变成了 IETF 标准以后,会话发起协议 (SIP) 有了很大的发展。最初,SIP 纯粹是针对视频和音频,现在已发展为很多交互服务(特别是对等计算领域)的控制协议。SIP 及 SIP 相关标准提供了基于标准的机制,用于在任何其他协议上的任何网络查找、协商和管理对等连接。

WebSphere Application Server V6.1 通过其基础设施提供了富 SIP 功能。通过使用 V6.1,可以编写利用 SIP Servlet 1.0 规范的应用程序;而引入该规范的目的是为了使用 SIP 和支持以 SIP 为主的应用程序充分利用 Java EE 环境中包含的大量工作成果。

WebSphere Application Server 还提供了开发环境工具和高性能边缘组件,用以处理分布式应用程序环境。WebSphere Application Server 中的 SIP 组件与现有 HTTP Servlet 和 Portlet 工作成果实现了紧密集成,可利用其编写具有代理服务器提供的无缝故障转移功能的高度聚合 HTTP 和 SIP 应用程序。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=160119
ArticleTitle=IBM WebSphere 开发者技术期刊: WebSphere Application Server V6.1 中的会话发起协议——第 1 部分
publish-date=09172006