lizhe1985/
共255个网摘 [
1 2 3 4 5 6 ...
9 ]
下一页 |
访问lizhe1985的个人空间
lizhe1985收录，使用标签：SOA，时间：2008-4-8 13:39:08 | 相关网摘，我也收藏
摘自：计世网
集成技术和SOA的结合
谈到ESB，人们会自然想到两个关键词:集成和SOA。是的，ESB正是集成技术和SOA思想结合的产物。
分布式时代的集成技术
从集成技术的发展历史来看，最早是简单地点对点集成，两个应用通过各自的接口来实现通信。这种接口固化在应用当中的紧密耦合方式，使得系统毫无灵活性可言，应用本身的每次变化都会要求其相应接口的重新定制。
于是发展出基于消息的中间件，接口被消息代理所取代，应用与应用之间不再是通过其本身的接口互联，而是通过独立的消息代理来通信，这使得应用与应用之间耦合更松，应用的变化影响的只是消息代理，而不需要其他应用改变。但是它仍然是点对点集成的一种方式，路由逻辑和业务逻辑没有分离，系统基本没有扩展性，部署上还是网状结构。
这种点对点的集成方式应付少量应用的整合还差强人意，对于大规模的集成，在EAI时代，逐渐发展出“集线器”模式。通过把所有的系统都连接到中央交换中心，这种模式巧妙地把集成逻辑和业务逻辑分离开来，大大增加了系统弹性。但是这种中央控制的方式使得管理相当复杂，同时中央又往往成为集成的瓶颈所在。
分布式时代的到来对于集成的方式提出了巨大的挑战，这时候ESB就应运而生。通过采用轻量级的分布式体系，ESB将更多的处理逻辑分配到多个的端点上，中央服务器不复存在，业务逻辑处理能力及系统压力可灵活调配。
“总线对于Hub进行了拓展，拓扑的模式还是那样，但是这个单一的物理中心被虚拟化，分散到了整个网络上，负载和灵活性都大大增加了。”IBM的毛新生这样解释ESB，他认为ESB真正实现了系统间的松耦合，从而能够应对大规模的集成。
“ESB就是EAI在SOA时代下的一种形态。”金蝶中间件ESB产品项目经理倪晓兵说，“区别于传统的EAI技术，ESB不仅支持高度的分布式部署，同时支持异步消息的交互，强调面向的对象是符合标准的服务。”
另外，ESB在集成的过程中，更强调一种“统一消息”的概念。这种“统一消息”的格式，是可以被在ESB中所集成的各个服务都认可的。例如，IBM提出的SDO这样的一种统一的数据格式。
SOA时代下的产物
在SOA时代下，ESB为SOA的实施提供了底层架构的技术支持。SOA从根本上来说就是要解决两个问题:重用和异构，但是作为信息化系统建设永远要面对的两个难题，解决的方法却并不简单，所以SOA的体系庞大而复杂。
另外，SOA从根本上来说是一种软件架构的思想和方法论，它必须有相应的技术来帮助它落地，应用在具体的项目当中，而ESB则提供了实施SOA、简化SOA的技术手段。“ESB的意义在于让SOA有了一个可实现的基础设施。”IONA公司大中国区高级架构师陆飞舟这样说。
对于SOA要解决的两个难题，ESB从底层架构上都进行了技术支持。对于服务的重用，ESB提供了服务仓库和消息的路由，来实现服务之间的彼此调用。一个应用如果需要调用一个服务，它根本不用知道这个服务在什么地方，如何调用等，而只需要发送一个调用的请求，ESB就会帮助它找到那个服务，并进行绑定和消息的路由。“ESB为服务提供者和服务消费者之间的集成提供了一个平台。”倪晓兵说。
更重要的是ESB为分散服务提供了交互、组合和治理的基础架构。有了它，SOA才能释放自己的最大价值。
而对于异构环境的连接，这是ESB天生就具备的能力，因为集成技术一开始就是面向异构环境的。不同的数据、消息遵循不同的协议，采用不同的格式，为了完成它们之间的交互，ESB就必须提供转换的能力。同时作为EAI在SOA下的一种形态，ESB更具开放性，尤其是对Web服务的支持。
IBM为ESB定义了四个必备的功能:“路由器”——根据信息内容，在不同应用和服务之间进行信息传输和路由;“转换器”——进行应用之间的通信协议转换;“翻译机”——进行应用之间的消息格式转换;“收发室”——处理来自不同渠道的业务事件(同步传输，异步传输，发布/订阅等方式)。
其中“路由器”和“收发室”都是针对服务的重用而设计的，而“转换器”和“翻译机”则专门用来解决异构的通信问题。
针对重用和异构这两个难题，倪晓兵认为ESB提供了两个核心的功能，服务的管理和数据的转换。
那么ESB到底是什么呢？业内对ESB的定义是:它是由中间件技术实现并支持SOA的一组基础架构，支持异构环境中的服务、消息以及基于事件的交互，并且具有适当的服务级别和可管理性。
ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。
ESB不仅仅是连通 连通是最基础的能力
不管是应对集成还是支持SOA落地，连通性都是ESB要解决的首要问题，数据和消息的传输和转换是SOA实现的基础。作为SOA架构的信息传输龙骨，ESB为SOA提供一种连通性基础架构，用以连接SOA中的服务。
IBM WebSphere软件全球副总裁Sandy Carter女士介绍说，“ESB是SOA中的消息框架，即消息相互交换和通信的方式，是业界标准与客户消息框架的整合。”
“IT系统如果是一个人体的话，血液就是数据，心脏和血管就是ESB，大脑等器官就是应用，这样一个整体就是SOA。”毛新生这样比喻。
ESB要做到还很多
但是ESB的作用绝不仅限于连接。“企业需要不受限制的ESB。这是因为SOA不仅仅需要ESB来解决连通性问题，而且还需要ESB与附加产品的运行环境一起得到扩展，以便形成一个可以充分整合并有效连通的解决方案。”Sandy Carter说。
BEA公司中国区技术经理刘汩春说:“SOA的‘服务’不仅仅是可重用，而且必须是可组装编排;可快速注册发布; 质量可监控;生命周期可管理的。这样SOA才能在整个IT范围内实现服务治理和优化，从而直接推动业务的优化。”
倪晓兵介绍，金蝶中间件推出的Apusic ESB不仅包含了数据连通的功能，还涵盖了智能网络、服务仓库、业务重组和管理工具。
首先，分布式部署和集中控制是ESB的典型特征。ESB服务器在物理上可能相隔很远，但是通过集中管理，这些服务器组成了一个ESB网络，在逻辑上形成完整的企业服务总线。
在Apusic ESB的智能网络中，不要求网络中的各个服务器都必须明确地和其他所有的服务器建立连接关系，只要一个节点不是孤立节点，那么这个节点就可以和 Apusic ESB网络中的任意非孤立节点通信。并且，在通信过程中的路径选择上，Apusic ESB 网络会根据网络连接状况的实际情况，作出智能调整，自动选择最优路径。
其次服务的注册、发布和编排也是SOA实现服务重用性的基础。在Apusic ESB的服务仓库中，任何符合标准的服务都可以在其中注册，从而被其他服务调用。而消费服务也无需知道被调用服务的具体特征，只需要发送相应地请求即可找到相应的服务，并进行绑定和数据的传输。
同时为了满足具体的业务需求，不同的服务需要被组装在一起形成新的应用系统。Apusic ESB引入了工作流流程的概念，引入自主实现且基于业界标准的，具有条件分支和合并并行流转功能的BPEL4WS流程引擎，从而实现综合的、复杂的业务逻辑编排。这个流程引擎支持子流程、条件脚本、路由节点等功能。通过灵活的流程定义，按照即时的业务需求，将单个离散服务有机的组合起来，达到服务重组的目的，完成集成的业务需求。
此外，Apusic ESB在引擎级别将BPEL规范的细节进行了包装，对用户来说，只需要关心流程中的一个服务即可，无须再去关心BPEL的具体技术细节。
最后，所有的调用、转换都必须有一个良好的管理工具来帮助实施，并进行监控。Apusic ESB则提供了一体化的管理工具，通过这些工具，您可以非常方便的对Apusic ESB进行集中式管理、可视化的流程设计，以及运行期的实时监控等功能。
ESB其实只是技术 SOA项目不应从ESB开始
ESB在SOA中的重要作用，使得各个SOA厂商纷纷推出自己的ESB产品，并在具体的SOA实施中，利用ESB来作为切入点，并简化SOA的复杂性。
但是这种对ESB的重视正在使SOA的实施进入迷途。因为ESB只是技术手段，而SOA的目标则是业务价值。对技术手段的过分重视往往使人们忽略了SOA的最终目标，陷入在技术的泥潭当中不能自拔。同时ESB的简化掩盖了SOA的复杂性，使大家对SOA的实施过分盲目乐观，忽略了除了技术以外其他很多更重要的因素。
针对这种错误倾向，IBM WebSphere SOA与J2EE顾问Bobby Woolf最近写了一篇文章《以ESB为中心的架构是实施SOA错误的途径》来质疑这种把ESB当作SOA的实现基础的做法。Bobby Woolf在文章中提到，很多客户在开始建设SOA时要求先为他们建立一个ESB，他们抛弃了SOA的理念而只对ESB感兴趣。“这些客户在ESB和 SOA之间划了一个等号，或者更准确地说建设SOA就必须建设ESB。”毛新生指出了这种错误的根源所在。
因此以ESB来启动一个SOA项目是有害的，它将陷入技术的怪圈中，而无法产生最大的业务价值。毛新生认为业务才应该是SOA开始的起点和最终的目标。“你首先要在业务上进行服务的分解，然后才把他们映射到技术实现中。”毛新生说。
SOA项目的实施必须从业务需求的分析开始，而不是从构建ESB来开始。倪晓兵对这种观点也表示支持，“SOA框架体系下的软件开发，应该是从业务流程分析开始的，用一些组件化的业务建模方法，对实际的业务场景进行分析。在这个基础上建立业务用例，并根据这些业务用例构造业务流程模型。”
倪晓兵同时强调:“ESB不过工具和技术而已，关键上集成业务如何做？业务逻辑如何编制？如何实施？金蝶不仅提供产品,还能提供一套实施方法论。针对简单集成业务，提供标准知识集，也就是工具包，SI马上就可以用，针对复杂业务，我们提供一套方法论，金蝶的六步实施法，可以加速实施过程”。
引入ESB的最佳时机
我们既然不能从ESB来开始一个SOA项目，那么应该在项目的什么时候引进这个重要的工具呢？Accenture首席技术官Don Rippert认为激活SOA的全部潜力需要通过四个阶段，依次是使用XML，以更标准的方式使用应用程序接口;捕获一些业务过程，并将它们转化成为 Web服务;引入并全面使用企业服务总线;产生业务过程执行语言(Business Process Execution Language，BPEL)，它可由业务过程建模工具完成。
在这四个阶段，ESB的采用则位于第三阶段中。同时他认为当前大多数的企业还只是处于第一个阶段，因此ESB实际上对于他们来说并不是迫切需要的。
Burton Group的分析师Anne Thomas Manes的观点与Rippert相似，他认为要采用ESB，必须首先实现启动SOA的基本组件，这些组件是一个或多个服务平台(如.NET，Java EE应用服务器等)，SOA管理解决方案，注册表，另外如果服务要被暴露在防火墙之外，那么需要XML网关。
她说:“如果缺少我推荐启动SOA的‘基本组件’，ESB将不会列在我的清单中。事实上，我并不鼓励人们由ESB开始。ESB并不会鼓励好的SOA行为。ESB本质上是集成系统，而非SOA系统。”并且她认为ESB应该在后期购买。
毛新生认为，做SOA的事情不要先上来建立一个大而全的ESB，相反是关注你的业务问题，找到用SOA的方法来解决业务上的需求，在解决这个问题的过程当中，你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装，动态地解决你变化的业务需求。这是它的价值，只有这样才能使你的业务敏捷起来，随需应变起来。而在服务的组装过程中，你再去考虑利用ESB来把他们连接起来。
需要注意的是，这并不是否认ESB的价值。ESB是好的，单纯的ESB项目是坏的。让架构围绕服务，而非总线。
http://cio.ccw.com.cn/research/qiye/htm2008/20080404_400777.asp
lizhe1985收录，使用标签：SOA，时间：2008-4-3 10:12:44 | 相关网摘，我也收藏
摘自：计世网
国际著名的应用程序整合和SOA专家David Linthicum说，我每个星期都能收到来自雅虎或者谷歌电子邮件账户的讨论有关在一个大型企业中建立他们第一个SOA实例的电子邮件。
Linthicum说，事实上，大多数这些电子邮件都没有谈到正确的方法或者正确地实现这个技术的技术。他们绕过了人员的问题。具体地说，这就是新出现的“愚蠢的SOA人员(Dumb SOA Guy)”问题。我把这个问题称作“DSG”问题。
DSG(对不起，女士们，这些人中也包含女性)是那些在IT机构中似乎拥有政治权利，但是，却不知道SOA是什么以及如何建立一个SOA的那些人。核心的问题是在机构中理解SOA是什么和如何建立SOA的人没有政治手腕获得这个项目的控制权。有政治手腕并且被选择承担新的SOA工作的人不知道SOA是什么，从而把SOA当作一项技术或者系统来做，而没有当作一个架构来做。可以肯定，一些人在阅读这个栏目的时候会有同感，对吗?
Linthicum说，再说一次，围绕SOA的技术是简单的。我从来不担心我们能够用SOA解决一个问题。然而，人员问题是更令人担心和更难解决的问题。随着SOA成为企业领导层关注的“重要问题”，DSG人数会日益增多。我已经注意到当SOA的重要性提高的时候，DSG很快就去控制这种项目。
许多DSG试图把这个流程过于简单化，要快速通过这个过程或者甚至提前实施计划的步骤。他们的重点是选择技术或者试图使用一个预先制定的技术解决方案硬性解决一个问题。这种做法是不好的。
事实是，SOA是一个复杂的分布式系统，因此，计划、设计、建立和测试都是非常复杂的。在计划方面花费的时间将在以后得到巨大的回报。至少应该有一个严格的过程/技术方法来定义SOA项目，为你提供一个有关问题领域的语义级、服务级和流程级的理解，更不用说治理模式和安全战略了。如果你第一次实施SOA项目，你需要的计划时间和努力会超过你的预期。
这个问题是许多人在SOA的计划阶段没有得到有关如何实施SOA的合适的忠告和指南，他们甚至完全不知道SOA是什么。因此，更大的悲剧是许多这种项目将碰壁。出现这种问题反映了人们对SOA的错误理解，而根本不是SOA本身的问题。
这个问题是许多DSG不理解JBOWS(一组Web服务)和一个真正的SOA的区别，把JBOWS当作一种经验。事实上，这个迹象表明DSG不理解SOA的核心价值，因此可能使你走向危险的和代价昂贵的错误方向。因此，一定要雇用理解SOA的配置、灵活性和可改变性的人，而不仅仅是知道实现服务的人。提供服务是很容易的，但是，把这些服务变成解决方案是另一种高水平的工作。
除了提出这个问题之外，还没有确定如何解决这个问题。全球2000强企业的领导人必须要理解和解决这个问题。
http://cio.ccw.com.cn/research/qiye/htm2008/20080403_400003.asp
lizhe1985收录，使用标签：SOA，时间：2008-4-1 13:47:24 | 相关网摘，我也收藏
摘自：IT专家网
在中间件领域驰骋多年的BEA和IBM如今不得不担心自己是否会从宝座上跌落，因为整合的风潮已经在不知不觉间让该市场的“春秋争霸”重新上演。
变局之源起
每一场变革都会有一个导火索，在这场中间件市场的变革中，始作俑者则是SOA。
2005年 8月初，一向以数据库和CRM等管理软件的先导地位自居的ORACLE突然宣布，根据第三方咨询机构的统计，其合成中间件产品在全球的市场份额跻身第二位，而如果单纯以出货量计算，ORACLE甚至已经赢得了第一的位置。
同样，自2003年开始向中国市场正式推出JP1中间件产品的日立信息系统方面近日也声称，随着JP1产品被越来越多的用户所认可，在2005年占据国内中间件市场10%以上份额的规划也在有条不紊地进行中。姑且不论这些消息与数据的准确性，此类论调的蔓延多少可以让人感受到中间件市场的变局正在酝酿。
应该说，厂商们在这个时间点选择中间件作为市场拓展的突破口理所当然。伴随着用户对整合应用需求的日益迫切，谁掌握了该领域的话语权，也就意味着赢得了获取竞争先机的秘钥。因此，利益的驱动使已经十数年波澜不惊的中间件市场格局在悄然间变得复杂而竞争迭起也就不足为奇。
相关统计数据显示，中间件产品在2004年的全球市场规模已经达到72亿美元，并在2005年继续保持强势增长。在国内市场，预计2005年销售规模为16.8亿元，比2004年增长31.5%，今后5年的市场年增长率将高达25%。究其根本，电信行业的整合大潮无疑是推动中间件市场发展的重要动力。如此巨大的市场空间让众多的中间件厂商们没有理由不对这个潜力巨大的市场充满期待。
新介入者的机遇
在IDC看来，SOA理念的兴起应该是造成该市场硝烟燃起的最深刻原因。“由于企业用户业务、适应变革的要求，迫使IT系统必须成为一个有生命的实体，能随着业务环境的变化不断地发生演变，并具备柔性扩充、随时支持业务流程变化的基础功能。正是这个原因，使得面向服务架构的集成市场的竞争热度不减。”IDC(中国)公司副总经理、业务发展总监万宁如是说。
从某种层面上说，SOA已经不仅仅是一个单纯的中间件和EAI整合的概念，它其实代表着一种方法论，即可以将IT与电信进一步融合的崭新模式。如果说传统的中间件仅仅是利用EAI的模式将运营商内部的各种业务支撑和管理系统统一在一个平台之上，使数据流通和管理的流程更加顺畅，那么SOA所要实现的则更进了一步，即试图使整个IT架构更加灵活，可以根据用户需求的变动进行随时调整和增删。正是基于该原因，SOA也就成为了越来越多中间件厂商和套装软件厂商挑战BEA与IBM在中间件市场统治地位的一条捷径，因为站在SOA这个新兴的理念面前，每一个厂商都是新介入者，机遇随时存在。
竞争进行时
谁都不会轻言放弃，在这场竞争中，每一个厂商都需要竭尽全力。这是生存的惟一法则。
厂商们已经开始动作。“业务需求是实施SOA的根本动力，HP也在根据客户需求对建立更加灵活的中间件平台和IT架构进行着相应的战略调整。与其他厂商相比，HP在对异种环境下信息的处理能力，以及为适应性管理而发展起来的技术和方法论方面都具有优势，这让HP拥有了在业务流程实施和转变方面的专家级经验。而与BEA、ORACLE、SAP等厂商良好的合作关系也使得HP能够借助双赢的战略迅速切入市场。”HP咨询与集成服务事业部电信业总经理许安特表示。
与HP的包容战略不同，ORACLE则直截了当地将矛头直指BEA与IBM。“与2004财年相比，亚太区通信、媒体与公用事业部在应用产品销售收入方面增长了93%，在技术产品收入方面增长了29%，其中通信行业的收入占有最大份额。在中间件市场，Oracle与第一名Bea的差距已经相当小。”ORACLE大中华区通信、媒体与公用事业行业总经理李翰璋宣称。
除了国际厂商对中间件这块巨大蛋糕的瓜分与蚕食之外，传统中间件厂商之间的较量也从未停止。曾经在2001年拿到中国联通15个省大单的东方通科技尽管目前已经将更多的精力转向电子政务市场，但其多年来与BEA、IBM所形成的抗衡局面始终令国产中间件厂商振奋，并促使金蝶、用友、中创等众多的国产中间件厂商加入这一领域，成为一支不容忽视的力量。
市场无先后，在这场新兵老兵齐上阵的较量中，惟一的胜出标准只能是看谁能更好地满足客户的需求。而从电信行业这个细分的市场来看，尽管各家厂商的方向都锁定在了SOA这个崭新的机遇上，但运营商的想法却并不一定与之相同。
SOA无疑是一个趋势，否则不会有如此众多的厂商蜂拥而至。然而要真正让这个机遇扩大，并成为一个现实的市场空间，或许还需要有一段时间去等待。
http://soa.ctocio.com.cn/xwpl/348/8058348.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-19 16:41:02 | 相关网摘，我也收藏
摘自：IT专家网
IT建设：路越走越窄
随着证券业务的快速变化，企业IT投资越来越大，系统越建越多，IT建设的路反倒越走越窄了，越来越难以快速应对频繁的业务变化发展的需要。
目前，证券企业拥有了众多的IT系统，使用不同的架构和平台。如证券交易系统、企业的互联网站、办公自动化系统、客户关系管理系统、数据仓库、商业智能(BI)系统、总部综合管理系统、财务管理系统等等。其中证券交易系统是企业的核心系统，证券交易系统在渠道接入方面又包括柜台交易系统、网上交易系统和电话委托系统等。这些系统的大部分来自不同的软件开发商，少数由企业自行开发。
证券企业内的各系统之间有着如下三种不同的联系：
● 相互独立。如企业的互联网站、财务软件等都独立于其他系统。
● 通过专用程序把一个系统的数据传给另一个系统。
● 通过TCP/IP包交换接口进行系统集成。
证券交易系统通过TCP/IP包交换接口进行系统调用或集成，主要的缺点是没有统一的TCP/IP包交换接口标准，且只提供与证券交易相关的接口，证券交易系统其余的众多功能并没有提供接口，其他系统无法重用这些功能。通过TCP/IP包交换方式调用对编程也不便利。
与TCP/IP包交换接口相比，通过专用程序进行系统集成要更糟糕得多。以转存营业部证券交易系统数据到总部各系统的数据采集程序为例，如果要更改或增加采集数据内容，需要熟悉数据采集程序的全部源码。由于IT人员流动性高的特点，几年前编写数据采集程序的开发人员已经离开公司，因此必须让新的维护人员去熟悉这些源代码，然后才能进行修改。
重构功能，还是梳理流程
证券企业实施SOA，首先要做全局规划。由此引申出两条道路，是从重构功能入手，还是由梳理流程开始实施SOA?
证券企业实施SOA，首先要做全局规划，要对自己所有的系统做全面的评估，要了解这些系统有哪些功能，哪些系统中具有共性的功能可以跨系统复用，有多少系统需要改造，还需要上哪些新的系统。
SOA实施先从影响小的部门级系统入手，从办公、管理、决策分析等非核心应用系统开始，立足现有系统，循序渐进地开展SOA。证券企业的总部综合管理系统(包括稽查监控，各种业务查询与汇总，业务报表等)是不影响企业实时交易业务的系统，适合最先实施SOA的系统。
如何识别服务是实施SOA的关键，服务必须代表有形的业务概念。确定服务模块有两种方法。
一种是从软件功能的角度：将现有应用系统中所能提供的功能以列表的形式列出，如果发现相同的功能模块在不同的系统都有所实现，那么这些功能模块可以以服务模块的形式加以合并和重构。这种方法是基于软件功能层面的，所以是低级的确定服务的方式，相对容易，可以在实施的初期使用，然后再逐渐调整。例如查询客户资料(包括客户资金，股票等)功能是证券交易系统、客户关系管理系统(CRM)、总部稽查监控管理系统等都有的功能。像这样一些多个系统共有的软件功能，同时又是有形的业务功能就可以作为SOA的基础服务。
另一种是从业务流程的角度：通过对业务流程进行分析，可以清楚地知道我们需要完成什么样的工作，对于这些工作，又需要什么样的信息系统。由此可以清楚地知道哪些功能性要求可以以服务的形式加以实现。对业务流程进行充分的分析可以帮助我们更好地了解其业务流程，明白真正需要的是什么，从而更好地改善企业的业务流程，提高其效能。对于SOA架构的系统而言，服务模块最好通过业务流程管理来确定。
如上图所示，是股票委托业务流程的主要步骤，该流程与银证转账服务资金转出的业务流程有些共同的步骤(确定客户可用资金余额，冻结转出资金，根据银行确认将冻结资金转为资金减少)。这些为多个流程所共用并具有有形的业务功能(如冻结资金)可作为基础服务，而股票委托业务流程，银证转账业务流程将作为核心的流程服务以及公共企业服务(跨企业服务)。
服务的四个级别
SOA分为不同的成熟级别，SOA的成熟度越高，所实施服务的难度越大。下表是四种实现不同SOA成熟度的服务，依次从低到高递增。
实施SOA按照循序渐进，由易到难的原则，从基础服务开始依次实施这些服务。随着SOA的不断扩展，成熟度也不断提高。
证券企业现有各类业务系统交换的大都是数据，如证券交易数据、股票行情数据等。通过SOA，各类业务系统交换的不是独立的数据，而是服务之间的相互调用。通过增加一些Web服务,使得数据采集程序存取数据都使用Web服务，将原有的数据采集程序整合为向SOA提供ETL(抽取、转换、装载)服务，将数据仓库从一个数据源演变为能独立提供服务的系统。这样只需要把ETL、数据仓库的服务接入到ESB(企业服务总线)中，总部综合管理系统的应用程序前端和商业智能BI前端工具就可以方便地从ESB中获取需要的服务，通过调用服务来获取证券交易系统或数据仓库的数据，而不是直接取得数据。这样当抽取装载的数据结构发生变化时只需修改相关的服务即可，增强了灵活性。
企业中软件开发商提供的软件产品的SOA实施较难控制，很大程度上取决于这些软件产品本身的架构。如证券交易系统。开发商最关心的是该系统的功能是否满足要求，而不关心该系统的功能是否被其他的系统重用。因此需要向开发商提出，在不影响交易效率的情况下提供企业所需功能的Web服务，这在软件产品升级时更容易得到厂商的支持。
http://soa.ctocio.com.cn/xwpl/355/8037355.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-6 14:26:31 | 相关网摘，我也收藏
来源：IT专家网
分布式SOA架构完全可以替代EAI，如果用户已经建立了EAI，可以将其纳入分布式SOA架构这个体系之内。
宣传SOA的厂家非常之多，但是真正提出分布式SOA架构的并不多。
在SOA被炒得火热的时候，IONA公司不失时机地开始推广分布式SOA的概念。
IONA公司中国区总裁薛志勇回忆，2005年，IONA在内部讲SOA架构的时候，对企业服务总线(ESB)提出了一些自己的看法。IONA当时的解决方案很像是SOA网络，网络和总线的概念还是有所不同的。虽然公司高层曾考虑提出分布式SOA，并且顾问公司也建议这么做，但是最后的综合意见认为，市场已经习惯了ESB的叫法，所以还是沿用比较好。他说：“但是到今天，大家对SOA提出的问题越来越多，比如SOA如何保证服务质量?SOA如何保证服务安全性?SOA如何进行综合治理?IONA感觉到，市场已经作好准备，是提出分布式SOA基础架构这个理念的时候了。”
SOA是分布的
薛志勇认为，SOA与生俱来就应该是分布式的，因为组织和业务的价值链是分布的，SOA解决的就是分布式计算、分布式应用这样的需求。分布式就是没有中央的集线系统，分布式SOA是一种架构，不是一种简单的产品或者技术，分布式意味着必须不断应对市场的变化以及用户的要求。
分布式的价值在于，它是帮助企业构建SOA的捷径，是通过IT系统实现企业业务变革的捷径，包括：降低运营成本，更好的投资回报，更快速响应业务变化的IT架构。
现在宣传SOA的厂家非常之多，但是真正提出分布式SOA架构的并不多。因为很多大型软件厂商习惯了以紧耦合的方式提供SOA架构的主要功能，SOA紧紧地和他们的数据库、操作系统、服务器和存储绑定，这种紧耦合方式缺乏与其他系统的互操作性，初期需要大量的资金投入，往往会导致用户对某个厂商的依赖。紧耦合式SOA架构导致用户对采用SOA处于犹豫状态，因为在还未看到成功的希望时就需要大量的投资。
分布式SOA基础架构可以帮助用户摆脱紧耦合的方式，以较少的投资开始SOA建设，用户只配置需要的功能，并根据需要以渐进的方式扩大整合的规模。分布式SOA可以在运行环境中动态配置，也就是说用户的业务无需中断。在分布式SOA基础架构里，具备今天SOA所涉及的全部元素。在这个架构里，为了使各种服务能够重用以前的或者是现在的各种应用，实现各种服务元素的共享，首先要把这些元素互联、互通，消除信息孤岛，不管是基于主机、CORBA还是基于Java，统一对其进行封装，就像原来不同的网络协议被TCP/IP封装一样。IONA的分布式SOA基础架构分为三层，最底层是对不同应用进行SOA封装，使其成为标准;第二层提供中间层服务;第三层是基于Eclipse的开发工具。
取代EAI
企业应用集成(EAI)曾经被认为是应用整合的好方法，而薛志勇的观点是，目前全球很难找出EAI成功的案例。这是因为，首先，EAI的投资比较大，而用户却无法确定到底能获得哪些收益;第二，EAI平台所使用的很多协议都是专有协议，是不标准的;第三，EAI平台承担了很多的任务。中间件要占用资源，数据转换要占用资源，业务流程的编制还要占用很多资源，这意味着对硬件平台提出了比较高的要求。
分布式SOA架构完全可以替代EAI，如果用户已经建立了EAI，可以将其纳入分布式SOA架构这个体系之内，加上端点，加上封装，就可以进入SOA网络。以某省网通公司为例，如果对BSS、OSS和MSS系统进行EAI建设，投资是1500万。而如果采用分布式SOA架构，预计能够节省80%的投资。
http://webservices.ctocio.com.cn/comment/249/7832249.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-6 14:25:52 | 相关网摘，我也收藏
摘自：IT专家网
当企业规划一个SOA项目以推动用户价值并充分利用语音通信基础设施时，面临的一个主要挑战是他们缺少拥有合适的SOA技能的架构师。事实上，在很多企业中，人们对软件架构规则仍然误解很深。与此同时，目前架构专业分为好多种类型，大多数架构师只精通其中一两门专业。要成为面向服务的架构师，首先要对于企业架构有清除的了解，其次还要熟悉技术架构、信息架构、业务流程架构和数据架构。要找到具备所有这些技能的人无异于大海捞针。
部署中型SOA项目同样需要技能熟练的架构师，但这些架构师的经验深度不必与那些规划重量级SOA工程的架构师相同。事实上。事实上，在完成几个中型SOA部署后，你的架构师就会变得逐渐程序，并且他们的SOA技能也在不断提高，这为将来他们能够胜任重量级SOA项目的部署工作打下了良好的基础。
开发人员和架构挑战
SOA给整个IT机构都提出了技能挑战，而不仅仅是架构师团队。特别是，SOA---就像其它任何架构一样，给应用开发团队带来了很多困难。毕竟，开发人员都是有创造性的精英，他们喜欢自由自在，不欣赏太多的结构。然而，作为一种架构，SOA给开发人员带来了太多地限制。
重量级SOA的部署可能涉及到很大的团队进行参与，并且责任分工很广泛，而中型SOA项目一般都是由规模较小、比较灵活的开发团队完成的，在部署过程中，架构师可直接与开发人员、测试人员和其它日常工作人员直接打交道。此外，如果企业能够利用可以支持如此广泛专业的工具，那么，这样的一个以团队为基础工具可以缓解许多架构师和开发人员之间的矛盾。
其实上，这些冲突往往归结为治理(governance)问题---当开发人员在创建、发布、发现以及重用服务时，应该使用什么策略，谁负责制定和执行这些政策。中型SOA工具因此应该还具备对于这种治理能力的支持，从而使得应用程序开发团队与架构师可以一起参与策略的制定和执行，而不是仅仅让架构师负责制定这些策略，这种做法是不切实际的，通常会引起开发人员的抵制。
过程专家和技术实施的挑战
SOA提出的挑战超越了应用开发团队的范围。事实上，商业分析家和其他业务流程专家也必须应对SOA提出的挑战。毕竟，为了实现灵活性，业务流程必须保留其商业背景。然而，大多数情况下，技术上的细节占据了上风。如果代表商业发展路线的商业分析师无法有效地与架构师以及应用开发团队进行交流，那么，服务所需要的这个关键性的业务需求背景以及SOBA(面向服务的业务应用)，将可能会丢失。
中型SOA方法对于简化业务流程的自动化可能极为重要的，尽管底层技术的复杂很高。在一个架构清晰的SOA中，商业服务给业务提供了一个简化的接口。如果业务流程建模环境能够充分利用商业服务，那么业务分析师以及其它业务流程专家就可以有一个创建和配置SOBA的环境，这对于SOA团队很有意义。
当然，实施一个中型SOA项目和重量级SOA项目的最主要的区别之一就是成本。项目越大，成本也就越高。成本的限制往往是企业部署中型SOA的主要动力。所以，这种类型的夏木要面对的挑战,一般侧重于利用相对较低的成本实现较大的商业价值---这就是你可能称之为“一美元大收获”型项目。
避免SOA中间件陷阱
很多重量级软件供应商千方百计想要使你相信要部署SOA，你需要购买大量的中间件---但是，事实上，这是不正确的。“SOA中间件”或“SOA平台”以及其它重量级、以集成为中心(integration-centric)的产品，实际上对于有效的降低SOA部署的成本不会起很大的作用。但即使如此，市场上也有许多成熟的产品，可以对于你成功部署SOA做出真正的贡献，同时还能降低成本。尽管如此，重要的是要记住，目前在市场上你可以买到最好的SOA产品，无论你花钱多少，那都不能代表你拥有了SOA。毕竟“购买最好的工具不会让你成为一个木匠的”。请记住，SOA是由组成一套最佳做法组成的---需要遵循一些规则。
因此，在SOA产品的选择中，中型项目的办法与重量级项目、以中间件为中心的方法是有本质上的不同的。在中型SOA项目中，体系结构和业务流程驱动SOA基础设施和工具的选择，而这应该是最好方法，与之相反的是单个大型厂商的推动。SOA基础设施一般依赖于中间件，这是可以肯定的，但是，大部分企业已经有足够多的中间件软件。中型SOA部署对于中间件的使用方法是，充分利用那些已经部署了的中间件，同时还要引入一流的治理、质量、管理以及服务创建和组合工具。
利用中型工具
重量级和轻量级工具所面临的最大的挑战之一是缺少重视SOA的最佳实践。最重量级的工具取决于较早的集成技术。
另一方面，轻量级的解决方案，仅仅着眼于服务，而且很少提供架构上的协助。不过，中型解决方案专注于把许多SOA的核心规则同集成工具打包在一起。因此，架构师有可能会充分利用这些工具，并且他们也可以灵活地参与企业SOA和治理项目的措施。
http://webservices.ctocio.com.cn/comment/52/7832052.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-6 14:22:39 | 相关网摘，我也收藏
摘自：IT专家网
面向服务架构(Service-Oriented Arthitecture，SOA)提供了一种方法，可以把企业的业务战略和必要项目与IT项目结合起来。因而，SOA治理不但涉及技术，同样涉及组织问题以及人员如何协同工作来实现业务目标。
IT治理涉及获得进行变更的批准，涉及权力，涉及谁拥有这种决策权，涉及在业务迅速变化的形势下这类决策需要多长时间。SOA通过减少决策的发生，从而大大减少了IT治理的需要。不过，为了获得这种好处，贵企业必须首先采用SOA。
SOA的演进
采用SOA并不能让你迅速获得投资回报，反而需要战略性投资，包括在结合IT和业务的治理和文化变化方面进的投入。不过据Gartner公司的分析，这不是SOA会不会取代如今架构的问题，而是完成这种演进需要多长时间的问题。
想要采用SOA的许多公司面临的一大绊脚石，那就是目前的IT成本分摊模式。许多公司把项目开发和支持的成本与批准项目的业务部门一一对应起来。在SOA中，服务常常在多个应用和业务部门之间共享，这就意味着你可以就参与SOA战略的某个项目向以后使用服务的每个人收费。
一种比较好的方法是为SOA应用资产设计共享分摊结构，甚至抵消可能高于采用非SOA方式的独立开发所需成本的SOA开发成本。因为只有服务被多方使用后，才能够得到重复使用的好处，所以要有激励措施确保来发布及设计可重复使用的服务。同样，也要有激励措施来促进充分利用现有的企业服务。如果你正在实施外包项目，对于应当加以的积极管理，特别难以实现。
公司在与负责实施的合作伙伴打交道时，似乎更容易忽视治理和执行方面的工作。举例说，常常由IT部门外的个别业务部门决定把某些项目外包出来。即使在IT部门里面，针对批准厂商列表和采购的重点往往与内部治理流程和决策机制相脱节。
IT治理和SOA采用
SOA面临的挑战之一就是实施不是一蹴而就的，而是要通过跨越空间和时间的多个不同项目才能实施完毕。SOA项目的这种空间和时间分布使得治理对SOA的成功而言更加至关重要。SOA治理和可执行的策略是确保跨地域和跨时域，这也符合SOA的两大关键。
空间分布、数量激增的服务(需要由企业内外的不同部门来维护)以及时间分布(随着支持的业务流程不断变化，服务本身或者服务组合随之不断变化)，这一切使得治理特别具有挑战性。从很大程度上来说，只有服务符合服务级别协议(Service Level Agrement，SLA)在安全、可靠性、性能和成本等方面规定的要求，跨组织边界分布的这些服务才能够正常、有效地使用。只有设立合规办公室，对整个企业进行监管，并且由业务分析人员和软件开发人员等代表组成，才能最有效地进行识别、指定、创建，然后部署企业级服务，从而实现SOA治理。
人们很容易纠缠于实施SOA方案的技术细节。幸好，SOA治理使得业务和技术之间合作的重要性重新受到关注。到最后，重要的不是技术，而是客户是否采用。如果最终用户认为自己能因而创造经济效益，才会采用及使用基于SOA的应用。
传统和联合的治理方案
过去有两种IT治理方案：集中式和分散式。
至于前者，IT部门对开发预算及技术标准的采用保留控制权。业务和IT部门之间的这种关系有时很紧张。业务部门需要迅速实施新战略的敏捷性，于是把需求交给IT部门;不但实施所需的功能似乎需要很长时间，许多信息也常常会在需求文档到可执行系统之间的转变过程中丢失。至于后者，预算和技术事务方面的一定权力交给经营单位，甚至交给这些单位下面的单个部门。由于相对缺乏集中监管，这批独立用户最终开发出来的系统从长远来看协同工作的效果很可能不是特别好。
由于只有这两种IT治理方案，IT部门只好面临这种取舍：要么现在牺牲响应时间，让权力集中在中央的IT部门，要么之后面临失去控制的分散环境带来的后果。
不过，SOA有望采取中间路线。这是一种基于标准和服务的方案：注册中心(repository)和平台作为系统核心，而服务使用方进行的建模和应用开发为业务分析人员及其他分布的战术用户给予了很大的自由度。战术使用和战略监管的这种分离也为在特定情况下实行治理带来了机会。在这种联合架构中，SOA把IT方面与业务方面分离开来，为各自提供了一直寻求的东西。企业首次能够获得统一IT架构带来的优点，同时又能在IT方面获得新的灵活性，足以满足业务要求。
SOA的一条根本原则就是业务逻辑与应用逻辑相分离。业务分析人员得到了这种能力：定义、变更及修改SOA服务支持的业务流程。IT部门的责任同样明确：它必须管理从应用逻辑直到物理基础设施的整个部分。IT要负责SOA的底层平台，即注册中心。
这并不是说IT和业务以后根本不再协商;而是通过为业务部门提供使用关键业务流程、利用现有企业服务组建应用的敏捷性，从而减弱对接口的需要，并且减少相关问题。
业务部门获得了这种能力：进行战略性变化，又不危及应用生态系统，无须通过IT部门对整体式应用(monolithic application)进行重大改动，再次让每方各取所需。
当然，这种联合架构自身也带来组织难题。除了由传统的治理委员会监管服务和平台的完整性外，公司和CIO如今必须处理这个问题：到底把多大权力交给业务分析人员及其上司，还要考虑治理领域的范围和界限;每个领域里面谁有权施加影响、提供咨询，以及最后作出治理方面的最终决策。
仍必须进行取舍，不过这回是在灵活性和组织复杂性之间进行取舍。
http://webservices.ctocio.com.cn/comment/163/7831663.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-5 10:57:10 | 相关网摘，我也收藏
摘自：IT专家网
随着近几年SOA概念的推广及相关技术标准的发展，SOA逐渐为众多的用户所接受，并在电子政务及企业应用的建设中逐步得到应用。但是，面对众多纷繁复杂的SOA相关技术标准，IT企业在开发SOA相关软件产品及用户实施SOA进行选择时，往往分不清楚哪些技术标准是他们所需要的，而且相当部分的SOA技术标准的定位，有一定的重合。因此，选择适合的SOA相关技术标准，成为IT企业和实施SOA用户的面临的难题。下面，简单介绍一下部分SOA相关技术标准，并作简单分析。
1.SOA相关技术标准分类
标准与规范基本相似，但略微不同，规范是标准的建议文档。标准一般是由业界公认的标准化组织制定和发布，而规范多为厂商或非标准化组织发布。本文不对它们进行区分，统一称为标准。SOA相关技术标准有多种分类方式，本文介绍两种。
1.1.分类方法一
一种方法是将其分成三类，即XML标准集、Web服务标准集和SOA参考模型：
XML标准集
主要包括两类，一是基于纯文本的编码技术，XML信息集、XML Schema、XML Query和XSLT 2.0等。二是允许不透明的二进制数据与传统的基于文本的标记交织在一起的编码技术。如XML二进制优化封装协议(XML-binary Optimized Packaging，XOP)、SOAP 消息优化(Transmission Optimization Method，MTOM)等。
XML标准集是促进SOA发展的头等功臣，它们多数是由W3C组织制定，并得到了众多软件厂商及用户的支持和使用，如不管是Java阵营还是.NET阵营，乃至其他软件开发技术，大都提供XML标准集的工具包。XML标准集不但是用于SOA数据描述和处理的最佳标注，它还是其他SOA相关技术标准的基础，如Web服务标准，都是以XML来进行描述的。
Web服务标准集
Web服务标准集已经初具规模，内容涵盖传输层、消息机制、编程模型、服务发现和描述、可靠性、事务处理、安全和管理等方面。如WSDL用于Web服务的语义描述，WS-Policy用来描述Web服务的能力和策略等，WS-Security、SAML等用来描述Web服务相关安全性要求，等等。目前，多数Web服务标准集，由OASIS组织制定，有些Web服务标准尚不完善，正在发展中。
SOA参考模型
SOA发展早期，不同厂商宣扬的SOA参考模型不尽相同，随着相关技术标准的发展，各个厂商的认识逐渐统一。当前，OASIS已经制定了SOA的参考模型SOA-RM1.0规范，它提供了一个整体的抽象框架，它用来理解SOA先进技术理念的抽象框架，是在面向服务环境里的重要衔接方式，是标准逐步统一的重要发展进程，也是服务支持的详尽规范。SOA参考架构，能够在企业的SOA整体计划中提供一个很具有全局性的整体框架加以指导，但却不能在现实的SOA执行中提供太多具体可行的意见。
虽然已经有了SOA参考模型的推荐性标准，但标准化组织和厂家在SOA的参考架构上还没有统一。
1.2.分类方法二
SOA相关技术标准的另一种分类方式，是根据技术标准在 SOA 中的角色功能，将其分为三大类：服务层次上的信息交互规范、基础通信标准规范、元数据标准规范。根据各种标准规范在SOA 体系中的角色功能，可以将 SOA 协议栈分为 7 层，如图1所示。从底向上，包括传输层、消息层、描述层、管理层、服务组合层、表示层，其中除了ebXML和电子商务相关的技术标准(如资源注册的ebRS、消息表示ebMS、外部服务资源编排的WS-CDL等)外，大多数在国内已经得到了相当的应用，如东方通科技的应用集成产品TongIntegrator和应用服务器TongWeb，都支持部分Web服务的相关技术标准。传输层作为传统的传输协议，在SOA技术实现中，依然发挥着重要的作用;消息层SOAP已经是Web服务消费的消息传输载体的首选;Web服务描述标准WSDL，虽然在语义方面的描述还不完善，但它已经被绝大多数厂商和用户接受并使用了;在管理层的相关技术标准，目前还在发展完善，国内实际应用的还不多，但诸如常用的安全要求WS-Security、可靠传输要求WS-Reliability等，已经有用户和厂家开始考虑使用;服务组合层，已经有不少的商业及开源组织，基于BPEL标准来开发业务流程管理软件了;表示层的标准如JSR168和WSRP，主要用于Portal软件的开发。
图1.SOA协议栈分层结构
2.SOA相关技术标准比较说明
由于SOA相关技术标准太多，图1中，并没有完全列举出所有的SOA相关技术标准。下面，就部分相似的SOA相关标准进行比较说明，以便进行SOA开发时，能够基于了解认识进行选择。
2.1.WSDL与OWL-S
W3C组织提出的标准的Web服务描述语言WSDL，它从句法层面对Web服务的功能进行描述，包括4个不同的粒度：数据类型(Data type)、消息(Message)、方法(Operation)和访问端口(PortType)。这只是提供了Web服务的接口描述，对服务的行为约束和属性描述缺乏进一步的支持。
OWL-S是语义Web服务标记语言的标准，它比WSDL更能向用户提供可理解的服务资源的描述形式，提高服务选取与推荐的准确性。语义Web服务的主要方法是利用Ontology来描述Web服务，然后通过这些带有语义信息的描述实现Web服务来实现服务的自动发现，调用和组合。语义Web和Web 服务是语义Web服务的两大支撑技术。OWL-S是连接两大技术的桥梁，目前对语义Web服务标记语言研究最重要的组织就是DARPA组织，其研究组OWL Services Coalition提出了语义Web服务标记语言OWL-S(原DAML-S)。
语义Web服务及相关标准(OWL-S等)对于Web及Web服务应用的深化具有重要意义，同时也具有很好的发展前景。目前OWL-S等语义Web服务相关标准的应用还主要是研究性、示范性的。
2.2.XML Web服务与ebXML
SOA中的服务，当前多以Web服务技术实现和解释，传统的Web服务及其相关协议，都是以XML为基础进行扩展的，因此我们把它称为XML Web服务。其实，在XML Web服务之前，ebXML已经出现，鉴于此标准复杂而完善，因此它在传统的电子商务领域，用处较广。就具体的内容和定位而言，两者有一定的区别。
1)消息传输技术
XML Web服务和ebXML都使用SOAP作为消息传输技术，但是XML Web服务服务定义了松散耦合的协议堆栈，该堆栈由可靠传输 (WS-Reliability) 和 安全 (WS-Security) 的各个规范组成，而ebXML将所有这些功能都融入到自己的消息传递标准和ebMS中，从而使用混合技术。
2)服务描述和发现
XML Web服务分别使用WSDL和UDDI标准，UDDI注册机制是基于目录的体系结构，其注册内容包括技术模型和业务模型，本身可扩展但目前其注册的内容和描述还不够丰富和完整，图3为UDDI的数据模型及关系图。
而ebXML将服务描述和发现机制对应两个标准，一是注册信息模型ebRIM，二是注册服务规范ebRS。ebXML注册机制要比UDDI丰富和完善的多，它的注册机制用途广泛，可以表示范围广泛的数据对象，包括 xml 模式、业务流程描述、ebXML Core Component、UML模型、一般贸易合作伙伴信息及软件组件。为了支持如此多样的数据，使用一个定义良好的信息模型而不是目录，将ebXML注册设计得更像一个数据库，图2为ebXML的注册信息模型ebRIM的组织结构示意图。
3)业务流程协作
基于Web服务的业务流程协作和服务编排，有WS4BPEL、WS-CDL、基于XML的工作流XPDL等，这些基于XML和Web服务的标准都彼此相对独立，甚至是不同的组织制定。
ebXML标准也包含业务流程协作的标准，如ebCPPA、ebBPPS。
总之，ebXML是一个独立的规范集，具有内部一致性，而且不依赖于新兴标准和规范，它的用途主要定位在有特殊要求的电子商务方面，目前，ebXML已被国家确定为国标推荐，但其应用看起来还要有一段路要走。而XML Web服务由于其内容相对简单，技术实现容易，对应的一系列协议栈相对松耦合，因此其在构建SOA的应用中使用越来越广泛。
图2.ebXML的注册信息模型(ebRIM)
图3.UDDI数据模型及其关系图
2.3. SCA/SDO与JBI/JDO
SCA(Service Component Architecture)，即服务组件架构，提供了一种编程模型，可以支持基于SOA的应用程序实现。SCA是一种模型，可以支持实现服务组件的各种技术，连接服务组件的各种存取方法。对于组件，不仅包括不同的编程语言，也包括这些语言使用的框架和环境。对于存取方法SCA合成操作支持各种通讯、服务存取技术，如：WS、MQ、RPC。SCA规范包括了Assemble Model和Client Model两部分。前者约定了如何将异种组件(Java类，BPEL，Web Service)组装并发布成SOA服务，是SCA最大的特点和最核心的概念;后者则约定了如何在异种语言环境中调用SOA服务。通过这两部分的规范，就可以完全解决了服务从服务端到客户端的跨语言、跨环境的问题。图4为SCA的服务组件组装模型。
服务数据对象(SDO)的设计初衷是为了统一和简化应用程序处理数据的方式,使用SDO,应用编程人员可以用一致的方法操作异构数据源,包括关系型数据库,XML数据源,Web services和企业信息系统 。
JBI是Java商业集成(Java Business Integration)的简称。JBI的制订者们认为传统的EAI和B2B解决方案使用非标准的技术，这使得用户往往被锁定到特定的方案和产品提供商上，与此同时，没有任何一个单独的提供商可以覆盖EAI和B2B领域的所有问题。因此他们提出这个标准以期解决这个问题。这个标准定义了一个标准的体系结构允许第三方的组件插入到标准的基础设施上，并且即使这些组件是有不同提供商提供的，它们也可以以一种可预见的和可靠的方式互操作。从高层次上看，JBI定义了可以从可插入组件构建集成系统的体系结构，这一结构中组件的交互使用一种经过中介的消息交换机制，而这一消息交换模式是基于WSDL 2.0或WSDL 1.1的。图5为JBI环境组成及结构。
图4.SCA服务组件组装模型
图5.JBI环境组成与结构
JDO，即Java Data Object，它定义了持久保存类与JDO运行时环境之间的关系。JDO的设计目的是用来广泛支持不同的数据来源，甚至包括一般不被认为是数据库的来源。因此我们用“数据存储空间”(datastore)一词泛指以JDO 访问的底层数据来源。
从上面的分析来看，SCA/SDO定义了与具体技术无关的服务组件组装模型及服务间访问的数据结构表示方式，SCA的定位，主要在于细粒度的组件和服务组装方式。SCA/SDO由于技术无关性及众多厂商的参与，他们得到了大多数厂商的支持。而JBI/JDO，它们都是基于Java的技术，JBI更多的像服务总线的Java标准定义，其粒度比SCA，而且更多的是服务间的通讯和组装模式，而JDO是基于Java的数据对象表示，因此它们使用的范围受到限制，当前支持的主流厂家也不多，但是开源的实现相对还是比较多的。
2.4.WS4BPEL与WS-CDL
WS4BPEL，即Web Service Business Process Execution Language的简写，Web服务业务流程执行语言，它是一种可执行语言，能够与各种促使业务流程自动化的软件系统相兼容。Web服务编制，通过说明性的方式(而不是编程的方式)表达了进行Web服务合成的需求。此标准主要用于组织内部的业务流程管理及服务编排，目前越来越多的BPM产品基于此规范实现。
WS-CDL，即Web Services Choreography Definition Language，Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点(endpoints)都有Web服务基础设施。此规范更多地用于组织之外的服务与流程编排，目前在国内还不常用。
另外，XPDL也可以用于服务的编排和组合，但它主要用于传统的工作流定义，目前它也是BPM产品实现的重要技术标准。
2.5.JSR168与WSRP
JSR168是java 规范要求(java specification request ，jsr)的缩写，它为创建portlet建立标准的api，它是为实现porltet、基于java的门户服务器和其他web应用程序之间的互操作性而设计的。JSR168的主要价值在于它被独立软件开发商(isv)所广泛采用。在采用JSR168之前，企业应用程序开发商不得不支持所有开发商门户的不同portlet集，支持多个门户开发商不同的portlet集在类似业务信息、内容管理、检索和分析这样的领域中非常令人头疼。使用JST168规范，现在开发商只需要支持一种portlet集。目前，JSR168在基于Java技术开发Portal产品上，得到了广泛的支持，但也仅限于Java技术。
WSRP，即Web Services for Remote Portlets的缩写，它定义了如何利用基于 SOAP 的 Web 服务在门户应用程序中生成标记片断的规范。通过定义一组公共接口，WSRP 允许门户在它们的页面中显示远程运行的 portlet，而不需要门户开发人员进行任何编程。对于最终用户，这些 porlet 就和运行在他们本地的门户上一样，但是实际上这些 portlet 来自于远程运行的 portlet 容器，并且交互是通过 SOAP 消息的交换来实现的。在面向服务的体系结构中利用 WSRP 将是一个强大的组合，从而使面向呈现的 portlet 应用程序可以被发现并重用而不用任何额外的开发和部署活动。WSRP是由OASIS组织制定，目前已得到多数厂商的支持，鉴于它基于Web服务标准，而且技术相对独立，因此随着此标准的逐渐完善，相信越来越多的Portal生产企业会支持此标准。
3.总结
前面对部分SOA相关技术标准的比较分析，不可能覆盖所有的SOA相关技术标准，如SOA的参考架构、Web服务协议栈的比较分析等。本文的目的，希望能够为希望了解SOA相关技术标准及面临技术标准选择困惑的开发人员、软件厂商及用户等提供一些参考，以此达到抛砖引玉的作用。
http://webservices.ctocio.com.cn/comment/414/7830414.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-5 10:51:54 | 相关网摘，我也收藏
摘自：IT专家网
网格计算已经成为热点，它所带来的低成本、高性能以及方便的计算资源共享正是众多企业所追求的。在这一大潮下，数据库技术将向何处发展?Oracle对此问题的回答是：未来的数据库将构筑在网格计算环境之上。
RAC(Real Application Cluster，真正应用集群)是Oracle9i数据库中采用的一项新技术，也是Oracle数据库支持网格计算环境的核心技术。它的出现解决了传统数据库应用中面临的一个重要问题：高性能、高可伸缩性与低价格之间的矛盾。
过去，如果企业希望其信息系统具有良好的可靠性、可伸缩性和高性能，就必须选择基于主机的系统，这意味着企业在系统建设之初就必须投入大量资金;如果要节省成本，企业可以选择基于客户机/服务器的计算体系，并在需要时逐步增添新硬件、扩展系统，但如果需要进行应用升级，企业就不得不付出高昂的升级费用，同时这种分布式系统的维护成本也不菲。采用RAC技术，用户就有了更多的选择，无论是选择基于Intel架构的PC服务器、Unix工作站，还是最近两年颇受关注的刀片服务器;也无论是选择Unix、Windows，还是Linux操作系统，只要在这些软硬件平台上部署了Oracle9i的RAC系统，这些分布在各处的系统就能组成集群，实现用户所需的高性能和高可靠性。且当系统需要进一步扩展时，无需对应用程序进行任何修改。“这就是基于网格计算环境的数据库，也是数据库技术的未来发展方向。”Oracle公司负责数据库业务的高级副总裁Andy Mendelsohn先生说。
为什么Oracle的RAC技术能够实现以上目标?因为RAC技术采用了“sharing everything”的实现模式。据Oracle公司技术专家介绍，RAC技术通过CPU共享和存储设备共享来实现多节点之间的无缝集群，用户提交的每一项任务被自动分配给集群中的多台机器执行，用户不必通过冗余的硬件来满足高可靠性要求。另一方面，RAC可以实现CPU的共享，即使普通服务器组成的集群也能实现过去只有大型主机才能提供的高性能，这也是Intel、Dell等公司非常愿意与Oracle合作、共拓高端市场的原因。
除了RAC技术，Oracle9i数据库还提供其他功能来支持网格计算，包括支持在数据库之间进行数据快速复制的Transportable Tablespaces、支持数据流更新的Oracle Streams、支持应用可移植性的One Portable Codebase等。Mendelsohn认为，对那些需要建立数据中心的企业来说，Oracle9i RAC加上刀片服务器和Linux操作系统，就完全能够替代传统的基于大型机的数据系统。
http://webservices.ctocio.com.cn/comment/186/7830186.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-5 10:51:17 | 相关网摘，我也收藏
摘自：IT专家网
网格计算是伴随着互联网技术而迅速发展起来的，专门针对复杂科学计算的新型计算模式。这种计算模式是利用互联网把分散在不同地理位置的电脑组织成一个“虚拟的超级计算机”，其中每一台参与计算的计算机就是一个“节点”，而整个计算是由成千上万个“节点”组成的“一张网格”， 所以这种计算方式叫网格计算。这样组织起来的“虚拟的超级计算机”有两个优势，一个是数据处理能力超强;另一个是能充分利用网上的闲置处理能力。简单地讲，网格是把整个网络整合成一台巨大的超级计算机，实现计算资源、存储资源、数据资源、信息资源、知识资源、专家资源的全面共享。
网格计算的目的是，通过任何一台计算机都可以提供无限的计算能力，可以接入浩如烟海的信息。这种环境将能够使各企业解决以前难以处理的问题，最有效地使用他们的系统，满足客户要求并降低他们计算机资源的拥有和管理总成本。网格计算的主要目的是设计一种能够提供以下功能的系统：
提高或拓展型企业内所有计算资源的效率和利用率，满足最终用户的需求，同时能够解决以前由于计算、数据或存储资源的短缺而无法解决的问题。
建立虚拟组织，通过让他们共享应用和数据来对公共问题进行合作。
整合计算能力、存储和其他资源，能使得需要大量计算资源的巨大问题求解成为可能。
通过对这些资源进行共享、有效优化和整体管理，能够降低计算的总成本。
现在，网格计算主要被各大学和研究实验室用于高性能计算的项目。这些项目要求巨大的计算能力，或需要接入大量数据。
网格计算的目的是支持所有行业的电子商务应用。例如，飞机和汽车等复杂产品的生产要求对产品设计、产品组装和产品生命周期管理进行计算密集型模拟。其他一些实例还有，通过 Monte Carlo 方法对复杂金融环境的模拟，以及生命科学领域的许多项目。
网格环境的最终目的是，从简单的资源集中发展到数据共享，最后发展到协作。
资源集中 —— 使公司用户能够将公司的整个 IT 基础设施看作是一台计算机，能够根据他们的需要找到尚未被利用的资源。
数据共享 —— 使各公司接入远程数据。这对某些生命科学项目尤其有用，因为在这些项目中，各公司需要和其他公司共享人类基因数据。
通过网格计算来合作 —— 使广泛分散在各地的组织能够在一定的项目上进行合作，整合业务流程，共享从工程蓝图到软件应用程序等所有信息。
网格计算进入业务应用
Albert Bunshaft，IBM全球网格计算销售和业务拓展副总裁,曾是Rensselaer理工学院交互式计算机制图中心研究员。
何谓网格?
最近有关网格计算的讨论非常多，有的甚至可以用天花乱坠来形容。我相信网格是─种全新的计算方法。IBM将随需应变公司定义为一家在企业内部以及与关键合作伙伴、供应商和客户之间实现了端到端过程集成的企业。这样组织能够快速对任何客户需求、市场机遇或外部威胁做出响应。成为随需应变公司，企业需要创建一个随需应变的运行环境——一个具有集成、开放、虚拟和自主特性的基础设施。这时就需要谈到网格计算了。它是一种计算基础设施的新思维，这种基础设施能够支持随需应变的业务转换。
网格计算是随需应变运行环境的一个组建模块，它在使各类组织提高效率的同时，降低运行成本，从计算和数据资产中获得更多的价值。网格能实现多种分布式计算资源的虚拟化，如处理过程、存储容量、数据和网络带宽，从而创建一个单一的虚拟系统，进而为用户和应用提供对大量IT功能的无缝访问。简而言之，网格使客户从拥有的资产中获得更多的业务价值。
这很重要，因为很多公司都在面临新的“80/20”困扰：80%的计算机使用率不到20%。试想，如果公司能够将这些分布在各个地方的异构计算和数据资源连接起来，充分利用它们总的处理能力，并像对待一个单一、虚拟的大型机那样对它们进行管理，那将会是一种什么情形呢?
从理论走向后台应用
与互联网一样，网格计算起源于研究和学术机构。由于网格软件的成熟，及能支持对异构分布式资源进行集成的开放标准的出现，网格计算已经进入到商业领域。
业内有许多企业正在推动网格进入企业应用。IBM在2003年的网格战略以5个重点领域为中心，满足航空航天、汽车、金融、政府和生命科学行业客户的需求，分别在研究和开发、工程和设计、业务分析、企业优化和政府发展领域。根据这些重点领域，又推出了10种结构化的产品和功能，旨在帮助客户在获得网格计算能够带来的益处同时，向随需应变的电子商务迈进。
虽然实际网格应用的资源组合不同，但它们通常由以下三种类型的资源组成。
桌面：桌面浏览网格可以创建对─个大型处理容量资源池的访问。为实现这一目标，这些网格可以充分利用那些未使用的桌面计算能力。网格在终端用户计算机的后端运行，最常见的是以“屏幕保护程序”的形式出现——只有在PC未被使用时才发挥作用。桌面浏览网格特别适用于那些高度并行的分布式应用，如那些在科学和研究领域中使用的应用。
服务器：服务器网格与桌面浏览网格的类似之处在于它们也是强调在共享资源未得到全面使用时充分利用这些资源。此外，服务器网格可用于创建对专有设备的访问，以支持某─特殊的计算或处理过程。
数据：数据网格可提供单一数据源，用于实现共享和协作，可用于为大型协作创建一组数据源的单一虚拟视图。这一过程被称为“数据联合”。例如，一些数据网格，如英国的乳腺X线照片国家数字档案库和eDiamond网格，主要用于为很多处理站点提供大型数据集。利用这些大型数据集和网格计算提供的大型处理能力，科学家和研究人员可以创建对这些汇聚信息进行分析的应用。通过搜寻模式信息或特征信息，科学家们可能发现有关环境或基因致病因素的新知识。
网格的美好前景
网格计算技术可应用于很多业务和IT环境，包括如下几个方面。
研究和开发。这类活动基本上是信息和计算密集型的，涉及到使用多种方法，如分析、深入计算、数据挖掘和数据抽取。网格计算可以帮助提高研究人员的工作效率，对于那些要求在开发过程中确保保密性和离散性的竞争性市场环境来说特别重要。
商业智能和分析。此类网格通常用于执行大型的数据挖掘、数据智能和数据研究项目。采用传统方式，这些项目一般需要相对较长的时间(数天或数周)。网格计算技术能充分利用未用的计算资源，大大加快分析过程的速度，同时精度也高得多。
工程和产品设计。创建统一的产品开发网格，制造商们不仅能够实现跨供应链的协作，而且还能够利用扩展的计算功能来减少开发周期，降低开发成本和缩短进入市场所需的时间。
企业优化。利用网格，各类组织可以快速将不同的资源连接在一起，进行负载优化，从而能够跨企业边界以“不中断运行(on thefly)”的方式提供计算和数据资源。
综合来说，网格能及时响应需求的变动，通过使IT组织能够汇聚各种分布式资源和利用未使用的容量，网格技术极大地增加了可用的计算和数据资源的总量。网格计算可以帮助创建能够对意外流量和使用高峰做出快速响应的IT基础设施。此外，资源池的虚拟化使管理员能象对待一个单一系统那样，跨多个异构设备方便地监视不同任务的进展和状态。可以说，网格是未来计算世界中的一种划时代的新事物。
2002 年 8 月，IBM 宣布投入数十亿美元研发网格计算，与Globus 合作开发开放的网格计算标准，并指出网格的价值不仅仅限于科学计算，商业应用也有很好的前景。于是网格计算和 Globus 一起从幕后走到前台，受到前所未有的关注。
Globus 是美国 Argonne 国家实验室的研发项目，全美有 12 所大学和研究机构参与了该项目。Globus 对资源管理、安全、信息服务及数据管理等网格计算的关键理论进行研究， 开发能在各种平台上运行的网格计算工具软件(Toolkit)，帮助规划和组建大型的网格试验平台，开发适合大型网格系统运行的大型应用程序。Toolkit 是 Globus 最重要的成果， 其第一版在 1999 年推出，最新版本是 2002 年推出的 Release 2.2。 Toolkit 开放源码，任何人都可以从其网站上直接下载源代码。目前，Globus 的技术已经在 NASA 网格(NASA IPG)、欧洲数据网格(Data Grid)、 美国国家技术网格(NTG)等多个项目中得到应用。
在 2002 年的 2 月， IBM 与 Globus 共同发表了 OGSA(Open Grid Services Architecture)， 勾勒了Globus Toolkit 3.0 的蓝图。 OGSA 主要是将 Web Services、数据库存取、J2EE 等技术规范纳入网格计算。初步的规范已经公布在网络上供大家评估建议， 正式的版本预计将会在 2003 年问世。实际上，OGSA 的第一个供参考和评价技术用的部分已经于 2002 年 5 月 17 日在网上公布。 IBM 是网格系统和服务方面的领先供应商，已经为很多科技团体、政府机构、以及商业化用户的网格系统提供了产品和服务， 其中包括英国国家网格，荷兰国家网格，美国国防部网格，美国 DTF，宾州的乳癌档案库，北卡州的生物网格等等。 IBM 研究中心还使用 Globus 技术构建了自己的“蓝色网格”，该网格将分布在美国、以色列、瑞士、 日本和英国的 IBM 研究和开发实验室的超级计算机连接在一起，实现资源的共享和利用，同时也能对网格服务和解决方案进行测试和原型实验。
IBM 的 WebSphere 电子商务基础设施软件将为 OGSA (开放网格服务结构)网格服务标准提供一个可靠的实施方案参考。目前，IBM 正在与 Globus 合作，使用 IBM WebSphere 作为参考应用服务器，重新改造 Globus 的工具包以使其与 Java2 企业版 (J2EE) 兼容。
IBM eServer (™) 系列已经构成了世界上最强大的网格计算的硬件基础。IBM 存储部也宣布了几项支持网格功能的主要产品。此外，IBM 的全球服务部还将为正在考虑网格战略的客户提供各种服务。
除了推出一系列新产品支持网格计算的应用，IBM 还积极地与 Globus 这样的开放源代码开发团体和有影响力的行业标准组织“全球网格论坛”进行合作，共同推动开放的协议。 开放的协议是实现网格的基本条件，因为它们能够保证异构系统象单一的系统一样配合工作。
就如在电子商务中发挥领导作用一样，在网格计算的领域中，IBM 又一次走到了最前面。
http://webservices.ctocio.com.cn/comment/172/7830172.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-5 10:49:02 | 相关网摘，我也收藏
来源：IT专家网
在目前的中国制造业，很多企业，尤其是中型企业具有较高的成长性。他们对ERP已经不再限于财务管理的需求，而是希望能用软件管理企业的所有业务流程，包括原材料的采购、产品的生产、研发和销售等，其中也包括对合作伙伴关系的管理等。企业部署了PLM、ERP、MES、SCM、CRM等系统后面临的最大挑战在于各应用的整合，否则离散的信息孤岛将会成为企业整体运营效率提升的最大瓶颈。而且，缺乏连贯的数据流也无法使商务智能(BI)发挥最大的效率。
目前，只有SOA可以很好的解决这个问题。SOA的价值在于它的灵活性和可操作性。借助SOA，企业可以摆脱依赖于平台和厂商的技术，转而通过一种架构技术来从容应对不断涌现的IT问题。SOA意味着支持异构系统并最大化的利用现有IT投资。
作为世界工厂，当前的中国企业基本上是全世界产业链上的一个环节。产业链的上下游交互的IT成本已经明显高于企业内部运营的IT成本。SOA解决强异构问题的能力将使企业和上下游基于ERP等IT系统实现高效的供应链乃至整合重组都优势明显。
1. SOA为中间件带来了巨大的发展机遇。
SOA与现今流行的Web服务紧密联系在一起。Web服务提供了技术，而SOA则提供了应用这种技术的框架，这是一个非常好的思路，因此得到了软件业界普遍的认可。中间件对于Web应用具有简化和帮助其相互连接、相互访问的作用。目前，几乎所有新的中间件类型、新的中间件产品都支持Web服务，可以基于它们实现SOA架构的应用。正因为如此，人们将中间件视为实现SOA架构的理想平台。
凭借这种天然的联系，中间件搭车SOA也是一个增加曝光率的明智选择。中国市场对中间件的需求正进入旺盛的时期，而对于信息安全、信息整合、以及满足个性化服务的精细化方面，中国企业中间件有着特殊的优势，利用这些优势，企业完全可以在这场中间件的反攻战中赢得更多的空间，打造更强的竞争力。
2. 2008年大量中国企业将开始局部性实施SOA。
中国企业有不同于美国的独特的SOA关键任务。大部分中国企业在进行系统新建或改造优化，对系统整合的需求相对较少;而且已有系统难以被标准化切割成为SOA服务。相比美国实现SOA架构的关键任务——对已有系统中的功能进行提取和包装并形成标准的服务，中国企业的SOA关键任务是在一个标准的平台上构造企业所需要的所有标准服务。中国企业实现SOA架构时，原有系统将主要依靠服务来切割，或者推倒重来;大量的新建系统将采用标准的小颗粒构件构造流程级别的标准服务构件。
面向构件技术实现SCA/SDO国际标准，逐渐成为中国企业实现SOA架构的基础。面向构件技术的积极意义在于，SOA服务可以用构件来建造，SOA服务本身的管理和组装也是一个面向构件的过程。构造服务和整合服务是成功实施SOA的两个互补的重要方面。只有构建大量的SOA服务之后，方可通过ESB(企业服务总线)对服务的注册与管理，从而使服务被检索、发现并使用。基于构件技术的SOA服务构造和基于ESB产品的服务整合，是成功实施SOA架构的互补的两方面。
http://webservices.ctocio.com.cn/comment/63/7830063.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-3 15:50:14 | 相关网摘，我也收藏
摘自：计世网
笔者公司在过去一年时间内业务量增长4倍，原有的业务流程已经远远不能满足业务需要--IT系统承载的负荷越来越重，多次发生系统宕机或故障，业务部门的抱怨越来越多。在现实面前，我们被迫对IT系统进行调整以应对业务流程。
老板提出的IT目标是IT系统必须有灵活性，有余力接受公司业务进一步增长的挑战，但同时又不能影响原有的业务增长轨迹。而原有IT架构难以解决的最大难题之一是，技术层难以随着业务层的需求变化而灵活变身，而硬要改动技术层，则需要技术人员把系统上下左右分拆和重新焊接，不但成本昂贵，而且伤筋动骨，后患难测。因为原有系统中各子系统、各模块之间是一种"紧耦合结构"，拆分和沟通很不灵活。
原有系统的复杂度很高，为完成系统功能，定义了很多复杂的接口，并且代码相当复杂。比如，要想完成数据的抽取转换装载功能，我们必须针对不同的需求，重构这一功能模块。这些工作量和成本都非常巨大。
以上这些因素都迫使我们在应用新的IT架构时必须考虑商业成本和灵活的系统架构模式：首先，新的架构必须降低IT系统结构的复杂度；其次，需要减少系统的运营成本，同时，增加系统的灵活性。
柳暗花明 IT架构规划遇到SOA
笔者公司的IT规划包括三个层面上的内容：一是战略层面的规划，它主要确定的是信息化的大方向；二是IT项目层面的规划，它确定的是每一个具体IT系统的建设的目标范围，以及方案、实施计划与投资；第三是IT架构规划,它是IT规划的核心内容，是公司战略与IT目标的支撑框架，是联接公司战略与具体每一个IT项目之间的桥梁。
随着信息化建设的深入，IT架构成为公司信息化建设的核心问题，公司原有的IT规划，缺位主要表现在没有进行深入IT架构规划，在公司战略与IT系统之间，没有细化的框架联接，这种不完整的IT规划，导致造成巨大的IT投资风险和浪费。
就在我们关于如何规划IT架构经过多次会议讨论无结果而陷于绝境的时候，柳暗花明之处， SOA出现了。因为SOA使IT架构的构建机制发生了史无前例的变化，所以系统规划一旦加入SOA因素，企业就必然重新考虑IT规划的技术架构。
SOA变革基础架构
以前，随着业务需求和网络技术的发展，笔者公司产生了大量为满足产品或服务需要的软件系统，如:ERP、CRM、OA、SCM等。但这些系统一般都是单独实施、独立存在，由于数据标准不统一、接口不一致，系统间往往缺少联系与合作，这也就导致每一个系统成为一个孤岛。
SOA（面向服务的体系结构service-oriented architecture）与其说是一种技术，不如说是一种的思维方式。它是一项大胆的基础架构变革，表达我们如何通过技术和协同工作来实现业务变化。
与面向对象的技术架构不同，SOA架构所需要的服务模块可以分布在更为广泛的分布环境中，而不必像面向对象技术架构那样，需要使用大块的可重用去构建一个全新的系统。通过合理的部署，SOA系统可以改善原有的IT系统效率，使得原有的那些应用系统更具有柔性。
SOA架构的革命性思路是在传统的业务层和技术层之间增加一个服务层，服务层通过一套协议或规范把应用程序从底层技术层调出来，加以封装，再根据业务层需求灵活组合。
服务层不依附于任何特定技术平台，能够在业务层和技术层之间沟通、组合，业务应用系统就变成了"松耦合结构"，想用什么功能就调用什么功能，需要什么功能就装配什么功能，改动调整非常方便。而且这些构建在各种各样系统中的"服务"可以以一种统一和通用方式进行交互。保证系统灵活性，另外，还可以保证"服务"的重复利用。
SOA让二次开发成本降低为零
在笔者参与的项目中,有一个架构设计小组和两个开发小组，其中一个开发小组主要开发面向客户的应用服务，另一个开发小组主要开发核心系统服务。经过一段时间的工作，我们发现那些在业务流程中最基本最通用的功能是可以抽取出来，使用SOA架构进行重构。并且，系统的开发部署时间以及系统的性能这两个检验系统是否成功的两个关键标准都得到极大的改善。
①SOA降低成本。我们成功构建了一个通用的服务功能模块，在下一次开发时，我们可以直接调用这一功能模块。从这个意义上讲，第二次开发时的开发成本为零。
②SOA架构使管理统一。对于SOA系统而言，要想成功实施一个系统，必须从企业整体来通盘考虑，成立专门的架构设计小组，确定整个企业业务流程运作的最佳路径。这样整个业务流程及信息系统的管理将会实现统一管理，改变过去各部门、各业务环节脱节的现象。
③SOA架构从一开始就显示出ROI（投资回报率)，因为SOA反对四处出击，是按成本受益顺序确定服务开发的优先级。通过仔细的规划，启动成本就能限制在现有预算内。经过一段时间后，服务模块的重用会确保以后每个新业务应用程序的启动成本很低。在实施开始时设置好基线，确保可测量性，避免临时修路的效果。
http://cio.ccw.com.cn/research/qiye/htm2008/20080303_384743.asp
lizhe1985收录，使用标签：SOA，时间：2008-3-3 15:37:15 | 相关网摘，我也收藏
摘自：IT专家网
最近几个月来，关于业务流程管理(BPM)和面向服务架构(SOA)之间关系的讨论热闹非凡。二者也是多年来的热门话题，但是关于它们的讨论通常都出现在互不相关的论坛上，讨论它们的人通常也属于不同的圈子。不过现在这种情况正在改变，因为这两个概念以及相关技术的使用者和提供者正日渐将二者结合起来看待。
BPM阵营通常声称，SOA对于实现BPM来说不是必需的。只需部署一个BPM套件，就可以更快地实现目标而不会带来多少复杂性。SOA阵营则注重于如何从一般意义上解决企业IT的复杂性。该阵营通常声称BPM是SOA的一个特性，但是它是SOA解决方案的一部分，而不是一个单独的东西。当SOA领域的人士谈到BPM时，该术语通常与服务编排或流程整合同义，而不强调对业务分析人员友好的建模或人员交互，而后者对BPM阵营来说非常重要。
为了澄清这些误解，我认为有必要阐明BPM与SOA的不同本质：SOA是一种架构方法;BPM则是一组协调活动。
因此，可以很容易地得到使用SOA或不使用SOA的BPM，反之亦然。我们来看看不同组合的优点。
如果部署一个不使用SOA的BPM套件，则可以获得快速创建、执行和监控/管理业务流程的能力。业务流程的模型可以由业务分析人员创建，但是其完整实现则需要与底层IT系统的集成(以及定义用户如何与该流程交互，但是现在我们暂不考虑)。BPM套件(如BEA的AquaLogic BPM Suite)支持使用各种不同的技术(面向服务的或不是面向服务的)对应用程序和数据库进行轻松访问。实现由代码和来自于并依赖于底层系统接口的元数据组成，因此，对底层数据库和应用程序的任何更改都将导致对业务流程的更改。
如果组织和IT环境规模比较小，并且由同样一组人来控制所有的系统(包括BPM套件)的话，这是完全可以的。如果底层系统完全不更改的话，这种方法同样运行良好。
但是，如果BPM套件由一个小组部署，并消费来自另一个小组的系统的服务，那么协调和管理每个小组中的更改的任务很快就会变得非常困难。这是SOA要解决的典型问题，因此，SOA可以应用于BPM套件的部署，就像应用于其它地方一样。
如果BPM作为SOA的一部分进行部署，这意味着当一个业务流程连接到底层系统时，它连接到由企业服务总线所提供的代理服务，这样就隐藏了底层应用程序和数据库的复杂性。这具有以下优点：
* 将业务流程连接到系统的过程会更简单，因为IT可以公开更有用的接口，比如聚合的数据服务或使用标准协议而不是专有协议的服务。这减少了实现流程所需的IT工作量，并允许流程人员将精力集中于流程，而不是粘合流程与底层系统所需的技术。
* 它使得实现更为健壮，因为对底层IT系统的更改不必影响流程所使用的接口。
* 它在BPM套件之外提供了一个独立的控制和管理层。这允许IT小组更好地管理他们所拥有和维护的服务的策略和资源。
SOA还支持从BPM套件中获得对它所连接到的系统的更好可见度。IT小组可以在服务注册库中注册服务，流程开发人员(甚至可能是业务分析师)可以在构建流程时浏览这样的注册库。这确保了服务可以被正确地使用和重用，而且通常简化了业务流程，因为使用正确的服务可以将流程本身的复杂性降至最低。
无疑，这些优点只有在IT基础架构足够复杂，并且/或者BPM项目达到一定的范围和规模时才能显现出来。因此，在很多情况下，应该首先开发出BPM，而将SOA组件留待以后考虑。
最好的方法是一开始就让业务运作团队和IT企业架构小组保持良好的对话，并针对未来进行规划，同时支持战术性执行。这就需要正确地组合产品。例如，BPM套件本身应该能够提供丰富的连通性，以便无需全面应用完善的SOA来使得BPM运行，这一点非常重要。类似地，BPM套件应该支持SOA，这样BPM与SOA才不至于存在于独立的竖井中，这也很重要。
http://webservices.ctocio.com.cn/comment/253/7828253.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-3 15:35:44 | 相关网摘，我也收藏
摘自：IT专家网
Nucleus Research公司的一份最新报告中显示，在调查的106个组织中，只有37%的SOA项目产生了投资回报。
“人们有时确实成功地从SOA中获益，这种获益主要表现为开发人员工作效率的提高，”麻省的研究机构Wellesley公司的高级分析师David O'Connell称。“但我们发现应用的范围有些狭窄。人们倾向于在特殊的环境下或以部门为基础进行SOA应用。”
O'Connell称SOA的应用有“进退两难”的趋势。他指出，SOA的一个主要价值就是重用的概念。在SOA中，开发人员创建执行通用功能或“服务”的软件，这些功能或服务可以在不同商业环境中使用。它们可以在一个架构中被连接起来以执行业务流程。此架构的主要优点就是许多软件服务可以被重用从而在应用程序开发中节省时间和资源并加快部署速度。
O'Connell说，组织通常未能深入挖掘其SOA应用。他们将会看到在软件开发人员和测试人员生产效率提高方面的一些效益，但对这一可重用软件的应用尚不够广泛。例如，在Nucleus Research公司的调查中，开发人员的生产效率平均只提高了28%。
但公司没有足够深入应用此项技术。O'Connell发现在一般的组织中SOA只涉及了其现有IT项目的27%。在发布的软件服务中只有32%得到了重用。
加州的SOA软件和咨询服务厂商Tibco软件公司的市场副总裁Jeff Kristick指出，Nucleus调查的许多组织可能正在获得投资回报的过程上，他们只是还没有最终获得回报。
“对此次调查中项目的成熟度进行分析将很有趣，”Kristick说，“我认为那些获得了积极回报的公司有着更多的项目。”
Kristick指出，在最初的几个SOA项目中公司通常无法得到回报。只有在进行了几个项目并且公司开始重用软件代码后才能真正开始看到积极的结果。
O'Connell称Kristick的观点是正确的，但他补充指出还有其他一些因素也在其中起作用。
“能在最初的几个项目中获得投资回报将是幸运的，”他说，“你需要进行几个项目后才能获得积极的回报。但SOA的出现已经有一段时间，我认为缺乏投资回报的更多原因在于应用领域的狭小而不是项目的缺乏。”
组织未能达到适当的应用范围是因为他们未能将SOA重用的优点在内部散播。O'Connell称太多的组织未能拥有内部支持者以推动软件服务的重用。
“这是我们所强调的，”Kristick称，“如何促进重用以及鼓励开发人员在其工作的项目和创建的服务之外进行思考。关于这一点我们向我们的客户进行了大量的解释，而人们却总是低估这方面的作用。”
许多公司在注册库和存储库上进行了投入，开发人员可以从中找到能够被重用的软件服务。但仅有这些应用程序仍不足以保证重用。人力资源部门应该执行相应政策以要求开发人员重用这些软件服务。
但O'Connell称最重要的还是这些公司拥有内部的SOA支持者。
在Con-Way公司，一家位于加州圣马特奥、年营业额42亿美元的货运和物流公司，这一支持者是领先的企业架构师Maja Tibbling。
“高级IT行政管理是绝对需要的，”Tibbling说。“如果不是从架构的角度来看待问题，将不会有成功。只是进行随意的、不连续的工作而不管其是否成功，SOA将不会产生任何价值。
她说公司需要有SOA的传道者。
“人们可以谈论治理，”Tibbling说。“他们可以拥有很好的存储库，但如果没有人知道向那里看，他们就将无法找到所需的东西。你必须积极宣传SOA的好处并让人们了解重用意味着什么。
“关键是要以特定的方式来创建服务以便其能够在不同的环境中被利用，同时要为业务流程提供一个灵活的平台，”她说。
Tibbling从1995年就开始使用SOA，她说她正在将此技术从Con-Way公司的货运部门扩展到整个企业。她说在公司内部所听到的最大的应用障碍就是理解重用。
“我听到人们说，‘我们没有时间考虑服务的其他使用，’”Tibbling说。关键是要创建足够通用的软件服务以更方便地重用，但并不是通用到使其无用的程度。
Tibbling说许多开发人员通常都会抵制SOA，因为他们觉得其不够灵活。她说这使他们不能“只把工作完成”，因为他们必须花时间考虑分离服务中的功能和建立严谨的体系结构。
http://webservices.ctocio.com.cn/comment/232/7828232.shtml
lizhe1985收录，使用标签：SOA，时间：2008-3-3 15:31:04 | 相关网摘，我也收藏
摘自：IT专家网
大多数企业IT运营主要依赖批处理操作。这种依赖在你升级到SOA的时候也不会消失，尽管SOA仅意味着向许多人提供在线交易处理。IBM软件实验室服务部门主管IT设计师Sridhar Sudarsan遇到过这些问题。他曾指导过一些全球客户的企业架构解决方案。这些客户包括在金融、公共部门和汽车行业的一些大企业。
对于Sudarsan的客户来说，在这些客户转移到SOA的同时，批处理问题仍是一个大问号。
Sudarsan在J2EE平台上与其他人共同创建了IBM的批处理编程模型，在批处理现代化工作方面花了许多时间。他还演示了诸如“在SOA中的批处理最佳做法：转变状况”等主题，就像他在1月29日在旧金山举行的Open Group的企业架构从业者会议上做的那样。
批处理和实时处理
在批处理能够一夜之间简单地运行的时候，这个架构是简单的。它由工作申请、调度(使用一个调度程序和一个分配程序)和执行等组成。你有大量的数据流，使用某种类型的检查点机制反复进行处理。
现代批处理必须要发生，同时每一件都将或多或少地发生。因此，你必须要处理批处理窗口缩小的问题以及伴随的需要调度和优化IT资源的问题。你必须要把批处理集成到现代设计方式中，在Java/多平台上处理，把一些处理转移到Unix平台以降低成本计算。
对于某些用户来说，把批处理集成到现代设计方法的逻辑结论意味着所有的处理都将成为可处理的。
Sudarsan说，如果我遇到一个SUBMIT，我要立即得到答案。但是，他坚持认为这种事情不会很快实现。他解释说，你不能同时处理许多请求。这是你要严格的调度的原因。
Sudarsan并不认为在线交易处理(OLTP)将取代批处理。然而，他发现选择竞争优势的企业(或者仅仅为了生存的企业)需要把批处理与实时/在线处理结合起来。
在把批处理与实时处理集成在一起之后，企业通过维护较少的系统和通过进行技能的整合实现了成本优势。使用批处理和OLTP系统的人员可以使用一种开放的和灵活的架构。处理系统能够分布到各个地方。因此，批处理会更经常地、少量地、在更多的地方与OLTP一起使用。
Java程序员不知道批处理
Sudarsan承认，在谈到有关企业批处理系统的时候有一个令人担心的因素。他承认，人们确实害怕接触老式的系统。15或者20年前编写这些系统代码的人正在退休。新的程序员没有这些方面的技能，包括批处理以及如何把批处理与当前的系统和商业环境集成在一起的技能。
他解释说，客户没有财力为Java应用程序和批处理工作维护两个代码库。这两个代码库需要使用相同的逻辑，但是却不能使用。
每周7天每天24小时的处理需求意味着使用老方法的批处理应用程序必须要更换。此外，你不能让一切东西都是OLTP的，因为当前的硬件和软件不允许这样做。Sudarsan知道这些限制，因为他曾设法创建一个实时解决方案。
Sudarsan说，我也是这些情况的受害者。你在这种情况下可以提出一个雄心勃勃的架构。我们设法让整个事情都是实时的。但是，当我们经过测试并且升级到生产阶段时，一切都崩溃了。然而，他发现批处理与OLTP的集成是有用和必要的。
SOA实现了批处理/OLTP集成
Sudarsan总结了在一个现代化的努力中实现集成对SOA的需求。市场研究公司Gartner在研究报告中引述他的话说：
“...在线处理中使用的商业功能与在批处理中使用的商业功能是相同的。因此，机构应该考虑自己的IT现代化战略并且考虑把SOA当作一个标准化的应用程序集成机制。”
Sudarsan现在使用服务组合以便在SOA环境中使用批处理。
他说，一个批处理环境可作为一个轻型的包装物用于现有的OLTP应用程序基础设施。因此，你的处理编排使批处理成为一个商务处理步骤--另一种老式的集成方法。你不再需要从早上8点至晚上8点做OLTP工作并且从晚上8点至早上8点进行批处理工作。相反，你每天24小时都可以做批处理工作。
在概念上，你要把基于SOA的批处理工作量管理分为三个部分：批处理客户、批处理调度程序和工作量资源管理器。这个客户需要规划、调度、执行、监视和管理批处理工作的服务。批处理调度程序进行计划、优化、启动和编排无人管理的执行工作或者工作网络。这个批处理调度程序提供坚实和管理批处理工作的服务。然后，工作量资源管理在全部可用的资源中分配应用程序工作量以满足工作政策和服务水平协议的要求。
这种批处理执行环境可以是计算机集群、计算机网格和分布式环境，或者好的老式大型计算机。
共同的缺陷
Sudarsan说，那些努力要把批处理引进到21世纪的IT组织经常犯同样的错误。一般来说，这样的组织研制支持基础设施和安全系统的复杂的应用程序。他们过度使用第三方的库，向这个问题扔许多钱。
Java应用程序开发人员对这个过程控制得太多了，尽管他们一般都缺少有关批处理系统的知识。同时，这个平台的技术支持人员缺少能够证明自己的技能。
编码前要详细说明商务逻辑
Sudarsan在把批处理升级到SOA环境的时候采取了一种吸取教训的方法。他的最佳做法列表一开始就是避免许多IT部门采取的“预备!开火!瞄准!”的做法。
如果你仅做一项批量应用程序的“代码翻译”，例如要不费劲地从COBOL翻译到Java，这种事情可能是代价昂贵和不可行的。此外，你将制作出不可读的、不能维护的和不充分的代码。如果你要了解批处理工作的不依赖平台的模式是什么样的，你必须要了解商业逻辑和商业流程。
Sudarsan主张使用手工处理和工具创建这些商务逻辑/流程制品。他说。这样做是要保证捕捉当前的实施和满足未来的需求。自动的设计流程不会做这个事情。
速度胜过携带性
Sudarsan接下来说，为了提高效率，你需要把处理功能尽可能地安排在这个系统附近。这对于Java程序员来说是很难接受的，因为这些程序员接受的教育就是便携性超过一切。
但是,即使Java用于目标批处理平台，那也不是实施每一个组件的规定或者Java工作。
例如，你应该把分类放在操作系统的层面。你还可以从Java启动这个分类。分区也不应该用Java完成，操作系统互动也是如此(具体操作系统的登录、审计和监视)。你也许在OLTP系统中的用Java做这个事情。但是，在批处理过程中，数据(文件、数据库)的数量之大无法使用Java。
如果批处理的工作流不寻常地轻，你应该仅选择一种更便携式的实施。但是，Sudarsan说，整个纯数据处理或者ETL(提取/转换/装载)式的处理最好在数据层完成，而不要在对象层完成。
瞄准有效的数据访问
批处理性能问题可能拖整个系统的后腿。Sudarsan说，避免出现这个问题的关键是有高效率的数据访问。他提供了9个可以利用的领域以便在设计数据中心模型的时候保证快速访问：
·还存
·把只读数据与更新数据分开
·全球文件系统
·数据分区、移动
·复制
·大量数据访问与一次的单个记录
·并发性/争论/一致性
·数据联合/转换/虚拟化
·规定数据内容的宣布方法和对一个工作的需要
把数据放在应用层附近
最后，据Sudarsan说，你把数据放在应用层附近能够极大地提高数据的吞吐量。
如果你的应用层和数据层互动很麻烦，性能就会下降。如果你把数据放在应用层以外的不同的子系统，你也会造成性能下降。这样做将导致管理费用问题。这些问题是由网络负载、翻译、串行化等引起的。
做移植工作的四个步骤
你当前的实施可能使用几种独特的批处理功能。如果是这样的话，你每个功能需要采取四个步骤：
·询问在用Java实施时作为一个单独的批处理功能是否需要一个特殊的步骤。也许它能够合并，也许它需要分开。每一项实施应该需要总时间的十分之一。
·找出批处理的组建--数据流、逻辑、检查点和相关的工作控制参数。这应该用你的30%的时间。
·编写不依赖于批处理容器逻辑的商业逻辑，提供批处理应用程序能够调用的一个应用程序编程接口(API)。这应该占你20%的时间。
·测试(单位、性能和升级性)和调谐。这应该占你40%的时间。
Sudarsan称，只要你有人力资源能够实施这种可升级的开发模式，这个过程能够让你并行开发多个工作。
Sudarsan最后介绍了IBM用于J2EE的批处理编程模型。它的关键的功能包括异步执行、处理架构、面向记录和容器管理的设计、一个真正的批处理编程模型和使用XML工作控制语言。他最后介绍了他如何设计在大型计算机上执行现有的批处理应用程序的Java wrapper。
他对于Java程序员的基本观点是：只要他们熟悉每周7天每天24小时批处理的特殊需求以及这些需求如何能够满足OLTP的需求，他们就能够开发很好的批处理系统。
http://webservices.ctocio.com.cn/comment/215/7826715.shtml
lizhe1985收录，使用标签：SOA，时间：2008-2-29 11:25:43 | 相关网摘，我也收藏
来源：IT专家网
在商业社会，只有永远的利益，没有永远的竞争对手。而SOA也会在这种竞合中稳步向前，成为下一个主流。
SOA正逐渐成为一个流行的词汇。IBM、SAP等IT服务厂商都宣布投入重金进行SOA的研发。但是，就像任何其他软件技术一样，国内SOA发展状况跟国外比还有一段距离。
有厂商认为，目前中国的SOA还局限于技术人员间的探讨，还没有到大规模部署和实践的时候。对于这一点似乎没有人提出疑问，因为尽管中国企业的基础信息化建设已经比较完善，但涉及到更高层次的应用还有诸多掣肘。
SOA最吸引人的地方在于，通过实施SOA可以实现更高的业务和IT一致性。它的整个IT系统是基于松散耦合组件组成的系统，建成的系统允许分散于各地且采用不同技术的资源协同工作。它要求研发人员开发的程序有更多的通用性。通俗来讲就是有标准化的接口，可以将各种组件迅速组装成为新的产品和服务。
显然，要实施SOA，难点在于把整个业务和IT逻辑重新梳理，提炼出更多的共性模块，之后的技术实施反而不是关键。
在中国的电信、银行对SOA需求迫切的行业，企业内部的信息化系统很多是按照部门来部署的，每个部门都有自己的利益，因此希望通过大集中式SOA部署，一次性实现所有部门和系统之间的共性组合，显然是不现实的。与此同时，各个部门为了应对日益加大的竞争压力，都希望在局部的范围内实现尽可能多的业务一体化组合，也就是希望快速而波及面小地实施SOA。此外，中国企业在信息化建设上，一向信奉稳重推进的策略，它们不希望一下子上马一个牵动全公司的项目，而是先试点，成功后再逐步推广开来。这种信息系统的实施性格也决定了集中式SOA在中国推进的困难，尽管从SOA希望实现的最终目标来讲，集中式SOA是最合适的。
IONA中国区总裁薛志勇就主张SOA实施应该是分布式的，能满足企业在局部实现SOA部署的需求，而不是大包大揽，所有系统都进行SOA转化。今年IONA公司通过大唐软件帮助内蒙网通公司上SOA，在条件准备充分的情况下，开通一个接口或者一个服务最多两天，少则一天就成功实现了SOA。
当然，任何公司都是根据自己的技术特长和产品优势来推广SOA的，IBM、SAP、IONA、普元等都是如此。它们的这种“自卖自夸”式的宣传一定程度上把整个SOA市场炒热了。但是它们作为一个盈利企业，不会死板到只推广自己的SOA模式，而不理会别的公司的方案和产品。当自己所掌握的客户有需要，而自己又一时没有性价比合适的SOA产品提供的时候，与竞争对手合作也不是不可能的。在商业社会，只有永远的利益，没有永远的竞争对手。而SOA也会在这种竞合中稳步向前，成为下一个主流。
http://webservices.ctocio.com.cn/comment/214/7824214.shtml
lizhe1985收录，使用标签：SOA，时间：2008-2-29 11:24:11 | 相关网摘，我也收藏
来源：IT专家网
大多数的组织在对SOA思考的时候都会处于这样的境地：他们想确定他们最终在何时以及是否应该投资SOA，以及很多其他的问题，例如进行这项工作应该选用哪些工具以及哪个软件生产厂商的产品。但是，由于技术解决部门应该有这种方案，很多在SOA领域的软件厂商现在都在面向SOA的客户推出一个全新的概念，那就是事件驱动结构(EDA)。这个概念看上去是一个新的术语，其使用了在SOA领域广泛实用的首字母缩写的方式。因此，我们将来看看EDA这个概念到底是什么意思，以及它是如何和SOA市场相关的。
让我们先从探索当我们在企业软件部分谈及事件的时候，我们会最有可能想到什么事情这件事出发。对于很多人来说，他会让大家要么想起信息中间件，要么想起什么异步通信，出版/订阅标题，JMS，MSMQ或者是其他一些能够建立事件提示的技术。当然了，这些都不是什么新的技术，因此我们可以将目光转向能够解决简单情形的Web服务标准。在Web服务标准中，你可以看到Web服务事件(WS-Eventing)，它是由OASIS组织的W3C(Web服务公告)制定的。咋一看去，这是一个将基于服务的架构和事件处理混合起来的东西，但是，事实上，这是一个很精妙的想法。
而EDA是一个更加广泛的概念——很像SOA自身也是一个方法一样——EDA在事实上已经被研究了很多年。如果在过去几年你曾经听说过有软件厂商推出过复杂的事件处理流程(CEP)，那么实际上你已经对EDA所涉及到的部分有所了解了，尽管也许你并没有意识到那三个缩写字母的含义。而对那些不熟悉这一概念的人们来说，在CEP和EDA之后的假设是在存在确定的系统事件的基础上运行的商业逻辑。事实上这样做是发源于非常广泛的媒介中的，甚至包括前面提到的出版/订阅中间件来进一步描述类似通过RFID扫描仪进行事件探索以及平凡如在数据库里发生的事件的设置的情况。
在这种判断下，CEP的软件厂商开拓出了跨行业的充满机会的市场。特别是在事件敏感逻辑对企业非常重要的财务和制造行业，股票指令触发或者完成操作等对企业都会产生重大的影响。但是在面临这类问题领域的过程中，不止一个的CEP软件厂商都不得不为企业特定的系统中存在的有意义的事件开发特别的方法，创建过多的所有权引擎，适配器，查询语言以及理所当然的各自的管理、监控和编辑工具。
上述的种种都导致了在早期的SOA建议者、CEP软件厂商以及事实上有效的EDA这些SOA2.0的组成部分的分离。站在CEP的立场上，几乎没有能够使得CEP实现成为事实的目的的SOA的技术或者是其他相关的技术。这使得CEP在2000年在生产类型的情况下，没有SOA的影响就取得成功的原因。
但是，让我们再看一看到底是什么使得CEP对企业而言是特殊的。绝大多数CEP解决方案的卖点在于他们能真正提供实时的事件处理。而这正是和中间件事件处理系统的静态方式完全相反的。这样做避免了在相关的找回存档事件中或者仅仅是在简单的为了描述极端的事件流程而决定行动的路线的活动中承担延时。因此就像俗语中描述的那样：通过SOA的设定，我们获得了基础的鸟瞰图：基于标准的松散的耦合的接口/服务，能够跨越企业层级和不同平台的访问等。举个相关的例子，就是通过用相同方法访问事件的可能性简化了的对企业大多数数据的访问。
尽管对CEP的需求仅仅是在一小部分行业中是至关重要的，但是，他并没有花费SOA供应商太多的精力去描述存在利用同样的基础设施加载SOA以实现CEP需求的商业机会，其所导致的术语有：事件驱动SOA、作为SOA2.0的EDA，包括围绕同样的范例的大量的引擎和产品公告。直到在CEP市场中旧的防护被关注——如果你愿意就是非SOA营地——在同样的语句中联合SOA、EDA和CEP上存在一定的抵抗性，尤其是在SOA风暴之前大多数都做得很好。
事实是SOA从CEP中获取了很多，就像CEP从SOA中获取很多一样，在现在的状态下，基本上每一件SOA产品线都缺乏实时的事件处理能力，而其在小的CEP引擎中存在，从另一方面来说，大多数CEP引擎拥有成帧技术——读取供应商占据——以执行实时事件处理，他们都能从已经开发的SOA设计中获益。不管是术语SOA2.0或是EDA都将会被如“模糊”的已经成功的中介所惩罚，但是其将很快成熟，在流行的SOA供应商和小的CEP供应商的产品之间存在一个倒数关系，不管其是如何称呼的。
http://webservices.ctocio.com.cn/comment/357/7824357.shtml