Web 服务项目角色

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Olaf Zimmermann (ozimmer@de.ibm.com), 顾问 IT 架构师, IBM Applied Web Services
Frank Mueller (mueller.frank@de.ibm.com), IT 专家, IBM Global Services AMS

2004 年 1 月 01 日

本文描述的是 Web 服务开发项目中所涉及到的各种不同的工作角色，包括各自的目标，任务以及彼此之间是如何协作的。本文并没有详细讨论所执行的实际任务(比如从 WSDL 创建文档/文字样式的服务)；相反，我们试图给具有任何背景的 IT 人员提供全面的指导，让他们了解在着手准备 Web 服务项目时应该如何思考。目的就是要帮助 IT 部门理解如何更好地组织自己的项目并制订出项目的整个蓝图。

Web 服务经历了只有少数爱好者使用的时代,当时他们使用的是并不成熟但却受到高度赞扬的技术,他们努力去实现一切 —— 甚至是简单且不安全的基本数据结构的交换。而在最近两年，这项技术在大量实际项目中证明了自身的成熟。因此，许多技术主管现在都认为，Web 服务是企业应用程序与软件集成工具箱的另一个强大的组成部分，可以用在此领域以后的大项目中。这样，当 Web 服务的使用扩展到您所在组织的“普通”企业应用程序项目中时，您也许会发现自己已经成为 Web 服务项目组中的一员了，即便您从来就没有将自己当作上面提到的爱好者。如此说来，现在，您将扮演的是什么角色呢？让我们来看一看哪些是可行的！

阅读的理由

有很多理由让您觉得应该考虑阅读这篇文章：如果您是一名项目经理、首席架构师或组织内的另一名技术主管，您可以获得一些建议来指导您如何构造您的第一个 Web 服务项目以及为项目配备人员。我们汇集的角色与职责可以用于您的工作分解结构（work breakdown structure）。如果您是一名刚接触 Web 服务的开发人员，您就可以了解到存在哪些任务和工具 —— 并且应该在您的简历中添加哪些重要的词，以使您的名字能够出现在与您关系密切的下一个 Web 服务项目的项目计划书中。

请注意，这不是一篇普通的关于小组开发的文章，我们的重点在于 Web 服务的特定方面；例如，您在通常的 J2EE 项目中找不到的角色、以及分派给一个或多个角色的专业人员的工具和信息源。

您或许不明白为什么我们决定写这样的一篇文章，乍看起来似乎有点枯燥。说实在的，我们也同意应用技术来解决真正的业务问题对于任何项目来说都是很有意思的。然而，好的结构和方法是成功的关键，不成功的项目是决不会有乐趣的，即便它采用的是世界上最热门的技术。因此，请相信我们，您为此付出努力是值得的！

回页首

概述：Web 服务简介

Web 服务解决方案和面向服务体系结构（SOA）包括服务请求者（客户端）和服务提供者（服务器）的实现，它们通过 SOAP（XML 消息传递）来通信。Web 服务描述语言（WSDL）服务描述提供请求者和提供者之间的联系。可选的服务代理（例如统一描述、发现和集成（Univesal Description, Discovery and Integration，UDDI）注册中心也可能是需要的。服务描述和交互必须进行建模，XML Schema 也是如此。此外，还必须设计、开发、部署和测试实现。到目前为止，一切都还不错；如果您以前访问过 developerWorks Web 服务专区，您也许会说，这并没有什么特别之处呀。现在的问题是：项目组如何达到这些目的呢？

回页首

项目阶段和角色

任何开发项目都要经历不同的阶段，在其生命周期中需要不同的技能和协作。Web 服务在这方面也不例外。取决于您的环境中所用的方法，您可能已经遇到过下面列出的一般术语：

• 需求工程
• 业务领域分析
• 解决方案体系结构轮廓
• 概要设计和详细设计
• 面向对象分析与设计（OOAD）
• 各个测试阶段（比如单元测试、集成测试、系统测试、验收测试）
• 实现
• 维护
• 管理

