Web服务项目角色

本文描述的是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 SOA & Web服务专区，您也许会说，这并没有什么特别之处。现在的问题是：项目组如何达到这些目的？

项目阶段和角色
    任何开发项目都要经历不同的阶段，在其生命周期中需要不同的技能和协作。Web服务在这方面也不例外。取决于您的环境中所用的方法，您可能已经遇到过下面列出的一般术语：
l 需求工程
l 业务领域分析
l 解决方案体系结构轮廓
l 概要设计和详细设计
l 面向对象分析与设计（OOAD）
l 各个测试阶段（比如单元测试、集成测试、系
统测试、验收测试）
l 实现
l 维护
l 管理
    有些方面（比如服务建模（例如粗或细粒度接口）、SOAP 引擎（IBM WebSphere SOAP、Apache AXIS 或 Apache SOAP 2.3）的选择和组织互操作性测试）是Web服务需要首先考虑的特定事项。这些问题的性质各不相同，例如，服务建模的先决条件是要有不同的技能与思维方式，而不是互操作性测试。
    角色这个比喻在此上下文中已经证明是非常有用的，它使混乱变得有序。角色与项目阶段有关，它定义了一个将工作描述与执行资源分解开来的抽象层。所有的项目组成员都担当一个或多个角色。角色模型是项目管理和设计方法中的一个普通构造。角色的概念创造了一个容易理解的词汇，它已经证明是项目启动时的一个非常强大的工具。
    因此，现在让我们考察一下Web服务开发项目中这样的一种角色模型。我们将模型中的角色分为三种类别来表示。由于Web服务项目不过是另一种类型的开发项目，所以我们看到此处有很多熟知的角色就不足为怪了。我们为它们定义了一种称为现有角色的类别。然而，有些现有角色承担与Web服务有关的附加职责；我们将这些角色归类在扩展角色之下。最后，还有一些新角色具有与Web服务有关的特别职责，我们将这些角色归类在额外角色之下。
现有角色
让我们从您都已经在项目中看到（或担当过）的四种角色开始：
项目管理员
负责项目组的全面管理与领导。定义并追踪项目计划与工作分解结构。
商业分析员
获取商业用户的功能需求并且给项目组提供相关领域的知识。必须懂得商业语言并且具备相关行业和领域的技能。
架构师
项目的技术主管。开发整个解决方案及其组件的逻辑和物理布局（结构）。
开发人员
又称编码人员。不需要在此处介绍这个角色。
安全专家
负责定义安全指导方针（策略），并且负责实现遵循这些安全指导方针的安全措施。
系统与数据库管理员
执行硬件、操作系统和数据库系统以及中间件的安装和正在进行的维护工作。
请注意，这份清单肯定不是唯一的。我们本可以列出没有 Web 服务的特定方面的所有角色，因为它们都适合于这一类别。然而，我们将清单限制在Web服务项目中出现的最普遍的角色—本文并不是一般的项目方法教程。

扩展角色
五个标准角色接收Web服务项目中附加职责。这些角色以及它们的新职责是：
产品供应商
提供遵守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服务的特定角色。图1展示了这些角色以及它们所执行的任务。
    下页表一显示的是这些角色彼此之间如何进行交互，这些角色执行时需要哪些技能，以及这些执行专业人员可以使用哪些工具：
    关于工具讨论，我们已经假定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 这本书（请参见http://www.ibm.com/developerWorks/cn/webservices/ws-roles/#6），在书中它是作为一个端到端案例研究以及未来引用实现的场景来描述的。如果您愿意，可以把本文看作是该书的一个小小的学习指南—其实践观点（Engag-ement Perspective）的延伸。

结束语
      在所有实际应用程序开发项目中，仅仅有技术是无法成功的。诸如合理的工作分解结构、正确的技能结合以及好的团队合作这样的一些条件都是成功的关键，在很多时候它们比起技术解决方案的因素来甚至显得更为关键。由于Web服务是一种相当新的技术，所以在这个领域缺乏有记录的经验可资借鉴。有一些 Web 服务的特定角色和其他众所周知来自标准开发项目的角色承担了附加的职责。
    可以需要使用某些附加的技能和许多合适的工具来协助您。要协调考虑角色到资源的分派；要权衡高度专业化与相关通信开销之间的利弊。在任何情况下，“单独行动”的方法对于重要项目无疑都是不起任何作用的，一般项目管理技术都要应用到Web服务项目中，就跟应用到任何其他的项目中一样。
    作为IBM服务组织的成员，在最近这两年里，我们有机会全面参与了大量Web服务项目。我们希望能够通过这篇小文章来与您分享我们在这些项目中的亲身体验。