方法8：前端系统应用使用分析

　　要想快速识别服务，一个较为实用的方法就是绘制信息功能需求图表。这种方法会选取一套应用支持重要业务流程。我们可以通过将前端应用系统使用的查询和交易做成的表格，监督后端系统应用提供的功能。这些功能被聚集在一起，冗余性得到了消除，最佳化步骤与可比功能结合在一起，构成了一个单一的服务。

　　其中最大的好处就是，可以很快识别服务。在一定程度上，应用提供了业务功能模型和服务的视图，这个视图在即时可重用性，群集和最佳化步骤中效果十分明显。但是这个方法还是有一个负面作用，就是这种方法的使用环境缺乏可以使用的流程或者功能模型。

　　但是，在考虑到种种情况之后，问题守恒定律又一次发生作用了。设计较差的应用会和现有的业务流程实施紧耦合在一起，这样在设计质量服务时，就会产生许多问题。通常我们都希望这个质量服务以后还可以重用。如果你对现有的应用设计信心十足，可以考虑这个方法。

　　方法9：基础设施

　　平台独立性一直被认为是服务的结构原则，但是，复合服务需要人们给予更多的关注。这个方法不能保证服务是和使用中的技术基础设施是相独立的关系。

　　如果服务是由两个以功效为核心的服务，（例如主机和一个Unix机器）所组成的，将会是多么方便呢？（这两个服务运行于不同的平台）想一想所需的连通性、执行和潜在的交易重算、以及可行性变体、安全性和监测、网络信息流通量等。

　　尽管可以依靠技术解决所有这些问题（使用现代中间件），成本效益分析则表明，还需要一个可替代方案。非功能性要求同时也在分析中起到了一定的作用。

　　在谈到这个方法的优越性时，我们可以简要的将其概括为：只有在迫不得已的情况下，才可以使用这个方法。服务定向的核心理念就是隐藏并抽取基础应用环境（尤其是其支持基础设施层！）

　　方法10：非功能要求

　　该方法将非功能要求作为识别服务的最初输入。它本身并不是一个“方法”，更多的像是一套作用于其它方法之上的技术。

　　依靠其他的服务识别方法，可以初步验证一套服务。未来服务供应商能够核实未来服务客户非功能性要求的可行性。如果其中一个或者多个非功能性要求被看做是不可行的，但是仍然比识别方法的设计原则更为重要，服务就需要被重新设计。

　　有两个普遍的非功能性要求在这里扮演着十分重要的角色，它们是安全性和性能。试考虑以下这个例子：发布服务X，同时希望从应用A和B中获取功能性。如果应用A满足强加在服务X以及应用B上的安全性要求，但是应用B却无法满足这个要求，最好将服务X划分为安全服务或者是不安全服务。

　　换句话说，如果一个机构选择通过Web服务实施SOA，一些服务就无法交付要求的性能。这里有以下几种选择方式:

　　记住，如果出于性能考虑，需要重新设计大批服务，必须进行进一步的分析，以便知晓目前的IT架构是否大体上适合SOA（而不仅仅是IT前景的当前部分）。

　　利用服务模式语言评估方法

　　不管你使用哪种方法识别及定义服务，你必须了解服务设计背后的基础理论，以便支持服务定向。

　　基本服务设计模式语言[REF-4]为服务的识别定义以及设计提供了7个基本设计模式，该设计模式构成了基础服务模式语言。这个模式语言可以被看做是在创建服务过程中帮助解决重大问题的原始流程。

　　你可以回顾一下前文提到的10种方法，当然，每种方法都有各自的优先主次，以及取舍选择，这样会影响到既定服务设计所受到的支持度，但是如果理解了基本设计模式语言，可以帮助你更好的对这些方法做出评价，例如这些方法可以在何种限度上支持服务对象。

　　一般陷阱

　　·由于人们一直在追求物有所值的事物，所以实现良好服务的道路并不是一帆风顺的，这一路上潜藏了很多陷阱。以下是几个和服务识别有关的典型实例：

　　·从字面上来看SOA，—在很多IT环境中，“SOA”和“服务”的使用都非常宽松。项目小组喜欢称其为“服务定向”，只是因为这种叫法显得更为前卫，抑或是因为人群之间流传着一种普遍定位误解，他们认为单独凭借Web服务就可以构成一个SOA。不管是出于哪种原因，如果要利用这些措施实施“服务”，似乎是程序设计师在掌控局势。他们创建了过剩的Web服务，却没有考虑到业务/IT-对齐，可重用性或者其它一个服务所应该具备的特性。结果就变成了Web服务本身并不是以服务为导向的。最终，这个陷阱会令所有人都大失所望，人们并没有获得理想状态下SOA的收益。完美虚幻服务—另一方面还有一个问题，所有的设计师和分析师都模拟那些在现实中无法利用现代科技创建的虚幻服务-或者-需要付出昂贵代价才能够实现的完美服务。如果能够客观的实施建模措施就可以避免上述问题。

　　·服务兼容性是一大难题——同一家机构的不同项目小组，进行的是不同的服务定义采用的是截然不同的交付方法（例如，完全相反的自上而下以及自下而上策略），他们所创建的服务也可能互不相容。所有的这一切会形成一个自然栈，当需要进行跨栈通信时，必须采取集成化措施。

　　·巴别塔服务——如果一个机构没有规范数据模型（对于服务语义的定义也是模糊的），服务自然而然不兼容。结果环境就要依赖许多年以后才会诞生的转换和桥接技术。这样对服务定向的许多方面起到抑制作用。

　　·意大利面服务—如果服务是以不同的颗粒度层面定义的，这样就会令技术术语和业务术语混合在一起，服务本身是非直觉性的，非常令人困惑，有些时候根本无法使用。

　　以下是一些避免这些陷阱的简单原则：

　　·遵守服务定向原则。创建能够支持SOA战略目标，定义明确的服务。

　　·当涉及到服务识别和定义方法时，通过学习文章所提及的方法，了解你的选择。

　　·通过将提议的服务设计流程映射到基础服务设计模式语言中，衡量服务识别方法的效能。

　　结论

　　我们强烈推荐使用已被证实的方法处理创建精良服务的有关问题。你可以充分利用在流程中获取的原有经验。但是没有哪一种方法是完美的，每一种方法都有各自的好坏。最好从自己的兴趣出发，选取经过证实的方法，然后考虑如何将其最佳化，以便满足各自SOA的具体要求。