有些方面（比如服务建模（例如粗或细粒度接口）、SOAP 引擎（IBM WebSphere SOAP、Apache Axis 或 Apache SOAP 2.3）的选择和组织互操作性测试）是 Web 服务需要首先考虑的特定事项。这些问题的性质各不相同，例如，服务建模的先决条件是要有不同的技能与思维方式，而不是互操作性测试。

　 角色这个比喻在此上下文中已经证明是非常有用的，它使混乱变得有序。角色与项目阶段有关，它定义了一个将工作描述与执行资源分解开来的抽象层。所有的项目组成员都担当一个或多个角色。 角色模型是项目管理和设计方法中的一个普通构造。角色的概念创造了一个容易理解的词汇，它已经证明是项目启动时的一个非常强大的工具。

因此，现在让我们考察一下 Web 服务开发项目中这样的一种角色模型。我们将模型中的角色分为三种类别来表示。由于 Web 服务项目不过是另一种类型的开发项目，所以我们看到此处有很多熟知的角色就不足为怪了。我们为它们定义了一种称为 现有角色的类别。然而，有些现有角色承担与 Web 服务有关的附加职责；我们将这些角色归类在 扩展角色之下。最后，还有一些新角色具有与 Web 服务有关的特别职责，我们将这些角色归类在 额外角色之下。

现有角色

项目管理员

负责项目组的全面管理与领导。定义并追踪项目计划与工作分解结构。

商业分析员

获取商业用户的功能需求并且给项目组提供相关领域的知识。必须懂得商业语言并且具备相关行业和领域的技能。

架构师

项目的技术主管。开发整个解决方案及其组件的逻辑和物理布局（结构）。

开发人员

又称编码人员。不需要在此处介绍这个角色。

安全专家

负责定义安全指导方针（策略），并且负责实现遵循这些安全指导方针的安全措施。

系统与数据库管理员

执行硬件、操作系统和数据库系统以及中间件的安装和正在进行的维护工作。

请注意，这份清单肯定不是惟一的。我们本可以列出没有 Web 服务的特定方面的所有角色，因为它们都适合于这一类别。然而，我们将清单限制在 Web 服务项目中出现的最普遍的角色 —— 本文并不是一般的项目方法教程。

扩展角色

五个标准角色接收 Web 服务项目中附加职责。这些角色以及它们的新职责是：

需要这么多人吗? 请注意，任何真实的人都可以戴几顶帽子。换句话说，单个执行资源可以扮演所列出的多个角色。例如，IT 架构师可能还同时负责服务建模。在工作分解结构抽象定义之后，将角色映射到人就是项目经理的主要任务。 显然，让个人戴几顶帽子是可行的，对于组内的高级执行人员尤其有效。我们真诚希望您能够获得至少一个或两个这样知识渊博的人的协助。

产品供应商

提供遵守 WS-I 的 Web 服务运行时容器以及可选的服务注册中心和 SOAP 网关服务。

部署人员

获取开发构件并把它们安装在目标运行时环境中。从 WSDL 中生成目标环境的存根（stub）和骨架（skeleton）并把它们与服务实现一起安装。通过 Web 服务的特定部署描述符来提供 JAX-RPC 映射和处理程序配置。

测试人员

负责各类标准测试阶段，比如单元测试、集成测试、加载测试和验收测试。此外，还定义 Web 服务互操作性测试与一致性测试的测试用例。

开发人员

设计并实现项目的特定脚本，生成器以及其他实用程序。Web 服务领域中的标准等级使得有可能开发诸如理解　 WSDL、JAX-RPC 或 JSR-109 这样的自定义工具。

知识转移服务商

提供接触相关主题的专家和技术指导的机会，他们会带来 Web 服务概念和实现资源方面的广博知识。

额外角色

最后，到了定义您可以在 Web 服务项目中看到的额外角色的时候了：

SOA 架构师

负责端到端的服务请求者和提供者设计。负责询问和表述非功能服务请求。

服务建模人员

应用数据与功能建模技术来定义服务接口契约，包括所交换消息的 Schema。

流程流设计人员

研究显式的、声明性的服务编排（聚合、组合）功能。这是一个可选的角色。

服务开发人员

