【IT168 技术文章】

    您刚好接触到SOA。现在，所有需要您完成的就是构建系统。这很容易，对吧？

    恭喜您！项目架构师刚刚交给您——企业开发人员——新的面向服务的架构（SOA），以供系统实现业务实践。现在，您只需构建系统即可。

    当然，SOA方法在设计和组织业务功能以及IT基础架构方面较好。SOA模型有助于确保系统的灵活性、可重用性和互操作性，使现在和将来进行管理和修改更容易。它也能节约成本。它只是可能不像光芒四射的新SOA一样容易实现。

    考虑一个类似的例子——建造一所房子。设计者可能非常优秀，但是那并不意味着他们设计的房子是可以信赖的。担任建筑师的一位朋友讲述了他的第一项任务的故事：落实一个公司的新办公室计划，它占用了一座巨大办公楼的整个一层。新的入口处看起来富丽堂皇——直到我的朋友意识到前任建筑师忽略了一根承重柱子，这根承重柱子直接矗立在地板中央。现在他有三个选择：切段柱子，大楼也就破坏了；逐渐习惯于有一根柱子立在地板中央破坏美观；或者更改计划以反映现实。

    开始之前

    设计一个系统的架构也与此相同。如果在别人将SOA交给您的时候您才第一次了解SOA，那么您可能从一开始就遇到了麻烦。开发人员必须从业务流程的开端就参与业务流程的设计。对于保证真实性是SOA的一部分，开发人员的看法是非常宝贵的。这个看法来自技术、将来的发展以及特别的考虑等通用领域。

    例如，在技术方面，开发人员与架构师的看法可能会不同。当然，在我们的房子上面搭上凉棚很好，但是我们将怎样拉回屋顶呢？与此类似，写下过程A将与过程B进行通信是容易的。但是，实际上，要使过程A与过程B通信良好可能需要能够获奖的——而且费用最大的——编程技巧。

    灵活性也是SOA的目标之一，但是它可能会走得太远。认为家庭办公室有一天会被用作卧室——但是或许不是用作厨房——可能是聪明的想法。同样，比如说，要求某种服务来处理所有的输入可能没有意义。调整SOA，反映出什么是难以做到的以及什么是很可能做到的，就能够确保得到一种较好的结果。

    开发人员不只是在规划过程中令人扫兴的人。他们往往了解不久后将成为可能并且会在SOA里出现的技术。在建造一所房子时，您可以预期某一天完成地下室，并且包括简单的基础结构。同样，一家公司现在可能不提供无线服务，但是开发人员可以将它作为未来的可能性，这很可能带来全新的业务面貌——以及SOA的重要部分。

    另外，开发人员可能知道SOA必须处理的特殊问题。例如，采用在Web上分布的组件服务模型时，通信的安全性可能比现有的内部应用需要更多的关注。

    最后，在设计期间的信息流不应该仅仅是单向的。开发人员应该从架构师那里获悉业务的结构——以及未来的方向。在以后的开发过程里，了解并且保持这个观点对于指导决策将是至关重要的。

    为开始做好准备

    在开始开发过程之前，您需要从SOA的角度考虑技能、标准和工具等的特殊方面。这一部分是一种新SOA思维倾向。例如，既然整个服务思想是创造多个可重用组件，开发人员就必须超越一个应用程序的界限进行思考。您必须开始重用现有的服务，并且想像您的同事如何重用您的服务。打破旧的习惯，并且通过将服务链接在一起而不是通过编写新代码来构建应用程序，这可能是困难的。正确的态度将走向成功。

    开发人员应该拥有面向服务的开发的正确技能。在业务流程、数据和元数据管理、消息传递和事务，以及安全性等方面，可能需要一些训练。因为这应该是一个迅速的过程，在必要时，您希望人们已经为开始做好了准备。

    将您的开发过程流线化。从一开始就使应用程序的生命周期标准化——包括交付阶段——能够缓解以后的麻烦。

    早早建立您的标准。这些标准可能是结构化信息标准促进组织（OASIS）的接口标准（比如WSDL）、协议标准（比如SOAP）、传输标准（例如HTTP和JMS），等等。要注意这些标准可能在现有的基础设施和环境中遇到问题。

    您可能需要面向Web服务的工具和一个SOA。不仅要考虑开发的特征，而且要考虑在企业内与其他成员通信的特征。如果您的可视化界面能够将您的工作表达为非技术类型，那么您就可以节省很多工作量。您的工具应该能够处理细节，例如元数据库、XML索引和规则引擎。