本文描述的是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服务有关的特别职责，我们将这些角色归类在额外角色之下。[本文共有 3 页，当前是第 1 页] <<上一页 下一页>>
|
|
|
|
|
|
|
您的位置：