熟悉 Web 服务概念和 XML 的 J2EE 开发人员。开发服务接口、实现（提供者端）和服务调用代码（请求者端）。

互操作性测试人员

验证开发的请求者和提供者实现是否可以无缝地进行互操作，并且确保遵循 Web 服务互操作性（WS-I）。

UDDI 管理员

定义一般的 UDDI 数据模型是如何定制和植入的。这是一个可选角色。

请注意，我们划分扩展角色与额外角色在某种程度上是任意的。扩展角色与附加角色都来源于现有角色（例如，SOA 架构师和服务开发人员）。然而，我们相信对于额外角色，介绍新名称是合理的。从现在开始，我们将只集中于额外角色。

回页首

Web 服务的特定角色

现在，让我们更深入地研究 Web 服务的特定角色。下图展示了这些角色以及它们所执行的任务：

下表显示的是这些角色彼此之间如何进行交互，这些角色执行时需要哪些技能，以及这些执行专业人员可以使用哪些工具：

角色和技能 识别角色是有帮助的，但是最关键的是找到具备适当技能的合适人员。不要低估这项工作的重要性。从技术上讲，Web 服务通常是轻量级且相当简单的；这是它们强大的一个方面。采用 Web 服务，孤立的异类系统之间的协作就必以前容易得多。然而，随着这些新的机会的出现，也会带来一些以往没有出现过的错误。Web 服务项目对于您的组织来说或许是一种 新的项目，但是很有可能它们将不是一种 更简单的项目。 您建立的项目组应该通过适当的技能水平来反映这一点。建议您召集具备在不同平台上工作的经验的专业人员。这对于您的 SOA 架构师来说尤为重要。如果您的组内没有这样的人选，您可以找一些辅助（业余）的副架构师来填补这个空缺，这样做也是可行的。

关于工具讨论，我们已经假定 J2EE 是所选择的服务实现平台。如果涉及到诸如 Microsoft .NET 这样的平台，就必须在图中添加其他的技能和工具等等。此外，到目前为止，我们都一直在故意不提及产品的名称；您可以想象得到，Web 服务的一整套工具与运行时支持都可以从 IBM 以及开发源码社团获得。请查阅 Eclipse 和 Apache Web 服务开放源码项目，不要忘记研究 IBM WebSphere Studio Application Developer 产品和 alphaWorks 上的技术评论（请参阅 参考资料）。

回页首

人员到角色的分派

每个角色都负责整个项目的一个不同方面。前面我们说过，一个人通常可以戴几顶帽子，换句话说，担当多个角色。如果各种具备渊博知识和多方面技能的人在一起工作，就会减少项目的风险。在有些情况下，只有这样的各种人开展有目的的合作才会揭示项目至关紧要的问题并且提出合理的解决方案。在另一方面，通信开销会随着每个新组员的加入而增加。没有单一且简单的答案来解决角色到人员映射的难题。关于应该如何着手处理这个问题存在许多不同的意见和争论（甚至本文的两位作者也没有达成一致的意见！）。

我们不继续这些争论，现在让我们来看一个小例子。考虑下面的场景：我们虚构一家来自保险业的公司，这家公司决定构建一组新的 mid-office 业务应用程序来用于风险和策略管理，这不可避免地涉及两种不同的后端系统。两种后端系统都已经作为 J2EE 应用程序构建好了 —— 一个使用 EJB ，另一个只使用 Servlet、JSP 和 JDBC 来连接到它的客户和契约数据库。

在已启动的开发项目的初始阶段，会将上面定义的角色分派到组员。除了 Web 服务的特定活动之外，还要确定和分派标准的项目任务和角色。下表列出的是这项工作分解训练的结果：

您可以看到，除了项目管理员和商业分析员以外，所有其他的组员都戴了多顶帽子。而且根本没有分派属于额外角色的流程流建模人员，因为在这个场景中它是不需要的。

