从上世纪九十年代末到本世纪初，可扩展标记语言（Extensible Markup Language，XML）技术日趋成熟。通过XML，开发人员摆脱了HTML语言的限制，可以将任何文档转换成XML格式，然后跨越互联网协议传输。借助XML转换语言（Extensible Stylesheet Language Transformation，XSLT），接受方可以很容易地解析和抽取XML的数据。这使得企业既能够将数据以一种统一的格式描述和交换，同时又不必负担标准通用标记语言（Standard Generalised Markup Language，SGML）那样高的成本。这无疑为SOA的兴起奠定了稳固的基础。

    2000年以后，伴随着互联网的浪潮，越来越多的企业将业务转移到互联网领域，人们也普遍认识到基于互联网之上的电子商务具有极大的发展潜力，因此需要创建一套全新的基于互联网的开放通信框架，以满足企业对电子商务中各分立系统之间通信的要求。于是，一家机构咨询于2002年指出：SOA是“现代应用开发领域最重要的课题”。但在这一时期，人们更多的还是关注于Web服务这一概念，同时也出现了三个著名的Web服务标准和规范：简单对象访问协议（Simple Object Access Protocol，SOAP）；Web服务描述语言（Web Services Description Language，WSDL）；通用服务发现和集成协议（Universal Discovery Description and Integration，UDDI）。这三个标准极大地推动了Web服务的普及和发展。短短几年时间，互联网上出现了大量的Web服务，越来越多的网站和公司将其对外服务或业务接口封装成Web服务，有力地推动了电子商务和互联网的发展。Web服务也是互联网Web 2.0时代的一项重要特征，同时，“服务”这一概念也被越来越多的人所接受。

    到了2005年，SOA突然一下子就火了起来。不仅专家学者、各大跨国IT厂商，几乎所有关心软件行业发展的人士都开始把目光投向SOA。一时间，SOA成了IT界的焦点。各大IT厂商也逐渐放弃成见，通过建立厂商间的协作组织共同努力制定中立的SOA标准。这一努力最重要的成果体现在3个重量级规范上：服务组件架构（Service Component Architecture, SCA）/服务数据对象(Service Data Objects, SDO)/Web服务策略框架(Web Services Policy Framework，WS-Policy)。SCA和SDO构成了SOA编程模型的基础，而WS-Policy建立了SOA组件之间安全交互的规范。这三个规范的发布，标志着SOA进入了实施阶段。

    国内市场风云变换

    这里我们把主要的注意力集中在国内的SOA市场上，看看在国内市场上SOA的一个发展现状。

    2005年以前，中国的大部分企业还在问什么是SOA，一部分企业用户开始在内部交流论证SOA，但觉得SOA远不如EAI（企业系统集成）或ERP（企业资源计划）等技术术语那样通俗易懂。大部分IT专业人员也在头痛，如何给企业用户讲明白什么是SOA。2006年，部分企业已经开始试点实施SOA项目。随着厂商产品技术的不断完善和相关国际标准的出台，到2007年，关于SOA的话题逐渐从为什么要上SOA转变到如何上SOA。

    根据2007年的一项调查显示，77.5% 的接受调查的中国企业开始考虑或着手实现SOA 架构，其中已经部署SOA 项目的企业占10％，已经规划或正在部署的占30％，正在进行SOA 项目论证的为37.5%。尚未论证或考虑SOA 项目的仅有22.5%。

    不难看出，当前大部分企业对SOA的接受程度仍然集中在论证、实验，或者是某一功能或部门级别的局部性部署阶段。然而，这种局面正在慢慢发生变化。一些具有前瞻性的公司正在跨越功能和部门来拓展他们的SOA实施，最终将涵盖整个企业甚至他们的合作伙伴、供应商和客户。这无疑是更高级的SOA实施。企业可以由此获得重要的商业利益，比如系统整合将节约大量成本；优化的单一客户界面将提高客户满意度；服务的快速开发和部署能力也将不断推动企业创新和利润增长。我们虽然不敢肯定2008年是否有超过60%的企业在创建关键任务的应用程序时会使用SOA作为主导原则，但至少大部分企业会开始在局部范围部署SOA 应用，为以后SOA在全企业的实施打下一个良好的基础。

    在竞争日益激烈的今天，要想企业能从容面对市场环境的不断变化，就要求企业的IT架构具有更好的灵活性，能够充分地整合企业现有的IT系统，使各个部门和环节之间更好的协同，同时也提高了企业原有IT系统的可重用性，降低企业成本。而所有这些，正是提出SOA所要解决的问题。所以，企业发展所面临的这些问题，在某种程度上也推动了SOA的快速发展。

    任何新生事物的发展都伴随着问题的不断出现，这些问题也会在新事物向前发展的道路上产生一定的阻力，SOA也不例外。SOA项目设计和实施往往涉及对企业软件基础架构、管理和运营全方位的冲击，加之涉及现有的关键业务系统以及现有软件供应商利益分配格局，SOA项目的提出和具体实施等不同阶段都隐藏诸多不确定的风险。同时，成功的SOA实现对系统涉及、产品技术和实施人员都提出了很高的要求。

    标准化程度不够

    相对于国外成熟市场而言，中国已有的软件系统数量相对较少，中国的企业软件系统建设尚处于早期建设或中期发展阶段，由于早期软件开发的不规范和业务需求的不断变化，使得现有的系统很难被标准化切割成SOA服务。许多中国企业的现有软件开发技术和业务制定均不是很规范，导致业务流程难以有效的提取。同时，不同系统的不同标准数据源也难以得到有效的整合。久而久之，在企业陆陆续续建立的系统中由于缺乏一个统一的技术架构，最终产生了大量的信息孤岛，业务需求频繁多变使得业务设计不准确，这也让系统的易用性和可扩展性大大降低，以至于在想要实现SOA架构时，想整合，没法整合，想重用，没法重用，许多的系统不得不重新设计，造成了企业资源的极大浪费，同时增加了企业的成本。

    由此可见，中国企业在实施SOA时的一个需要特别关注的地方就是如何构建一个标准的平台，并在其上实现企业所需要的所有标准化的服务。因此，企业应该对全企业有一个清晰明确的认识，弄清楚其各项业务流程，以至于在系统的流程设计上不会出现失误。另外，对于软件开发商来说，一方面，在以自己的技术路线来帮助企业构建SOA平台的同时，要充分理解企业的业务流程，将其标准化成各项服务，严格遵循开发、编写代码的各项标准以及遵从SCASDO标准的面向构件技术，为企业提供真正粗粒度、随需应变的架构模式；另一方面，对于国内技术力量相对薄弱的这些SOA厂商来说，要想真正的参与到激烈的市场竞争中，在日趋庞大的SOA市场上分得一杯羹、甚至是占有一席之地，就要在保住自己优势（相对于国外厂商来说通常是在价格和本土化上的优势）的同时，也要充分理解各项标准，使自己的产品迅速的标准化，正所谓“一流的厂商卖标准，二流的厂商卖技术”，有可能的话，国内厂商要尽可能的跟国际上的大厂商合作，提高自己技术水平的同时，也有更大的机会参与到各项国际标准的制定当中，只有这样才能向真正的一流厂商靠拢，缩小两者之间的差距，甚至成为一流的厂商。

    人才的缺乏

    一方面，企业用户缺乏对企业业务和IT 需求以及SOA均充分了解的人员和机制，使得很多企业没有充分的意识到SOA的优势，即便意识到了，很大程度上也是看到别人用了好，自己也要跟着上，却没有充分考虑自身的实际情况，没有从自身已有的系统资源、实施能力、业务需求等出发，而只是“随风而动”，这往往会给企业带来很大的风险；另一方面，就SOA厂商而言，同样缺乏SOA系统的架构设计、项目管理和高级开发人员，大部分从事代码开发的人员并没有把那些可能会使用到自己编写的代码的人员当作使用者去对待，即没有意识到自己编写代码实际上是为别人在提供一种服务，总的来说或多或少还是缺乏SOA的意识。这两方面人才的缺乏，导致SOA项目对人才依赖程度过高，也就难以大面积推广和实施。

    要解决这一问题，不能一蹴而就，只能是对现有的技术人员加强SOA方面的培训，增强他们的SOA意识，与此同时，对于厂商来说，还有必要提高技术人员关于企业业务流程方面的认识，以便更加快速有效的理解企业客户的需求，也有利于业务流程服务的标准化细分。在对未来人才的培养上，让SOA走进高校是一个最好的选择，关于这一点，IBM就做得很不错，他们很早就开始有意识地去培养高校学子们的SOA意识，举办了类似“IBM杯中国高校SOA应用大赛”等的一系列旨在培养SOA人才的比赛，大大激发了学子们对SOA的热情，也有利于SOA后备人才的建设。

    探路者还不够多

    虽然在有些行业如电信、金融、电力等的企业已经实施了SOA战略，但可以看到，这些个企业都是一些经济实力雄厚的企业，对于它们来说，在SOA上的投入是可以接受的，而且这些投入不会影响到其现有业务的开展。而对于一些中小企业来说，它们的IT系统大多是刚刚建成不久，有的可能确实给企业带来了很大的帮助，使得企业在这几年有很好的发展，现在却又要对目前运行良好的系统进行SOA改造，甚至还有可能要重建以前的系统，不免让人有所担心。中小企业本来受市场变化的影响就比较大，业务的变化也比较频繁，虽说SOA可以很好的解决这一问题，但是目前它们所看到的还是风险大过收益。首先，企业必须要投入大量的资金来实施SOA项目；其次，他们并没有从那些已经开始实施SOA项目的企业身上看到有很好的效果（毕竟SOA这一概念也就近几年才火起来，任何事物的效果都不会是立竿见影的）。加之人们对改变企业IT 建设基础架构的新技术往往过度谨慎，因此，很多的中小企业在已有系统运行良好的情况下，大多不愿意去冒这个“险”。

    这就要求我们企业的领导者要有高瞻远瞩的眼光。SOA是一个发展的必然趋势，作为企业的领导者，要想企业在长期的发展中始终处于一个有利位置，那么，就要在企业资源允许的条件下，逐步实现企业的SOA化。当然，这也不是一蹴而就的，可以一步步来，先是各个部门，然后是各相关部门，最终实现全企业的SOA。对于SOA厂商来说，在关注大型企业的同时，同样也需要开发相应产品来满足中小企业客户发展的需要，做出一些有代表性的成绩，让各行各业的企业都能真正认识到SOA带来的好处，这样越来越多的企业才会真正的考虑自己是否也应该SOA一下了。

    新生技术自身不足

    作为还在不断发展成熟的技术体系，基于SOA的系统在性能和安全性方面仍有待时间的考验。前面我们也提到，作为一个松耦合的系统，服务由大量的链接来提供，其中包含了大量的依赖关系，一旦其中某个环节的安全性出了问题，很有可能导致整个系统处于不安全的状态。不仅如此，由于各个服务之间是相互独立的，也就是说一个服务相对于调用它的另一个服务来说是处于“黑盒”的状态，一旦出现问题，查找错误的源头也是比较困难的。因此，如果SOA的安全性问题得不到很好的解决，将会极大地限制其发展。

    如果我们能够保证系统的每次通信、每次数据交换、每次服务的提供都是安全的，那么整个系统也就是足够安全的了。那么如何来保证这种安全性呢？我们知道，SOA体系下的各项服务的提供多是基于各种协议的，因此首先要做的就是要保证各个协议的安全性。当然，判断协议是否正确的方法有很多，但大多是基于测试的。这里，我们可以考虑将形式化模型检测方法应用到协议验证中来，采用验证的手段，从逻辑证明的角度，而不仅仅是测试的角度，来“证明”协议的是正确的，从而给整个系统的正确性以有力的保障。当然，就目前的形式化模型检测方法来说，能够验证的协议还是相当有限的（因为要想进行形式化的模型检测，必须将系统模型化，对于比较复杂的协议来说，模型化后的验证过程可能出现状态爆炸的问题，这一问题也是形式化模型检测以及形式验证领域里一个困扰已久的问题）。当然，我们还可以利用一些特殊的方法来处理那些敏感数据和私有数据以及服务之间消息的传递，并且根据需要来限制服务访问，以保护这些重要数据。因此，在大力发展SOA的同时，我们也需要适当的考虑、发展与其相关的一些服务安全性方面的技术，为其更好、更快、更安全的发展提供良好的支持和保障。

SOA在实现中的组成部分
 

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