项目架构师刚刚把新的面向服务的架构（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索引和规则引擎。
烦恼的时刻
即使有了正确的培训、态度、标准和工具，SOA开发也可能是困难的，这不足为奇。大多数业务流程基于实际的程序，这些程序复杂并且要求多个异步步骤。例如，一个简单的采购订单，可能涉及几天的复杂工作流，并且要求几个负责人签署意见。您将面对无意义的副本，乱七八糟的数据，以及缺少集成。虽然您一次只能开发一种服务，但是您必须专注于整个系统：保持灵活性是困难的。即使您从实现一些高使用率的服务开始，您也必须知道它们将如何与其他服务交互。您一层一层地进行开发——核心应用程序基础、公用服务层以及定制门户层——但是您必须知道所作的更改是否真的没有干扰其他层。
牢牢记住SOA的目标是重要的：灵活性、可重用性和互操作性。的确，对于给定的服务，有时看起来您只能挑选其中两个，或者可能只能挑选其中一个。但是那些是目标。事实上，有时精练而灵活的组件的想法似乎自相矛盾。假如它是精练的，它又怎能灵活地完成全部的工作？假如它足够灵活，能够处理所有事务，难道它会不复杂吗？难道它会是精练的吗？是的，要达到那个美妙的结合点，需要一些折衷。服务必须可供多个应用程序使用，因此，必须正确地开发。此外，我们需要维护并增强服务，因此，它们必须简单。
这是不是听起来全部不可能？不是的。它只需要一个更大的视角。考虑一下房子的例子。您能仅仅挂起那扇门而完全不考虑到其他任何事情吗？不，因为假如门不在这个位置，这里将开一扇窗。假如门在这里，它会影响墙里的布线。假如门在那里，它就影响了另一扇门的设置。您将找到合适的位置，但不是仅仅专注于那扇门：您必须查看它四周的一切。利用SOA进行开发的情况也是一样的。
为目前的需求进行开发是艰难的；为将来的需求进行开发则是一项更大的挑战。除了观察其他所有组件以外，您还需要留心观察将来的可能性。假如您的服务是考虑到将来的需求而创建的，那么它们就可能用于将来的应用程序。这里有一个技巧：假如服务完全与当今业务实践相匹配，那么它可能不支持对业务实践的更改。假如服务接收特定的输入，就使输入通用化。假如该服务处理五个进程，那就让它处理十个进程。假如它将结果传输给另一个服务，那么使另一个服务是可以选择的。您需要的不是一套扳钳，而是一把月牙扳钳。
将来会出问题吗？试着想像从现在起三年后，您正在将这种服务转换到一个新职能。您希望它如何简化您的工作？请记住，该代码直接将转换重用于为企业提高劳动生产率和节约成本，并且为您节省了开发时间。
节拍在继续
尽管最初几个服务不是流程的结束，但是它在不断进行的过程中是一个有价值的里程碑。在执行了这些最初的组件之后，您应该能够判定它们是否达到了您的目标。其他服务能否轻易地使用这些服务？假如能的话，那很好。假如地板不是水平的，那么现在就弄平，然后在上面进行建造。
在这个过程中，开发人员在某处发现意外的困难不足为奇。例如，因为种种原因，事实可能证实两个业务流程终究不能使用同一个组件。在开发过程中，您应该有一种适当的机制，与架构师交流需要进行哪些更改。SOA不是青铜铸成的：它是某台机器上的一些小东西，正如您所使用的其他一切事务一样。从假定更改是必不可少的开始，构建您需要加入任何所需更改的触点。
您如何发出某些任务不能执行的调用？在不可能与“我们不能完成”之间有很大的差别。假如您陷入了这样的困境，不要不战而降。首先，进行一些研究。在讨论区中询问如何处理这样的情况。假如有人已经解决了您需要执行的任务，那就表明您可能能够完成它。即使他们的情况只是有点类似于您的情况，您也可以在这个有价值的问题上获得一个看问题的角度。
假如那样不能产生一个答案，那就回去找架构师协商。向架构师解释困难。SOA可能需要修改。但是也可能是架构师们对此有设想，而您没有。请记住他们是解决方案的一部分：假如他们有解决方案，那就使用它。
因为这是一个企业开发项目，因此，让企业知道情况将如何发展是很重要的。您应该经常报告成果。解释已完成的每个服务的意义，展示它在整个开发中所处的位置。当整个应用程序完成时，证实它们的商业价值。您应该使用一种方法来衡量投资收益：让每个人都了解它。
这不仅对于企业来说是重要的，而且对于开发人员来说也是重要的。所有为脑海中的大图——以及未来——所作的非凡的编码工作都将获得补偿。并且企业会承认这种工作的价值。现在该是举行庆功宴的时候了。
SOA的未来
在2002年，Gartner Group称SOA为“现代应用程序开发过程中惟一非常重要的主题”。执行SOA方法能够帮助您更迅速地完成项目，并且更快地兑现投资收益率。不过，它仍是一种新方法，并非每个人都是这方面的专家。随着时间的流逝，您和您的同事将能更熟练地实现面向服务的架构。您可以利用更多、更好的工具。那时将出现改进的策略，并且成为标准问题的标准解决方案。在正确的计划和观点指导下，您精心打造的服务将能够在许多年内不断运作、发展和改善。