同时需要注意的是，这个例子是相当简单的；在实际项目中，需要有更大的项目组。根据我们成功的经验，在核心组的大小最好为 7 到 10 个的范围内。这完全取决于您所处的场景；为了避免您的工作分解结构由于过于复杂而变得难以处理，您可以将项目分解成几个阶段。换句话说，要确保项目按计划循序渐进地进行。这可以让项目组成员有机会学习这项工作并减少项目风险。在灵活的开发领域，这种原则称为 连续 集成 （continuous integration）。

我们不再进一步在这里详述这个虚构的保险例子了。其实，它来自 Perspectives on Web Services 这本书（请参见 参考资料），在书中它是作为一个端到端案例研究以及未来引用实现的场景来描述的。如果您愿意，可以把本文看作是该书的一个小小的学习指南 —— 其实践观点（Engagement Perspective）的延伸。

回页首

结束语

在所有实际应用程序开发项目中，仅仅有技术是无法成功的。诸如合理的工作分解结构、正确的技能结合以及好的团队合作这样的一些软事实都是成功的关键，在很多时候它们比起技术解决方案的因素来甚至显得更为关键。由于 Web 服务是一种相当新的技术，所以在这个领域缺乏有记录的经验可资借鉴。有一些 Web 服务的特定角色和其他众所周知来自标准开发项目的角色承担了附加的职责。

可以需要使用某些附加的技能和许多合适的工具来协助您。要协调考虑角色到资源的分派；要权衡高度专业化与相关通信开销之间的利弊。在任何情况下，“单独行动”的方法对于重要项目无疑都是不起任何作用的，一般项目管理技术都要应用到 Web 服务项目中，就跟应用到任何其他的项目中一样。

作为 IBM 服务组织的成员，在最近这两年里，我们有机会全面参与了大量 Web 服务项目。我们希望能够通过这篇小文章来与您分享我们在这些项目中的亲身体验。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 查阅 Eclipse 和 Apache Web 服务开放源码项目。
  
  
  
  
• 研究 IBM WebSphere Studio Application Developer 产品和 alphaWorks 上的技术评论。
  
  
  
  
• 查阅 Perspectives on Web Services 中的体系结构与实践透视。这是支持该书的 网站。
  
  
  
  
• Java Community Process 规范 JSR-109 定义了它自己的一组角色和职责。
  
  
  
  
• 同时参阅诸如 eXtreme Programming（XP）和 Rational Unified Process 这样的一些方法。
  
  
  
  
• Web 服务互操作性组织 （Web Services Interoperability Organization，WSI）制订了它自己的基本概要（Basic Profile）（可以在 这里找到）。
  
  
  
  
• 在 Death March （Prentice Hall 1997，ISBN 0-13-014659-5），Edward Yourdon 教您如何发现和避免注定会失败的项目。
  
  
  
  
• 如果您想了解一些成功的例子，可以在 IBM jStart 网站找到成百上千。
  
  
  
  
• Web 服务最佳实践的讨论（比如由 Kyle Brown 和 Rachel Reinitz以及 Mark Colan 参与的）也涉及到了角色和职责。
  
  
  

作者简介

		Olaf Zimmermann 是 IBM worldwide Applied Web Services 组的顾问 IT 构架师。他在分布式计算和面向服务体系结构领域一般都颇有专长，而在 Web 服务/XML 和 Java 2 企业版（J2EE）方面的造诣尤深。在过去的几年里，Olaf 指导了大量与 Web 服务有关的交流项目，包括几本产品参考书。他是 Springer 教科书 Perspectives on Web Services （ISBN 3-540-00914-0）的作者。他还参与了几本 IBM ITSO 红皮书（比如 Web Services Wizardry with WebSphere Studio Application Developer （SG24-6292-00））的写作。Olaf 从 1994 年开始就与 IBM 合作，涉及的领域非常广泛，其中包括产品开发、技术预售咨询、教学以及系统集成。Olaf 在位于德国 Braunschweig 的 Technical University 获得计算机科学学位。

		Frank Mueller 是 IBM Global Services AMS Solution Delivery Organization 的 IT 专家兼 IT 构架师。Frank 具有面向对象和 XML 的背景，在过去两年里，他主要研究用于 IBM 关键帐户的电子商务集成项目，重点是工业和金融部门。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首