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