??xml version="1.0" encoding="utf-8" standalone="yes"?> 从偶然架构到一个全球规模的l一的集成基设施可能是像一个人畏~的d?把一切都准备qAQ然后再象扳动一下开关那样将所有的应用都一下子转移到新的基设施之上是不现实的。这已经是组lؓ(f)什么老是要不断添加偶然架构方案作为权益解决之计的一个主要的理由Q甚至他们确实知道这样相关的问题永垂不朽也是如此? ESB 提供?jin)能力来帮助减轻所介绍的痛苦?W?9 章将通过一个案例来介绍如何q离一个完全徏立在 FTP 和每夜批处理作业之上的早以存在的集成解决Ҏ(gu)? 让我们现在重新回到对偶然架构的讨论?在图 2-6中,实线、虚Uѝ点划线代表用于集成的不同类型的q接技术和通信协议。注意其中有一个用集成Broker表达的已存在?“集成孤岛”Q以?qing)POS应用和胦(ch)务应用之间的q接是用FTP 文g传输。在POS应用和ERP应用之间先前已经升来用HTTP 之上的SOAP协议Q正如销售自动化应用 (SFA) 和客户关pȝ?(CRM) 之间的联l? 图表 2? 使用SOAP通信?FTP 、手工插座(SocketQ、而且包括一个集成Broker的代表性的偶然架构 ESB 可以在一个部门的层ơ或在一个项目的基础上被引入?在项目层ơ采?ESB 允许你能够习(fn)惯于使用 ESB 服务容器q行Z标准的集成,q且完全可以坚信该项目能够集成到一个更大的集成|络之中Qƈ且与企业U的公司的集成策略目标相一致? 我们采用ESB的例子中的第一个步骤是要集成前端应用(F(tun)rontOfficeQ。在?2-7 中,前端的CRM、胦(ch)务和SFA 通过“服务容器”q接到ESB 之中。这些容器是 ESB 架构的主要组Ӟ我们在W?6 章详l解释?l过 ESB 服务容器q行的集成的Ҏ(gu)可能会(x)不同?容器和应用之间的接口可以通过使用W三方的应用适配器来完成Q容器可以暴露用WSDL描述的XML数据Q或者它可能被实Cؓ(f)完全用户定制的代码? 图表 2? ESB 可以在不打破原有点对点\径的前提下,在单个项目基上采? 但是也许更有的不是那些已经集成到ESB 之内的东西,而是q没有集成进ȝ东西。图 2-7 表示?jin)已有?FTP 和SOAP协议之间的通信U,原来是连接到前端应用的,现在直接q接到那些特别配制来使用那些协议q行通信的ESBlg。应用仍然处于ȝ“之外”QPos应用和伙伴CRM应用可以与集成到ESBȝ“之内”的前端应用进行通信而不需要做M修改Q对他们如何参与ESB基础设施也不需要知道Q何东ѝ注意,现在POS应用是连接到ESB 上的一?FTP 桥接器,而且伙伴CRM应用则是q接到配|ؓ(f)ȝ的一部分的Web Services端点? ESB 已经被引入了(jin)Q但是对q些配备?jin)ESB能力的应用以前所q接的点对点通信l合区没有生Q何媄(jing)响。被插入ȝ的应用如今{而用连接到ESB 集成容器的一个单一接口Q?而且已经省却?jin)对它们先前所有其他类型的通信q接的管理和l护? 我们会(x)在第 9 章中看到Q即使是ȝ域中最新集成的应用也可以就地将他们转移到完全的ESB方式Qƈ且与它们各自的项目开发时间线怸致? 在我们的ESB采用的例子得下一阶段中,POS应用在每一个远端实现ESB能力Qƈ且去除对不可靠的 FTP 联结上的依赖?q可能会(x)单如在每一个远端安装一个ESB容器Qƈ且插入到总部的ESB之中Q或者涉?qing)到在每一个远端的多个应用之间的一?#8220;q你”的集成环境。那么二?ESB节点可以通过一个基于可靠消息的安全q接q行通信(?2-8) 图表 2? 在各个地点分立安装的ESB可以安全和可靠地q接在一? 此外Q远端位|仍然可以在他们自己的分集成环境里面运行,q且可以按照需要有选择地共享数据。例如,q端位置可以独立地拥有ƈ且运作一个属于集体特许经营的零售店铺。它们没有必d享关于它们的日常q作的信息,但是的确需要共享诸如h(hun)格更新和库存?sh)息之类的数据。远EESB 节点可以q接C于总部?ESB |络Q有选择地暴露消息通道以共享h(hun)格变动之cȝ数据? 我们的ESB 采用CZ目的第三阶D|?qing)到桥接q进一个已l部分地与一个集U器-?插头 EAI Broker集成在一L(fng)部门。我们先前提醒过Q采?ESB 不是一个全有或全无的概c(din)如?2-9 所C, ESB 允许IT部门通过一个已存在?EAI Broker桥接到ESB之内来保护它里面的IT资? 图表 2? “保留-?分层”方式允许ESB桥接到EAI Broker安装之内 桥接 EAI Broker可以一多种方式q行。比如,它可以通过使用一个Web Services接口来完成,或者绑定到下层的消息通道。依赖于ESB?EAI Broker 的实玎ͼESB 更加可以建立在EAI Broker下面的消息队列基设施之上Q因此部分地替换EAI Broker的功能仍然可以保留较低层的、消息通道? 我们?ESB 采用CZ目的最后步骤是解决和业务伙伴集成的问题。如?2-10 所C,q可能包括原样保留SOAP联结Q以?qing)在每个伙伴端安装一?ESB 节点。决定采用哪一U方法完全依赖于你的l织和伙伴之间的关系Q以?qing)业务伙伴是否允怽在其地点安装软gQ或者他们已l有能够q接C的ESB之上的ESB? 图表 2?0 ESB 可以个别地管理与业务伙伴的SOAP联结, 或者可以连接到另一个地点的ESB节点 插入C?ESB 扩展的分层的服务能够理对伙伴的q接的后勤保障。例如,一个特D的伙伴l理者服务可以在每一个伙伴的基础上管理与伙伴之间的正在进行的协作的细节。这些细节可能包括正在用哪一个更高层ơ的业务协议(比如Q?ebXML、RosettaNet {?、以?qing)对话的状态,比如消息交换的当前状态、是否收C个期望的应答消息、以?qing)从业务伙伴接收C个业务响应所能够接受多长的时延? 本章包含下列主题Q? 2.4.1 从单个项目层面引?/a> ESB
2.4.2 跨广泛分布的企业传播ESB
2.4.3 保留和分?/a>: q入现有?EAI Brokerq接
2.4.4 集成伙伴
2.5结
]]>
在我们l前qƈ且牺牲我们的先前努力Q丢掉前面的每个技术,q且向失败Dh们的双手之前Q还有一条\能够让我们能够利用从学来的宝늻验,q且仍然q离偶然架构—那是采用ESB?集成的最?jng)_践,已经l过寚w成Broker的经验被_Q如今还可以l合建立于XML、Web Services、可靠的异步消息、以?qing)分布式的ESB集成lg之上的基于标准的架构来一起用?他们一起Ş成一个高度分布的、松散耦合的集成架构,以提供集成Broker的所有主要功能,却没有其所有的障壁?
q离偶然架构q且使用 ESB重构到的一个统一的和一致的集成骨干Q涉?qing)到下面结描述的步骤?
虽然ESB 实能够传送许多类型的数据格式Q但是采用XML作ؓ(f)应用间交换数据的手段 (?2-2)Q如同已l被用在一些传l的 EAI 方式中一P可以由很多好处。我们将?x)在W?4 章中看到Q用XML可以一x(chng)逸地隔绝全局的数据格式和接口的变更和偶然架构本n。ESB可以q一步通过(g)查XML消息的内容,q且控制其向何处提交Q有时候还可以改变提交路径来包括可能会(x)修改和增加数据的附加服务Q一ơ来?j)进业务处理?
图表 2? ESB 使用XML来作为应用间׃n数据的方?
?SOA 的方式来思考和规划在向 ESB重构的一个基本步骤。如?2-3 所C,服务U接口的引入在提供了(jin)一个公共抽象层来创建接口和实现之间的分R这样就通过使用一U通用的接口定义机Ӟ比如Web Services描述语言(WSDL)Q来减轻?jin)由l粒度服务接口组成的复合业务程定义的构造的隑ֺ?
图表 2? Web 服务?SOA 提供?jin)一个隔L口和实现的通用抽象?
虽然服务U接口的抽象是正方向上的一步,l果仍然是一个\由逻辑密合于应用之内的连?( 注意在图 2-3 中,“流E逻辑”仍焉附于应用)。Web Services中的传统智慧已经模仿?jin)客?服务器模式。甚臛_一个Web Services分布式网l中Q一个应用L另一?“客户”。范例用法仍焉要抽象层也包括胶水代码,比如说“调用服务X上的Ҏ(gu)aQ然后调用服务Y上的Ҏ(gu) b()?”诸如此cR?
Web Services实现中所实的东西是流E\由逻辑从接口定义和应用逻辑中分d来观c(din)如?2-4所C,ESB 提供了(jin)那种隔离Qƈ且仍然完全利用SOA?
图表 2? ESB 业务流E的路由逻辑从接口定义和应用实现中分d?
通过分离接口定义和流E\由逻辑Q我们已l开始看到ESB 形式的ȝ??2-5)。通过流E业务\由逻辑和接口定义放入ȝ层之内,应用能够l箋自己集中于实现逻辑?我们在第 1 章中看到q,ESB 被实际上区分为多个功能层。它为应用间的可靠的、异步的、基于消息的通信提供?jin)一U坚固的底板。也是在q里Q流E\由通过Z(g)查消息中的XML内容来附加的条g决策点,从而变得具h能。这个智能\由是被可理地定义的、可以被修改、ƈ且可以加上增值服务,比如补充数据变换功能。ESB 提供?jin)一个可扩展的集成服务网l,q且可以无限伸展Q同时仍然可以以逐渐增加的方式进行构?
图表 2? ESB 可靠地连接和协调SOA 的服务之间的交互
q一节将详细讨论Q今天各个企业应用怎样q行集成、或者怎样没有集成。还包括对今天很多组l中很流行的集成方式Q偶然架构的讨论?
在过M十年以来Q无数分布式计算模型一一dQ包?DCE、CORBA、DCOM、MOM?EAI Broker、J2EE、Web Services?NET?然而,q象表明Q不采用何U技术,只有很少C业的应用时很好连通的。按照来?Gartner 公司的一个研I报?a href="#_ftn1">[1]
Q这个数字少?0%?关于应用的连通性,其他的统计数l果更o(h)人吃惊,?只有 15% 的应用的集成采用?jin)正式的集成中间件。其余则使用 ETL 和批量文件传输技术,其主要以手工~写的脚本和其他定制Ҏ(gu)为基。关?ETL 和批量文件传输的更多信息Q以?qing)他们相关的问题Q我们在W?章讨论?
Gartner 15% l计值提供一个关于当今的集成状态的一个o(h)人深思的数据。那么其?5% 的应用是如何q接的呢? 一U在今天的企业中普遍存在的情形,我将其称为是“偶然架构”。所谓偶然架构就是没有h公开宣布创造的Q相反,是多q积累的一U?#8220;׃Z”的解x(chng)案。在一个偶然架构中Q公司的应用被永q锁定在一个不灉|的刚性基架构之上。然后他们又被视为是信息“地牢”Q因为集成基设施不能适应新的业务需求?(?2-1)
大多数集成尝试都从某个深思熟虑的设计开始,但是l过一D|间后Q其他的部分好像都各各位地“集成”?jin),但是手工~写的代码却早已飘移出原来的内容之外。经q逐渐q行的螺栓和补丁Q所谓整合的pȝ已经失去?jin)其原来的设计完整性,其是如果系l是被很多的人来l护的,而他们对最初的设计意图可能没有很好地沟通。事实上Q这U?#8220;׃Z”的方法将完全失去集成的一致性,因ؓ(f)工程师d?#8220;只是做一点点修改”作ؓ(f)解决问题的权益之计。最后甚臛_扑և那些地方做了(jin)修改都变得非常困难,更不要说要理解这些结果导致了(jin)那些斚w的副作用影响。在一个部|系l中Q这可能?x)对你的业务造成损失惨重的?zhn)惨结果?
寚w成遵守标准能够ؓ(f)你创Z个针Ҏ(gu)期望功能的基U来遵从。如果基设施是专有的Q?不基于标准的Q那么随旉变化保持计划的设计和指导原则变成棘手问题。虽然也可以构造专有的q_q且变通规则,但是q通常又导致更?#8220;多样?#8221;的后果,l果更加锁定于其上。然而,你应该记住的是简单地遵守标准q不必然地阻止你构徏一个偶然架构?
图表 2? 偶然架构永q公司的应用成?#8220;信息发射?#8221;
在偶然架构背后的技术是各不相同的。图 2-1中的实线、虚U和点划U表CZ(jin)q接应用的不同技术。这些技术可能包?FTP 文g传输、直接的socketq接 、专有的MOM、以?qing)有时?CORBA 或其他类型的q程q程调用(RPC) 机制。某些定向的点对点解x(chng)案可能已l用了(jin)XML信封定义Q或者基于SOAP或者其他什么机制的技术,来ؓ(f)集成的应用之间承载数据?
图中间的集成Broker表示?jin)在部门U的层次q接应用的一个岛ѝ然而这q不意味着它能够连接Q何事物。集成Broker通常只是l交l基设施中的某一块,因此资金丰富的项目可能会(x)取得适度的成功,但是它们再也不能与其它所承诺的部分进行很好的集成?
偶见架构表现为得C个刚性的Q不能对集成提供一致的、持久的基础设施。它不能如其应该辑ֈ的效果那样很好地解决你的l织性的问题。要改变偶然架构一直以来就是个挑战Q因为点对点的解x(chng)案的数量不断在增ѝ这通常也意谓着应用之间的互怾赖性是紧密耦合的。应用中的数据的表现的修改意谓着你还必须修改׃n该数据的其他所有应用。这限制你快速地改变?sh)的业务程Q以适应变化?jin)的或者新的业务机?x)。这些紧密耦合的、硬q接的接口不仅仅是偶然架构的问题。因为控制流、业务应用之间的通信的编排被编码进应用本n之中Q这q一步导致了(jin)复杂化。这些都增加?jin)系l之间的紧密耦合和脆弱性,使变更业务流E更加困难,q且D?jin)厂商所定?
偶然架构的先天技术不队l织中的人力协调问题h推L助澜的作用。不问题是紧密耦合的接口还是硬~码的流E编排,要想回头或者对其进行较大的L攚w简直是一件恐怖的事情。这l常需要安排大量的?x)议Q和属于不同目的不同的开发组的h们开?x),q紧对要做什么以?qing)何时做q类的问题达成一致。如果应用,以及(qing)他们分属的开发项目组Q分别处于不同的地理位置和时间区Q应用改变所需的协调问题则?x)变得更加困难?
有时某些应用E序被视?#8220;遗留”pȝQ对他们你是不愿意或不能够对其进行多修改,因ؓ(f)它们已经q入l护模式。我们通常_(d)“遗留pȝ”的一个定义就是那些你昨天刚安装的pȝ。即使你对自己开发的应用h完全的访问和源代码的控制权,当开发h员l进行其他项目或d公司的时候,对其q行修改也是非常困难的。我们将?x)在W?4 章中看到Q?ESB 大大地减了(jin)随时间变化,修改数据模式和格式所带来的媄(jing)响?
即你已l对跟踪和修改应用数据及(qing)其接口徏立了(jin)良好的公司实践,偶然架构仍然q有其他~点。用不同的q接技术意谓着安全模型可能是杂的Q所以没有确定的方式来徏立和执行公司U的安全{略?Ҏ(gu)入新的应用没有一致的 API可以依赖Q而且没有基础来在上构徏公司关于集成的最?jng)_c(din)最q与一些领导的专家q行?jin)交,ȝ?jin)偶然架构的下列各项问?
应用之间的通信或许能得益于异步的消息的可靠性。如果一个大型业务流E中的某两个应用之间的通信q接p|Q整个业务流E可能会(x)事务性地q回或者重启。我们将?x)在W?章学到更多有x(chng)散耦合的、异步的可靠消息的更多内宏V?
不管你是否你已经有了(jin)一个预先的性能规划q且试图分析一个现有的性能问题Q由于偶然架构的许许多多的子pȝ和他们各自的q行特征Q这个工作是极其困难的。通常的做法是采用h的?#8220;投入资源到其中,直到它能正确q行”式的解决Ҏ(gu)Q这造成盘、处理器、内存等上面的过度开支?
没有哪个单一Ҏ(gu)能够提供充分的诊断和报告能力?意外架构需要很多具有很高能力的l护人员围着所有有~陷得生产系l{Q这导致整体拥有成?(TCO)的急剧上升。各部分实现的方式差异越大,在其失效旉要用来解军_们的问题的专家经验就宽。另外,建立一个基U来描述期望的正行Z是一个挑战?
没有M方式能够保证q个泥潭中的所有组建都能够满你的关于可接受的冗余、弹性和定w度的定义。这意谓着要ؓ(f)依赖于后D늳l的新功能定义可辑ֈ的服务别协?(SLAs) 是很困难的?
如果你的pȝ携带又能够收费的帐单数据 ( 比如?sh)?Q那么̎单数据的利息可以被丢失在偶然架构之中。因此,你可能会(x)损失收入q且q(sh)炚w不知道?
没有一致的Ҏ(gu)来监控和理一个偶然架构。假定你的整合应用系l必运?24/7 Q而且你的职员负责x(chng)q行监控工具Qƈ且做出纠正。这些工具将不会(x)以相同的方式工作Q那么在无数不同的小Ҏ(gu)的基上进行培?( 和再培训) 是非常昂贵的事情。简单地安装企业U的q行理工具q不能自动地自省能力提供给集成基础设施Qƈ且偶然架构通常q不能提供所有可能需要的控制炏V?
总而言之,偶然架构表现ZU刚性的、高成本的基设施Qƈ且不能满你的组l变更的需要,q要承受以下~点的痛苦:(x)
如你所知,偶然架构的创建已l有些年头了(jin)Q要替换和解军_q不是一y而就的事情。随着l承目的需求的增加Q解x(chng)案应该更加柔性的、简单、以?qing)运行便宜,而不是其他什么东ѝ偶然架构给?jin)你的那些敏L(fng)竞争者得到好处,而你却不能够在一个合理的旉范围内实现新的业务机?x)?
你需要一个内聚的架构Q面向实c(din)标准来解决着大量的问题。ESB 提供?jin)架构和基础设施Qƈ且你能够逐个目的基上采用它。采?ESB q不是全有或全无Q推倒重来式的方式。而是Q你可以渐进式地采用它,同时q能利用你的现有资-包括偶然架构和集成BrokerQ以一U?#8220;留下而分?#8221;的方式?
提取、{换、和载入 (ETL) 技术,比如 FTP 文g传输和每夜批处理式的集成在今天仍然是最行的方法?
q通常涉及(qing)到将位于各个应用中的数据打包然后上传q样的操作。问题是有很大的可能在应用间的数据失d步。一个失败的打包上传的处理程序可能要׃一天的旉。在京及(qing)和业务全球化的情况下Q系l以24/7 的方式运行,再也没有?#8220;夜晚”的概念,那你得批处理又该在何时执行呢Q?
其他问题?sh)可能与每夜的批处理相关。因为批处理的反应期问题Q在分析关键业务数据的时候,最好的情Ş?4 时轮{旉。这一延迟可能严重地阻你寚w时变化的业务事gq行反应的能力?
有时Q一ơ跨多个面向批处理pȝ的端对端处理处理甚至?x)花费一整个星期才能完成。处理从源头到目标的数据的M潜伏反应期完全阻止了(jin)攉h意义的,反应目前业务情Ş的数据的z察力。比如,在供应链的场景中Q这导致你永远不知道你的库存的真实状态?
W?9 章将?x)呈C个通过FTPq行成批传输的技术和业务意义的案例研IӞq且?x)研IESB如何能帮助你逃脱偶然架构的困境?
集线??插头的集成BrokerQ或者EAI BrokerQ提供了(jin)偶然架构的替代。集成Broker是从上世U?0q代出现在,现在已经被植入到MOMd或应用服务器q_之中?
集成Broker?jng)场的一些公司包?
集成Broker能够使用一个集U器-?插头架构帮助偶然架构提供应用之间的集中\由。此外,他们q允怋用业务程序管?(BPM) 软g业务流E从下层的集成代码中分离出来。到此ؓ(f)止,所有的都是好消息?
然而,寚w成Broker方式也有~点。一个集U器-? 插头拓扑不允许对局部集成域之上q行局部控制。构建在一个集U器-?插头拓扑之上的BPM 不能够徏立跨部门和业务单位的业务流E极其编排?集成Broker也可能受限于下面的MOM不能过物理的LAN|段和防火墙的能力限制?
有许多公司已l在光成策略中采用?jin)集U器-?插头的集成Broker解决Ҏ(gu)?q些技术具有较高的成本Qƈ且成功也值得怀疑?990 q代后期的昂贵集成Broker目已经取得?jin)名义上的成功,但是组l置于专有的集成域的井中。一Forrester?001 q十二月发布的研I报?a href="#_ftn2">[2] 展示?jin)下列各统?
q项研究q是在EAI 在它的最峰的时候进行的Q而且几乎没有q象表明q一数字在那时候v之后得到?jin)改善。注意一q六癑֛十万元是公怼(x)在集成项目上p的^均数的一个预。当于这些公司的领导们交这些问题的时候,我进行了(jin)一个一般性的求证?
照今天的预算标准来看QEAI Broker目是很昂贵的。集成Y件费用很늚Q通常单独对于软g许可费用Q每个项目的h范围在?$250,000 C百万元不等。这q(sh)一L(fng)咨询服务lgQ而这个组件的h往往是Y件许可费用的5?2倍?
集成Broker高昂的启动成本又被另一事实所q一步恶化,即从一个项目中学到的知识不能很好地转移C一个项目。由于传l的 EAI Broker技术的专有Ҏ(gu),通常h很陡峭的学习(fn)曲线Q对于每个项目来_(d)有时候实6个月。要试图弥补q个负担的通常方式是聘请事前对专有技术经q培训的特别的顾问。当?dng)高特D?高(sh)h(hun)根{这是高昂咨询费用的一个重要组成部? 另一个大的组成是技术安装、配|、部|Ӏ和理的复杂?。ƈ且一旦项目完成,N׃见了(jin)?
集成目的实现时间普遍是?6-18 月之间。这意谓着。根据事前针对短期设定的标准、以?qing)项目资金,实施旉吃掉了(jin)项目原本想要利用的{略性窗囗?
集成Broker的专有性质Q以?qing)高昂的咨询费用通常D供应商锁定和重启后箋目的巨大成本。这意谓即便对于成功的项目,增长和展也是o(h)人恐惧的。而且在你对你的供应商或者实现心(j)生不满的时候,你也得面对到底是q前的情况l箋C去,q是选择完全重新开始,雇用更多的咨询顾问或者投入另一个新的学?fn)曲U之间左右ؓ(f)难。因为所有这些,一些ITl织通常留下?jin)一些难以再集成到其他项目的“集成孤岛”。总而言之,集成Broker已经证明是偶然架构里面的老套技术,而ƈ非它的解x(chng)案?
当我们更详细地讨论集成Broker的时候,我们看到导致这里所列的问题的技术屏障。另外,许许多多的非技术因素也D?jin)对采用ESB的需求的增长?
[1] [2]来自 Gartner 公司的统?"集成BrokerQ应用服务器?APSs,"10/2002.
[2] [3]来自 Forrester 研究的统计学,"减少集成费用,"12/2001.
各种因素Q包括技术和业务层面的,DҎ(gu)的集成方式的需要。有许多新的业务驱动因素Q比如经条件的改变、新的革命性的g技术比如射频识别标{?(RFID)的出现、法规管制的遵从Q都预示着从业务视图来看,应用集成和数据共享都要发生重大变革。这些驱动好像与企业中目前的集成状态不一致子Qƈ不象你所想的那样前。当我们在这一章中详细研究的时候,大多数应该只是简单集成的目不能很好集成Q主要是׃~Z能够q泛采用的一致的l承{略所致?
下面是媄(jing)像着Ҏ(gu)大规模的集成解决Ҏ(gu)的需要的各种需要:(x)
q些已经改变?sh)(jin)ITp的Ş式。经因素导致IT部门主要集中于事情能够与他们当前已l有的应用一起工作?
调查l果表明集成l箋处于CIO的优先序列的最层?
Sarbanes-Oxley法案、PATRIOT法案、以?FCC 法规都强q公司徏立一个必ȝ内部基础设施来比以前一h加详l地跟踪、\由、监控、和获取业务数据?
STP 的目标是消除业务程的无效率Q比如数据的人工再输入、传真、纸面邮件、或者不必要的数据批量处理。在行业中,比如金融服务Q这可以帮助辑ֈ几乎零反应期的交易处理?
被视Z一代条形码的革斎ͼ RFID 可能?x)生大量的新型数据Q然后这些数据需要被路由、变换、聚集,和处理?
不幸的是Q公司的集成环境的目前状态在q些领域几乎没有取得什么进展。这又得业界领袖不得不重新L更广泛的集成解决Ҏ(gu)。而有关集成的目前状态的问题包括:
q阻了(jin)企业向自动化业务程q步Q然后由ȝ?jin)其对不断变化的业务需求的快速反应?
偶然架构是一U一直用的事实上的集成方式Q其l果是没有连贯一致的公司U的集成{略。这表现是要留下点对点的集成、每一个都有其自己的连接和集成风格。偶然架构表Cؓ(f)不连贯的脆弱和刚性架构、ƈ且不能经受集成环境的新的附加条g和变化?
使用FTP文g传输和每夜批处理的方式进行提取、变换和载入 (ETL) 的技术仍然是今天“集成”最行的方法?q些处理涉及(qing)到每夜对各种应用之上的数据进行打包上载的操作。由于这U做法的潜伏反应期和错误率,l织从来不会(x)不真正拥有对它们的关键数据的好的快照?
上世U?0 q代后期Q昂늚集成Broker目看似成功Q但是给l织留下?jin)大量专有的集成领域难以消化?
q章会(x)详细讨论q些因素。除此之外,它将?x)解释通过逐渐采用重构到ESB的好处,同时使用学习(fn)自集成Broker技术的最?jng)_c(din)?
l济因素DIT部门主要集中于事情能够与他们当前已l有的应用一起工作。在Y2K之前Q大多数公司都把它们的主要花贚w中在准备应付 Y2K之上Q包括购买打包的没有Y2K问题的应用?
后来的经低qh期,不管是否归结于后Y2K时代、Internet泡沫破灭时代?/11、或者战?sh)的不确定性,都已l导致了(jin)ITp的急剧变化。这已经有对集成造成?jin)特D的冲击Q不是正面的还是负面的。IT预算和前 Y2K时代相比已经今非昔比。再也不?x)出现ITl理手中握着寚w成Broker软g和服务的数百万美元预,q且q要p18-24个月的时间来{待目l果q样的事情了(jin)。ITp现在变得都要通过执行层,每一个项目都要经q仔l审查。只有对业务生存能力臛_重要的项目才能得到资金。公司在每一个项目的基础上要求在3-6个月的时间片内得到切实的效果和投资回报,虽然他们仍然l持着改良整体q行效率的策略目标?
新的节P时代q没有减对业务程的改q和寚w成的需要?业务层面的驱动仍然存在;减少业务周{旉需要,减少存货水^的需要,消除重复IT服务的需要,如此{等?
IDC的一分报告指?a href="#_ftn1">[1]
他们调查?57个CIO关于他们2004q事情的优先U。关于集成报告中q样??003q?月D行的IT和执行层交流?x)上Q关于什么可以被UCؓ(f)“市(jng)场推动”趋势的问题Q集成已l成?004qIT规划中比安全h更高?sh)先U的事情?
报告同时指出Q集成和安全分别占第三和W四位,在最高的CIO优先U的列表中,仅仅排在“基设施替换/升”和“IT费用削减”之后?
M癑ֈ比则受到?jin)?21% 的“中间市(jng)场”公司将集成的重要性排在前面的影响Q甚臌q了(jin)“减低成本”和“基设施替换/ 升”。表 2-1 战士?jin)这个问题的{案:?下列各项问题Q你认ؓ(f)?2004 q终期待有最高的优先U吗? 选择一个。?
[1] IDCQ应用开发中的集成标准趋? 着全赖于“开䏀的真正含义Q?003 q?1?(文g #30365) Q?http:// www.idc.com ?
有时候,寚w成的需要在强加于你的,不管你是否喜Ƣ它?甚至在困难时期,当预紧张时Qؓ(f)?jin)集成目的而对基础设施q行修补也一定要遵从政府的法规管制?如大部分它h们会(x)证明,不有而有很多的仅仅l尝试维持状?为新的集成策略担忧?然?没有像有者监牢时间和强烈的罚ƾ视野得到资q理注意?
׃范规制的问题,一些行业的公司必须向竞争者提供信息,q且对信息访问进行审计。比如,在电(sh)信业中,负有职责的电(sh)信营q商(ILECs) 应该提供信息l竞争的 LECs 。能源公用事业也应该提供账单信息l竞争者。保健机构和隐私法律需要跟t客戯录访问以供审计之目的。这需要你的分ȝ数据能够以标准的协议和以标准的格式轻易被讉K?
下面是一些领域,在其中法规遵从是个驱动力?
一?FCC 法规要求所有的?sh)讯提供商和地方性的向地Ҏ(gu)的营运商暴露他们的客户数据的某些部分?一M?sh)讯供给者正在有强烈的罚ƾ欺骗它Z遵从q一个需求。很明显Q甚至一家主要公怹不能够负担得L(fng)l基上支付那么多的钱。与法律要求的共享信息相关的许多问题和高额成本,q且qo(h)掉那些法律不要求的部分。因此,一个过分单U的Ҏ(gu)不能同时满法律要求又能保护敏感的公司数据。你需要又l粒度的qo(h)器和有选择的数据变换来只提供必需的数?(也许只有在最后的一分钟) 来最化你的竞争者可能访问所D的对你的数据的利用。所有这些都需要有对业务流E的l粒度的讉K和控制?
?sh)信提供商需要一个基于标准的、能够展到的?sh)信提供商的集成解决?gu)Q用较?yu)的电(sh)信商也能够采用来作为集成策略的各种协议。ؓ(f)?jin)满个需要,公司最l采?ESB ?
2002q颁布的Sarbanes- Oxley 法案旨在通过改善公司信息披露的准性和可靠性来保护投资者,它强制了(jin)新的报告需求,q且对公司的决策者和他们的企业引入了(jin)更高的问责性?遵从Sarbanes- Oxley 法案需要面临一些真正的挑战。包括费用考虑Q后勤复杂性,数据攉和管理问题,以及(qing)正确的数据的?qing)时报告Q不数据存在于哪一个企业之中?
国联邦政府已经讑֮一个目??003 之前变成无纸化。在2003q一月的国政府CIO高峰?x)上QBrand NiemannQCIO理事?x)XML Web Services工作l的dQ对国政府的集成中采用XML的驱动力是这栯?
1998q的政府文书工作消除法案Q要求联邦政府机构在2003q?0月前Q如果可行,允许与政府打交道的个人或者实体能够有选择地向政府机构?sh)子化地提交信息和进行交易处理,或者如果可行,允许l持?sh)子记录?
法规遵守产生?jin)巨大驱动能量,q且集中于跨整个政府机构集成后端应用和数据源。当我们在第 11 章讨论门L(fng)境中的ESB 的时候,ESB能够在门h务器和多个后端应用之间扮演媒介中介而提供重要的价倹{?
直通处?(STP)意味着对于跨越整个pȝ和组l的业务程的事务性数据只需要输入一ơ。在其他行业中, STP 可能被称为“流通供l”、“无UR集”、“lights-out”或者“hands-free”处理?
达成 STP 的目标要消除业务程的无效率Q比如数据的手工重新输入、传真、纸面邮件、或数据的不必要的批处理。今天阻?STP 的事物的例子包括采购订单重新输入到信用卡验证系l,或者周期性处理的数据分批?
在金融服务、电(sh)信和公用事业中,STP 是一个主要驱动。在金融服务中,“T+1”的目标是将交易数据沉淀(wn)一天。自动化E序q行可以帮助公司在整个订单和贸易的生命周期中减少成本Q更快捷地服务客P以及(qing)更有效地理业务风险?
频识别标签(RFID) 正在改变?sh)业跟踪其整个供应链中各处的货物和供应的方式。RFID标签q承够通过消除Z打开外包板条和托盘扫描条Ş码内容的需要从而自动化供应链。装备有RFID标签的货物通过安装在仓库或者装货码头的阅读器时Q会(x)差生大量的消息,而这些数据又会(x)产生大量的需要被捕捉、\由、变换和输入到其他队业务有意义的应用之中的数据?
零售卖场中装备有RFID阅读器的“智能货架”能够自动跟t货架上的货物数量,q且在货架存量低于标准的时候自动生补货的订货命o(h)。这些货枉d也会(x)知道Q消费者从货架上拿起一件商品^Q然后可能又因ؓ(f)另一U商品而将它放回货架。这U类型的数据对于那g重新攑֛货架的商品的刉商来说也是很有价值的?
领导零售商,比如Wal- Mart?Tesco、和国防卫部,已经寚w大型供应商强制要求在大外包装U别装备RFID标签?jin)。其最l目标是要驱动标{本w的h下降Q得最l对每一但见商品Q比如一把牙h者一|苏打,q行RFID标签识别变得可行。这样将大大增加在一个托盘经q阅d是所产生的消息数量。这U数据量在h工扫描外包装上的条码的时候是不会(x)产生的。当一个托盘经q阅d的时候,ESB能够作ؓ(f)因ؓ(f)而缠w的爆发性数据的~冲以便能够准确捕获q些数据。那些没有针对这U数据量q行设计的应用可以得到ESB 的消息层的保护,它能够将工作量分配到多个后端pȝQ或者进入消息队列排队,直到其能够被处理?
因ؓ(f)个体物品URFID标签而导致的消息的粒度更l,寚w些没有针对处理超q大包装U别_度的数据的应用也是个问题。ESB 能提供殊的缓存、聚集和变换服务Q以便能够将攉更细_度的数据,q将其聚集ؓ(f)大包装别的数据Q以侉K些应用能够读取?
EPCglobal l织正在?j)?RFID 标签、阅d、以?qing)将阅读器整合到应用的Y件的标准化。ؓ(f)?jin)要q泛地共?RFID 数据Q需要对整个供应链中的相兛_用和阅读器网l定义集成规则。而ؓ(f)?jin)避免网l中的RFID 数据z水Q过滤和聚集规则应该可能地分布到最靠近RFID 事g的生点。ESB 是一个很好的理和配|那些控制数据流得规则的理想q程集成q_?
许多新生技术都l受q试图找到问题来解决以获得采用的痛苦l历。另一斚wQESB的概忉|׃界领袖的架构师和技术社Z的领导厂商一起和定义和构建的Q因此,ESB从诞生之时便得到采用。ESB正在或已l被用在多种行业Q包括金融服务、保险、制造业、零售、电(sh)信、能源、食品分销和政府。下面是一些例子?
ESB 的部|模型允许制造商在分销商的地点部vESB 服务容器。这是在每个q程地点部v一个集成BrokerҎ(gu)的另一选择?
n 一个美国政府机构正在用ESB 来整合多个政府系l,以满USA PATRIOT法案。USA PATRIOT法案允许政府跟踪金融交易Q以防止恐怖䆾子得到资金。该目包括使用 ESB 来集成门h务器和各U政府机构中的后端系l,以提供一个统一的数据视图?
概括hQ?ESB h下列各项Ҏ(gu)?
ESB 可以采用来适应各种集成情Ş下的各种通用目的集成目的需要。它能够构徏跨越整个企业和其业务伙伴的集成项目?/em>
松散耦合的集成组件可以在ȝ上以q泛分布的地理拓扑进行部|Ԍq且在ȝ中可以随处作为共享服务进行访问?/em>
适配器、分布式的数据变换服务、基于内容的路由服务都可以在需要时有选择地部|Ԍq且可以独立C~?/em>
通过ȝq行通信的所有组件能得益于可靠消息、事务完整性、以?qing)安全的认证通信机制?/em>
ESB 允许数据过插入到ȝ中的M应用Q?不管是本地还是远E?/em>
ESB 支持部门和业务单元别的本地自治Qƈ且仍然能够在较大的受的集成环境中整合?/em>
每个个别的项目能q入一个更大的集成|络Q它们可以从ȝ上的M地方q行q程理?/em>
ESB 可以充分利用XML作ؓ(f)“原生”数据cd的好处?/em>
ESB 提供?jin)对及(qing)时业务数据的实时洞察能力。BAM能力已经被构建到ESB 框架之内?/em>
你现在应该有?jin)关?ESB的够的信息来满你的好奇欲?jin)?接下来,在更详细的章节中Q你会(x)学到更多有关其底层技术方面的内容。下几章会(x)讨论 ESB 的进化、目前的集成状态,采用XML来作Z个通用的数据交换架构以在不同的数据表示之间协调的好处,以及(qing)异步消息和MOM?
]]>
׃试图快速进入成长中?ESB 范畴的厂商的慌ؕQ以?qing)大量行业分析师和记者在分析报告中分别展CZ们各自的观点Q可以理解,q其中对于ESB 到底是什么还h很多h。这一节将概略说明 ESB 的主要特性?
如第 1 章所C, ESB 能Ş成普遍的|格的核?j)。它能够跨越和超q扩展企业,q且横跨部门l织、业务单位和贸易伙伴形成全局的范围。ESB 也能很好地适合于局部的集成目Qƈ且对?j)进它们采用Mcd的集成环境提供柔性的支撑?
图表 1? ESB 形成一个能跨越?jin)一个全球企业网l的普遍|格
应用可以按需插入ȝQƈ且具有可视性,以及(qing)能够与其它已l插入到ȝ中的M其他应用和服务共享数据。虽然Web Services?ESB 架构的一个有机组成部份,但是所有的应用q不是一定要被修Ҏ(gu)为真正的Web Services才能参与?ESB。连接性是通过多种协议、客L(fng)API 技术、遗留消息环境、以?qing)第三方应用适配器来辑ֈ的?
Z标准的集成是 ESB 的基本概c(din)对于连接性,ESB 可以使用J2EElgQ比如用Java Message Service (JMS)来进行MOMq接Q用J2EE q接器结?(JCA ?J2CA) 来连接应用适配器。ESB 也能够非常漂亮地与?Net、COM、C#、C/C++构徏的应用进行集成。除此之外,ESB 也能集成支持SOAP和W(xu)eb Services API的Q何组Ӟq其中包括事实上的标准Web Services工具q实现Q比如Apache Axis。ؓ(f)?jin)处理数据操U, ESB 可以使用XML标准Q比如XSLT、XPath ?XQuery 来提供数据变换、智能\由、以?qing)在数据过ȝ的时候提?#8220;IZ”查询。ؓ(f)?jin)处?SOA 和业务流E\由, ESB 可以使用 Web Services描述语言 (WSDL) 来描q抽象的服务接口Q用针对Web Services的业务流E运行语a(BPEL4WS)、WS- Choreography或者一些其他基于XML的词汇表Q如 ebXML BPSSQ来描述抽象的业务流E?
如果你还?sh)懂q些深奥的词汇的含义Q也不要担心(j)。虽然本书ƈ不想作ؓ(f)是这些各个技术的详细参考或个别指导Q我们也?x)在他们如何?ESB 有关的语境中_详细地解释它们?
q些Z标准的接口和lg被整合到一个意义非凡的包含开攄点的可插入架构之中。ESB提供?jin)一U基讄来同时支持基于工业标准接口集成组件和使用标准化接口来实现的专有元素。下囑ֱCZ(jin)一个用JMS和JCA集成一?J2EE 应用、用JCA应用适配器集成第三方打包软g、用C#客户端程序集成一?NET应用、用Web Services集成两个外部应用的案例的高阶视图?
图表 1? ESB 整合多种不同的技?
ESB 在其中借鉴?jin)传lEAI Broker的许多功能,比如从它提供集成服务 , 像是业务程~排、数据\由、数据变换、以?qing)应用适配器。然而,集成中介者通常是高度集中和单一的Ş态。ESB 这些集成能力提供ؓ(f)独立的服务,能够以一U高度分布的形态一起工作,q且能够彼此间独立~。在W?6 章中Q你会(x)学习(fn)更多有关 ESB“服务容器”QESB 的一Ҏ(gu)?j)概늚内容Q它允许寚w成服务进行选择部v?
M集成{略的一个关键部分就是能够轻易地在应用之间{换数据格式的能力。许多应用对描述怼的数据ƈ不共享相同的数据格式?
数据变换是一?ESB部v的一个固有部份。变换服务特别针寚w些被插入ȝ的个别应用能够在ȝ的Q何地方被定位和访问的需要。因为数据变换是ESB 本n的一个有机组成部份,解决应用之间的阻抗失配问题(sh)可以惛_ESB?
ESB 能够Z提供本质上针对Q何集成项目所必需的核?j)能力,q且可以通过使用分层的服务来处理特定的用途来增加。例如,Ҏ(gu)的能力,比如业务程理 (BPM) 软g能处理工作流相关的业务流E,而协作服务器能够提供对伙伴业务流E管理的Ҏ(gu)服务。专门的W三方翻译器能够外部数据,比如EDIQ{换到能进入目标企业资源规?(ERP) pȝ之内的格式,或者在通用ȝ之上的规范XML表现?
?ESB驱动的、事仉动的 SOA中,应用和服务被当做抽象服务端点Q能够轻易地对异步事件做出响应。SOA 对其底层的连接性和线l节提供?jin)一个抽象的方式。服务的实现不需要理解协议。服务也不需要了(jin)解消息是如何路由到其它服务的。他们只是简单地接收自 ESB 的一个消息作Z个事Ӟ然后处理该消息。ESB 可以把消息发送到它想要去的其他Q何地斏V?
?ESB SOA 中,用户定制服务可以被创建、扩展,q且被重用ؓ(f)ESB 功能。被暴露为服务的应用端点Q可以同Ҏ(gu)的集成功能一h造成复合业务服务和业务流E,q且它们可以Ҏ(gu)不同目的重新l合Q其目标是在一个即时企业中提供自动化的业务功能?
W?7 章将?x)更详细地讨?ESB 中的 SOA ?
ESB的处理流从简单的优先步骤序列C用条件分支和联合来ƈ行执行的l合业务程~排。这些特征可以用简单的消息元数据或者通过使用诸如BPEL4WS 之类的业务编排语a来控制?
ESB 的处理流能力使得定义属于某个部门或者业务单位局部的Q或者共存(sh)一个较大的集成|络中的业务程成ؓ(f)可能。这点却是一个集U器-插头中介者或一?BPM 工具自己所不能很好地自p决的问题。第 7 章将?x)详l讨论分布式的流E能力,它能提供高度分布的流E编排能力而不需要中?j)化的流E和规则引擎?
ESB的业务流能力也涉?qing)到Z内容的消息的路由的特D集成服务?
因ؓ(f)ESB 的业务流能力构徏于分布式的SOA之上Q它也能够跨高度分布的物理部v拓扑Q甚x(chng)大z)(j)而不用痛苦地忍受ȝ上各U应用和服务之间的物理边界和多协议的鸿沟?
图表 1? 跨越物理和逻辑边界之上的部|拓扑的~排和业务流
?ESB 上的节点之间的连l是h防火墙能力的。应用和 ESB之间的安全性,甚至?ESB 节点自n之间的安全性,能够建立和维护最高强度的认证、凭证管理、和讉K控制?
可靠性是通过处于ESB核心(j)的企业MOM来达到的。MOM核心(j)提供异步通信能力、业务数据的可靠传输、以?qing)事务的完整性。你们将在第 5 章中学到Q这已经不是十年以前的传lMOM技术了(jin)。需求从那时以后开始进展,q且已经成熟Q?作ؓ(f)ESB 的核?j)的MOM必须W合今天的需求?
传统的集U器-插头中介者方式往往hl织性的边界问题Q这主要是因为EAI Broker对跨防火墙和网l域的无能的实际限制所引v。更重要的是Q即使一个集U器-插头架构能够被展而跨q组l的交界Q它仍然不允许各个业务单位彼此半独立地运行所需要的局部自沅R与不断扩展的集成范围g伸超q部门层ơ所相关的最大问题(sh)一是自d集中控制之间的问题?
作ؓ(f)大多数大型公司环境的业务文化的一部分Q每个部门或业务单位需要彼此独立地q作?然而,他们仍然依赖于共享资源,以及(qing)输入到通用业务功能之中的报告和帐户信息?
在这样一个环境中Q需要所有的消息量都流q位于总部的一个集中的消息Broker的集成策略是不合理的?q不只是一个技术上的障;它也是公司文化的问题。在一个松散耦合的业务单元环境中Q诸如本地应用之间的业务程Q或者安全域Q被一个集中化的公司IT功能理直没有一炚w理。组l中的松散耦合业务单元需要彼此独立地q作。他们每一个都应该有其自己的IT功能Q而不必须路由所有的消息量Q或代表它的业务规则和安全域的控? l过一个集中的集成l纪人在一个位|或另一?W?1 ??
图表 1? 如果使用一个集中的集线器,分开业务单位~Z必需的自???jin)集成经Uh
本地业务单位和部门需要有对他们自q局部IT资源的控Ӟ比如在其站点q行的应用。集成基设施应该支持部v拓扑来支持具有实用性的业务模型。ESB 也提供这U部|模型, 允许本地量、集成组件以?qing)适配器能够被本地安装、配|、加固和理Qƈ且仍然能够以一U集成的安全模型一起将本地集成域插入到一个更大的联邦集成|络之中?
图表 1? 自治的而且公布联邦?ESB 允许横过l织的交界对合作地同盟的q算l织
ESB 的分布式特征是通过从实际的部vl节和底层的q接协议中抽象出来的端点定义,以及(qing)在那些端点之间的数据的编排和路由来达到的。联邦特征则是通过 ESB 能够隔离和选择地横q应用域和安全边界的能力来达到的?
在一些业务模型中Q在每一个远E地炚w安排有本地的IT职员是不大可能的Q虽然仍焉要松散耦合的、自ȝ联邦的集成网l。D例来说明q一个点Q我们来惌一下部|在零售行业中的ESB 的案例。一个视频租借链可能有数百或数千个包含相同应用的地点Q所有以相同的Ş态运行的操作涉及(qing)到目录管理、会(x)计和报表{?
图表 1? 和数以千计遥q的储存?sh)个视像零售链,所有的包含应用E序的相同组
使用 ESBQ可以徏立一个集成蓝图来处理q程店铺中的局部应用之间的通信。这包括店内应用的接口定义、消息流量的路由、消息通道的管理、以?qing)安全许可。它q可能包括集成组Ӟ比如应用适配器、协议适配器或者数据变换器。这个集成蓝图,或称模板Q可以在所有地点进行部|和定制Qƈ且独立地扮演所有其他店铺?
图表 1? ESB 配置蓝图在每个遥q的位置和很q地展开配置而且处理
q个q程部v蓝图的能力ƈ不单针对零售行业Q它也可以扩展到所有其他行业的应用。联邦的集成域的q程理对于在一个高度分布的环境中的MESB的成功部|都是非常关键的?
安全、可靠的消息联结
除了(jin)在每个店铺的本地应用之间׃n数据之外Q这些远E店需要同总部׃n信息以便q行帐务处理和报表、信用管理以?qing)职员数据的q踪。远E店需要彼此之间共享信息。D例来_(d)一个大型的韛_q锁店可能会(x)提供q样的服务,֮可以选择从离家近的店U赁qQ然后在d公室q的另一个店归还。因此,在同一个地理区域内的店Z间可能会(x)需要以q乎实时的状态共享有关租赁的数据。因为在q程店铺和总部之间的卫星网l通信q接存在较大的反应期和弹性,要在总部l护一个有x(chng)有租赁信息的实时集中讉KҎ(gu)不现实的。那些有关你只是在两个小时之U借的数据需要共享,或者通过q程店铺之间的一个集成的数据׃nq接来进行访问?
因ؓ(f)总部和远E店Z间的q接是通过可靠的消息来辑ֈ的,因此׃不可靠的卫星?sh)\所造成的网l服务终端可以从消息层得到补ѝ也应该注意刎ͼ对于q程店铺之间来说Q通过Internet来徏立一个安全和可靠的消息通道也是可以的?
当数据通过ESB 在应用之间流动的时候,XML是一个表现它们的理想基础。被应用E序的一个巨大的行列生而且耗尽的数据能以多U的格式存在和包装方案。有大量的应用生和消费的数据,可以以各U格式或者打包的Schema存在。对ESB来说虽然的确可以依你喜欢的打包Ş式或者封装方案来承蝲数据Q但途中数据表现为XMLh莫大的好处,包括使用能够l合来自于不同的源数据以创徏一个新的数据视囄产生数据的特D?ESB 服务Q?以及(qing)针对应用间高U数据共享的羃和重定目标。第 4 章将?x)探I用XML功能本好处—将避免一个组l的应用间同步升U的需要—ƈ且更详细地讨论分布式XML变换之后的基本原理?
ESB通过为途中数据在ȝ之上的应用间传输的时候提供实时吞吐消除了(jin)潜伏反应问题。目前,最行的集成方法之一是每夜进行批处理?然而,打包的成批处理集成策略,不管是每夜还是其它,都具有较高的辚w错误率,q且造成信息获取的gq。其l果是高反应期生获取了(jin)q时数据代h(hun)高昂的。第 9 章将详细讨论q个问题Qƈ且研I?ESB 可以如何用来你的业务数据从每夜批处理模式重构ؓ(f)实时吞吐模式?
q行感知意思是业务分析师能够获得对业务q行的状态和健康情况的洞察能力?一个允许对数据在其以某个业务流E中的某个消息Ş式在l织中流动时q行实时跟踪和报告的基础设施Q对于帮助徏立运行感知是一个无L(fng)工具。一个称为是业务zd监控 (BAM)的品门cdl出现来解决q行感知的这些问题?
使用XML作ؓ(f)ESB的原生数据格式的好处之一是消息没有被处理ؓ(f)不透明的数据块。如果应用和服务之间的所有数据都被格式化为XML文档QESB提供的基支撑便允怽在ESB之上再构Z层高U能力,以获得对过你的企业的业务数据的实时z察能力。这些能力,不管是否是ESB的固有组成部分,q是有一个扩展来驱动Q都表现为包括了(jin)路由、处理流、以?qing)下层的线Qƈ且不需要再在其上锁定一个第三方的BAM产品的一个通用基础设施的一个有机组成部分?
作ؓ(f)ESB的一个基部分的审计和跟踪能力允许对在SOA中的所有流动的业务程和消息流的健L(fng)况进行监控和跟踪。诸如数据缓存、数据收集和聚集、以?qing)XML数据的可视化表现之类的增值服务,可以用来创徏一个基服务Q该基础服务可以在数据在企业中流动时Q生对业务程的状冉|察的警告、提醒和报表能力?
图表 1? 增值型服务?j)成操作的觉察提供对zȝ业务数据的即时洞?
对ESB中的数据的根t和报表是通过在业务流中定义审计点来达到的Q然后再对从业务消息中收集的重要内容在ESB中流动时提供插入炏V可q踪数据例子是业务消息自w,以及(qing)指示某业务消息是否通过?jin)某个特定的业务处理步骤的业务事件?
高的增值服务可以提供数据收集服务、查询机制以?qing)报表能力,它们能够讲所有数据进行收集、进而表Cؓ(f)各种h意义的Ş式。XML持久性服务可以提供缓存和聚集点,q样可以攉要转换的数据从而向其他应用提供数据输入Q或q入到可以被业务分析师用的人可ȝ报表机制之内。这意味着经ESB的数据可以进行实时分析,以提供有关你的业务状态的实时信息—比如,可以随时提供有关你的供应链中的存货的状态快照?
区别是否真正?ESB 的一个主要方面是看其是否h逐渐采用的能力,相对于另一?#8220;全有-?全无”的论断。在 Y2K 之后的开支削减中Q数百万元预算的项目数目已l今非昔比。有一些迹象表明,预算资金{备正在开始释放以解决短期的战术性集成需要,但是预算仍然谨慎地处于一个执行层面。,然而,同时仍然有一些期望实现较大的公司范围集成{略计划—这些计划严重依赖于集成和现有IT资的重用?
?-10说明?ESB 可以如何用于项目中Q然后它们都可以q入C个更大的集成|络之内?当我们深入阅L书的时候,我们?x)详l研I这是如何实现的?
图表 1?0 ESB 支持逐渐采用的集成,同时向着一个策略目标工?
ESB 的联?自治能力也对一ơ一个项目采?ESB的能力有助益。ESB 集成目渐进式的分布部v能够在朝着一个更q的企业层面的计划目标的前提下得到立即h(hun)倹{?
逐渐采用的观念将q一步通过桥接C个已有的集成Broker集线机器和遗留系lBroker来得到进一步支持。集成Broker集线器和他们的特点将在第 2 章中详细研究?/p>
在一个事仉动型企业中,影响业务程的正常进E的业务事g可以以Q何顺序随时发生。那些以自动化的业务处理方式交换数据的应用需要用事仉动的 SOA 来彼此通信Q以便能够对不断变化的业务需求具有敏L(fng)反应。SOA 向业务分析师和集成架构师提供?jin)处理高阶服务的关于应用和集成组件的宽泛的抽象视图。而在 ESBQ应用和事g驱动的服务彼此以一U松散耦合的紧密地与流行的 SOA l系在一Pq允许它们彼此能够独立运行,q且仍然能够提供较宽q的业务功能价倹{?
?SOA 的王国,事g被表Cؓ(f)一U开攄XML格式文gQ以?qing)经q一个对验证开攄Q可以协调的透明线中的(F(tun)lowQ?
—John Udell, InfoWorld
SOA 的服务组件暴露的是一U粗_度的接口,其目的是使应用之间能够异步地׃n数据。而?ESBQ一U集成架构将应用E序和分ȝ集成lg拉在一P以生服务装配组合从而Ş成复合的业务程Q进而自动化一个即时企业中的业务功能?
ESB 为SOA提供实现骨架。那是_(d)它通过一个跨多U协议的消息ȝ来提供一个有兛_名\q的地的高度分布的世界来提供松散耦合的,事g驱动?SOA。ESB 中的应用E序 (和集成组? 在理Z是彼此解耦的Q而且通过ȝ彼此q接为暴露ؓ(f)事g驱动服务的逻辑端点?
通过分布式的部v配置基础设施Q?ESB 能有效率地提供对在扩展企业中分布的服务的中心(j)配置、部|和理。一U普遍集成的新方式应用诸如SOA、EAI、B2B 和W(xu)eb服务之类的技术的通常目标主要是创Z个集成架构,且能够深入ƈ且跨整个扩展企业。对于一个集成基设施到达到这U普遍性,它必d有下列各特?
?ESB中,应用和事仉动服务以一U松散耦合的方式紧密地联系在SOA 中?q得它们能够彼此独立运行,q且仍然能够提供q泛的业务功能h(hun)倹{?
ESB 架构解决?jin)这些需要,q且正在被各U通用的集成项目所采用。它也能够在企业应用层面普遍C展,不管是物理位|还是技术^台。Q何应用都可以通过大量的连接选择插入C?ESB |络中,q且可以立即参与C那些通过ȝ暴露为共享服务的应用之间的数据共享之中。这?ESB Z么经常被UCؓ(f)集成|络Qintegration networkQ或集成构造(fabricQ的~故?
ESB 提供为集成提供了(jin)一U高度分布式的架构,q且h能够让独立的部门和业务单元能够以一U逐渐增加的、可消化的分块来构徏它们的集成项目的独特能力。?ESBQ部门和业务单元仍然能够l箋在独立的集成目中维护它们自q本地控制和自治,q且仍然能够它们的集成计划q接C个更大的、更全局的的集成|络或网g中?
Web 服务已经通过为应用间的互操作性提供一U基于标准的方式为面向服务架构找C(jin)新的重要性。Web服务的主要目的是提供?jin)一U服务抽象,它允许应用之间的互操作性用不同的q_和环境来构徏。这一个目标的实现能够提供一个应用之间的普遍集成的更Ҏ(gu)的\径?
׃ESB的出玎ͼ现在有了(jin)一U方式能够将Web Services和SOA合ƈC个意义非凡的架构中,以将应用和服务以一U高度~的状态集成到一个扩扩展企业的骨架之中。ESB使用今天已经成熟的技术立M得Web Services、XML、以?qing)其他集成技术更加有用?
SOA 的核?j)原则对于普遍集成项目的成功臛_重要Qƈ且已l在 ESB 中被d实现?Web Services标准正在有朝着正确的方向前q,但是在提供企业能力斚wq未完成Q比如安全性、可靠性、事务管理和业务程~排。ESB 以这些领域中今天已经定的标准ؓ(f)基础Q而且已经有实际实现部|在各种领域和行业中。ESB完全有能力跟上Web Services相关能力的革新进展步伐。第 12 章提供了(jin)更详l的关于q一个主题的讨论?
ESB 通过从EAI中介者(BrokerQ那里学来的概念和技术将Web Services和其他补充标准结合在一赗然而,ESB q不仅仅是在同一个老式的EAI 集线器之上的单的Web Services外衣?
传统的Ş式化的集成方法都有其优缺炏V第 1 章就展示?jin)有关集成的一些高阶的显著特色Q?范围从左下方最不o(h)人想要的Q到右上方象限中的最令h惌的?
图表 1? 传统?EAI 中介器,应用服务器,MOM?ESB 的特?
传统?EAI 中介器,包括那些已经构徏在应用服务器之上的,使用一U集U器和插_(d)hub-and-spokeQ架构。集U器和插头有一些中?j)化功能的好处,比如路由逻辑和业务规则的理Q但是不能很好地伸展扩越部门和业务单位的边界。第 2 章将讨论使用集线器在集成中的早期试的巨大代P以及(qing)它们的初步成功?
应用服务器可以通过标准协议q行互操作,然而它们是以一U紧密耦合的方式进行连接的Qƈ且集成逻辑和应用程序逻辑U缠在一赗?
EAI 中介器通过应用逻辑从集成和程路由逻辑中分d来提供了(jin)增加价|然而你仍旧要忍受集U器-插头架构的痛苦?
面向消息中间?(MOM) 提供?jin)以松散耦合和异步的方式q接应用的能力。然而,MOM自n需要在应用中进行低U的~码。用传l的MOMQ以?qing)定制的~程技术,比可以在分布式的集成解决Ҏ(gu)上走得更q。然而,没有对\由逻辑的高阶抽象,q种方式仍然要忍受集成逻辑难以q接Qƈ且也和应用逻辑U缠在一L(fng)痛苦。依赖于MOM的用,即是分布式特征也会(x)受到限制Q因Z些传l的MOM基础设施对实际的|络边界的跨也不是做得很好?
最后,?ESB 中,服务可以被配|而不是编码。处理流E和服务能够透明地跨整个服务ȝ。ESB 提供?jin)能够很好地扩越集线?插头架构范围的高度分布式集成环境Qƈ且清晰地分离?jin)应用逻辑和\由数据变换之cȝ集成逻辑。一?ESB 架构形成?jin)一个消息集U器和集成服务的互连接性网|h一个彻底分布的集成|络的功能性和性?
W?6 章更q一步描q在使用应用服务器集成和使用ESB集成之间的对比。MOM的概念在W?5 章讨论。第 2 章的 “附属架构”l箋讨论业务程路由逻辑和业务逻辑之间的分R?
ESB 的一个关键特性就是要为支持分布式的、松散耦合的业务单位和伙伴Q比如自动化供应链,提供支撑基础。ESB 的这些能力是其固有的必要特征Qƈ且是中间件厂商与那些惌创徏大规模集成架构的业界专家共同工作的结果。这些业界专家包括了(jin)大公司IT架构师、以?qing)?sh)子市(jng)集N易社Z惌Z׃n服务、消息、XML何其他众多的q接选择来徏立B2B集成骨架的改革者,q且要坚持遵守工业标准。第 3 章将?x)讨论?ESB 概念的创造有助益的许多催化剂?
同时Q仍然必解决的最大需要在于如何还没有的最大需要被定址包括该如何有效地提供集成能力、比如应用适配器、数据变换、以?qing)能够用于通用的集成项目,跨越多种集成情性的路由。ƈ且需要超于个别战术性的集成目之上的,更加通用的技术和更加架构性的方式?
IT专家已经对以前的一些技术趋势失望,比如CORBA、或者EAI什么的。CORBA 有着与SOA 一L(fng)正确理念Q但是其与生俱来太复杂而难以维护,因ؓ(f)它依赖于应用和服务之间的紧密耦合接口。EAI 也痛苦于对单个项目上的陡峭的学习(fn)曲线和昂늚q入负担 (下一章将详细讨论q个内容)。真正需要的是SOA的简单方式,以及(qing)可以被采用来适应M集成工作Q大型或者小型,的一U架构。此外,那就是需要一个能够经受协议、接口、甚至业务徏模趋势的变革的持久架构。ESB的概念就是创建来解决q些需要的?
自从ESB 概念?2002 q被首次引入QESB 的集成方式已l被中间件、集成和W(xu)eb服务?jng)场中的很多重要的厂商采用。其接受度正在稳定持l地增长?
?002q早期开始,分析公司Q比?Gartner 公司、IDC、ZapThink{,已l开始跟t和~写有关 ESB 的技术趋ѝ在Gartner 公司?002q发布的一份报?DF-18-7304)中,分析?Roy Schulte q样写道Q?
一U新型的 企业服务ȝ架构- l合?strong>面向消息中间?/strong>QMOMQ、Web Services、数据变换和路由的基设施?/em>会(x) 2005 之前在很多的企业中运行?/em>
q些高功能、低成本的ESB能够被很好地适应作ؓ(f)面向服务架构和企业神l系l的d?
那四个支柱—MOM、Web Services、数据变换和路由 ?表现?jin)Q何优U的ESB 的基。当我们探究 ESB 的时候,本书会(x)集中于其中每一个基和其他必ȝlg的角艌Ӏ我们还要讨论将?x)讨?ESB I竟能ؓ(f)企业做些什么、以?qing)它的基本组件所扮演的角艌Ӏ我们还要讨Z些高阶主题,包括横越多种行业之上的实跉|用的架构性概q?
有许多中间g和集成厂商已l,或者正在构建,W合ESB描述的某些品。ƈ且这个名单还在不断增加。附录中列出所有的已知厂商。一些厂商已l声UC们已l开始提?ESB?Q而有些则正在计划构徏Q有些则只是在市(jng)场宣传材料中使用q一技术术语而实际上背后q没有实质性的东西。当过 25个厂商正在ؓ(f)相同的技术空间竞争的时候,q一个技术范畴注定要变成像上世纪90q代的应用服务器一L(fng)炙手可热?
q个清单中有个别厂商应该特别提及(qing)。Sonic软g最先倡导?jin)这个概念,此后不久许多其他的较(yu)厂商业q入此领域,声称他们也正在提?ESB 或是正在开发之中。一但那些著名的集成公司Q比如webMethods、SeeBeyond ?IBM 最l搭上这巴士(“BUS”Q,q且惌开始徏立他们的ESBQESB 术语才真的开始广泛引起业界注意,是一个强大的不断发展技术范畴?
在本书写作的时候,微Y公司q没有对其Indigo目和有关ESB发布M公开的说明。然而,一些记者和分析师在Indigo目宣布的时候还是将二者联pv来?003 q?1?30 日, ComputerWorld 的文章说Q?#8220;开发h员的兴趣被微软的技术伤害了(jin)”QGartner 公司?Roy Schulte关于Indigo目提出?
Roy SchulteQ是Gartner 公司在斯坦福的一个分析师Q注意到Indigo目其实是微软消息队列(MSMQQ、公司的COM、COM+?Net Remoting、以?qing)Web Services技术的集?#8220;把它x(chng)代表微Y公司的通信中间件计划的化和l一Q?#8221;他说Qƈ说他认ؓ(f)Indigo是一个非常好的企业服务ȝ(ESB)?
Indigo以消息ؓ(f)基础Qƈ且打结合MSMQ 和W(xu)eb Services。可以提供一个消息ȝ的基。然而,光成能力的其余部分则被锁定到BizTalk 之内Q而它是一个集U器-插头风格的集成服务器。ؓ(f)?jin)成为真正的ESBQ分布式消息ȝ和分布式集成能力都要具备?
如果Indigo目完成Q构Z微Yq_之上的应用和服务能够更加吸引hC为端点连接到ESB之上。将Indigo包含到微软^台和开发环境之内将更加能够使得应用h松散耦合和消息感知能力?/p>
1.5.1 采用 ESB的厂?/h5>
A lot has been written recently about Service-Orientation and Web services
and REST and the massive amounts of confusion that seem to be surrounding the
whole subject. After much navel-contemplation, I'm convinced that the root of
the problem is that there's two entirely orthogonal concepts that are being
tangled up together, and that we need to tease them apart if we're to make any
sense whatsoever out of the whole mess. (And it's necessary, I think, to make
sense out of it, or else we're going to find ourselves making a
The gist of the idea is simple: that in the term "Web services",
there are two basic concepts we keep mixing up and confusing. "Web",
meaning interoperability across languages, tools and platforms, and
"services", meaning a design philosophy seeking to correct for the
flaws we've discovered with distributed objects and components. These two
ideas, while definitely complementary, stand alone, and a quick examination of
each reveals this.
Interoperability, as an idea, only requires that programs be written with
an eye towards doing things that don't exclude any one platform, tool or
technology from playing on the playground with the other kids. For
example, interoperability is easy if we use text-based
protocols, since everybody knows how to read and write text;
hence, HTTP and SMTP and POP3 are highly-interoperable protocols, but DCOM's
MEOW or Java's JRMP protocols aren't, since each relies on sending binary
little-endian or big-endian-encoded data. Interoperability isn't necessarily a
hard thing to achieve, but it requires an attention to low-level detail that
most developers want to avoid. (This desire to avoid low-level details isn't a
criticism--it's our ability to avoid that kind of detail that allows us to
write larger- and larger-scale systems in the first place.)
This "seeking to avoid exclusion"
requirement for interoperability is why we like using XML so much. Not only is
it rooted in plain-text encoding, which makes it relatively easy to pass around
multiple platforms, but its ubiquity makes it something that we can reasonably
expect to be easily consumed in any given language or platform. Coupled with
recent additions to build higher-order constructs on top of XML, we have a
pretty good way of representing data elements in a way that lots of platforms
can consume. Does interoperability require XML to work? Of course not.
We've managed for the better part of forty years to interoperate without XML,
and we probably could have kept on doing quite well without it; XML makes things easier, nothing more.
Services, on the other hand, is a design philosophy
that seeks to correct for the major failures in distributed object and
distributed component design. It's an attempt to create
"things" that are more reliable to outages, more secure, and more
easily versioned and evolvable, things that objects/components never really
addressed or solved.
For example, building services to be autonomous (as per the "Second
Tenet of Service-Orientation", as coined by Mr. Box) means that the
service has to recognize that it stands alone,
and minimize its dependencies on other
"things" where possible. Too much dependency in distributed object
systems meant that if any one cog in the machine were to go out for some
reason, the entire thing came grinding to a halt, a particularly wasteful
exercise when over three-quarters of the rest of the code really had nothing to
do with the cog that failed. But, because everything was synchronous RPC
client/server calls, one piece down somewhere on the back-end meant the whole
e-commerce front-end system comes to a shuddering, screeching pause while we
figure out why the logging system can't write any more log messages to disk.
Or, as another example, the First Tenet states that "Boundaries are
explicit"; this is a well-recognized flaw with any distributed system, as
documented back in 1993 by Wolrath and Waldo in their paper "A Note on
Distributed Computing". Thanks to the fact that traversing across the
network is an expensive and potentially error-prone action, past attempts to
abstract away the details of the network ("Just pretend it's a local
call") eventually result in nothing but abject failure. Performance
failure, scalability failure, data failure, you name it, they're all
consequences of treating distributed communication as local. It's enough to
draw the conclusion "well-designed distributed objects are just a
contradiction in terms".
There's obviously more that can be said of both the "Web" angle
as well as the "Services" angle, but hopefully enough is here to recognize
the distinction between the two. We have a long ways to go with both ideas, by
the way. Interoperability isn't finished just because we have XML, and clearly
questions still loom with respect to services, such as the appropriate
granularity of a service, and so on. Work remains. Moreover, the larger
question still looms: if there is distinction between them, why bring them
together into the same space? And the short answer is, "Because
individually, each are interesting; collectively, they represent a powerful
means for designing future systems." By combining interoperability with
services, we create "things" that can effectively stand alone for the
forseeable future.
And in the end, isn't that what we're supposed to be doing?
Mule 是一个基于ESB架构理念的消息^台。Mule 的核?j)是一个基于SEDA的服务容器,该容器管理被UCؓ(f)通用消息对象QUniversal Message Objects /UMOQ的服务对象Q而这些对象都是POJO。所有UMO和其他应用之间的通信都是通过消息端点Qmessage endpointQ来q行的。这些端点ؓ(f)众多的分立的技术,比如Jms, Smtp, Jdbc, Tcp, Http, Xmpp, file{等Q提供了(jin)单和一致的接口?/P>
Mule 应用通常是由|络中的许多Mule 实例l成。每一个实例都是一个驻留一个或者多个UMOlg的轻量容器。每一个UMO lg都有一个或者多个通过它(们)(j)发送和接收事g的端炏V?BR>
容器通过UMOlg提供各种各样的服务,比如事务理、事件{换,路由Q事件关联、日志、审计和理{等。Mule对象构造从理手段中分d来,通常行框架和IoC/DI 容器Q如Spring, PicoContainer 或?Plexus 可用q种理手段来构Z的UMO lg?/P>
很多为, "Mule是一个Jms 实现"。实际上QMule 不是一个Jms serverQ但是可以配|来使用M你觉得非常漂亮的Jms server。Mule 的理忉|Q如果已l有?jin)稳定和q泛接受的实玎ͼ׃?x)直接实CQ何传输。例如,Mule 重用了(jin)Axis ?GLUE 的SOAP栈而不是重新实C个。Mule 提供?jin)一个一致的服务集来理Mcd的连接的事g、关联、事务、安全和审计?/P>
下面是Mule Server lg的简单图C:(x)
Mule Manager是Mule server 实例的中?也称Z个节Ҏ(gu)或者Mule Node)。其主要的角色是理各种对象Q比如Mule实例的连接器、端点和转换器。这些对象然后被用来控制q出你的服务lg的消息流Qƈ且ؓ(f)Model和它所理的组件提供服务?/P>
model 是管理和执行lg的容器。它控制q出lg的消息流Q管理线E、生命周期和~充池。默认的MuleModel是基于SEDA的,它用一个有效的Z事g的队列模型来获取的最大的性能和直通性?/P>
UMO代表Universal Message ObjectQ它是一个可以接收来自于M地方的消息的对象。UMO lg是你的业务对象。它们是执行引入的事件之上的具体业务逻辑的组件。这些组件是标准的JavaBeanQ组件中q没有Q何Mule特定的代码。Mule Z你的lg的配|处理所有进出组件的事g的\由和转换?/P>
Endpoint是Mule的通信能力的基。一个Endpoint定义?jin)两个或者多个组建应用或者存储库之间的通信渠道。ƈ且提供了(jin)一个强大的机制来允怽的对象在一个统一的方式上再多U协议之上进行交谈。端点可以通过消息qo(h)器、安全拦截器和事务信息进行配|来控制什么消息,在何Ӟ以及(qing)怎样通过端点q行发送和接收?/P>
外部应用可以使Q何应用,从应用服务器到遗留的传统应用Q主机程序,或者C/Spȝ。基本上是Q何可以生和操纵数据的应用。因为Mule通过endpoints执行所有通信QUMO lgq不打算在其中包含应用生数据,以及(qing)应用LQ以?qing)用传输协议的部分?/P>
一般在q些情Ş下用Mule -
目地址Q?A >http://mule.codehaus.org/