SOA基本概念已经得到了广泛的宣传，也被众多厂商和用户所接受。SOA作为一种新的软件开发范型，通过松耦合方式更好的实现了软件资产的复用，因而可以很方便地构建业务敏捷的应用系统，以应对不断变化的市场环境和用户需求。下面我们就从一些SOA的案例中寻找实施SOA的途径。

    从Comcast公司到美国联合航空，这些大公司不分行业都已经开始纷纷投入到SOA领域之中，他们改变其组织计划、开发和部署企业应用软件以进一步的实现这一领先的IT技术架构理念。

    SOA在最初发展的时候，目的仅仅只是为了使应用功能可以被作为共享服务来使用，这一点牵引着这个领先的IT架构理念一步一步走到现在。不过，企业从最初开始得SOA道路到现在，都还在建立属于自己的架构体系。相比之下，不同的是在过去几年中，业务方面的需求更好的体现了这一IT技术的战略价值，而IT方面也更多的了解了业务方面需要承受多大的竞争压力。如此一来，SOA就能够提供IT与业务前所未有紧密结合的可能。

    业务需要的是一组服务：能够重组，得出新业务流程以支持新的产品或服务组件。而SOA的职责所在就是发布这些服务，提供连贯一致的框架，使服务组件能够得到治理并重组为应用。虽然许多SOA的举措仍停留在早期阶段，它对增加业务反应度的承诺还是真是可靠的。我们看到越来越多的企业正推进更为高级的部署。以下案例研究则是最好的证明。

    在自身独有技术领域内建立SOA

    Comcast公司的应用体系架构和IT治理高级经理Tom Adler说：当你决定要采用SOA方案时，购买ESB、注册库和其他工具是很具吸引力的，这样能够使其所创建的应用程序结合起来并应用到其所执行的业务流程中去。从架构入手能帮助你确保目前和将来随时间推移后，任何需要改变的时候都有一个正确的框架来指导执行。

    他还说：“一年半以前，我们开始这个努力时，我们顶住了来自厂商的诱惑，他们总是希望我们能够购买他们全套的产品套件。但是，我们引进了项目专家而不是厂商，并通过这些专家首先确定了我们到底需要什么。所有的厂商都只是希望将ESB出售给我们。”他指出：在架构上的努力不仅仅在于建立框架，还要开始找出自己在业务流程和应用程序方面存在的冗余。这才是在业务上得到大宗买入进的关键所在， 因为它能真实的呈现哪里有节约成本的机会、帮助确认SOA最终基础架构和工具的投资，并且能展示通用服务组件在哪里运用能帮助减少维护和整合的复杂性， 为未来更多的响应功能的发展提供了机会。这个目标使我们消除了那些冗余的服务组件。

    在开发架构之后――Adler称之为共同域模型――Comcast公司的下一步是进行服务组件的发展和配置，以及治理框架的开发。他表示：服务必须要经过治理，否则没有人会知道该服务组件存在或是否遵循正确的政策和程序。只有经过治理的服务才能被增加到服务注册库中，才能被其他人再利用。

    很快出现的一个治理挑战就是决定谁是服务的所有者。Adler说，Comcast公司是一家相当分散的公司，所以企业文化自然的支持由服务组件原创者在他们自身所在的特有技术领域中拥有该服务。他还补充道：如登陆之类的常见服务组件自然由IT负责。

    目前Adler意识到Comcast公司错过的一个步骤就是在确定了架构体系之后需要开发一个公共数据模块。由于没有标准的数据服务组件以取得企业信息和管理系统之间的互动，开发人员最终没有以合适的方式设计自己的服务来完成任务，而这也导致他们对SOA原则的破坏，使服务组件之间容易混合与配对，并且出现不一致性。他说：“我们低估了先前的价值。”而代价就是在此之后为了加强该模式对一些服务的重复工作。

    Adler相信：Comcast公司的 SOA努力着眼于架构而非将SOA视为技术问题，这帮助SOA的理念更为广泛的在公司传播和应用。例如，因为Comcast公司从一开始并不认为SOA就是对Web服务的使用，该公司在其所有的努力中都使用了SOA的理念，而非仅仅限于那些明显的能通过网络实现的地方。他说：Web服务仅仅是公开服务的一种方式，是执行的具体途径。一个结果就是，多数初期SOA努力实际上被导向遗产应用软件，从而使内外部整合性降低(比如帐单供应商)，这是业务方面的一大痛处。

    开发商会使用最适合自己知识和应用的不同工具和编程语言。Adler说：通过标准化流程和政策替代特殊工具和技术手段，开发人员可以更好地坚持架构的意图而不是将每个人的努力硬塞进某种特殊工具或技术的限制或假设中。在共同架构下保持技术异质也是有现实原因的，他指出：在一个拥有9000名员工的公司，让每个人使用同样的方法论是不现实的。

    Adler说：这样规模的公司也要适应不断变化的业务需求和技术机遇。定期回顾参考架构是很重要的，可以避免它成为一纸空文或是企业的束缚，任何一种情况都会使你损失SOA给你带来的好处。虽然架构的变化并没有那么频繁，Adler每月都会回顾一次。

    让开源思想融入SOA策略之中
 
    对于开发人员而言，他们无时无刻不面临的问题是：所有的应用程序使用在对于一个很普遍的系统时，即便是在同一时刻不同的团队之间也无法很好的达成协作。这样的问题在2007年初的时候给Leapfrog公司带来了不小的麻烦，当这个玩具公司试图将其多样的应用程序系统应用于供应商和客户，并在两者间取得一致，用以更好的利用以网络为基础的业务交易。Leapfrog公司系统基础设施主管Eugene Ciurana对此说道：正是这样的一个原因让我们决定采用一个全新的方式去开发应用程序，今年3月，也就是SOA开始得以实施的时候，到此为止我们也已经取得了一定的成果。他强调：“我们需要为将来基于网络的基础设施和应用系统奠定坚实的基础，因此，我们一切从头开始。”

    在这个过程中Leapfrog公司一直有着一个确定不变的目标，而这个目标也是SOA思想最典型的目标：更大程度的代码重用，更快的开发时间以及更为简捷的集成应用。但是，Leapfrog公司并不仅仅只是打算让简单的让SOA在开发工具和综合应用平台上发挥微乎其微的作用。更多的是他们希望SOA能够在更为广泛的程度上自由发展，从一个领先理念指导的前提出发整合所有平台为一体以达到最佳的效果，从而可以更好的专注于应用程序的功能性并在此程度上最大限度的使用各个开发技术所带来的优势。(Leapfrog公司的开发人员使用的是Java，微软的C#，以及来自第三方库中的Web服务。)

    举例来说，Ciurana不希望迫使开发人员使用相同的传输方式。他说道，“如何传输其实并不重要”。他选择使用开源Mule ESB作为通讯支柱，并以此作为解决各层面传输问题之间的关键工具。通过这个途径，“开发人员可以尽可能的减少所需要面对的服务实施问题。”同时，他们可以更多的将精力集中在对功能性方面的实现，这也是他们努力的工作的目标重点所在。这样一来开发人员更趋向于使用HTTP传输协议，当然，REST和SOAP也会是他们的选择。“他们会考虑使用一些项目实现最佳的同时也是最合适的传输方式。” Ciurana对此解释道。在Mule ESB的帮助下，“开发人员不需要担心在他所使用的SOAP栈中有什么独特不能被重用的内容或者是什么样的集成开发环境会是他们使用的。” Ciurana早在Walmart.com的时候就已经使用过Mule了，所以他认为这是Leapfrog公司值得“从头开始”的依据所在。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。