关于工具讨论，我们已经假定 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 服务项目。我们希望能够通过这篇小文章来与您分享我们在这些项目中的亲身体验。