SIP Modeling Toolkit for IBM® Rational® Software Architect 是对 Rational Software Architect 平台的一组领域扩展。该工具包提供您所必需的工具，从而以自然的方式利用 Rational Software Architect 平台设计并开发针对 Session Initiation Protocol（SIP）的专门领域的技术。本文还说明了您如何能够将 Rational Software Architect 平台和 Domain Specific Language（DSL）元素集成，从而形成单个开发环境。该工具包扩展包含统一建模语言（UML）概要文件、参考模型、自定义用户接口元素、转换和转换扩展。 介绍Session Initiation Protocol（SIP） 是用于在 Internet 上连接一个或多个多媒体参与者（用户代理）的 Internet Engineering Task Force（IETF）规范（RFC3261）。用户代理一般是电话（POTS、移动电话、软件电话、IP-PBX 设备，等等），但可以是任意的允许 SIP 的设备。 该协议负责创建、修改，和终止会话，但实际上与转换媒体交换没有联系。一旦设备被连接了（换句话说，它们直接在彼此之间交换媒介流），就不再涉及 SIP 服务了。然而，SIP 服务提供的价值超过连接两个代理。举例来说，当建立或拆开连接时，SIP 服务还可以实现调用的阻塞或转发，以及带有对策和事务部门系统的界面。 SIP Modeling Toolkit for IBM® Rational® Software Architect（参见参考资源）向 Rational Software Architect 提供的 UML 建模和开发平台添加 SIP 专用的扩展。这些扩展包括专门领域的概要文件、参考模型、转换和其他下一代通信服务的建模和模型驱动开发（model-driven development，MDD）的应用。该工具包还向 Rational Software Architect 中的，更新服务实现的 SIP 专用工件的现有的 UML 到 Java ™ 的转换提供代码生成扩展。 因此，该工具包将瞄准 SIP servlet 的代码生成的设计层模型的创建变得更容易。它通过提供获取 servlet 模型中的 SIP 专用的信息（例如 P-Header 信息等等）的领域相关的参考模型，以及原型化的元素和属性来做到这点。该工具包使用那些模型、元素和属性来生成代码转换。 像 SIP servlet 那样，利用 SIP Modeling Toolkit，可以在 IBM® WebSphere® Application Server 产品上创建并部署 SIP 和汇集的 SIP-HTTP 服务。还可以定制该工具包，用于在其他的 SIP 应用服务器平台上部署。用 Java™ Servlets 对 SIP 服务的实现是由 Java™ Community Process JSR 116 指定的。WebSphere Application Server Version 6.1 及更高的版本提供对 JSR 116 的本地支持。本文介绍了该工具包，并且概括了其关键的特性。 工具包功能SIP Modeling Toolkit 解决了 SIP 服务建模的三个关键领域：
该工具包不会为基于 SIP 的服务的开发预先假设任何具体的方法。使用调用流建模或 servlet 建模是可选的，然而，可以将它们一起成功使用，它们之间不存在依赖性。另一方面，模型到代码的转换依赖于 servlet 模型和相关扩展的正确使用。 SIP Design Model 模板SIP 设计模型要求，UML 模型拥有 SIP 参考类型和 SIP 概要文件。SIP Modeling Toolkit 安装了可以应用于任意现有的 UML 模型的新的参考模型和概要文件。或者为了简化事情，该工具包包括用于利用已经应用的参考模型和概要文件创建新的模型文件的模型模板。SIP 参考模型包括设计模型中所使用的大部分 SIP 类型（从 JSR116 到 WebSphere Application Server 扩展），以及用于调用流图中的预构建的 SIP 消息。SIP 概要文件包括用于调用流建模的 servlet 和 UML 协作的原型。当您创建新的 UML 模型时，SIP Design Model 模板就在模板列表中，如图 1 所示。 图 1. SIP Design Model 模板
调用流建模在用户代理和 SIP 服务之间沟通具体的活动场景的最普遍的方法之一是利用调用流图。这些图多半是 UML 序列图，如图 2 所示。SIP
User Agent（UA）一般用对能察觉 SIP 的服务的 
参与者之间交换的大部分信息是标题内容。SIP Modeling Toolkit 提供了专门的用户界面（user interface，UI）来获取该额外的信息（参见图 3）。用户界面定制使得从其他消息中复制标题，以及重新组织标题的顺序变得容易。一个按钮将根据消息体中指定的实际内容创建或更新内容长度标题。 图 3. 调用流消息细节
调用流表示非常具体的场景，因此最简单的调用流不包含分支或循环。然而，因为 Rational Software Architect 中的调用流建模是基于 UML 序列图的，所以您可以利用 UML 序列图绘制的全部特性来绘制带有循环、分支，和选择部分的精细的调用流。 生成 servlet 或测试代码 在工具包的当前版本中，不能自动地将这些调用流图直接翻译为实现模型或代码。为了以一般的方式，令这件事成为可行的，需要考虑太多的设计决策（这些决策通常都是局部决定的）。然而，因为调用流是在 UML 模型中获得的，创建您自己的，使用此调用流信息来生成 servlet 或测试代码的模型到模型或模型到代码的转换是可能的。 虽然没有现成的自动化方法可用，但是您可以很容易地在 SIP 服务的实现和它支持的调用流之间建立可溯性。举例来说，«trace» 关系可以绘制于调用流生命线（调用流中的个别参与者）和正在实现的 servlet 之间。图 4 显示了 Call Blocked 场景，它是 Rational Software Architect 中作为技术示例的 Call Blocking 示例应用程序的简单调用流。 Call Blocked 和 Call Connected 场景只获得了每个场景的重要消息。没必要为每种可能的细节建模：根据定义，模型只需要获取重要且有关的信息。 图 4 中所示的调用流的余下部分遵照了标准的调用连接流，因此没有全面地完成。 图 4. 调用阻塞实例（阻塞的调用）的调用流图
建模的最重要的用途之一是在工件和设计元素之间建立可溯性。在最简单的情况下，这件事情可以在简单的设计模型中，通过在正在实现的 servlet 类和它们实现的调用流之间绘制 «trace» 关系来完成。 在图 5 中，显示出 Call Blocking 示例的实现，具体的参与者角色和正在实现的类之间有 «trace» 关系。不仅 «siplet» （实现 SIP 服务的主 SIP servlet）可追溯到两个调用流，其他架构上重要的元素，像访问控制列表，也可以追溯到调用流中的参与者。 图 5. 调用流可溯性
这些追溯关系是重要的，这不是因为它们在自动化和模式中的潜在用途，而是因为它们是需求、实现，和测试之间的可溯性链中的重要链接。这些在模型中建立的链接使得在不依赖于命名和编码规范的情况下，对于系统的分析和理解更加容易。当建议对系统进行将来的变更时，您可以在影响分析中导航并研究这些链接。 Servlet 建模当您实现 SIP 服务时，您通常从一组可能包含高层次文本文档和抽象的调用流实例的需求开始。设计过程通过向调用流中的标题内容中添加更多细节（适合在测试中直接使用），并且将外部的 API 和本地的框架类并入设计模型，来部分地精炼这些工件。一些开发团队可能决定使用 UML 状态机作为一种机制，结合调用流，并且增加具体服务的设计细节。 图 6 展示了结合了 Call Blocking 的两个主要场景的简单状态机。UML 为设计人员提供了许多建模工具，以精心设计服务的行为（状态机、活动、协作等等）。 图 6. 调用阻塞状态机
SIP 服务的运行时组件（根据 JSR116 规范实现的）只需要一个 Java 类来继承 SipServlet 框架类，并且包含一些在 Web 项目的 sip.xml 和 web.xml 部署描述符中的元素。通过使用 Siplet（SIP servlet）或 ConvergedServlet 的工具选项板项，以及在模型中创建新的原型化的类，来从头在模型中创建 servlet。表 1 列出了类原型。选项板包括针对 SIP 概要文件中三个主要原型的工具。 UML 模型元素的原型能使您将附加的语义关联到已知的模型元素上。它还允许您定义在模型中获取的，并且在自动的转换过程中使用的额外的属性。 表 1. SIP Modeling Toolkit 中的类原型
当您使用选项板创建新的 Siplet 或 servlet 时，还要确保新的类继承来自 SIP 参考模型中的适当的超类（参见图 7）。如果您不使用选项板，那么您仍旧可以将原型应用于类，并且您有机会继承不同的框架类或接口。 图 7. 设计模型中的新 servlet
服务的实现，如一组调用流图所描述的，在设计模型中从继承正确框架类的单个原型化的类开始。其方法接收 SIP 客户端的请求，并且负责与代理通讯，从而与一个或多个其他设备建立会话。 Siplet 存在于更大的设计中，包括许多用于服务的实现中的其他类和库 API。对于所有但平凡的 SIP 服务来说，其实现存在于更大的应用程序中，并且将与后端进程、数据库、企业 bean 和其它服务通讯，如图 8 所示。 图 8. SIP 服务设计模型的结构化的部分
使用原型的主要原因是确定特殊的类，作为 SIP 服务行为的主要实现。这些类需要附加的元信息来向 Web 服务应用程序服务器“注册”。这些附加的信息是与原型相关联的，并且以特殊视图的形式呈现于开发人员面前（如图 9 所示）。该视图是标准的 Properties 视图部分中的新的选项卡。 在 Siplet 的情况下，该信息包括定义了情况的模式或过滤器标准，在这些情况下，该 Siplet 应该由容器激活。模式是翻译为 XML 片段，并且直接用于 sip.xml 部署描述符（如 JSR116 中所指定的）中的简单树结构。 图 9. Siplet 属性视图
视图余下的部分提供了方便的方法来添加公共 SIP servlet 方法的方法覆盖。Load On Startup 属性是标准的 web.xml 部署描述符字段。它指出一种相对重要的方法，该 servlet 应该在服务器启动过程中被激活。通过在视图中选择复选框来创建公共的方法覆盖。 当设计模型接近完成时，是时候将设计转换为 Java 代码和部署描述符了。SIP Modeling Toolkit 包含对现有的 UML 到 Java 的转换（Java 1.4 和 Java5）的转换扩展。因此，您可以以同样的方式，使用生成一般的 Java 代码的同一个转换来生成 SIP 和 HTTP Servlet 的代码和扩展。您不需要做任何不同的事情来生成所需的 SIP 内容。 抽取现有的 SIP 部署信息对于现有的 SIP 应用程序，将现有的 sip.xml 和 web.xml 部署描述符信息转换为 SIP Design Model 是可能的。您可以通过创建新的转换配置来做到这点，类似于为 UML 到 Java 过程创建的方法。这个 SIP Modeling Toolkit 提供的新类型的转换配置称为 SIP to UML Transformation，如图 10 所示。 图 10. 创建新的逆转换
该转换唯一的参数是 Web 项目和目标模型。调用该转换将通过创建 SIP servlet、HTTP servlet 或 Converged servlet 类，以及更新来自部署描述符的 SIP 专用的属性，来更新模型。该转换只更新部署描述符内容。它不更新类的属性、方法，或关联。对于 Java 内容的余下部分，您可以通过利用由 Rational Software Architect 现成提供的现有的 Java 到 UML 的转换来完成这些活动。 设计活动概要整个的设计工作开始于分析人员的输入，通常是以调用流图的形式，这些图可以是序列图的。一些设计人员可能想要将这些结合到 UML 状态机或 UML 活动中，作为固定所有场景的意外行为的方法。状态机或活动会表示为（当作为 SIP 服务实现时）支持所有的调用流的单个行为组件。这也是在预期的场景中辨别歧义和冲突的很好的分析机制。 服务解决方案的设计开始于在 UML 模型中创建 «Siplet» 原型化的类。该类将直接映射到主 SipServlet 实现类。设计人员通过定制的 Properties 视图设置 SIP 领域专用的信息，并且通过添加附加的类、到 Web 服务的链接、数据库、企业 bean 等等来继续设计。如前面所提到的，在实际开发中，设计和实现 SIP 服务的大部分工作发生在您用这些类和技术创建业务逻辑的时候。 参考资料学习
|
Siplet
HttpServlet
ConvergedServlet