内容


使用 SIP 和异步 Web 服务开发下一代聚合应用程序

Comments

简介

随着即时通讯、Internet Protocol (IP) 电话技术、IP 视频等技术的发展,新一轮应用浪潮正在出现,这些应用结合了多种基于 IP 的技术。为支持 Session Initiation Protocol (SIP) 和 IP Multimedia System (IMS) 等技术,电信服务提供商(ISP)需要在新的 IMS 网络和旧系统(比如 Transaction Capabilities Application Part (TCAP) 和 Signaling System #7 (SS7) 网络)之间建立连接并交换信息。为此,人们正在开发新的 SIP 和 Web 服务聚合应用程序,用于以异步方式连接这两种网络。

在本文中,我们将通过一个 TCAP 应用程序来讨论开发生产就绪的应用程序时获得的一些最佳实践和经验教训。本文的讨论主要围绕以下几点:

  1. 在 TSP 网络中使用同步或异步 Web 服务各有哪些优点和缺点?
  2. 如何通过 SIP 和 Web 服务开发下一代聚合应用程序?
  3. 如何在聚合应用程序中同步 SIP 和 HTTP servlet?
  4. 与远程终端通信时,应该考虑使用 HTTP Keepalive 实现最佳性能?
  5. 如何在性能负载和网络可靠性测试期间开发和调试应用程序?在 TSP 网络中部署电信运营商级(telecommunications carrier-grade)应用程序时需要执行上述测试。

服务提供者网络中的同步和异步 Web 服务之比较

开发聚合应用程序时,应用程序可以同步或异步处理 Web 服务调用的响应消息。

但是,事情并非如此简单。差别存在于两个级别。应用程序级别的消息传递可以同步也可以异步,此时,应用程序代码要么等待响应消息,要么立即返回控制权,稍后在收到响应时通过一个回调通知应用程序。

通信级别的消息传递也可以是同步或异步的,此时,容器要么等待 “线路” 上的低级响应,要么在响应最终通过一个不同的线程到达 “线路” 上时继续处理响应。

这样就有 4 种可能配置:

  • 同步应用程序,同步通信
  • 同步应用程序,异步通信
  • 异步应用程序,同步通信
  • 异步应用程序,异步通信

通信级消息传递响应

开发聚合应用程序时,容器处理通信级消息传递响应的处理。默认行为是同步处理这些响应,以便容器等待响应消息,不在那个线程中继续处理。

要实现异步通信,必须将客户端请求上下文环境上 com.ibm.websphere.webservices.use.async.mep 属性设置为布尔值 true。这个属性启用后,为消息提供额外路由信息的 WS-Addressing 头部被添加到请求和响应消息中。这些消息将在被收到时由容器中的一个不同线程处理。这样,当前线程被释放,可以处理其他作业,而不必等待响应消息。

同步 Web 服务应用程序消息传递

使用同步 Web 服务应用程序消息传递,应用程序代码在等待接收响应消息时阻塞。这种机制有几个优点和缺点。

优点:

  • 由于消息在行内处理,不必维护上下文,因此代码更简单。
  • 由于所有消息都在代码内顺序处理,回调没有必要打断应用程序流,因此竞争条件(race condition)更少。
  • 由于所有消息都按顺序处理,应用程序流不会被回调和中断分离,因此更容易调试。

缺点:

  • 保持调用挂起可能会导致收费问题,因为当应用程序受阻塞、等待响应消息时,不能处理入站调用挂起。等待响应的时间越长,客户多花费的费用越多。
  • 更少的调用量需要更多资源,因为应用程序的同步行为必须等待每条消息。

虽然比较简单,但同步方法并不够健壮,不能满足 TSP 网络中的应用程序的要求。

异步 Web 服务应用程序消息传递

开发异步 Web 服务时,有两种处理响应的方法:轮询回调

在 TSP 网络中,重要的是 Web 服务请求的响应在被容器收到后被立即处理。因此,本文将主要关注如何使用回调方法。回调方法将句柄返回应用程序,这样,应用程序能继续处理其他消息,不必轮询响应消息。回调方法比轮询方法更及时,能确保响应被及时处理。由于响应可用性和轮询周期,轮询方法可能有延迟。

下面的代码展示了回调处理程序的使用方法。当容器从此前发送的请求接收到一条 Web 服务响应时,即调用这个回调处理程序。

清单 1. 定义异步回调处理程序类的样例代码
// Define the async callback handler
ServiceCallbackHandler asyncHandler = new ServiceCallbackHandler(param1,param2);
// Start the callback handler 
Future<?> response = AsyncResponseMessage(message, asyncHandler);

// Define the class for the callback handler
public class ServiceCallbackHandler implements AsyncHandler<SendResponse> {	
// Define parameters that can be passed to the callback handler
private int param1 = 0;
private SipApplicationSession param2 = null;		
// Define the callback handler method
	public ServiceCallbackHandler(int param1, SipApplicationSession param2) {
			param1 = dialogId;
			param2 = appSession;
	}

	public void handleResponse(
		Response<SendResponse> response) {
		// Business Login Added Here	
	}
}

回调方法的主要优点如下:

  • 立即处理响应,无需等待。
  • 应用程序能继续处理更多并发流量,因为资源没有被绑定为等待响应。
  • 应用程序没有因等待响应而受到阻塞。这允许应用程序及时处理 SIP 调用(比如挂起)并生成正确的收费记录

这些优点在服务提供者环境中非常重要,因为客户的付费依据是调用的时长,可能还包括额外的资源和服务。另外,尽快处理调用对于提高客户满意度也很重要。

回调方法的缺点如下:

  • 在错误的情况下,如果响应丢失,资源可能一直挂起。
  • 代码可能更加复杂。需要关联各个会话,以确保响应消息关联到正确的调用。
  • 需要更多错误处理和清理代码。
  • Future 对象不可序列化,这意味着,在高度可用的环境中,回调处理程序返回的句柄不能被复制。这意味着,故障转移发生时,不能取消未完成的回调。

这些缺点加大了开发难度,但总的来说,缺点还是小于优点。

使用 SIP 和 Web 服务开发下一代聚合应用程序

新型电信应用程序需要同时访问旧网络和下一代网络。为此,可以开发一种聚合应用程序,使用 SIP 协议与下一代网络通信,使用 HTTP 访问旧协议。在本文中,我们将使用一个样例 TCAP 应用程序来对此进行演示。我们的应用程序拥有一个 SIP 接口,提供到 IMS 网络的连通性;还拥有一个 HTTP 接口,通过 Web 服务与 TCAP 通信。我们的下一代应用程序通过 WebSphere Application Server Network Deployment 托管,利用 WebSphere 的基本功能。

在我们的示例中,当应用程序服务器收到一个新 SIP 调用时,应用程序被触发。然后,应用程序通过一个 TCAP Web 服务接口发起一个 TCAP 事务。

鉴于本文的目的,我们使用一个简单的调用流(如图 1 所示)来模拟一个简单的 TCAP 游戏提示(play prompt)应用程序。此图表已经过简化,移除了任何 Session Description Protocol (SDP) 和 ISDN 头部处理、中介媒体服务器 SIP 消息传递、以及模拟 TCAP 交换的其他部分(比如模拟其他 Begin 消息)可能需要的消息传递。

图 1. 样例 SIP/TCAP 调用流
样例 SIP/TCAP 调用流
样例 SIP/TCAP 调用流

下一代 SIP 和 TCAP 聚合应用程序样例概述

此应用程序由三个主要的交互组成:

  1. 处理入站 SIP 会话。
  2. 发出 TCAP 请求事件:
    1. 发送一个出站 TCAP Web 服务请求
    2. 处理入站 TCAP Web 服务响应
  3. 接收 TCAP 指示事件:
    1. 处理入站 TCAP Web 服务请求
    2. 发送出站 TCAP Web 服务响应

我们假定您熟悉标准 JSR 116 SIP servlet 开发技术。最好还熟悉 描述 TCAP 协议的 JSR 11 TCAP 规范。这两个 JSR 都可以在 Java Community Process 网站 上找到。

这个聚合应用程序由两个主要部分组成。第一部分是一个 SIP servlet,处理入站和出站 SIP 消息。作为那些 SIP 消息的结果,SIP servlet 发起一个出站 Web 服务请求(在本例中,聚合应用程序充当一个 Web 服务客户机)。第二部分是一个 HTTP servlet,处理任何入站 Web 服务调用(在本例中,聚合应用程序充当一个 Web 服务服务器)。这两个组成部分共享一个公共数据结构,称为应用程序数据

开发 SIP servlet

SIP servlet 使用标准的 JSR 116 SIP servlet 编程技术开发。要了解更多关于如何开发 SIP servlet 的信息,请参阅以下 developerWorks 文章:WebSphere Application Server V6.1 中的会话发起协议,第 1 部分第 2 部分

init() 函数是一个标准 JSR 116 init() 函数。入站和出站 SIP 消息传递的核心处理在标准 JSR 116 doInvite() 处理块中实现。在本文中,我们不描述实际的 SIP servlet 编程,而是聚焦于发送和接收 TCAP Web 服务的那些特殊方面。

初始步骤是处理 SIP INVITE 消息并使用一个 200 OK 进行响应。下一步是使用关联对话框和组件参数生成一个 TCAP BEGIN 消息。您应该通过使用 TCAP setters 和 getters(比如 setQualityOfService())渐进式地构建一个请求对象,编写 TCAP 代码的核心应用程序部分。

还有一些参数需要针对每个调用单独设置,比如 dialogID。为此,我们创建了一个名为 getNewDialogueId() 的实用工具方法,为这个特定 TCAP 会话生成一个唯一 dialogID。应用程序程序员负责编写为每个调用实际生成唯一 ID 的实现代码。生成的 dialogID 存储在 applicationData 对象中,如下所示: applicationData.setDialogId(utils.getNewDialogId(applicationData));

下一步是生成一个已编码的 URI,稍后当应用程序处理从 TCAP 接口发来的 Web 服务请求时,这个 URI 将用于会话相关性。为此,首先检索 IBMApplicationSession,然后调用 encodeURI(),如清单 2 所示。借助会话相关性,预定前往某个应用程序会话的消息总是被路由到集群中的同一个会话。

清单 2. 生成一个将用于会话相关性的已编码 URI 的样例代码
IBMApplicationSession ibmSess = (IBMApplicationSession) appSession;

// Get my HTTP endpont
InetAddress in = InetAddress.getLocalHost();
appEncodedUri =
  ibmSess.encodeURI("http://"+in.getHostAddress()+":9080/tcap/AttTCAPHttpApp");

在集群环境中部署应用程序时,应用程序应该使用前置应用程序服务器集群的代理的 IP 地址,而不是主机地址(in.getHostAddress())。另外,如果系统配置了一个启用了 MAC 转发的前端负载平衡器,应用程序需要使用环回地址,别名化(aliasing)负载平衡器的虚拟 IP 地址,生成已编码的 URI。这在故障转移情况下尤其重要:WebSphere 使用已编码 URI 中的应用程序会话 ID 将请求路由到已失败的应用程序服务器的副本服务器。

发送出站请求

现在,我们可以发送一个请求了,比如 TCAP Begin 请求。为此,我们调用 sendWS() 方法,该方法用于设置一个 Web 服务请求并将其发送到 TCAP 接口。这种方法屏蔽创建一个异步请求所需的大部分编码。它使用 JAX-WS 通过 HTTP 分发异步 SOAP 请求,同时还设置异步 callbackHandler 来处理响应,如 异步 Web 服务应用程序消息传递 所述。TCAP 应用程序开发人员需要定义一个 callbackHandler 来正确处理来自 TCAP 接口的异步 Web 服务响应消息。

我们使用此前生成的已编码 URI 来设置这个特殊请求的应用程序会话相关性,如清单 3 所示。

清单 3. 设置 TCAP 请求消息中的已编码 URI 的样例代码
// Set the encoded URI in the request message for the specific app session
componentAndDialogRequest.setEncodedURI(applicationData.getAppEncodedUri());

sendBegin() 返回后,我们通过在 applicationData 对象上设置状态来捕获 TCAP 应用程序的当前状态,上述对象将保存在应用程序会话上下文中,以备故障转移,如清单 4 所示。

清单 4. 设置当前调用的状态
// Begin was sent, set the state appropriately
applicationData.setState(Constants.BeginSentState);

然后我们将此状态保存到应用程序会话,如清单 5 所示。

清单 5. 调整当前调用的属性的样例代码
// Save the application data in the application session
appSession.setAttribute(Constants.APP_DATA, applicationData);

最后,我们启动了一个计时器处理程序(如清单 6 所示)来处理以下场景:Web 服务客户机回调处理程序一直没有被调用,这将导致一个超时。这个处理程序负责处理超时情况并使用正确的后续 TCAP 消息传递处理它,如果必要,终止调用。

清单 6. 调用一个计时器来跟踪当前调用的状态的样例代码
// Start first timer to track the WS response from the TCAP Interface
timerService.createTimer(appSession, 
applicationData.getWSBeginSentWaitingForResponseTimer(), true,
	Constants.WSBeginSentWaitingForResponseTimer);

处理异步响应消息

当容器收到此前发送的请求的响应时,调用已定义的回调方法。客户机上的响应消息在回调处理程序中接受处理,方法是在 ServiceCallbackHandler 类中实现方法 handleResponse(),如 异步 Web 服务应用程序消息传递 所述。

这个处理程序被调用后,它首先需要获取当前应用程序上下文。这需要用到此前在请求中使用的 dialogID,如清单 7 所示。

清单 7. 检索与一个回调关联的调用会话的样例代码
// Retrieve the unique dialog ID from the callback message
dialogID = Integer.toString(response.get().getDialogId());

// Retrieve the correct application session from the context memory
appSession = (SipApplicationSession) sContext.getAttribute(dialogID);
applicationData = (SampleApplicationData) appSession.getAttribute(Constants.APP_DATA);

这个处理程序还包含任何必要的处理来终止 SIP 会话,例如,如果从 TCAP 接口收到一个 ABORT 消息的话。这种处理完全基于此前在调用中设置的当前调用状态。

开发 HTTP servlet

如前所述,此应用程序还通过实现一个 HTTP servlet 来充当一个 Web 服务服务器。这样,当 TCAP 接口从 TCAP 对等机接收消息时,它立即发送一个新的 Web 服务请求到包含提示事件的应用程序。

处理入站 Web 服务请求

当 TCAP 接口接收到入站请求(H1)时,它通过请求中使用的 encodedURI 发送一个调用到正确的应用程序会话。为此,TCAP 接口使用此前在调用场景(WS1)中接收的 encodedURI 并将出站请求的端点设置为那个值。

要处理这条信息,需要通过扩展 javax.servlet.http.HttpServlet 类来创建 HTTP servlet,如下所示: public class SampleTCAPHttpApp extends javax.servlet.http.HttpServlet

与 JSR 116 SIP servlet 编程模型类似,HTTP servlet 也提供一些标准函数,比如 init()doGet()doPost() 等。在本例中,我们将首先使用 init() 函数,因为该函数中有一些所有会话都需要的参数。

首先,我们需要创建一个新的 messageFactory 和一个 JAXB 上下文,用于处理 SOAP 请求。实际上,这个样例应用程序中 将使用两个不同的 JAXB 上下文。第一个用于读取 XML 配置文件;第二个用于打印解组 SOAP 请求后收到的对象。

清单 8. 新建一个用于处理 SOAP 消息的 JAXB 上下文的样例代码
msgFactory = MessageFactory.newInstance();
jbc = JAXBContext.newInstance(new Class[] { 
org.xmlsoap.schemas.soap.envelope.ObjectFactory.class,
listener.jain.protocol.ss7.tcap.ObjectFactory.class });
jbcpo = JAXBContext.newInstance("listener.jain.protocol.ss7.tcap");

下面,我们需要检查 doGet() 处理。这个函数在收到来自 TCAP 接口的入站 Web 服务请求时被调用。我们需要执行的第一项操作是获取应用程序会话上下文,然后获取我们在出站请求阶段创建的 applicationData,如清单 9 所示。

清单 9. 检索与一个 HTTP/SOAP 消息关联的调用会话的样例代码
// Retrieve the SipApplication session to get context.
HttpSession httpSession=request.getSession();
IBMSession extSession = (IBMSession)httpSession;
IBMApplicationSession ibmAppSession = extSession.getIBMApplicationSession();
SipApplicationSession appSession = (SipApplicationSession)ibmAppSession ;
SampleApplicationData applicationData = 
	(SampleApplicationData) appSession.getAttribute(Constants.APP_DATA);

注意:借助 JSR289,不再需要使用这些专有接口来访问应用程序会话。

现在,我们可以将请求传递到 processReceivedMessage 方法,该方法解析并打印消息,如清单 10 所示。

清单 10. 将一条 SOAP 消息转换为一个 Java 对象的样例代码
// Process received message (parse message, print it and change app state) 
componentAndDialogRequest = processReceivedMessage(request, headers, 
	applicationData, appSession);

此时,SOAP 请求已经被转换为一个 Java™ 对象,可以使用各种 getters 和 setters 来访问数据。从 doGet() 退出时,堆栈将自动发送一个 HTTP 200 OK 响应,完成该 HTTP 对话。

现在,我们已经处理了消息并发送了响应,但您可能想在这个阶段实现其他应用程序特有逻辑。

在聚合应用程序中同步 SIP 和 HTTP servlet

典型的下一代聚合应用程序通过前端中的 SIP 消息与 IMS 设备接口,通过后端中的 SOAP 消息中嵌入的 TCAP 组件与 SS7 网络资源通信,如图 2 所示。SIP 客户机发起的 IMS 调用通常在下一代应用程序和 TCAP 堆栈接口之间触发一系列异步 TCAP 事件。例如,下一代应用程序发送一个包含一条 BEGIN TCAP 消息的 Web 服务调用后,TCAP 接口可能会返回一个异步回调事件到应用程序,说明 BEGIN 消息在 SS7 网络上处理后的结果。另外,TCAP 接口还可能发起一些 Web 服务调用(比如 TCAP 消息)并将其返回应用程序。应用程序必须基于上面描述的 SIP 和 TCAP 事件跟踪和管理每个调用的状态,并确保如果发生异常(比如 CALLBACK 没有在时间限制内到达),将采取适当的操作来终止调用,优雅地释放网络资源。

图 2. 同时与 IMS 设备和旧 SS7 网络资源接口的典型的下一代聚合应用程序
典型的下一代聚合应用程序
典型的下一代聚合应用程序

图 3 展示了如何在我们的环境中实现一个典型的高级流,包括发起一个 SIP 会话,以及多个 Web 服务请求和响应。

图 3. 样例应用程序的状态机概览
样例应用程序的状态机概览
样例应用程序的状态机概览

这里,聚合应用程序跟踪和管理每个会话,将其作为一个状态机。S3 事件(即来自客户机的 ACK 消息)触发应用程序发送 WS1(即第一个 Web 服务请求事件)。如果到 WS1 的回调没有及时收到,聚合应用程序将重新发送 WS1,最多发送三次;否则,它将发送一个 ABORT 到 TCAP 接口并终止与客户机的调用。如果收到的回调表明处理 WS1 消息时出错,聚合应用程序也可能终止调用。否则,应用程序检查入站异步 Web 服务请求(H1 消息)是否在预期的时间内到达。如果没有,应用程序也可能发送一个 ABORT 并终止调用。否则,它可能会跟随一个响应到 H1,以及第二个出站 Web 服务请求(WS2),后者的处理方式与 WS1 相同。聚合应用程序和 TCAP 接口之间的这种交互可能重复很多次,直到客户机(通过 SIP BYE 消息)结束调用,或 SS7 网络通过(TCAP END 消息)与调用断开连接。

要确保上述状态机正常工作,重要的是聚合应用程序同步聚合 容器中部署的 SIP 和 HTTP servlet。这是因为 SIP servlet 的实例和处理相同调用的 HTTP servlet 通常在不同的线程上运行。如果允许这两个 servlet 读取和更新同一个状态机而无需同步,状态机逻辑可能不会工作。下面我们看看如何在我们的环境中解决这个问题。

  • 只有 SIP servlet 处理 SIP 事件和 Web 服务回调
  • 只有 SIP servlet 能发送出站 Web 服务消息
  • HTTP servlet 处理入站 Web 服务请求,但不能直接访问关联状态机。相反,它从 Context Memory 获取到 SIP servlet 的句柄。它更新状态或触发对一个状态机的动作的唯一方法是通过此句柄调用 SIP servlet 例程。如果 SIP 容器线程上发生其他事情,可能会遇到竞争条件。
  • HTTP servlet 调用的这些 SIP servlet 例程通过 SIP servlet 本身同步。
  • 应用程序使用应用程序的 SIP servlet 组件中的 SipAppliationSession 的计时器。这意味着 HTTP servlet 不能直接访问或控制超时事件,但可以通过 SIP servlet 句柄这样做。
  • SIP servlet 确保新的超时事件不能针对相同的调用启动,除非没有其他超时事件在等待或直到排队超时被取消。

使用 HTTP Keepalive 实现更好性能

HTTP 协议拥有一个简单的请求-响应范式。当客户机决定与服务器通信时,它会打开一个 TCP 连接,发送一条 HTTP 请求消息到服务器。然后,服务器通过相同的连接,使用一条 HTTP 响应消息响应客户机。TCP 套接字连接关闭时,事务结束。对于客户机和服务器之间的每个 HTTP 请求/响应,这个场景都会重复。这种途径速度慢,效率不高,且会导致大量性能问题。

HTTP Keepalive 通过大幅减少建立和终止 TCP 连接的相关开销来解决这个性能问题。它允许客户机通过相同的 TCP 连接发送几个请求,而无需重置连接。这通过在 HTTP 请求/响应消息中发送额外的头部信息来完成。

对于我们的样例应用程序,我们在 TCAP 接口中实现 HTTP Keepalive 来大幅提高性能。Keepalive 在 WebSphere 中默认开启。

在性能和网络可靠性测试过程中调试应用程序

在 TSP 网络中开发和部署电信运营商级系统有一些特殊的可用性、稳定性和健壮性要求。其中,系统和应用程序必须遵守 “五九”(five-nine)要求,高度可用,没有一个失败点。

要在 TSP 网络中全面部署这种应用程序类型,需要在系统上执行一种称为网络可靠性 的特殊测试类型。这涉及在高负荷下测试应用程序并模拟各种失败情况。应用程序必须能够正确处理失败,同时记录有用的失败信息。另外,应用程序必须在固定负载下从失败中全面恢复。

在满负荷下执行广泛的负载测试,验证一段时间内没有系统和性能降低也很重要。这要求执行 72 小时或更长时间的负载测试。

这种测试方法使得诊断最终调试错误情况非常困难,在这样高的调用量下,最终调试错误情况可能很难再现或发生。启用跟踪会导致不良后果,且在高调用量下也不是十分有效。

下面有一些调试技巧:

  1. 保持日志简洁,从而使要记录的信息量最少。
  2. 记录关于错误场景的消息数据。错误发生时,确保记录了足够多的数据。一个非常好的做法是在循环缓冲器中维护最近几条消息的历史记录,当错误情况出现时,可以转储循环缓冲器。值得重点注意的是,因某个错误而失败的调用可能并不是该错误的原因,错误的原因可能已经在更早以前发生。内存中存储的数据可能包括某条消息在其消息流期间记录的所有日志事件。这不仅允许您查看失败消息的消息流,还可以查看失败消息之前的那些消息流。
  3. 清理错误情况。确保在错误发生时进行清理。清理可能包括终止会话、取消计时器、取消回调处理程序或清理可能需要的任何数据结构。
  4. 很容易忘记计时器需要清除。如果您使用计时器跟踪事件,以确保消息及时到达,重要的是要在收到消息后取消这些计时器。
  5. 将会话信息传递到异步回调处理程序。这允许您访问某个失败情况下应该被记录的额外信息。
  6. 启动 HTTP 和 SIP servlet 时,注意初始化公共应用程序数据并在 Init 函数中启动计时器,因为 SIP 或 HTTP 都有可能首先初始化。
  7. 在聚合应用程序中同步 SIP 和 HTTP servlet 所述,必须注意确保 SIP 和 HTTP servlet 正确同步。

调试可能需要使用网络包嗅探器这样的工具来捕获网络包。然后可以分析这些包,查看消息流,最重要的是,了解消息在组件之间传递需要多长时间。这种分析还可以揭示,花费太长时间来处理消息的组件是否有问题。

调试最困难的部分是跟踪信息通过系统,因为消息在不同的组件中可能拥有不同的 ID,这些 ID 需要关联起来。这又将我们带回这个点:保持日志简洁,记录足够信息以跟踪调用通过系统。

注意:新的 WebSphere Application Server V7 Feature Pack for Communications Enabled Applications (CEA) 拥有许多帮助简化开发聚合应用程序的新特性。其中一个特性称为聚合 Web 服务通知,支持出站和入站请求的 Web 服务相关性。这个特性能降低我们的应用程序的复杂性, 因为我们不再需要创建双向 Web 服务。

结束语

在本文中,您了解到如何使用 WebSphere Application Server 提供的工具来创建和调试同时支持 SIP 和 Web 服务的聚合应用程序。这种聚合应用程序支持使用基于 IP 的网络新技术来连接旧的网络技术。您还了解到您的选择取决于应用程序的要求(包括同步或异步 Web 服务),以及使用 HTTP Keepalive 来提高性能的好处。借鉴来自我们的 TCAP 应用程序的经验教训,您应该能够构建您的应用程序并做出明智的设计决策。

致谢

本文作者感谢 Brian Pulito、Nitzan Nissim 和 Tom Thacher 对本文所做的宝贵的审阅、评论和贡献。我们还要感谢 Can P. Boyacigiller 和 Sreenivasa Pamidala 对本文描述的总体概念的贡献。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, SOA and web services
ArticleID=776928
ArticleTitle=使用 SIP 和异步 Web 服务开发下一代聚合应用程序
publish-date=10272011