狠狠色香婷婷久久亚洲精品,在线观看亚洲精品国产,亚洲码和欧洲码一码二码三码

企业服务�ȝ��(ESB)(7)

铁手 — Fri, 31 Aug 2007 03:11:00 GMT

2.4重构到ESB

从偶然架构到一个全球规模的�l�一的集成基��设施可能是像一个��人畏�~�的��d��?把一切都准备��q�A�Q�然后再象扳动一下开关那样将所有的应用都一下子转移到新的基��设施之上是不现实的。这已经是组�l��ؓ什么老是要不断添加偶然架构方案作为权益解决之计的一个主要的理由�Q�甚至他们确实知道这样��相关的问题永垂不朽也是如此�?

ESB 提供了能力来帮助减轻所介绍的痛苦�?�W?9 章将通过一个案例来介绍如何�q�离一个完全徏立在 FTP 和每夜批处理作业之上的早以存在的集成解决�Ҏ��?

让我们现在重新回到对偶然架构的讨论�?在图 2-6中，实线、虚�Uѝ��点划线代表用于集成的不同类型的�q�接技术和通信协议。注意其中有一个用集成Broker表达的已存在�?“集成孤岛”�Q�以及POS应用和胦务应用之间的�q�接是��用FTP 文�g传输。在POS应用和ERP应用之间先前已经升��来��用HTTP 之上的SOAP协议�Q�正如销售自动化应用 (SFA) 和客户关�pȝ��?(CRM) 之间的联�l��?

图表 2�? 使用SOAP通信�?FTP 、手工插座（Socket�Q�、而且包括一个集成Broker的代表性的偶然架构

2.4.1 从单个项目层面引�?/a> ESB

ESB 可以在一个部门��的层�ơ或在一个项目的基础上被引入�?在项目层�ơ采�?ESB 允许你能够习惯于使用 ESB 服务容器�q�行��Z��标准的集成，�q�且完全可以坚信该项目能够集成到一个更大的集成�|�络之中�Q��ƈ且与企业�U�的公司的集成策略目标相一致�?

我们采用ESB的例子中的第一个步骤是要集成前端应用（FrontOffice�Q�。在�?2-7 中，前端的CRM、胦务和SFA 通过“服务容器”�q�接到ESB 之中。这些容器是 ESB 架构的主要组�Ӟ��我们��在�W?6 章详�l�解释�?�l�过 ESB 服务容器�q�行的集成的�Ҏ��可能会不同�?容器和应用之间的接口可以通过使用�W�三方的应用适配器来完成�Q�容器可以暴露��用WSDL描述的XML数据�Q�或者它可能被实��Cؓ完全用户定制的代码�?

图表 2�? ESB 可以在不打破原有点对点�\径的前提下，在单个项目基��上采�?

但是也许更有��的不是那些已经集成到ESB 之内的东西，而是�q�没有集成进�ȝ��东西。图 2-7 表示了已有的 FTP 和SOAP协议之间的通信�U�，原来是连接到前端应用的，现在直接�q�接到那些特别配制来使用那些协议�q�行通信的ESB�l��g。应用仍然处于�ȝ��“之外”�Q�Pos应用和伙伴CRM应用可以与集成到ESB�ȝ��“之内”的前端应用进行通信而不需要做��M��修改�Q�对他们如何参与ESB基础设施也不需要知道�Q何东�ѝ��注意，现在POS应用是连接到ESB 上的一�?FTP 桥接器，而且伙伴CRM应用则是�q�接到配�|��ؓ�ȝ��的一部分的Web Services端点�?

ESB 已经被引入了�Q�但是对�q�些配备了ESB能力的应用以前所�q�接的点对点通信�l�合区没有��生�Q何媄响。被插入�ȝ��的应用如今�{而��用连接到ESB 集成容器的一个单一接口�Q?而且已经省却了对它们先前所有其他类型的通信�q�接的管理和�l�护�?

我们��会在第 9 章中看到�Q�即使是�ȝ��域中最新集成的应用也可以就地将他们转移到完全的ESB方式�Q��ƈ且与它们各自的项目开发时间线�怸�致�?

2.4.2 跨广泛分布的企业传播ESB

在我们的ESB采用的例子得下一阶段中，POS应用��在每一个远端实现ESB能力�Q��ƈ且去除对不可靠的 FTP 联结上的依赖�?�q�可能会��单如在每一个远端安装一个ESB容器�Q��ƈ且插入到总部的ESB之中�Q�或者涉及到在每一个远端的多个应用之间的一�?#8220;�q�你”的集成环境。那么二�?ESB节点��可以通过一个基于可靠消息的安全�q�接�q�行通信(�?2-8)

图表 2�? 在各个地点分立安装的ESB可以安全和可靠地�q�接在一�?

此外�Q�远端位�|�仍然可以在他们自己的分��集成环境里面运行，�q�且可以按照需要有选择地共享数据。例如，�q�端位置可以独立地拥有�ƈ且运作一个属于集体特许经营的零售店铺。它们没有必��d��享关于它们的日常�q�作的信息，但是的确需要共享诸如�h格更新和库存信息之类的数据。远�E�ESB 节点可以�q�接��C��于总部�?ESB �|�络�Q�有选择地暴露消息通道以共享�h格变动之�cȝ��数据�?

2.4.3 保留和分�?/a>: �q�入现有�?EAI Broker�q�接

我们的ESB 采用�C�Z��目的第三阶�D�|��及到桥接�q�进一个已�l�部分地与一个集�U�器-�?插头 EAI Broker集成在一��L��部门。我们先前提醒过�Q�采�?ESB 不是一个全有或全无的概��c��如�?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的功能仍然可以保留较低层的、消息通道�?

2.4.4 集成伙伴

我们�?ESB 采用�C�Z��目的最后步骤是解决和业务伙伴集成的问题。如�?2-10 所�C�，�q�可能包括原样保留SOAP联结�Q�以及在每个伙伴端安装一�?ESB 节点。决定采用哪一�U�方法完全依赖于你的�l�织和伙伴之间的关系�Q�以及业务伙伴是否允�怽�在其地点安装软�g�Q�或者他们已�l�有能够�q�接��C��的ESB之上的ESB�?

图表 2�?0 ESB 可以个别地管理与业务伙伴的SOAP联结, 或者可以连接到另一个地点的ESB节点

插入��C��?ESB 扩展的分层的服务能够��理对伙伴的�q�接的后勤保障。例如，一个特�D�的伙伴�l�理者服务可以在每一个伙伴的基础上管理与伙伴之间的正在进行的协作的细节。这些细节可能包括正在��用哪一个更高层�ơ的业务协议(比如�Q?ebXML、RosettaNet �{?、以及对话的状态，比如消息交换的当前状态、是否收��C��个期望的应答消息、以及从业务伙伴接收��C��个业务响应所能够接受多长的时延�?

2.5��结

本章包含下列主题�Q?

�Ҏ��q�泛的、更通用的集成基��设施的需要的各种驱动因素
偶然架构是今天所使用的主要集成设计�?在这�U�系�l�中�Q�当前的企业完全没有很好地联通的�?
只有 10% 的应用被联接�?
而这些之中，只有 15%的��用了某种�c�d��中间件�?
到目前�ؓ止，分布式计��技术加重了�Q�而不是解决了�Q�偶然架构的问题�?
集线�?�? 插头EAI Broker已经有了一定程度的成功。然而，它们:
大部分是专有技�?
没有为组�l�提供一个标准化的、可以在企业内通用使用的集成��^台�?
ESB 借鉴了在 EAI Broker技术方面学习的�l�验的�h倹{�?
集成作�ؓ是一个部门层面和公司文化的问题，和它作�ؓ一个技术上问题同样重要�?
ESB 允许逐渐增加的采用，以符合各个部门单独的开发时间表�?/li>

铁手 2007-08-31 11:11 发表评论

企业服务�ȝ��(ESB)(6)

铁手 — Fri, 17 Aug 2007 04:19:00 GMT

2.3借鉴来自 EAI �?SOA 的最佛_��?/h4>
在我们��l�前�q��ƈ且牺牲我们的先前努力�Q�丢掉前面的每个技术，�q�且向失败�D��h��们的双手之前�Q�还有一条�\能够让我们能够利用从学来的宝�늻�验，�q�且仍然�q�离偶然架构—那��是采用ESB�?集成的最佛_��践，已经�l�过寚w��成Broker的经验被�_��Q�如今还可以�l�合建立于XML、Web Services、可靠的异步消息、以及分布式的ESB集成�l��g之上的基于标准的架构来一起��用�?他们一起�Ş成一个高度分布的、松散耦合的集成架构，以提供集成Broker的所有主要功能，却没有其所有的障壁�?
�q�离偶然架构�q�且使用 ESB重构到的一个统一的和一致的集成骨干�Q�涉及到下面��结描述的步骤�?

2.3.1 采用XML

虽然ESB ��实能够传送许多类型的数据格式�Q�但是采用XML作�ؓ应用间交换数据的手段 (�?2-2)�Q�如同已�l�被用在一些传�l�的 EAI 方式中一��P��可以由很多好处。我们将会在�W?4 章中看到�Q��用XML可以一��x��逸地隔绝全局的数据格式和接口的变更和偶然架构本��n。ESB可以�q�一步通过��查XML消息的内容，�q�且控制其向何处提交�Q�有时候还可以改变提交路径来包括可能会修改和增加数据的附加服务�Q�一�ơ来促进业务处理�?

图表 2�? ESB 使用XML来作为应用间�׃�n数据的方�?

2.3.2 采用Web ervices�q�实�?SOA

�?SOA 的方式来思考和规划在向 ESB重构的一个基本步骤。如�?2-3 所�C�，服务�U�接口的引入在提供了一个公共抽象层来创建接口和实现之间的分��R��这样就通过使用一�U�通用的接口定义机�Ӟ��比如Web Services描述语言(WSDL)�Q�来减轻了由�l�粒度服务接口组成的复合业务��程定义的构造的隑ֺ��?

图表 2�? Web 服务�?SOA 提供了一个隔��L��口和实现的通用抽象�?

虽然服务�U�接口的抽象是正��方向上的一步，�l�果仍然是一个�\由逻辑密合于应用之内的��连�?( 注意在图 2-3 中，“流�E�逻辑”仍焉��附于应用)。Web Services中的传统智慧已经模仿了客�?服务器模式。甚臛_��一个Web Services分布式网�l�中�Q�一个应用��L��另一�?“客户”。范例用法仍焉��要抽象层也包括胶水代码，比如说“调用服务X上的�Ҏ��a�Q�然后调用服务Y上的�Ҏ�� b()�?”诸如此�c�R��?

Web Services实现中所��实的东西是��流�E��\由逻辑从接口定义和应用逻辑中分��d��来观��c��如�?2-4所�C�，ESB ��提供了那种隔离�Q��ƈ且仍然完全利用SOA�?

图表 2�? ESB ��业务流�E�的路由逻辑从接口定义和应用实现中分��d��?

通过分离接口定义和流�E��\由逻辑�Q�我们已�l�开始看到ESB 形式的�ȝ��?�?2-5)。通过��流�E�业务�\由逻辑和接口定义放入�ȝ��层之内，应用能够�l�箋自己集中于实现逻辑�?我们在第 1 章中看到�q�，ESB 被实际上区分为多个功能层。它为应用间的可靠的、异步的、基于消息的通信提供了一�U�坚固的底板。也是在�q�里�Q�流�E��\由通过��Z��查消息中的XML内容来附加的条�g决策点，从而变得具��h��能。这个智能�\由是被可��理地定义的、可以被修改、�ƈ且可以加上增值服务，比如补充数据变换功能。ESB 提供了一个可扩展的集成服务网�l�，�q�且可以无限伸展�Q�同时仍然可以以逐渐增加的方式进行构�?

图表 2�? ESB 可靠地连接和协调SOA 的服务之间的交互

铁手 2007-08-17 12:19 发表评论

企业服务�ȝ��(ESB)(5)

铁手 — Wed, 15 Aug 2007 03:11:00 GMT

2.2企业集成的目前状�?/a>

�q�一节将详细讨论�Q�今天各个企业应用怎样�q�行集成、或者怎样没有集成。还包括对今天很多组�l�中很流行的集成方式�Q�偶然架构的讨论�?

2.2 .1 企业大都�q�接不善

在过��M��十年以来�Q�无数分布式计算模型一一��d��Q�包�?DCE、CORBA、DCOM、MOM�?EAI Broker、J2EE、Web Services�?NET�?然而，�q�象表明�Q�不��采用何�U�技术，只有很少��C��业的应用时很好连通的。按照来�?Gartner 公司的一个研�I�报�?a href="#_ftn1">[1]�Q�这个数字少�?0%�?

关于应用的连通性，其他的统计数�l�果更��o人吃惊，�?只有 15% 的应用的集成采用了正式的集成中间件。其余则使用 ETL 和批量文件传输技术，其主要以手工�~�写的脚本和其他定制�Ҏ��为基��。关�?ETL 和批量文件传输的更多信息�Q�以及他们相关的问题�Q�我们在�W?章讨论�?

2.2.2 偶然架构

Gartner 15% �l�计值提供一个关于当今的集成状态的一个��o人深思的数据。那么其�?5% 的应用是如何�q�接的呢? 一�U�在今天的企业中普遍存在的情形，我将其称为是“偶然架构”。所谓偶然架构就是没有�h公开宣布创造的�Q�相反，是多�q�积累的一�U?#8220;��׃��Z��”的解��x��案。在一个偶然架构中�Q�公司的应用被永�q�锁定在一个不灉|��的刚性基��架构之上。然后他们又被视为是信息“地牢”�Q�因为集成基��设施不能适应新的业务需求�?(�?2-1)

大多数集成尝试都从某个深思熟虑的设计开始，但是�l�过一�D�|��间后�Q�其他的部分好像都各��各位地“集成”了，但是手工�~�写的代码却早已飘移出原来的内容之外。经�q�逐渐�q�行的螺栓和补丁�Q�所谓整合的�pȝ��已经失去了其原来的设计完整性，��其是如果系�l�是被很多的人来�l�护的，而他们对最初的设计意图可能没有很好地沟通。事实上�Q�这�U?#8220;��׃��Z��”的方法将完全失去集成的一致性，因�ؓ工程师��d��?#8220;只是做一点点修改”作�ؓ解决问题的权益之计。最后甚臛_��扑և�那些地方做了修改都变得非常困难，更不要说要理解这些结果导致了那些斚w��的副作用影响。在一个部�|�系�l�中�Q�这可能会对你的业务造成损失惨重的悲惨结果�?

寚w��成遵守标准能够�ؓ你创��Z��个针�Ҏ��期望功能的基�U�来遵从。如果基��设施是专有的�Q?不基于标准的�Q�那么随旉��变化保持计划的设计和指导原则��变成棘手问题。虽然也可以构造专有的�q�_��q�且变通规则，但是�q�通常又导致更�?#8220;多样�?#8221;的后果，�l�果更加锁定于其上。然而，你应该记住的是简单地遵守标准�q�不必然地阻止你构徏一个偶然架构�?

图表 2�? 偶然架构��永�q��公司的应用成�?#8220;信息发射�?#8221;

在偶然架构背后的技术是各不相同的。图 2-1中的实线、虚�U�和点划�U�表�C�Z��q�接应用的不同技术。这些技术可能包�?FTP 文�g传输、直接的socket�q�接、专有的MOM、以及有时是 CORBA 或其他类型的�q�程�q�程调用(RPC) 机制。某些定向的点对点解��x��案可能已�l��用了XML信封定义�Q�或者基于SOAP或者其他什么机制的技术，来�ؓ集成的应用之间承载数据�?

图中间的集成Broker表示了在部门�U�的层次�q�接应用的一个岛�ѝ��然而这�q�不意味着它能够连接�Q何事物。集成Broker通常只是�l�交�l�基��设施中的某一块，因此资金丰富的项目可能会取得适度的成功，但是它们再也不能与其它所承诺的部分进行很好的集成�?

偶见架构表现为得��C��个刚性的�Q�不能对集成提供一致的、持久的基础设施。它不能如其应该辑ֈ�的效果那样很好地解决你的�l�织性的问题。要改变偶然架构一直以来就是个挑战�Q�因为点对点的解��x��案的数量不断在增�ѝ��这通常也意谓着应用之间的互�怾�赖性是紧密耦合的。��应用中的数据的表现的修改意谓着你还必须修改�׃�n该数据的其他所有应用。这��限制你快速地改变你的业务��程�Q�以适应变化了的或者新的业务机会。这些紧密耦合的、硬�q�接的接口不仅仅是偶然架构的问题。因为控制流、业务应用之间的通信的编排被��编码进应用本��n之中�Q�这�q�一步导致了复杂化。这些都增加了系�l�之间的紧密耦合和脆弱性，使变更业务流�E�更加困难，�q�且��D��了厂商所定�?

2.2.2.1 部门和组�l�问�?/a>

偶然架构的先天技术不��队�l�织中的人力协调问题��h��推�L助澜的作用。不��问题是紧密耦合的接口还是硬�~�码的流�E�编排，要想回头或者对其进行较大的��L��攚w��简直是一件恐怖的事情。这�l�常需要安排大量的会议�Q�和属于不同��目的不同的开发组的�h们开会，��q��紧对要做什么以及何时做�q�类的问题达成一致。如果应用，以及他们分属的开发项目组�Q�分别处于不同的地理位置和时间区�Q�应用改变所需的协调问题则会变得更加困难�?

有时某些应用�E�序被视�?#8220;遗留”�pȝ��Q�对他们你是不愿意或不能够对其进行多��修改，因�ؓ它们已经�q�入�l�护模式。我们通常��_��“遗留�pȝ��”的一个定义就是那些你昨天刚安装的�pȝ��。即使你对自己开发的应用��h��完全的访问和源代码的控制权，当开发�h员��l�进行其他项目或��d��公司的时候，对其�q�行修改也是非常困难的。我们将会在�W?4 章中看到�Q?ESB 大大地减��了随时间变化，修改数据模式和格式所带来的媄响�?

2.2.2 .2 逃离偶然架构

即��你已�l�对跟踪和修改应用数据及其接口徏立了良好的公司实践，偶然架构仍然�q�有其他�~�点。��用不同的�q�接技术意谓着安全模型可能是�؜杂的�Q�所以没有确定的方式来徏立和执行公司�U�的安全�{�略�?�Ҏ��入新的应用没有一致的 API可以依赖�Q�而且没有基础来在��上构徏公司关于集成的最佛_��c��最�q�与一些领导的专家�q�行了交��，�ȝ��了偶然架构的下列各项问题:

不可靠�?/strong>

应用之间的通信或许能得益于异步的消息的可靠性。如果一个大型业务流�E�中的某两个应用之间的通信�q�接��p�|�Q�整个业务流�E�可能会事务性地�q�回或者重启。我们将会在�W?章学到更多有��x��散耦合的、异步的可靠消息的更多内宏V�?

性能和可伸羃性分�?/strong>

不管你是否你已经有了一个预先的性能规划�q�且试图分析一个现有的性能问题�Q�由于偶然架构的许许多多的子�pȝ��和他们各自的�q�行特征�Q�这个工作是极其困难的。通常的做法是采用��h��的�?#8220;投入资源到其中，直到它能正确�q�行”式的解决�Ҏ��Q�这��造成��盘、处理器、内存等上面的过度开支�?

��M��排错

没有哪个单一�Ҏ��能够提供充分的诊断和报告能力�?意外架构需要很多具有很高能力的�l�护人员围着所有有�~�陷得生产系�l��{�Q�这��导致整体拥有成�?(TCO)的急剧上升。各部分实现的方式差异越大，在其失效旉��要用来解军_��们的问题的专家经验就��宽。另外，建立一个基�U�来描述期望的正��行��Z��是一个挑战�?

冗余和弹�?/strong>

没有��M��方式能够保证�q�个泥潭中的所有组建都能够满��你的关于可接受的冗余、弹性和定w��度的定义。这意谓着要�ؓ依赖于后�D늳��l�的新功能定义可辑ֈ�的服务��别协�?(SLAs) 是很困难的�?

帐单漏洞

如果你的�pȝ��携带又能够收费的帐单数据 ( 比如电信)�Q�那么�̎单数据的利息��可以被丢失在偶然架构之中。因此，你可能会损失收入�q�且�q�一炚w��不知道�?

监控和管�?/strong>

没有一致的�Ҏ��来监控和��理一个偶然架构。假定你的整合应用系�l�必��运�?24/7 �Q�而且你的职员负责��x��q�行监控工具�Q��ƈ且做出纠正。这些工具将不会以相同的方式工作�Q�那么在无数不同的小�Ҏ��的基��上进行培�?( 和再培训) ��是非常昂贵的事情。简单地安装企业�U�的�q�行��理工具�q�不能自动地��自省能力提供给集成基础设施�Q��ƈ且偶然架构通常�q�不能提供所有可能需要的控制炏V�?
总而言之，偶然架构表现��Z��U�刚性的、高成本的基��设施�Q��ƈ且不能满��你的组�l�变更的需要，�q�要承受以下�~�点的痛苦：

紧密耦合的、易��的、对变更不灵�zȝ��
因�ؓ多个点对点解��x��案导致的昂贵的维护负�?
修改一个应用程序可能媄响其他很多应�?
路由逻辑是硬�~�码到应用程序之中的
没有通用的安全模型；安全是�؜杂的
没有通用�?API(通常)
没有通用的通信协议
没有建立和构建最佛_��늚�通用基础
难以支持异步处理
不可�?
没有对应用和集成�l��g的健��L��控和部��v��理

如你所知，偶然架构的创建已�l�有些年头了�Q�要替换和解军_��q�不是一�y�而就的事情。随着�l�承��目的需求的增加�Q�解��x��案应该更加柔性的、简单、以及运行便宜，而不是其他什么东�ѝ��偶然架构给了你的那些敏��L��竞争者得到好处，而你却不能够在一个合理的旉��范围内实现新的业务机会�?
你需要一个内聚的架构�Q�面向实��c��标准来解决着大量的问题。ESB 提供了架构和基础设施�Q��ƈ且��你能够逐个��目的基��上采用它。采�?ESB �q�不是全有或全无�Q�推倒重来式的方式。而是�Q�你可以渐进式地采用它，同时�q�能利用你的现有资��-包括偶然架构和集成Broker�Q�以一�U?#8220;留下而分�?#8221;的方式�?
2.2.3 ETL�Q�批量传输，�?FTP

提取、�{换、和载入 (ETL) 技术，比如 FTP 文�g传输和每夜批处理式的集成在今天仍然是最��行的方法�?
�q�通常涉及到将位于各个应用中的数据打包然后上传�q�样的操作。问题是有很大的可能在应用间的数据失��d��步。一个失败的打包上传的处理程序可能要�׃��一天的旉��。在京及和业务全球化的情况下�Q�系�l�以24/7 的方式运行，再也没有�?#8220;夜晚”的概念，那你得批处理又该在何时执行呢�Q?
其他问题也可能与每夜的批处理相关。因为批处理的反应期问题�Q�在分析关键业务数据的时候，最好的情�Ş�?4 ��时轮�{旉��。这一延迟可能严重地阻��你寚w��时变化的业务事�g�q�行反应的能力�?
有时�Q�一�ơ跨��多个面向批处理�pȝ��的端对端处理处理甚至会花费一整个星期才能完成。处理从源头到目标的数据的��M��潜伏反应期完全阻止了攉��h��意义的，反应目前业务情�Ş的数据的�z�察力。比如，在供应链的场景中�Q�这��导致你永远不知道你的库存的真实状态�?
�W?9 章将会呈��C��个通过FTP�q�行成批传输的技术和业务意义的案例研�IӞ��q�且会研�I�ESB如何能帮助你逃脱偶然架构的困境�?
2.2.4 集成Broker

集线�?�?插头的集成Broker�Q�或者EAI Broker�Q�提供了偶然架构的替代。集成Broker是从上世�U?0�q�代出现在，现在已经被植入到MOM��d��或应用服务器�q�_��之中�?
集成Broker市场的一些公司包�?

SeeBeyond
IBM
webMethods
TIBCO
Ascential (Mercator)
BEA (more recently)
Vitria

集成Broker能够使用一个集�U�器-�?插头架构帮助偶然架构提供应用之间的集中�\由。此外，他们�q�允�怋�用业务程序管�?(BPM) 软�g��业务流�E�从下层的集成代码中分离出来。到此�ؓ止，所有的都是好消息�?
然而，寚w��成Broker方式也有�~�点。一个集�U�器-�? 插头拓扑不允许对局部集成域之上�q�行局部控制。构建在一个集�U�器-�?插头拓扑之上的BPM 不能够徏立跨��部门和业务单位的业务流�E�极其编排�?集成Broker也可能受限于下面的MOM不能��过物理的LAN�|�段和防火墙的能力限制�?
有许多公司已�l�在光��成策略中采用了集�U�器-�?插头的集成Broker解决�Ҏ��?�q�些技术具有较高的成本�Q��ƈ且成功也值得怀疑�?990 �q�代后期的昂贵集成Broker��目已经取得了名义上的成功，但是��组�l�置于专有的集成域的井中。一��Forrester�?001 �q�十二月发布的研�I�报�?a href="#_ftn2">[2] 展示了下列各��统�?

集成��目�q�_�� 20+ 个月才完�?
��于 35% 的项目能够准时和在预��内完成
35% 的��Y件维护预��被��p��在维护点对点应用�q�接之上
�?2003 �q�_�� 全球 3500 家企业��^均期望花费六癑֛�十万��元到集成项目上

�q�项研究�q�是在EAI 在它的最��峰的时候进行的�Q�而且几乎没有�q�象表明�q�一数字在那时候�v之后得到了改善。注意一�q�六癑֛�十万��元是公�怼�在集成项目上��p��的��^均数的一个预��。当于这些公司的领导们交��这些问题的时候，我进行了一个一般性的求证�?
照今天的预算标准来看�Q�EAI Broker��目是很昂贵的。集成��Y件费用很�늚��Q�通常单独对于软�g许可费用�Q�每个项目的��h��范围��在�?$250,000 ��C��百万��元不等。这�q�不��一��L��咨询服务�l��g�Q�而这个组件的��h��往往是��Y件许可费用的5�?2倍�?
集成Broker高昂的启动成本又被另一事实所�q�一步恶化，即从一个项目中学到的知识不能很好地转移��C��一个项目。由于传�l�的 EAI Broker技术的专有�Ҏ��，通常��h��很陡峭的学习曲线�Q�对于每个项目来��_��有时候实6个月。要试图弥补�q�个负担的通常方式是聘请事前对专有技术经�q�培训的特别的顾问。当�Ӟ��高特�D��?高�h根{��这是高昂咨询费用的一个重要组成部�? 另一个大的组成是技术安装、配�|�、部�|�Ӏ�和��理的复杂�?。�ƈ且一旦项目完成，��N��׃��见了�?
集成��目的实现时间普遍是�?6-18 月之间。这意谓着。根据事前针对短期设定的标准、以及项目资金，实施旉��吃掉了项目原本想要利用的�{�略性窗囗�?
集成Broker的专有性质�Q�以及高昂的咨询费用通常��D��供应商锁定和重启后箋��目的巨大成本。这意谓即便对于成功的项目，增长和��展也是��o人恐惧的。而且在你对你的供应商或者实现心生不满的时候，你也得面对到底是��q��前的情况�l�箋��C��去，�q�是选择完全重新开始，雇用更多的咨询顾问或者投入另一个新的学习曲�U�之间左右�ؓ难。因为所有这些，一些IT�l�织通常留下了一些难以再集成到其他项目的“集成孤岛”。总而言之，集成Broker已经证明是偶然架构里面的老套技术，而�ƈ非它的解��x��案�?
当我们更详细地讨论集成Broker的时候，我们��看到导致这里所列的问题的技术屏障。另外，许许多多的非技术因素也��D��了对采用ESB的需求的增长�?

[1] [2]来自 Gartner 公司的统�?"集成Broker�Q�应用服务器�?APSs,"10/2002.
[2] [3]来自 Forrester 研究的统计学,"减少集成费用,"12/2001.

铁手 2007-08-15 11:11 发表评论

企业服务�ȝ��(ESB)(4)

铁手 — Mon, 13 Aug 2007 02:13:00 GMT

2集成的状�?/a>

各种因素�Q�包括技术和业务层面的，��D��Ҏ��的集成方式的需要。有许多新的业务驱动因素�Q�比如经��条件的改变、新的革命性的��g技术比如射频识别标�{?(RFID)的出现、法规管制的遵从�Q�都预示着从业务视图来看，应用集成和数据共享都要发生重大变革。这些驱动好像与企业中目前的集成状态不一致子�Q��ƈ不象你所想的那样��前。当我们在这一章中详细研究的时候，大多数应该只是简单集成的��目不能很好集成�Q�主要是�׃��~�Z��能够�q�泛采用的一致的�l�承�{�略所致�?
下面是媄像着�Ҏ��大规模的集成解决�Ҏ��的需要的各种需要：

�l�济的驱动器�?/li>

�q�些已经改变了IT��p��的�Ş式。经��因素导致IT部门主要集中于��事情能够与他们当前已�l�有的应用一起工作�?

最高优先序: 集成�?/li>

调查�l�果表明集成�l�箋处于CIO的优先序列的最��层�?

法规的遵�?/li>

Sarbanes-Oxley法案、PATRIOT法案、以�?FCC 法规都强�q�公司徏立一个必��ȝ��内部基础设施来比以前一��h��加详�l�地跟踪、�\由、监控、和获取业务数据�?

直通处�?(STP)

STP 的目标是消除业务��程的无效率�Q�比如数据的人工再输入、传真、纸面邮件、或者不必要的数据批量处理。在行业中，比如金融服务�Q�这可以帮助辑ֈ�几乎零反应期的交易处理�?

��频识别标签(RFID)

被视��Z��一代条形码的革斎ͼ� RFID 可能会��生大量的新型数据�Q�然后这些数据需要被路由、变换、聚集，和处理�?
不幸的是�Q�公司的集成环境的目前状态在�q�些领域几乎没有取得什么进展。这又��得业界领袖不得不重新��L��更广泛的集成解决�Ҏ��。而有关集成的目前状态的问题包括:

良好�q�接企业的普遍缺乏�?/li>

�q�阻��了企业向自动化业务��程�q�步�Q�然后由�ȝ��了其对不断变化的业务需求的快速反应�?

偶然架构

偶然架构是一�U�一直��用的事实上的集成方式�Q�其�l�果是没有连贯一致的公司�U�的集成�{�略。这表现��是要留下点对点的集成、每一个都有其自己的连接和集成风格。偶然架构表��Cؓ不连贯的脆弱和刚性架构、�ƈ且不能经受集成环境的新的附加条�g和变化�?

ETL�Q�批量传输和FTP�?/li>

使用FTP文�g传输和每夜批处理的方式进行提取、变换和载入 (ETL) 的技术仍然是今天“集成”最��行的方法�?�q�些处理涉及到每夜对各种应用之上的数据进行打包上载的操作。由于这�U�做法的潜伏反应期和错误率，�l�织从来不会不真正拥有对它们的关键数据的好的快照�?

�q�去使用集成Broker的危险�?/li>

上世�U?0 �q�代后期�Q�昂�늚�集成Broker��目看似成功�Q�但是给�l�织留下了大量专有的集成领域难以消化�?
�q�章��会详细讨论�q�些因素。除此之外，它将会解释通过逐渐采用重构到ESB的好处，同时使用学习自集成Broker技术的最佛_��c�?
2.1业务驱动�Ȁ发集�?/a>

2.1.1 IT开支的��势

�l�济因素��D��IT部门主要集中于��事情能够与他们当前已�l�有的应用一起工作。在Y2K之前�Q�大多数公司都把它们的主要花贚w��中在准备应付 Y2K之上�Q�包括购买打包的没有Y2K问题的应用�?
后来的经��低�q�h��期，不管是否归结于后Y2K时代、Internet泡沫破灭时代�?/11、或者战争的不确定性，都已�l�导致了IT��p��的急剧变化。这已经有对集成造成了特�D�的冲击�Q�不��是正面的还是负面的。IT预算和前 Y2K时代相比已经今非昔比。再也不会出现IT�l�理手中握着寚w��成Broker软�g和服务的数百万美元预��，�q�且�q�要��p��18-24个月的时间来�{�待��目�l�果�q�样的事情了。IT��p��现在变得都要通过执行层，每一个项目都要经�q�仔�l�审查。只有对业务生存能力臛_��重要的项目才能得到资金。公司在每一个项目的基础上要求在3-6个月的时间片内得到切实的效果和投资回报，虽然他们仍然�l�持着改良整体�q�行效率的策略目标�?
2.1.2 作�ؓ高优先��的集�?/a>

新的节�P时代�q�没有减��对业务��程的改�q�和寚w��成的需要�?业务层面的驱动仍然存在；减少业务周�{旉��需要，减少存货水��^的需要，消除重复IT服务的需要，如此�{�等�?
IDC的一分报告指�?a href="#_ftn1">[1] 他们调查�?57个CIO关于他们2004�q�事情的优先�U�。关于集成报告中�q�样�?
�?003�q?月�D行的IT和执行层交流会上�Q�关于什么可以被�U�Cؓ“市场推动”趋势的问题�Q�集成已�l�成�?004�q�IT规划中比安全��h��更高优先�U�的事情�?
报告同时指出�Q�集成和安全分别占第三和�W�四位，在最高的CIO优先�U�的列表中，仅仅排在“基��设施替换/升��”和“IT费用削减”之后�?
��M��癑ֈ�比则受到了有 21% 的“中间市场”公司将集成的重要性排在前面的影响�Q�甚臌��q�了“减低成本”和“基��设施替换/ 升��”。表 2-1 战士了这个问题的�{�案:�?下列各项问题�Q�你认�ؓ�?2004 �q�终期待有最高的优先�U�吗? 选择一个。�?

[1] IDC�Q�应用开发中的集成标准趋�? 着全赖于“开�䏀�的真正含义�Q?003 �q?1�?(文�g #30365) �Q?http:// www.idc.com �?

2.1.3 法规遵从

有时候，寚w��成的需要在强加于你的，不管你是否喜�Ƣ它�?甚至在困难时期，当预��紧张时�Q��ؓ了集成目的而对基础设施�q�行修补也一定要遵从政府的法规管制�?如大部分它�h们会证明,不有而有很多的仅仅��l�尝试维持状�?为新的集成策略担忧�?然�?没有像有者监牢时间和强烈的罚�ƾ视野得到资��q��理注意�?
�׃��范规��制的问题，一些行业的公司必须向竞争者提供信息，�q�且对信息访问进行审计。比如，在电信业中，负有职责的电信营�q�商(ILECs) 应该提供信息�l�竞争的 LECs 。能源公用事业也应该提供账单信息�l�竞争者。保健机构和隐私法律需要跟�t�客戯��录访问以供审计之目的。这需要你的分��ȝ��数据能够以标准的协议和以标准的格式轻易被讉K��?
下面是一些领域，在其中法规遵从是个驱动力�?
2 .1.3.1 电讯

一�?FCC 法规要求所有的电讯提供商和地方性的向地�Ҏ��的营运商暴露他们的客户数据的某些部分�?一��M��电讯供给者正在有强烈的罚�ƾ欺骗它��Z��遵从�q�一个需求。很明显�Q�甚至一家主要公�怹�不能够负担得��L��l�基��上支付那么多的钱。与法律要求的共享信息相关的许多问题和高额成本，�q�且�q��o掉那些法律不要求的部分。因此，一个过分单�U�的�Ҏ��不能同时满��法律要求又能保护敏感的公司数据。你需要又�l�粒度的�q��o器和有选择的数据变换来只提供必需的数�?(也许只有在最后的一分钟) 来最��化你的竞争者可能访问所��D��的对你的数据的利用。所有这些都需要有对业务流�E�的�l�粒度的讉K��和控制�?
电信提供商需要一个基于标准的、能够��展到��的电信提供商的集成解决�Ҏ��Q��用较��的电信商也能够采用来作为集成策略的各种协议。�ؓ了满��个需要，公司最�l�采�?ESB �?
1.1.1.2 Sarbanes-Oxley

2002�q�颁布的Sarbanes- Oxley 法案旨在通过改善公司信息披露的准��性和可靠性来保护投资者，它强制了新的报告需求，�q�且对公司的决策者和他们的企业引入了更高的问责性�?遵从Sarbanes- Oxley 法案需要面临一些真正的挑战。包括费用考虑�Q�后勤复杂性，数据攉��和管理问题，以及正确的数据的及时报告�Q�不��数据存在于哪一个企业之中�?
2 .1.3.3 政府

��国联邦政府已经讑֮�一个目�?�?003 之前变成无纸化。在2003�q�一月的��国政府CIO高峰会上�Q�Brand Niemann�Q�CIO理事会XML Web Services工作�l�的��d��Q�对��国政府的集成中采用XML的驱动力是这栯��?
1998�q�的政府文书工作消除法案�Q�要求联邦政府机构在2003�q?0月前�Q�如果可行，允许与政府打交道的个人或者实体能够有选择地向政府机构电子化地提交信息和进行交易处理，或者如果可行，允许�l�持电子记录�?
法规遵守产生了巨大驱动能量，�q�且集中于跨��整个政府机构集成后端应用和数据源。当我们在第 11 章讨论门��L��境中的ESB 的时候，ESB能够在门��h��务器和多个后端应用之间扮演媒介中介而提供重要的价倹{�?
2 .1.3.4 直通处�?/a> (STP)

直通处�?(STP)意味着对于跨越整个�pȝ��和组�l�的业务��程的事务性数据只需要输入一�ơ。在其他行业中， STP 可能被称为“流通供�l�”、“无�U�R��集”、“lights-out”或者“hands-free”处理�?
达成 STP 的目标要消除业务��程的无效率�Q�比如数据的手工重新输入、传真、纸面邮件、或数据的不必要的批处理。今天阻��?STP 的事物的例子包括��采购订单重新输入到信用卡验证系�l�，或者周期性处理的数据分批�?
在金融服务、电信和公用事业中，STP 是一个主要驱动。在金融服务中，“T+1”的目标是将交易数据沉淀一天。自动化�E�序�q�行可以帮助公司在整个订单和贸易的生命周期中减少成本�Q�更快捷地服务客��P��以及更有效地��理业务风险�?
2 .1.3.5 ��频识别标签 (RFID)

��频识别标签(RFID) 正在改变企业跟踪其整个供应链中各处的货物和供应的方式。RFID标签�q�承��够通过消除��Z��打开外包板条��和托盘扫描条�Ş码内容的需要从而自动化供应链。装备有RFID标签的货物通过安装在仓库或者装货码头的阅读器时�Q�会差生大量的消息，而这些数据又��会产生大量的需要被捕捉、�\由、变换和输入到其他队业务有意义的应用之中的数据�?
零售卖场中装备有RFID阅读器的“智能货架”能够自动跟�t�货架上的货物数量，�q�且在货架存量低于标准的时候自动��生补货的订货命��o。这些货枉��d��也会知道�Q�消费者从货架上拿起一件商品��^�Q�然后可能又因�ؓ另一�U�商品而将它放回货架。这�U�类型的数据对于那�g重新攑֛�货架的商品的刉��商来说也是很有价值的�?
领导零售商，比如Wal- Mart�?Tesco、和��国防卫部，已经寚w��大型供应商强制要求在大外包装�U�别装备RFID标签了。其最�l�目标是要驱动标�{�本�w�的��h��下降�Q��得最�l�对每一但见商品�Q�比如一把牙��h��者一�|�苏打，�q�行RFID标签识别变得可行。这样将大大增加在一个托盘经�q�阅��d��是所产生的消息数量。这�U�数据量在�h工扫描外包装上的条码的时候是不会产生的。当一个托盘经�q�阅��d��的时候，ESB能够作�ؓ因�ؓ而缠�w�的爆发性数据的�~�冲以便能够准确捕获�q�些数据。那些没有针对这�U�数据量�q�行设计的应用可以得到ESB 的消息层的保护，它能够将工作量分配到多个后端�pȝ��Q�或者进入消息队列排队，直到其能够被处理�?
因�ؓ个体物品�U�RFID标签而导致的消息的粒度更�l�，寚w��些没有针对处理超�q�大包装�U�别�_�度的数据的应用也是个问题。ESB 能提供殊的缓存、聚集和变换服务�Q�以便能够将攉��更细�_�度的数据，�q�将其聚集�ؓ大包装��别的数据�Q�以侉K��些应用能够读取�?
EPCglobal �l�织正在促�� RFID 标签、阅��d��、以及将阅读器整合到应用的��Y件的标准化。�ؓ了要�q�泛地共�?RFID 数据�Q�需要对整个供应链中的相兛_��用和阅读器网�l�定义集成规则。而�ؓ了避免网�l�中的RFID 数据�z�水�Q�过滤和聚集规则应该��可能地分布到最靠近RFID 事�g的��生点。ESB 是一个很好的��理和配�|�那些控制数据流得规则的理想�q�程集成�q�_��?

铁手 2007-08-13 10:13 发表评论

企业服务�ȝ��(ESB)(3)

铁手 — Sat, 11 Aug 2007 01:50:00 GMT

1.7采用ESB 的行�?/h4>
许多新生技术都�l�受�q�试图找到问题来解决以获得采用的痛苦�l�历。另一斚w��Q�ESB的概忉|��׃��界领袖的架构师和技术社��Z��的领导厂商一起和定义和构建的�Q�因此，ESB从诞生之时便得到采用。ESB正在或已�l�被用在多种行业�Q�包括金融服务、保险、制造业、零售、电信、能源、食品分销和政府。下面是一些例子�?
1.7.1 金融服务

一个领先的Subprime借贷公司实现�?ESB�Q�减��了60% 的业务处理费用。这是通过在eCredit �pȝ��、第三方信用机构、以及他们自��q��后端�pȝ��之上建立一个统一的客��h��据视图来辑ֈ�的�?
领先的银行已�l��用ESB实现了金融交易的直通处理，很客官地节省了手工处理成本�?
一个派生的贸易�pȝ��依靠ESB每天�?,200用户处理��过100,000 �W�交易，记录��过数十亿美元的帐务�?/li>

1.7.2 保险

世界最大的寿命和健康再保险公司�Q�年收入二百亿美元，��ESB作�ؓ理清在总部和销售及��理其政�{�的保险代理商之间的后端交易数据的交换的解决�Ҏ��Q��生了可观的费用节省�?/li>

1.8.3 刉��业

一个橱柜台面和地板刉��商通过使用ESB实现了一个一体化��理的存货系�l�和“可用性承�?#8221;查询�pȝ��Q�提高了供应铄��预见能力�Q�减��了最低库存报警的条�g。在部��v的第一阶段�Q?ESB被用来连接该刉��商和其60个分销商之间的供应铄��l��?/li>

ESB 的部�|�模型允许制造商在分销商的地点部��vESB 服务容器。这是在每个�q�程地点部��v一个集成Broker�Ҏ��的另一选择�?

一个主要的照明、电视和��d��成像的制造商正在使用 ESB 创徏一个统一的集成主�q�来�q�接光��布全球的业务单位�Q��ƈ且�ؓ全球的客户创��Z��个统一的��品和订单视图�?/li>

1.7.4 零售

使用一个基于标准的�Q�集中的��理框架�Q�一个全家的影像零售�q�锁店正在采用ESB 基础设施来通过一个中央管理和配置控制台动态地配置和管�?1,800个远�E�店铺，
世界最大的邮购公司 (收入一百二十亿��元)依靠 ESB 来从其许许多多的供应商订购��品�?/li>

1.7.5 电讯

一个电话营�q�商的Web门户�|�站依靠ESB来对用户点击�q�行分析跟踪 (二小时的响应�?30 天的响应旉��)�Q?�q�且每天处理一千六百万个消息�?
��国�W�二大的电信营运商，收入四百三十亿美元，使用 ESB来从内部的系�l�向竞争者提供信息�?/li>

1.7.6 能源和公用事�?/a>

一家一百亿��元的电力公司可靠地实现�?ESB�Q�用来连接内部系�l�和政府强制的应用�?对帐务、系�l�管理、运行报告、以及法规强制的与竞争者的信息�׃�n�Q�提供了实时数据�?/li>

1.7.7 食品分销

一个主要的�Ƨ洲食品分销�|?( 一个十二亿��元的分公司)在八个星期内实现�?ESB�Q��ƈ且节省了使用一个集中的集线�?插头 Broker的集成方式所需的三百万��元。ESB 通过��理供应链中的买、卖和物��协调，从肉�c�M�品的配送到饲养家畜的饲料的生��Q�从而自动化了整个分销�|�络�?
在这个食物分销�|�络中， ESB 集成了跨��三个不同的�q�行公司和许多第三方伙伴的应用，��D��q�行效率增加、可观的费用节省、以及更�Ҏ��的集成新�pȝ��的方法�?/li>

1.7.8 政府

n 一个美国政府机构正在��用ESB 来整合多个政府系�l�，以满��USA PATRIOT法案。USA PATRIOT法案允许政府跟踪金融交易�Q�以防止恐怖䆾子得到资金。该��目包括使用 ESB 来集成门��h��务器和各�U�政府机构中的后端系�l�，以提供一个统一的数据视图�?
1.8��结

概括��h��Q?ESB ��h��下列各项�Ҏ�?

普遍�?/li>

ESB 可以采用来适应各种集成情�Ş下的各种通用目的集成��目的需要。它能够构徏跨越整个企业和其业务伙伴的集成项目�?/em>

高度分布的、事仉��动的 SOA�?/li>

松散耦合的集成组件可以在�ȝ��上以�q�泛分布的地理拓扑进行部�|Ԍ��q�且在�ȝ��中可以随处作为共享服务进行访问�?/em>

选择性的集成�l��g部��v

适配器、分布式的数据变换服务、基于内容的路由服务都可以在需要时有选择地部�|Ԍ��q�且可以独立��C�׾~��?/em>

和可靠�?/li>

通过�ȝ��q�行通信的所有组件能得益于可靠消息、事务完整性、以及安全的认证通信机制�?/em>

�~�排和处理流

ESB 允许数据��过插入到�ȝ��中的��M��应用�Q?不管是本地还是远�E��?/em>

自治而联邦管理的环境�?/li>

ESB 支持部门和业务单元��别的本地自治�Q��ƈ且仍然能够在较大的受��的集成环境中整合�?/em>

逐渐采用。ESB 可用于小��目�?/li>

每个个别的项目能�q�入一个更大的集成�|�络�Q�它们可以从�ȝ��上的��M��地方�q�行�q�程��理�?/em>

XML支持

ESB 可以充分利用XML作�ؓ“原生”数据�c�d��的好处�?/em>

��x��z�察�?/li>

ESB 提供了对及时业务数据的实时洞察能力。BAM能力已经被构建到ESB 框架之内�?/em>
你现在应该有了关�?ESB的��够的信息来满��你的好奇欲了�?接下来，在更详细的章节中�Q�你��会学到更多有关其底层技术方面的内容。下几章��会讨论 ESB 的进化、目前的集成状态，采用XML来作��Z��个通用的数据交换架构以在不同的数据表示之间协调的好处，以及异步消息和MOM�?

铁手 2007-08-11 09:50 发表评论

企业服务�ȝ��(ESB)(2)

铁手 — Thu, 09 Aug 2007 01:26:00 GMT

16.1ESB 的特�?/h4>
�׃��试图快速进入成长中�?ESB 范畴的厂商的慌�ؕ�Q�以及大量行业分析师和记者在分析报告中分别展�C�Z��们各自的观点�Q�可以理解，�q�其中对于ESB 到底是什么还��h��很多��h��。这一节将概略说明 ESB 的主要特性�?
1.6.1 普遍�?/a>

如第 1 章所�C�， ESB 能�Ş成普遍的�|�格的核心。它能够跨越和超�q�扩展企业，�q�且横跨部门�l�织、业务单位和贸易伙伴形成全局的范围。ESB 也能很好地适合于局部的集成��目�Q��ƈ且对促进它们采用��M��c�d��的集成环境提供柔性的支撑�?

图表 1�? ESB 形成一个能跨越了一个全球企业网�l�的普遍�|�格
应用可以按需插入�ȝ��Q��ƈ且具有可视性，以及能够与其它已�l�插入到�ȝ��中的��M��其他应用和服务共享数据。虽然Web Services�?ESB 架构的一个有机组成部份，但是所有的应用�q�不是一定要被修�Ҏ��为真正的Web Services才能参与�?ESB。连接性是通过多种协议、客��L��API 技术、遗留消息环境、以及第三方应用适配器来辑ֈ�的�?
1.6.2 ��Z��标准的集�?/a>

��Z��标准的集成是 ESB 的基本概��c��对于连接性，ESB 可以使用J2EE�l��g�Q�比如��用Java Message Service (JMS)来进行MOM�q�接�Q��用J2EE �q�接器结�?(JCA �?J2CA) 来连接应用适配器。ESB 也能够非常漂亮地与��?Net、COM、C#、C/C++构徏的应用进行集成。除此之外，ESB 也能集成支持SOAP和Web Services API的�Q何组�Ӟ��q�其中包括事实上的标准Web Services工具��q��实现�Q�比如Apache Axis。�ؓ了处理数据操�U�， ESB 可以使用XML标准�Q�比如XSLT、XPath �?XQuery 来提供数据变换、智能�\由、以及在数据��过�ȝ��的时候提�?#8220;�I�Z��”查询。�ؓ了处�?SOA 和业务流�E��\由， ESB 可以使用 Web Services描述语言 (WSDL) 来描�q�抽象的服务接口�Q��用针对Web Services的业务流�E�运行语�a�(BPEL4WS)、WS- Choreography或者一些其他基于XML的词汇表�Q�如 ebXML BPSS�Q�来描述抽象的业务流�E��?
如果你还不懂�q�些深奥的词汇的含义�Q�也不要担心。虽然本书�ƈ不想作�ؓ是这些各个技术的详细参考或个别指导�Q�我们也会在他们如何�?ESB 有关的语境中��_��详细地解释它们�?
�q�些��Z��标准的接口和�l��g被整合到一个意义非凡的包含开攄��点的可插入架构之中。ESB提供了一�U�基��讄��来同时支持基于工业标准接口集成组件和使用标准化接口来实现的专有元素。下囑ֱ��C�Z��一个��用JMS和JCA集成一�?J2EE 应用、��用JCA应用适配器集成第三方打包软�g、��用C#客户端程序集成一�?NET应用、��用Web Services集成两个外部应用的案例的高阶视图�?

图表 1�? ESB 整合多种不同的技�?
1.6.3 高度分布的集成和选择性部�|?/a>

ESB 在其中借鉴了传�l�EAI Broker的许多功能，比如从它提供集成服务 , 像是业务��程�~�排、数据�\由、数据变换、以及应用适配器。然而，集成中介者通常是高度集中和单一的�Ş态。ESB ��这些集成能力提供�ؓ独立的服务，能够以一�U�高度分布的形态一起工作，�q�且能够彼此间独立�׾~�。在�W?6 章中�Q�你��会学习更多有关 ESB“服务容器”�Q�ESB 的一��Ҏ��心概�늚�内容�Q�它允许寚w��成服务进行选择部��v�?
1.6.4 分布式数据变�?/a>

��M��集成�{�略的一个关键部分就是能够轻易地在应用之间�{换数据格式的能力。许多应用对描述�怼�的数据�ƈ不共享相同的数据格式�?
数据变换是一�?ESB部��v的一个固有部份。变换服务特别针寚w��些被插入�ȝ��的个别应用能够在�ȝ��的�Q何地方被定位和访问的需要。因为数据变换是ESB 本��n的一个有机组成部份，解决应用之间的阻抗失配问题便可以惛_��ESB�?
1.6.5 通过分层的服务来辑ֈ�可扩展�?/a>

ESB 能够��Z��提供本质上针对�Q何集成项目所必需的核心能力，�q�且可以通过使用分层的服务来处理特定的用途来增加。例如，�Ҏ��的能力，比如业务��程��理 (BPM) 软�g能处理工作流相关的业务流�E�，而协作服务器能够提供对伙伴业务流�E�管理的�Ҏ��服务。专门的�W�三方翻译器能够��外部数据，比如EDI�Q��{换到能进入目标企业资源规�?(ERP) �pȝ��之内的格式，或者在通用�ȝ��之上的规范XML表现�?
1.6.6 事�g驱动�?/a> SOA

�?ESB驱动的、事仉��动的 SOA中，应用和服务被当做抽象服务端点�Q�能够轻易地对异步事件做出响应。SOA 对其底层的连接性和��线�l�节提供了一个抽象的方式。服务的实现不需要理解协议。服务也不需要了解消息是如何路由到其它服务的。他们只是简单地��接收自 ESB 的一个消息作��Z��个事�Ӟ��然后处理该消息。ESB 可以把消息发送到它想要去的其他�Q何地斏V�?
�?ESB SOA 中，用户定制服务可以被创建、扩展，�q�且被重用�ؓESB 功能。被暴露为服务的应用端点�Q�可以同�Ҏ��的集成功能一��h��造成复合业务服务和业务流�E�，�q�且它们可以�Ҏ��不同目的重新�l�合�Q�其目标是在一个即时企业中提供自动化的业务功能�?
�W?7 章将会更详细地讨�?ESB 中的 SOA �?
1.6.7 处理��?/a>

ESB的处理流从简单的优先步骤序列��C��用条件分支和联合来�ƈ行执行的�l�合业务��程�~�排。这些特征可以��用简单的消息元数据或者通过使用诸如BPEL4WS 之类的业务编排语�a�来控制�?
ESB 的处理流能力使得定义属于某个部门或者业务单位局部的�Q�或者共存于一个较大的集成�|�络中的业务��程成�ؓ可能。这点却是一个集�U�器-插头中介者或一�?BPM 工具自己所不能很好地自��p��决的问题。第 7 章将会详�l�讨论分布式的流�E�能力，它能提供高度分布的流�E�编排能力而不需要中心化的流�E�和规则引擎�?
ESB的业务流能力也涉及到��Z��内容的消息的��路由的特�D�集成服务�?
因�ؓESB 的业务流能力构徏于分布式的SOA之上�Q�它也能够跨��高度分布的物理部��v拓扑�Q�甚��x��大�z�）而不用痛苦地忍受�ȝ��上各�U�应用和服务之间的物理边界和多协议的鸿沟�?

图表 1�? 跨越物理和逻辑边界之上的部�|�拓扑的�~�排和业务流
1.6.8 安全和可靠�?/a>

�?ESB 上的节点之间的连�l�是��h��防火墙能力的。应用和 ESB之间的安全性，甚至�?ESB 节点自��n之间的安全性，能够建立和维护最高强度的认证、凭证管理、和讉K��控制�?
可靠性是通过处于ESB核心的企业��MOM来达到的。MOM核心提供异步通信能力、业务数据的可靠传输、以及事务的完整性。你们将在第 5 章中学到�Q�这已经不是十年以前的传�l�MOM技术了。需求从那时以后开始进展，�q�且已经成熟�Q��?作�ؓESB 的核心的MOM必须�W�合今天的需求�?
1.6.9 自治但联邦的环境

传统的集�U�器-插头中介者方式往往��h��l�织性的边界问题�Q�这主要是因为EAI Broker对跨��防火墙和网�l�域的无能的实际限制所引�v。更重要的是�Q�即使一个集�U�器-插头架构能够被��展而跨�q�组�l�的交界�Q�它仍然不允许各个业务单位彼此半独立地运行所需要的局部自沅R��与不断扩展的集成范围�g伸超�q�部门层�ơ所相关的最大问题之一是自��d��集中控制之间的问题�?
作�ؓ大多数大型公司环境的业务文化的一部分�Q�每个部门或业务单位需要彼此独立地�q�作�?然而，他们仍然依赖于共享资源，以及输入到通用业务功能之中的报告和帐户信息�?
在这样一个环境中�Q�需要所有的消息��量都流�q�位于总部的一个集中的消息Broker的集成策略是不合理的�?�q�不只是一个技术上的障��；它也是公司文化的问题。在一个松散耦合的业务单元环境中�Q�诸如本地应用之间的业务��程�Q�或者安全域�Q�被一个集中化的公司IT功能��理��直没有一炚w��理。组�l�中的松散耦合业务单元需要彼此独立地�q�作。他们每一个都应该有其自己的IT功能�Q�而不必须路由所有的消息��量�Q�或代表它的业务规则和安全域的控�? �l�过一个集中的集成�l�纪人在一个位�|�或另一�?�W?1 �?�?

图表 1�? 如果使用一个集中的集线器，分开业务单位�~�Z��必需的自�?�?了集成经�U��h
本地业务单位和部门需要有对他们自��q��局部IT资源的控�Ӟ��比如在其站点�q�行的应用。集成基��设施应该支持部��v拓扑来支持具有实用性的业务模型。ESB 也提供这�U�部�|�模型，允许本地��量、集成组件以及适配器能够被本地安装、配�|�、加固和��理�Q��ƈ且仍然能够以一�U�集成的安全模型一起将本地集成域插入到一个更大的联邦集成�|�络之中�?

图表 1�? 自治的而且公布联邦�?ESB 允许横过�l�织的交界对合作地同盟的�q�算�l�织
ESB 的分布式特征是通过从实际的部��v�l�节和底层的�q�接协议中抽象出来的��端点定义，以及在那些端点之间的数据的编排和路由来达到的。联邦特征则是通过 ESB 能够隔离和选择地横�q�应用域和安全边界的能力来达到的�?
1.6.10 �q�程配置和管�?/a>

在一些业务模型中�Q�在每一个远�E�地炚w��安排有本地的IT职员是不大可能的�Q�虽然仍焉��要松散耦合的、自�ȝ��联邦的集成网�l�。�D例来说明�q�一个点�Q�我们来惌��一下部�|�在零售行业中的ESB 的案例。一个视频租借链可能有数百或数千个包含相同应用的地点�Q�所有以相同的�Ş态运行的操作涉及到目录管理、会计和报表�{��?

图表 1�? 和数以千计遥�q�的储存一个视像零售链,所有的包含应用�E�序的相同组
使用 ESB�Q�可以徏立一个集成蓝图来处理�q�程店铺中的局部应用之间的通信。这包括店内应用的接口定义、消息流量的路由、消息通道的管理、以及安全许可。它�q�可能包括集成组�Ӟ��比如应用适配器、协议适配器或者数据变换器。这个集成蓝图，或称模板�Q�可以在所有地点进行部�|�和定制�Q��ƈ且独立地扮演所有其他店铺�?

图表 1�? ESB 配置蓝图在每个遥�q�的位置和很�q�地展开配置而且处理
�q�个�q�程部��v蓝图的能力�ƈ不单针对零售行业�Q�它也可以扩展到所有其他行业的应用。联邦的集成域的�q�程��理对于在一个高度分布的环境中的��M��ESB的成功部�|�都是非常关键的�?
安全、可靠的消息联结
除了在每个店铺的本地应用之间�׃�n数据之外�Q�这些远�E�店��需要同总部�׃�n信息以便�q�行帐务处理和报表、信用管理以及职员数据的�q�踪。远�E�店��需要彼此之间共享信息。�D例来��_��一个大型的韛_��q�锁店可能会提供�q�样的服务，��֮�可以选择从离家近的店�U�赁��q��Q�然后在��d��公室�q�的另一个店归还。因此，在同一个地理区域内的店��Z��间可能会需要以�q�乎实时的状态共享有关租赁的数据。因为在�q�程店铺和总部之间的卫星网�l�通信�q�接存在较大的反应期和弹性，要在总部�l�护一个有��x��有租赁信息的实时集中讉K��Ҏ��不现实的。那些有关你只是在两个小时之�U�借的数据需要共享，或者通过�q�程店铺之间的一个集成的数据�׃�n�q�接来进行访问�?
因�ؓ总部和远�E�店��Z��间的�q�接是通过可靠的消息来辑ֈ�的，因此�׃��不可靠的卫星电�\所造成的网�l�服务终端可以从消息层得到补�ѝ��也应该注意刎ͼ�对于�q�程店铺之间来说�Q�通过Internet来徏立一个安全和可靠的消息通道也是可以的�?
1.6.11 作�ؓESB�?#8220;原生”数据�c�d��的XML

当数据通过ESB 在应用之间流动的时候，XML是一个表现它们的理想基础。被应用�E�序的一个巨大的行列生��而且耗尽的数据能以多�U�的格式存在和包装方案。有大量的应用��生和消费的数据，可以以各�U�格式或者打包的Schema存在。对ESB来说虽然的确可以依你喜欢的打包�Ş式或者封装方案来承蝲数据�Q�但��途中数据表现为XML��h��莫大的好处，包括使用能够�l�合来自于不同的源数据以创徏一个新的数据视囄��产生数据的特�D?ESB 服务�Q?以及针对应用间高�U�数据共享的��羃和重定目标。第 4 章将会探�I��用XML功能本好处—将避免一个组�l�的应用间同步升�U�的需要—�ƈ且更详细地讨论分布式XML变换之后的基本原理�?
1.6.12 业务数据的实时吞�?/a>

ESB通过为途中数据在�ȝ��之上的应用间传输的时候提供实时吞吐消除了潜伏反应问题。目前，最��行的集成方法之一是每夜进行批处理�?然而，打包的成批处理集成策略，不管是每夜还是其它，都具有较高的辚w��错误率，�q�且造成信息获取的�g�q�。其�l�果是高反应期��生获取了�q�时数据��代�h高昂的。第 9 章将详细讨论�q�个问题�Q��ƈ且研�I?ESB 可以如何用来��你的业务数据从每夜批处理模式重构�ؓ实时吞吐模式�?
1.6.13 �q�行感知

�q�行感知意思是业务分析师能够获得对业务�q�行的状态和健康情况的洞察能力�?一个允许对数据在其以某个业务流�E�中的某个消息�Ş式在�l�织中流动时�q�行实时跟踪和报告的基础设施�Q�对于帮助徏立运行感知是一个无��L��工具。一个称为是业务�z�d��监控 (BAM)的��品门�c�d��l�出现来解决�q�行感知的这些问题�?
使用XML作�ؓESB的原生数据格式的好处之一��是消息没有被处理�ؓ不透明的数据块。如果应用和服务之间的所有数据都被格式化为XML文档�Q�ESB提供的基��支撑便允�怽�在ESB之上再构��Z��层高�U�能力，以获得对��过你的企业的业务数据的实时�z�察能力。这些能力，不管是否是ESB的固有组成部分，�q�是有一个扩展来驱动�Q�都表现为包括了路由、处理流、以及下层的��线�Q��ƈ且不需要再在其上锁定一个第三方的BAM产品的一个通用基础设施的一个有机组成部分�?
作�ؓESB的一个基��部分的审计和跟踪能力允许对在SOA中的所有流动的业务��程和消息流的健��L��况进行监控和跟踪。诸如数据缓存、数据收集和聚集、以及XML数据的可视化表现之类的增值服务，可以用来创徏一个基��服务�Q�该基础服务可以在数据在企业中流动时�Q��生对业务��程的状冉|��察的警告、提醒和报表能力�?

图表 1�? 增值型服务促成操作的觉察提供对�zȝ��业务数据的即时洞�?
对ESB中的数据的根�t�和报表是通过在业务流中定义审计点来达到的�Q�然后再对从业务消息中收集的重要内容在ESB中流动时提供插入炏V��可�q�踪数据例子是业务消息自�w�，以及指示某业务消息是否通过了某个特定的业务处理步骤的业务事件�?
高��的增值服务可以提供数据收集服务、查询机制以及报表能力，它们能够讲所有数据进行收集、进而表��Cؓ各种��h��意义的�Ş式。XML持久性服务可以提供缓存和聚集点，�q�样可以攉��要转换的数据从而向其他应用提供数据输入�Q�或�q�入到可以被业务分析师��用的人可�ȝ��报表机制之内。这意味着��经ESB的数据可以进行实时分析，以提供有关你的业务状态的实时信息—比如，可以随时提供有关你的供应链中的存货的状态快照�?
1.6.14 逐渐采用

区别是否真正�?ESB 的一个主要方面是看其是否��h��逐渐采用的能力，相对于另一�?#8220;全有-�?全无”的论断。在 Y2K 之后的开支削减中�Q�数百万��元预算的项目数目已�l�今非昔比。有一些迹象表明，预算资金�{�备正在开始释放以解决短期的战术性集成需要，但是预算仍然谨慎地处于一个执行层面。，然而，同时仍然有一些期望实现较大的公司范围集成�{�略计划—这些计划严重依赖于集成和现有IT资��的重用�?
�?-10说明�?ESB 可以如何用于��项目中�Q�然后它们都可以�q�入��C��个更大的集成�|�络之内�?当我们深入阅��L��书的时候，我们会详�l�研�I�这是如何实现的�?

图表 1�?0 ESB 支持逐渐采用的集成，同时向着一个策略目标工�?
ESB 的联�?自治能力也对一�ơ一个项目采�?ESB的能力有助益。ESB 集成��目渐进式的分布部��v能够在朝着一个更�q�的企业层面的计划目标的前提下得到立即�h倹{�?
逐渐采用的观念将�q�一步通过桥接��C��个已有的集成Broker集线机器和遗留系�l�Broker来得到进一步支持。集成Broker集线器和他们的特点将在第 2 章中详细研究�?/p>

铁手 2007-08-09 09:26 发表评论

企业服务�ȝ��(ESB)(1)

铁手 — Tue, 07 Aug 2007 05:14:00 GMT

本系列编译自 O'Reilly的《Enterprise Service Bus》，��陆�l�发布上来�?/em>

1 企业服务�ȝ��?/h3>
1.1一个事仉��动型企业中的SOA

在一个事仉��动型企业中，影响业务��程的正常进�E�的业务事�g可以以�Q何顺序随时发生。那些以自动化的业务处理方式交换数据的应用需要��用事仉��动的 SOA 来彼此通信�Q�以便能够对不断变化的业务需求具有敏��L��反应。SOA 向业务分析师和集成架构师提供了处理高阶服务的关于应用和集成组件的宽泛的抽象视图。而在 ESB�Q�应用和事�g驱动的服务彼此以一�U�松散耦合的紧密地与流行的 SOA �l�系在一��P��q�允许它们彼此能够独立运行，�q�且仍然能够提供较宽�q�的业务功能价倹{�?
�?SOA 的王国，事�g被表��Cؓ一�U�开攄��XML格式文�g�Q�以及经�q�一个对验证开攄��Q�可以协调的透明��线中的��（Flow�Q?
—John Udell, InfoWorld
SOA 的服务组件暴露的是一�U�粗�_�度的接口，其目的是使应用之间能够异步地�׃�n数据。而��?ESB�Q�一�U�集成架构将应用�E�序和分��ȝ��集成�l��g拉在一��P��以��生服务装配组合从而�Ş成复合的业务��程�Q�进而自动化一个即时企业中的业务功能�?
ESB 为SOA提供实现骨架。那��是��_��它通过一个跨��多�U�协议的消息�ȝ��来提供一个有兛_��名�\��q��的地的高度分布的世界来提供松散耦合的，事�g驱动�?SOA。ESB 中的应用�E�序 (和集成组�? 在理��Z��是彼此解耦的�Q�而且通过�ȝ��彼此�q�接为暴露�ؓ事�g驱动服务的逻辑端点�?
通过分布式的部��v配置基础设施�Q?ESB 能有效率地提供对在扩展企业中分布的服务的中心配置、部�|�和��理。一�U�普遍集成的新方式应用诸如SOA、EAI、B2B 和Web服务之类的技术的通常目标主要是创��Z��个集成架构，且能够深入�ƈ且跨��整个扩展企业。对于一个集成基��设施到达到这�U�普遍性，它必��d��有下列各��特�?

它必��能够适应多种集成情�Ş��目的通常目的需要，不管是大型的�q�是��型的。适应性包括提供一个能够经受协议、接口技术、甚��x��E�模型的变化��势的持久架构�?
它必��M��一�U�单一和统一的方式，以及一个通用的基��设施来连接扩��扩展企业的各种应用�?
它必��能够扩展超出单一公司IT中心的边界。�ƈ且自动化伙伴关系�Q�比如在B2B 和供应链的情况下�?
它必��d��有设计的��单性和较低的进入门坎，使得日常的IT专业人员也能够成��我修�l�的集成架构师�?
它必��L��供一个跨��普遍集成的 SOA�Q�它能��集成架构师能够对公司的应用资产和自动化业务流�E�有一个广泛的、抽象的视图�?
它需要有能够反应和符合不断变更的业务需求和竞争的压力需要的灉|��性和能力�?

�?ESB中，应用和事仉��动服务以一�U�松散耦合的方式紧密地联系在SOA 中�?�q��得它们能够彼此独立运行，�q�且仍然能够提供�q�泛的业务功能�h倹{�?
ESB 架构解决了这些需要，�q�且正在被各�U�通用的集成项目所采用。它也能够在企业应用层面普遍��C��展，不管是物理位�|�还是技术��^台。�Q何应用都可以通过大量的连接选择插入��C��?ESB �|�络中，�q�且可以立即参与��C��那些通过�ȝ��暴露为共享服务的应用之间的数据共享之中。这�?ESB ��Z��么经常被�U�Cؓ集成�|�络�Q�integration network�Q�或集成构造（fabric�Q�的�~�故�?
ESB 提供为集成提供了一�U�高度分布式的架构，�q�且��h��能够让独立的部门和业务单元能够以一�U�逐渐增加的、可消化的分块来构徏它们的集成项目的独特能力。��?ESB�Q�部门和业务单元仍然能够�l�箋在独立的集成��目中维护它们自��q��本地控制和自治，�q�且仍然能够��它们的集成计划�q�接��C��个更大的、更全局的的集成�|�络或网��g��中�?
1.2针对 Web 服务的SOA�Q�如今已�l�可�?/h4>
Web 服务已经通过为应用间的互操作性提供一�U�基于标准的方式为面向服务架构找��C��新的重要性。Web服务的主要目的是提供了一�U�服务抽象，它允许应用之间的互操作性��用不同的�q�_��和环境来构徏。这一个目标的实现��能够提供一个应用之间的普遍集成的更�Ҏ��的�\径�?
�׃��ESB的出玎ͼ�现在有了一�U�方式能够将Web Services和SOA合�ƈ��C��个意义非凡的架构中，以将应用和服务以一�U�高度�׾~�的状态集成到一个扩��扩展企业的骨架之中。ESB使用今天已经成熟的技术立��M��得Web Services、XML、以及其他集成技术更加有用�?
SOA 的核心原则对于普遍集成项目的成功臛_��重要�Q��ƈ且已�l�在 ESB 中被��d��实现�?Web Services标准正在有朝着正确的方向前�q�，但是在提供企业��能力斚w��q�未完成�Q�比如安全性、可靠性、事务管理和业务��程�~�排。ESB 以这些领域中今天已经��定的标准�ؓ基础�Q�而且已经有实际实现部�|�在各种领域和行业中。ESB完全有能力跟上Web Services相关能力的革新进展步伐。第 12 章提供了更详�l�的关于�q�一个主题的讨论�?
1.3常规的集成方�?/a>

ESB 通过从EAI中介者（Broker�Q�那里学来的概念和技术将Web Services和其他补充标准结合在一赗��然而，ESB �q�不仅仅是在同一个老式的EAI 集线器之上的��单的Web Services外衣�?
传统的�Ş式化的集成方法都有其优缺炏V��第 1 章就展示了有关集成的一些高阶的显著特色�Q?范围从左下方最不��o人想要的�Q�到右上方象限中的最令�h惌��的�?

图表 1�? 传统�?EAI 中介器，应用服务器，MOM�?ESB 的特�?
传统�?EAI 中介器，包括那些已经构徏在应用服务器之上的，使用一�U�集�U�器和插��_��hub-and-spoke�Q�架构。集�U�器和插头有一些中心化功能的好处，比如路由逻辑和业务规则的��理�Q�但是不能很好地伸展扩越部门和业务单位的边界。第 2 章将讨论使用集线器在集成中的早期��试的巨大代��P��以及它们的初步成功�?
应用服务器可以通过标准协议�q�行互操作，然而它们是以一�U�紧密耦合的方式进行连接的�Q��ƈ且集成逻辑和应用程序逻辑�U�缠在一赗��?
EAI 中介器通过��应用逻辑从集成和��程路由逻辑中分��d��来提供了增加价��|��然而你仍旧要忍受集�U�器-插头架构的痛苦�?
面向消息中间�?(MOM) 提供了以松散耦合和异步的方式�q�接应用的能力。然而，MOM自��n需要在应用中进行低�U�的�~�码。��用传�l�的MOM�Q�以及定制的�~�程技术，比可以在分布式的集成解决�Ҏ��上走得更�q�。然而，没有对�\由逻辑的高阶抽象，�q�种方式仍然要忍受集成逻辑难以�q�接�Q��ƈ且也和应用逻辑�U�缠在一��L��痛苦。依赖于MOM的��用，即��是分布式特征也会受到限制�Q�因��Z��些传�l�的MOM基础设施对实际的�|�络边界的跨��也不是做得很好�?
最后，�?ESB 中，服务可以被配�|�而不是编码。处理流�E�和服务能够透明地跨��整个服务�ȝ��。ESB 提供了能够很好地扩越集线�?插头架构范围的高度分布式集成环境�Q��ƈ且清晰地分离了应用逻辑和�\由数据变换之�cȝ��集成逻辑。一�?ESB 架构形成了一个消息集�U�器和集成服务的互连接性网��|��h��一个彻底分布的集成�|�络的功能性和��性�?
�W?6 章更�q�一步描�q�在使用应用服务器集成和使用ESB集成之间的对比。MOM的概念在�W?5 章讨论。第 2 章的 “附属架构”�l�箋讨论业务��程路由逻辑和业务逻辑之间的分��R�?
1.4被IT需要驱动的需�?/h4>
ESB 的一个关键特性就是要为支持分布式的、松散耦合的业务单位和伙伴�Q�比如自动化供应链，提供支撑基础。ESB 的这些能力是其固有的必要特征�Q��ƈ且是中间件厂商与那些惌��创徏大规模集成架构的业界专家共同工作的结果。这些业界专家包括了大公司IT架构师、以及电子市集��N易社��Z��惌��Z��׃�n服务、消息、XML何其他众多的�q�接选择来徏立B2B集成骨架的改革者，�q�且要坚持遵守工业标准。第 3 章将会讨论对 ESB 概念的创造有助益的许多催化剂�?
同时�Q�仍然必��解决的最大需要在于如何还没有的最大需要被定址包括该如何有效地提供集成能力、比如应用适配器、数据变换、以及能够用于通用的集成项目，跨越多种集成情性的��路由。�ƈ且需要超��于个别战术性的集成��目之上的，更加通用的技术和更加架构性的方式�?
IT专家已经对以前的一些技术趋势失望，比如CORBA、或者EAI什么的。CORBA 有着与SOA 一��L��正确理念�Q�但是其与生俱来��太复杂而难以维护，因�ؓ它依赖于应用和服务之间的紧密耦合接口。EAI 也痛苦于对单个项目上的陡峭的学习曲线和昂�늚��q�入负担 (下一章将详细讨论�q�个内容)。真正需要的是SOA的简单方式，以及可以被采用来适应��M��集成工作�Q�大型或者小型，的一�U�架构。此外，那就是需要一个能够经受协议、接口、甚至业务徏模趋势的变革的持久架构。ESB的概念就是创建来解决�q�些需要的�?
1.5行业的牵�?/a>

自从ESB 概念�?2002 �q�被首次引入�Q�ESB 的集成方式已�l�被中间件、集成和Web服务市场中的很多重要的厂商采用。其接受度正在稳定持�l�地增长�?
�?002�q�早期开始，分析公司�Q�比�?Gartner 公司、IDC、ZapThink�{�，��已�l�开始跟�t�和�~�写有关 ESB 的技术趋�ѝ��在Gartner 公司�?002�q�发布的一份报�?DF-18-7304)中，分析�?Roy Schulte �q�样写道�Q?
一�U�新型的 企业服务�ȝ��架构- �l�合�?strong>面向消息中间�?/strong>�Q�MOM�Q�、Web Services、数据变换和��路由的基��设施�?/em>��会 2005 之前在很多的企业中运行�?/em>
�q�些高功能、低成本的ESB能够被很好地适应作�ؓ面向服务架构和企业神�l�系�l�的��d��?
那四个支柱—MOM、Web Services、数据变换和路由�� ?表现了�Q何优�U�的ESB 的基��。当我们探究 ESB 的时候，本书��会集中于其中每一个基��和其他必��ȝ��l��g的角艌Ӏ�我们还要讨论将会讨�?ESB �I�竟能�ؓ企业做些什么、以及它的基本组件所扮演的角艌Ӏ�我们还要讨��Z��些高阶主题，包括横越多种行业之上的实跉|��用的架构性概�q��?
1.5.1 采用 ESB的厂�?/h5>
有许多中间�g和集成厂商已�l�，或者正在构建，�W�合ESB描述的某些��品。�ƈ且这个名单还在不断增加。附录中列出所有的已知厂商。一些厂商已�l�声�U�C��们已�l�开始提�?ESB�?�Q�而有些则正在计划构徏�Q�有些则只是在市场宣传材料中使用�q�一技术术语而实际上背后�q�没有实质性的东西。当��过 25个厂商正在�ؓ相同的技术空间竞争的时候，�q�一个技术范畴注定要变成像上世纪90�q�代的应用服务器一��L��炙手可热�?
�q�个清单中有个别厂商应该特别提及。Sonic软�g最先倡导了这个概念，此后不久许多其他的较��厂商业�q�入此领域，声称他们也正在提�?ESB 或是正在开发之中。一但那些著名的集成公司�Q�比如webMethods、SeeBeyond �?IBM 最�l�搭上这��巴士（“BUS”�Q�，�q�且惌��开始徏立他们的ESB�Q�ESB 术语才真的开始广泛引起业界注意，是一个强大的不断发展技术范畴�?
在本书写作的时候，微��Y公司�q�没有对其Indigo��目和有关ESB发布��M��公开的说明。然而，一些记者和分析师在Indigo��目宣布的时候还是将二者联�p��v来�?003 �q?1�?30 日， ComputerWorld 的文章说�Q?#8220;开发�h员的兴趣被微软的技术伤害了”�Q�Gartner 公司�?Roy Schulte关于Indigo��目提出�?
Roy Schulte�Q�是Gartner 公司在斯坦福的一个分析师�Q�注意到Indigo��目其实是微软消息队列（MSMQ�Q�、公司的COM、COM+�?Net Remoting、以及Web Services技术的��集�?#8220;把它��x��代表微��Y公司的通信中间件计划的��化和�l�一�Q?#8221;他说�Q��ƈ说他认�ؓIndigo是一个非常好的企业服务�ȝ��(ESB)�?
Indigo以消息�ؓ基础�Q��ƈ且打��结合MSMQ 和Web Services。可以提供一个消息�ȝ��的基��。然而，光��成能力的其余部分则被锁定到BizTalk 之内�Q�而它是一个集�U�器-插头风格的集成服务器。�ؓ了成为真正的ESB�Q�分布式消息�ȝ��和分布式集成能力都要具备�?
如果Indigo��目完成�Q�构��Z��微��Y�q�_��之上的应用和服务��能够更加吸引�h��C��为端点连接到ESB之上。将Indigo包含到微软��^台和开发环境之内将更加能够使得应用��h��松散耦合和消息感知能力�?/p>

铁手 2007-08-07 13:14 发表评论

铁手 — Wed, 08 Mar 2006 06:16:00 GMT
Martin的EIP之概论：使用模式解决集成问题�Q?/a>

铁手 2006-03-08 14:16 发表评论

RFID的领域应�?

铁手 — Tue, 15 Nov 2005 01:28:00 GMT

RFID的领域应�?

RFID是一�U�自动识别技术。从本质上讲�Q�它对其所标记的物品本�w��ƈ不带来�Q何附加�h��|��甚至增加成本。但是，它却能够驱动与物品相关的背后应用带来巨大的�h��|��而这些则�Ҏ��不同的应用体现而不同。这其中�q�有一个至关重要的驱动力，那就是以Internet、网�l�技术、通信技术、��Y件技术�ؓ代表的现代信息和通信技术（ICT�Q�。只有在此基��上，RFID本��n才能成�ؓ体系�Q�自动标记和识别的数据才能得以广泛地传输和共享，从而连接随旉��地的业务。即�Q�企业和�l�织能够在前所未有的集成之基础上，自动地进行通信、协作、教肌Ӏ�销售、配送、采购、服务，以及企业内部的业务流�E��?BR>
RFID 的本质是对物体或者�h�q�行识别。其最大优�Ҏ��自动化，不要求有��Zؓ�q�预�Q�被标记的对象一旦处于阅��d��的质询区域便能够被自动读取，而相关信息则实时传送到后段�q�行处理。被传递到业务�pȝ��的相关的数据主要包括�Q?标签�~�码�Q�tag ID�Q�，阅读器编码（reader ID�Q�以及读取时的时间片。所有的应用都是��Z��q�些基本数据�?

资��跟踪�Q?U>Asset Tracking�Q?/U>
很自�Ӟ��资��跟踪是RFID的最通用的应用。公司和�l�织可以��RFID标签�|�于那些��动的、分散的、易于丢失或者被盗的、难以定位和查找的物品之上。几乎每一�U�RFID�pȝ��都能够被用于资��跟踪。比如总部位于��国Secaucus, N.J.的一个第3方物��商，NYK Logistics��׃��用RFID来跟�t�其位于Long Beach, Calif.的集散中心的集装��。它使用一�U�基于阅��d��和主动标�{��实时定位�pȝ��Q�可以将集装��定位在10英尺之内。对于安全管理来��_��一些敏感的信息讑֤��Q�特别是�U�d��讑֤��Q�如�W�记本电脑等�Q�，��可以��用RFID来跟�t�管理�?BR>
加拿大航�I�公�怋�用RFID来跟�t�用于世界各地机场的食品车，每年可以节约数百万美元。这��P��不但因�ؓ使用了更��的食品车以及减��了保持库存的时间和费用�Q��ƈ且对世界各地�U�d��的食品�R的妥善管理也增进了效率和客户服务�?
其它应用案例�q�包括，El Paso County使用915 MHz被动式标�{�来跟踪计算机和办公讑֤�。一家法律公司Fish & Richardson P.C.甚至使用13.56 MHz标签来跟�t�重要文件。而一家新加坡公司使用13.56 MHz 技术来跟踪必须�l�过��的建筑混凝土以保证建筑安全�?

刉��（Manufacturing�Q?/STRONG>
RFID 应用在制造商其实已经很多�q�了。它可以对生产制造过�E�中的零件进行标识，甚至与工艺、制造参数、生产过�E�等相关。特别对自动化柔性生产线有巨大帮助�?
波音公司��在其Wichita, Kansas的工厂中使用了一�?15 MHz 的系�l�来跟踪零�g的达到。而过��d��是��用条形码来进行跟�t�的�Q�但条�Ş码必��ȝ��q��h工扫描，�q�且�q�必��ȝ��q�特�D�的化学处理。如果�h工扫描环节出了差错，则会失去寚w��件的跟踪。而如今这些都是自动化的，�q�且减少了错误和需要的人手�?
��国汽�R通用公司�Q�AM General �Q�也在其位于Mishawaka 的悍马汽车制造厂内��用了以一�U�主动式RFID �pȝ��来跟�t�零件。�?Club Car 则甚臛_��RFID作�ؓ其新的高��夫球�R装配�U�上的一个主要部�Ӟ��每辆�R的生产时间从88分钟减少�?6 分钟�?

供应铄��理（Supply Chain Management�Q?/STRONG>
RFID 技术过��d��用于企业内部控制之用的供应链闭环控制。宝�z�公司（Procter & Gamble�Q�在西班牙的配送中心��用了13.56 MHz �pȝ��来增加吞吐量、减��了差错和成本�?

Paramount Farms公司�Q�它加工大约整个��国60% 的pistachio 作物�Q��ƈ且出口到20多个国家�Q�便使用了RFID来帮助自动化处理收购自越来越多的�U�植伙伴的��品�?

随着标准的出玎ͼ�比如EPC�{�，使得不仅在企业内部进行供应链跟踪�Q�借助于基于标准的�~�码和数据交换，以及Internet的网�l�支持，可以扩展��C��企业相关的业务伙��_��从上游的供应商到下游的分销商。整个供应链在全球范围内形成�Q�包括间接的�W?方物��、运输商、以及零售商。�ƈ且，也在前所谓有的基��上提供了对生产（EPR�Q�、零售（POS�Q�、服务（CRM�Q�的集成�?
一家加拿大的护肤��品制造商Canus��׃��用了RFID 来减��其到零售客��L��q�输的检��成本，�q�且�q��用基于RFID 的温度感应器来监控运输过�E�中的条件�?

零售�Q?A >Retailing�Q?/STRONG>
零售商们�Q�如Best Buy, Metro, Target, Tesco �?Wal-Mart �{�，都是采用RFID技术的先驱。这些零售商都希望RFID能够整合供应链、有效管理库存和配送、以及有效的货架��理�Q�以便减��成本和提高服务�?
Wal-Mart已经有严格的旉��表，已经要求他的�?00家供应商提供RFID标记的��品，然后是前200�Ӟ��500家直臛_��部供应商。与��国国防部DoD成�ؓ推动RFID的最大力量�?

电子支付�Q?A >Payment Systems�Q?/STRONG>
RFID 不仅在供应链中很火热�Q�电子支付系�l�也很得到关注。包括不停�R收费�pȝ��、泊车收费系�l�、公交�R��务�{�等�?
�׃��其中涉及��C�h值存储和转移�Q�这里主要是高端RFID �pȝ��Q�特别是��卡。在世界很多城市、包括中国的很多城市�Q�都采用非接触式的智能卡来进行公交系�l�：巴士、地铁、轻轨、电车甚臛_��U��R�?BR>另外一个重要的斚w��是银行支付�Q�MasterCard 和Visa 都在计划��传�l�的��卡转换成智能卡�Q�增加安全性和解决其他很多问题�?

安全和访问控�Ӟ��Security and Access Control�Q?/STRONG>
RFID 已经用于物理安全的访问控制很久了。以前一般��用低频的RFID标签。最�q�，供应商大都推介如今采用高频的13.56 MHz�pȝ��Q�提供更�q�的��d��距离�?

RFID �q�用于保护重要胦产。许多最新型��L��汽�R都��用这�U�技术来防盗。即在方向盘部位有一个内�|�的RFID reader�Q�只有当��d��到封装与钥匙中的标签发出的正��的识别��L��Ӟ��才能够启动汽车�?
��d��式标�{�֏�以结合移动传感器来对极端敏感和高价值的东西�Q�比如武器和珠宝�q�行监控�Q�一旦检��到则会自动报警。RFID 标签也可以用于难以管理的�U�d��计算和存储设备如�W�记本电脑和USB存储讑֤��{��?

其他应用
随着技术和领域的发展，会出现层��Z��I�L��革新应用。比如，用于大型主题公园的儿童跟�t�和识别�Q�监��q��人的识别和监控，钞票和票据的保安、病人和孤寡老�h的监控等�{��?
无线传感器网�l�是下一代自�ȝ��l�，它将无数的集成温度感应、移动感应、放��传感等�{�感应器的主动或者被动式RFID�Q��ƈ且具有自�ȝ��|�络功能。美国军方已�l�研�I�出能够在实物中发现病原体的RFID传感器原型。这可以用于寚w��过食物感染疄��的恐怖袭�ȝ��和保护�?
比如NASA的Jet Propulsion Laboratory ��在研究��C��代的无线传感器网�l�。在其早期的实验中，可以用于��土壤和�I�气的温度、湿度，以及光线、水��方向等�{��?

铁手 2005-11-15 09:28 发表评论

此Slashdot不是那个Slashdot

铁手 — Wed, 19 Oct 2005 02:14:00 GMT
今天看到一个网站，slashdotcn.org,嘿，风格、系�l�、内容设�|�基本上都和Slashdot.org�c�M��Q�还以�ؓ是slashdot的中�? 版。仔�l�研�I�了半天�Q�好像与slashdot没什么关�p�R��不�q�也是一�U�不错的新闻站点方式�Q�因为它的国外榜��h��大大的有名�?br>
看到它是因�ؓ在O'Reilley看到了一片关于Web 2.0的文�?从该文的讨论中进来的。其作者是O'Reilly Media的掌�?a >Tim O'Reilly �Q�旨在�ؓ Web 2.0 正本清源�Q?以及讨论了��Y件的下一代设计模式及商业模式。非常值得一看，详细内容参见�Q?a >What Is Web 2.0�?br>

铁手 2005-10-19 10:14 发表评论

铁手 — Mon, 12 Sep 2005 03:52:00 GMT

TOP 10 Web应用脆弱�?/SPAN>之一�Q�未�l�验证的输入

描述

Web 应用使用HTTP ��h��(也许�q�有文�g�Q�也是一�U�特�D�请�?SPAN lang=EN-US>) 来进行输入，�q�决定如何进行响应。攻击者可以篡�?SPAN lang=EN-US>HTTP ��h��的�Q何部分，包括url�Q�查询字�W�串�Q?SPAN lang=EN-US>querystring�Q?SPAN lang=EN-US>, headers, cookies, 表单字段�Q�包括隐藏字�D�）�Q�试囄��q�服务器的安全机制。常见的通用输入��改��d��包括�Q?SPAN lang=EN-US>

o       ��览�Q?SPAN lang=EN-US>forced browsing�Q�；

o       命��o注入�Q?SPAN lang=EN-US>command insertion�Q�；

o       交叉站点脚本�Q?SPAN lang=EN-US>cross site scripting�Q�；

o       �~�冲区溢出（buffer overflows�Q�；

o       格式字符串攻击（format string attacks�Q�；

o       SQL注入�Q?SPAN lang=EN-US>SQL injection�Q�；

o       有毒饼干�Q?SPAN lang=EN-US>cookie poisoning�Q�；

o       隐藏字段操作�Q?SPAN lang=EN-US>hidden field manipulation�Q�，�{�等�?SPAN lang=EN-US>

某些站点试图通过�q��o恶意输入来保护自己。但问题是编码信息的方式无穷无尽。这些编码方式看��h��q�不是加密的�Q�所以似乎也用不着解码。但是，开发�h员仍然经常忘记将所有的参数在��用之前解码�ؓ最��单的形式。参数应该在其被校验之前转换为最��单的形式�Q�否则，恶意输入��可能掩饰自�׃��而流�q�过滤器。简化这些编码的�q�程�U�Cؓ是“规格化�Q?SPAN lang=EN-US>canonicalization�Q�”。因为几乎所有的HTTP 输入都可以编码�ؓ多种格式�Q�这�U�技术便可以打�ؕ各种旨在利用和攻��M��q�弱点的��d��行�ؓ。这使得�q��o非常困难�?SPAN lang=EN-US>

有非�怹�多的web 应用仅��用客��L��校验来验证输入。客��L��校验机制是非常容易绕�q�的�Q�这样就使得Web应用几乎�Ҏ��意参数的��d��毫无保护。攻击者可以��用攻�ȝ��?SPAN lang=EN-US>telnet来��生他们自��q��HTTP ��h��。他们才不关心开发�h员预定想要在客户端发生的时候事情呢。注意，客户端校验仅仅在提高性能和可用性方面有益，但是它毫无安全可�a�。因此，对于恶意参数��d��Q�服务器端校验是必须的�?SPAN lang=EN-US>

�q�种��d��的数量在不断上升�Q�因为有大量的支持参数的“模�p�化”（“fuzzing�?/SPAN>�Q�、腐朽（corruption�Q�、以及野蛮强制增长的工具出现。不应该低估了这些��用非校验输入�q�行��d��的媄响。实际上如果开发�h员能够在使用参数之前对其�q�行验证�Q�就可抵挡大部分的攻凅R��因此，最好��用一个中心化的、强大的验证机制来对所�?SPAN lang=EN-US>HTTP ��h��的输入都�q�行验证�Q�这样利用此��q��q�行��d��的数量就会大减�?SPAN lang=EN-US>

环境影响

所�?SPAN lang=EN-US>web servers, application servers, 以及应用环境都容易受到这�U�参数篡改的��d��?SPAN lang=EN-US>

如何军_��你的应用是否脆弱

一�?SPAN lang=EN-US>Web应用所用的未经验证�?SPAN lang=EN-US>HTTP��h��的�Q何和部分都称为是“脏�?参数。找��参数的最��单的方式是进行最详细的代码评审，扑և�所有从HTTP��h��提取信息的方法调用。比如，�?SPAN lang=EN-US>J2EE应用中，�q�些包括HttpServletRequest �c�（以及其子�c�）中的�Ҏ��。然后你��可以��@着代码查看参数变量是在哪里使用的。如果变量在使用之前未作验证�Q�这可能��是一个潜在的问题。在Perl中，你因该考虑使用 “taint�?(-T) 选项�?SPAN lang=EN-US>

你也可以通过一些工��h��扑և�脏参敎ͼ�比如OWASP�?SPAN lang=EN-US> WebScarab。它们可以查看和评审通过HTTP/HTTPS的所有数据，�q�进行分析�?SPAN lang=EN-US>

如何保护

保护很简单，那就是确保�Q何参数在被��用之前都�q�行了验证。最好的办法是��用一个中心化的组件库�Q�比�?SPAN lang=EN-US>Java中的Jarkarta Commons Validator.每个参数都演�q�行严格��查。涉及到�q��o脏数据的“负面”方法或者依赖于�{�֐�的方法都不可能很有效率，�q�且难以�l�护�?SPAN lang=EN-US>

参数应该�q�行“正向”规格的��查，正向规格�Q?SPAN lang=EN-US> “positive�?specification �Q�的定义可包括：

数据�c�d��(string, integer, real, �{?SPAN lang=EN-US>)
允许的字�W�集
最大最��长�?SPAN lang=EN-US>
是否允许null
是否必需
是否允许重复
数��D��?SPAN lang=EN-US>
特定的法定�?SPAN lang=EN-US> (枚�D)
特定模式(正则表达�?SPAN lang=EN-US>)

* 本系列整理自 OWASP�Q�Opensource Web Applicaiton Security Project �Q?/o:p>

铁手 2005-09-12 11:52 发表评论

EJB 3.0 vs Spring

铁手 — Fri, 15 Jul 2005 04:23:00 GMT
OnJava上看��C��文章，贴在�q�里�Q�做上笔记�?/FONT>
Albert Einstein once said, "Everything should be made as simple as possible, but not simpler." �Q�哈哈，相对论再��单，也会令不知多��感到头痛，包括我�?IMG height=20 src="http://www.tkk7.com/Emoticons/QQ/09.gif" width=20 border=0>�Q?/FONT>Indeed, the pursuit of scientific truth has been all about simplifying a theory's underlying assumptions so that we can deal with the issues that really matter. The same can be said for enterprise software development.

A key to simplifying enterprise software development is to provide an application framework that hides complexities (such as transaction, security, and persistence) away from the developers. A well-designed framework promotes code reuse, enhances developer productivity, and results in better software quality. However, the current EJB 2.1 framework in J2EE 1.4 is widely considered poorly designed and over-complicated�Q�复杂是对的�Q�设计倒未必差。）. Unsatisfied with the EJB 2.1 framework, Java developers have experimented with a variety of other approaches for middleware services delivery. Most noticeably, the following two frameworks have generated a lot of developer interest and positive feedback. They are posed to become the frameworks of choice for future enterprise Java applications.

The Spring framework is a popular but non-standard open source framework. It is primarily developed by and controlled by Interface21 Inc. The architecture of the Spring framework is based upon the Dependency Injection (DI) design pattern. Spring can work standalone or with existing application servers and makes heavy use of XML configuration files. �Q��ؓ什么就让Springg赶上春天了？其实DI在很多地斚w��用到了，其实�Q�应该是说Spring 用DI来解决Factory的依赖性问题，�q�点占得先机。）
The EJB 3.0 framework is a standard framework defined by the Java Community Process (JCP) and supported by all major J2EE vendors. Open source and commercial implementations of pre-release EJB 3.0 specifications are already available from JBoss and Oracle. EJB 3.0 makes heavy use of Java annotations.�Q?STRONG>要是抢标准，Jboss昄��不是Oracle的对手，�q�不JavaOne之后�Q�Oracle在这上面领先了。这下，Oracle�q�同它独步天下的DB�Q�加上这么一个持久层东西�Q�很是了得。这��P��Oralce今后�Q�会不会形成JSF(ADF Faces)+EJB3的格局�Q�在J2EE上来那么一个��o人吃惊呢�Q�IBM帕不怕？不知道，它和BEA搞的SDO也提��C��JCP�Q�不�q�不知前景如何？哪天�Q�抽旉��仔细看看。）

These two frameworks share a common core design philosophy: they both aim to deliver middleware services to loosely coupled plain old Java objects (POJOs). �Q?STRONG>POJO是个奇怪的名字�Q�其中第一个O字母�Q�就令�h奇怪。呵呵，谁说老树不能开新花�Q�这下要是搞的风水轮��{�Q�就有好戏看�?/FONT>�?IMG height=20 src="http://www.tkk7.com/Emoticons/QQ/14.gif" width=20 border=0>�Q�The framework "wires" application services to the POJOs by intercepting the execution context or injecting service objects to the POJO at runtime. The POJOs themselves are not concerned about the "wiring" and have little dependency upon the framework. As a result, developers can focus on the business logic, and unit test their POJOs without the framework. In addition, since POJOs do not need to inherit from framework classes or implement framework interfaces, the developers have a high degree of flexibility to build inheritance structures and construct applications.�Q?FONT color=#ff1493>有点包办婚姻的感觉，�Ҏ��是�q�些POJO的父母。��L��要等到最后，才知道和自己有关�pȝ��东西是谁。是谁的悲哀�Q�没有，但愿皆大�Ƣ喜。）
其实�Q�轻量架构和敏捷�Ҏ��的火爆主要来源于几个主要的原因：1�Q�程序员自��n的武侠主义者，呵呵�Q�也可说英雄��M��。��L��什么都会，认�ؓ武功天下�W�一�Q�就是懂得更多的语言�Q�从需求、分析、设计、测试到部��v�Q�无所不通，多多益善。当然这也是生存压力的后果�?BR>2 SUN曄��设想�Q�J2EE是一个重量的团队协作的开发方式，可是大大��Z�h意料�Q�这�U�方式要求很高的软�g工程水��^�Q�同时支撑它的同栯��重量的过�E�模型，比如RUP什么的。但是大型的分布式应用毕竟是��数�Q�中��企业的信息化应用才是主��。而且�Q�MS的解��x��案，从过�E�MSF刎ͼ� .Net和开发环境VS�Q�无一不在生��力方面占得先机。老大�Q�要��C��Q�用��h��量最所的才是市场�?BR>3 ��Z��开发成本考虑�Q�老板��L��希望工程师无所不会�Q�这��h��能减��成本嘛�Q�！才会出现很多招聘�q�告上这样写道“精通A,B,C,D,E。。。。，工作�l�验2�q�”薪水却只开�?K。这��L��事天天发生。是觉得可笑吗？�q�是觉得悲哀。是觉得��Z��部门的问题，�q�是该公司的技术管理着�Ҏ��׃��懂。或者就是老板的问题。不�Q�这是市场的问题。同一个��Y�Ӟ��规模和功能几乎一��P��在国内卖�?0万，很高了，在英国却卖到60万英镑。呵呵，�q�就是市场。市场就�l�对正确吗？可是房�h天天涨，现在毕业的程序员�Q�看着房�h怎的不愁�Q�NND.
hehe, 跑题了。。。。。。。。。。。。。�?BR>

However, while sharing an overall philosophy, the two frameworks use very different approaches to deliver POJO services. While numerous books and articles have been published to compare either Spring or EJB 3.0 to the old EJB 2.1, no serious study has been done to compare Spring to EJB 3.0. In this article, I will examine some key differences behind the Spring and EJB 3.0 frameworks, and discuss their pros and cons. The topics covered in this article also apply to other lesser-known enterprise middleware frameworks, as they all converge on the "loosely coupled POJO" design. I hope this article will help you choose the best framework for your needs.

Vendor Independence

One of the most compelling reasons for developers to choose the Java platform is its vendor independence. EJB 3.0 is an open standard designed for vendor independence. The EJB 3.0 specification is developed and supported by all major open source and commercial vendors in the enterprise Java community. The EJB 3.0 framework insulates developers from application server implementations. For instance, while JBoss's EJB 3.0 implementation is based on Hibernate, and Oracle's is based on TopLink, developers need to learn neither Hibernate- nor TopLink-specific APIs to get their applications running on JBoss and Oracle. Vendor independence differentiates the EJB 3.0 framework from any other POJO middleware frameworks available today.�Q?STRONG>其实�q�点也是见仁见智了，��M��走着瞧�?/FONT>�Q?/P>
However, as many EJB 3.0 critics are quick to point out, the EJB 3.0 specification has not yet reached the final release at the time of this writing. It will likely be another one to two years before EJB 3.0 is widely adopted by all major J2EE vendors. But even if your application server does not yet support EJB 3.0 natively, you can still run EJB 3.0 applications in the server by downloading and installing an "embeddable" EJB 3.0 product. For instance, the JBoss embeddable EJB 3.0 product is open source and runs in any J2SE-5.0-compatible environment (i.e., in any Java application server). It is currently under beta testing. Other vendors may also soon release their own embeddable EJB 3.0 products, especially for the "data persistence" part of the specification.�Q?FONT color=#ff1493>恐怕还是不好吧�Q�一锅烩�Q�前些天看Walmart�q�移到Java5�Q�真够大胆的�?/EM>�Q?/P>
On the other hand, Spring has always been a non-standard technology and will remain that way in the foreseeable future. Although you can use the Spring framework with any application server, Spring applications are locked into both Spring itself and the specific services you choose to integrate in Spring.�Q?STRONG>其实�Q�标准不标准�Q�不是JCP说了��的。是大家多了��的�?/FONT>�Q?/P>

While the Spring framework is an open source project, Spring has a proprietary XML format for configuration files and a proprietary programming interface. Of course, this type of lock-in happens to any non-standard product; it is not specific to Spring. But still, the long-term viability of your Spring application depends on the health of the Spring project itself (or Interface21 Inc., which hires most of Spring's core developers). In addition, if you use any of the Spring-specific services, such as the Spring transaction manager or Spring MVC, you are locked into those APIs as well.
Spring applications are not agnostic to back-end service providers, either. For instance, for data persistence services, the Spring framework comes with different DAO and template helper classes for JDBC, Hibernate, iBatis, and JDO. So if you need to switch the persistence service provider (e.g., change from JDBC to Hibernate) for a Spring application, you will need to refactor your application code to use the new helper classes.�Q?STRONG>�q�点��是我的最爱，Spring对谁都很友好�Q�也�怹�包括�q�里的EJB3。）

Service Integration

From a very high level, the Spring framework sits above application servers and service libraries. The service integration code (e.g., data access templates and helper classes) resides in the framework and is exposed to the application developers. In contrast, the EJB 3.0 framework is tightly integrated into the application server and the service integration code is encapsulated behind a standard interface.

As a result, EJB 3.0 vendors can aggressively optimize the overall performance and developer experience. For instance, in JBoss's EJB 3.0 implementation, when you persist an Entity Bean POJO using the EntityManager, the underlying Hibernate session transaction is automatically tied to the calling method's JTA transaction, and it commits when the JTA transaction commits. Using a simple @PersistenceContext annotation (see later in this article for an example), you can even tie the EntityManager and its underlying Hibernate transaction to an application transaction in a stateful session bean. The application transaction spans across multiple threads in a session and it is very useful in transactional web applications, such as multi-page shopping carts. The above simple and integrated programming interface is made possible due to the tight integration between the EJB 3.0 framework, Hibernate, and Tomcat inside of JBoss. A similar level of integration is also archived between Oracle's EJB 3.0 framework and its underlying Toplink persistence service.

Another good example of integrated services in EJB 3.0 is clustering support. If you deploy an EJB 3.0 application in a server cluster, all of the fail-over, load-balancing, distributed cache, and state replication services are automatically available to the application.�Q�这恐怕不是EJB3的原因吧�Q�） The underlying clustering services are hidden behind the EJB 3.0 programming interface and they are completely transparent to EJB 3.0 developers.

In Spring, it is more difficult to optimize the interaction between the framework and the services. For instance, in order to use Spring's declarative transaction service to manage Hibernate transactions, you have to explicitly configure the Spring TransactionManager and Hibernate SessionFactory objects in the XML configuration file. Spring application developers must explicitly manage transactions that span across several HTTP requests. In addition, there is no simple way to leverage clustering services in a Spring application.

(其实�Q�通过annotation 扩展了语义，而Spring ��实用常规手�D�c��这点出发点都不一栗��?

Flexibility in Service Assembly

Since the service integration code in Spring is exposed as part of the programming interface, application developers have the flexibility to assemble services as needed. This feature enables you to assemble your own "lightweight" application servers. A common usage of Spring is to glue Tomcat together with Hibernate to support simple database-driven web applications. In this case, Spring itself provides transaction services and Hibernate provides persistence services--this setup creates a mini application server �Q?STRONG>�q�个观点倒是新鲜�Q?/FONT>in itself.

EJB 3.0 application servers typically do not give you that kind of flexibility in picking and choosing on the services you need. Most of the time, you get a set of prepackaged features, some of which you might not need. However, if the application server features a modular internal design, as JBoss does, you might be able to take it apart and strip out the unnecessary features. In any case, it is not a trivial exercise to customize a full-blown application server.

Of course, if the application scales beyond a single node, you would need to wire in services (such as resource pooling, message queuing, and clustering) from regular application servers. The Spring solution would be just as "heavyweight" as any EJB 3.0 solution, in terms of the overall resource consumption.

�Q�当�Ӟ��SPring 本��n��׃��是针对分布式的应用需求，也不支持。所以，没必要这么比。关键是看针寚w��些应用。）
In Spring, the flexible service assembly also makes it easy to wire mock objects, �Q�For Testing�Q�instead of real service objects, into the application for out-of-the-container unit testing. In EJB 3.0 applications, most components are simple POJOs, and they can be easily tested outside of the container. But for tests that involve container service objects (e.g., the persistence EntityManager), in-container tests are recommended, as they are easier, more robust, and more accurate than the mock objects approach.(当然�Q�脱不脱��d��器的��试其实对大家�ƈ不重要，关键是要��单，快速！)

XML Versus Annotation

From the application developer's point view, Spring's programming interface is primarily based upon XML configuration files while EJB 3.0 makes extensive use Java annotations. XML files can express complex relationships, but they are also very verbose and less robust. Annotations are simple and concise, but it is hard to express complex or hierarchical structures in annotations.�Q?STRONG>所以需要简化Spring 的XML语法�Q�尽��我已经觉得很简单了。比起Struts之类的已�l�简单不��了。）

Spring and EJB 3.0's choices of XML or annotation depend upon the architecture behind the two frameworks: since annotations can only hold a fairly small amount of configuration information, only a pre-integrated framework (i.e., most of plumbing has been done in the framework) can make extensive use of annotations as its configuration option. As we discussed, EJB 3.0 meets this requirement, while Spring, being a generic DI framework, does not.�Q�谁知道�Q�以后Spring 会不会也Anotation一�?我觉得很可能会。）

Of course, as both EJB 3.0 and Spring evolve to learn from each other's best features, they both support XML and annotations to some degree. For instance, XML configuration files are available in EJB 3.0 as an optional overriding mechanism to change the default behavior of annotations. Annotations are also available to configure some Spring services.

The best way to learn the differences between the XML and annotation approaches is through examples. In the next several sections, let's examine how Spring and EJB 3.0 provide key services to applications.

Declarative Services

Spring and EJB 3.0 wire runtime services (such as transaction, security, logging, messaging, and profiling services) to applications. Since those services are not directly related to the application's business logic, they are not managed by the application itself. Instead, the services are transparently applied by the service container (i.e., Spring or EJB 3.0) to the application at runtime. The developer (or administrator) configures the container and tells it exactly how/when to apply services.�Q?STRONG>AOP的天�?/FONT>�Q?BR>

EJB 3.0 configures declarative services using Java annotations, while Spring uses XML configuration files. In most cases, the EJB 3.0 annotation approach is the simpler and more elegant way for this type of services. Here is an example of applying transaction services to a POJO method in EJB 3.0.
public class Foo { @TransactionAttribute(TransactionAttributeType.REQUIRED) public bar () { // do something ... } }

You can also declare multiple attributes for a code segment and apply multiple services. This is an example of applying both transaction and security services to a POJO in EJB 3.0.
@SecurityDomain("other") public class Foo { @RolesAllowed({"managers"}) @TransactionAttribute(TransactionAttributeType.REQUIRED) public bar () { // do something ... } }

Using XML to specify code attributes and configure declarative services could lead to verbose and unstable configuration files. Below is an example of XML elements used to apply a very simple Hibernate transaction to the Foo.bar() method in a Spring application.

�Q�EJB的方式的��简单，可是如果复杂度上升，恐怕优势也不怎么明显了。）

The XML complexity would grow geometrically if you added more interceptors (e.g., security interceptors) to the same POJO. Realizing the limitations of XML-only configuration files, Spring supports using Apache Commons metadata to specify transaction attributes in the Java source code. In the latest Spring 1.2, JDK-1.5-style annotations are also supported. �Q�对啦，也许今后是个方向�Q�学习是很重要的�Q?/EM>�Q�To use the transaction metadata, you need to change the above transactionAttributeSource bean to an AttributesTransactionAttributeSource instance and add additional wirings for the metadata interceptors.
�Q�Spring的一个问题是各种名称都不肯羃写，弄的老长。当�Ӟ��意思更加清楚明了。）

The Spring metadata simplifies the transactionAttributeSource element when you have many transactional methods. But it does not solve the fundamental problems with XML configuration files--the verbose and fragile transaction interceptor, transactionManager, and transactionAttributeSource are all still needed.

Dependency Injection

�Q�这�q�头松散耦合�q�么��行�Q�就像男奛_��p�M��_��一夜情好生��行似的。我们先前说的婚姻，恐怕也片面了些。各�U�滋呛_��含义�Q�大家自�׃��会吧。）

A key benefit of middleware containers is that they enable developers to build loosely coupled applications. The service client only needs to know the service interface. The container instantiates service objects from concrete implementations and make them available to clients. This allows the container to switch between alternative service implementations without changing the interface or the client-side code.

The Dependency Injection pattern is one of best ways to implement loosely coupled applications. It is much easier to use and more elegant than older approaches, such as dependency lookup via JNDI or container callbacks. Using DI, the framework acts as an object factory to build service objects and injects those service objects to application POJOs based on runtime configuration. From the application developer's point of view, the client POJO automatically obtains the correct service object when you need to use it.

Both Spring and EJB 3.0 provide extensive support for the DI pattern. But they also have some profound differences. Spring supports a general-purpose, but complex, DI API based upon XML configuration files; EJB 3.0 supports injecting most common service objects (e.g., EJBs and context objects) and any JNDI objects via simple annotations.

The EJB 3.0 DI annotations are extremely concise and easy to use. The @Resource tag injects most common service objects and JNDI objects. The following example shows how to inject the server's default DataSource object from the JNDI into a field variable in a POJO. DefaultDS is the JNDI name for the DataSource. The myDb variable is automatically assigned the correct value before its first use.
(JNDI仍然可以玩，只不�q�lookup也由容器代劳了。精彩！�Q�这对移植更加方便了)

public class FooDao { @Resource (name="DefaultDS") DataSource myDb; // Use myDb to get JDBC connection to the database }

In addition to direct field variable injection, the @Resource annotation in EJB 3.0 can also be used to inject objects via a setter method. For instance, the following example injects a session context object. The application never explicitly calls the setter method--it is invoked by the container before any other methods are called.
@Resource public void setSessionContext (SessionContext ctx) { sessionCtx = ctx; }

For more complex service objects, special injection annotations are defined. For instance, the @EJB annotation is used to inject EJB stubs and the @PersistenceContext annotation is used to inject EntityManager objects, which handle database access for EJB 3.0 entity beans. The following example shows how to inject an EntityManager object into a stateful session bean. The @PersistenceContext annotation's type attribute specifies that the injected EntityManager has an extended transaction context--it does not automatically commit with the JTA transaction manager, and hence it can be used in an application transaction that spans across multiple threads in a session.
�Q�这里才是EJB的关键。）

@Stateful public class FooBean implements Foo, Serializable { @PersistenceContext( type=PersistenceContextType.EXTENDED ) protected EntityManager em; public Foo getFoo (Integer id) { return (Foo) em.find(Foo.class, id); } }

The EJB 3.0 specification defines server resources that can be injected via annotations. But it does not support user-defined application POJOs to be injected into each other.

In Spring, you first need to define a setter method (or constructor with arguments) for the service object in your POJO. The following example shows that the POJO needs a reference to the Hibernate session factory.
public class FooDao { HibernateTemplate hibernateTemplate; public void setHibernateTemplate (HibernateTemplate ht) { hibernateTemplate = ht; } // Use hibernateTemplate to access data via Hibernate public Foo getFoo (Integer id) { return (Foo) hibernateTemplate.load (Foo.class, id); } }

Then, you can specify how the container gets the service object and wire it to the POJO at runtime through a chain of XML elements. The following example shows the XML element that wires a data source to a Hibernate session factory, the session factory to a Hibernate template object, and finally, the template object to the application POJO. Part of the reason for the complexity of the Spring code is the fact that we need to inject the underlying Hibernate plumbing objects manually, where the EJB 3.0 EntityManager is automatically managed and configured by the server. But that just brings us back to the argument that Spring is not as tightly integrated with services as EJB 3.0 is.
java:comp/env/jdbc/MyDataSource

Although the XML-based Dependency Injection syntax in Spring is complex, it is very powerful. �Q�正因如此，才和其它框架和遗恨好的集成，�q�样�Q�架构就有更多选择�?/FONT>�Q?/STRONG>You can inject any POJO, including the ones defined in your applications, to another POJO. If you really want to use Spring's DI capabilities in EJB 3.0 applications, you can inject a Spring bean factory into an EJB via the JNDI. �Q?STRONG>�q�样INDI也是老树新花。当然JNDI的用处大了，JavaEE不可能丢了他�?/FONT>�Q�In some EJB 3.0 application servers, the vendor might define extra non-standard APIs to inject arbitrary POJOs. A good example is the JBoss MicroContainer, which is even more generic than Spring, as it handles Aspect-Oriented Programming (AOP) dependencies.

Conclusions

Although Spring and EJB 3.0 both aim to provide enterprise services to loosely coupled POJOs, they use very different approaches to archive this goal. Dependency Injection is a heavily used pattern in both frameworks.

With EJB 3.0, the standards-based approach, wide use of annotations, and tight integration with the application server all result in greater vendor independence and developer productivity. With Spring, the consistent use of dependency injection and the centralized XML configuration file allow developers to construct more flexible applications and work with several application service providers at a time.

�Q�各有所�ѝ��EJB�q�是针对高端�Q�Spring针对低端�Q�中间一部分重合�Q�大家两全其��?/EM>

�q�篇文章在OnJava一��骂壎ͼ��q�是开源的同志们比较多�ѝ��）

Acknowledgments

The author would like to thank Stephen Chambers, Bill Burke, and Andy Oliver for valuable comments.

Resources

The Spring framework (see also CodeZoo: Spring)
EJB 3.0
JBoss EJB 3.0
Oracle Application Server EJB 3.0 Preview

铁手 2005-07-15 12:23 发表评论

Struts�U�籍之第2�D�：�W?.7式：动态��生JavaScript

铁手 — Tue, 07 Jun 2005 04:32:00 GMT

�W?.7�? 动态��生JavaScript

问题

你想要根据从应用模型获得的数据动态��生JavaScript�?/P>
动作要领

使用Struts 标签在你惌��包含在HTML中的JavaScript 代码中渲染数据：

<script language="JavaScript">
    function showMessage(  ) {
        alert( "Hello, !" );
    }
script>

动作变化

上述�Ҏ��产生了一个JavaScript 函数�Q�弹��Z��个消息框�Q�消息文本�ؓ"Hello, name!" name的值是使用 bean:write标签产生的。此�Ҏ��展示了��用Struts 标签创徏JavaScript 和它们创建HTML一��L��Ҏ��?/P>
JSTL也可以按�q�种方式使用�?/P>
虽然�q�种�Ҏ��很明显，但是很奇怪很多�h都在问这个问题。通常问题�q�可能是�Q?我如何才能从Struts中调用HTML中的JavaScript 函数�Q? 技术上�Ԍ��你�ƈ不能从Struts调用一个HTML��面中的JavaScript 函数。Struts 和JSP 技术都�q�行在服务器端。相反，JavaScript��是在客��L��的浏览器中处理的。但是，通过�q�里所�q�的动态��生JS的能力，基本上还是相当于所需的这个行为�?/P>
�q�个�Ҏ��的一个重要基��是JSP的�{换过�E�。JSP ��面由JSP 声明�Q�标准JSP 标签 (比如jsp:useBean), 定制JSP 标签(比如Struts 和JSTP 标签), �q�行是表辑ּ��Q�以及脚本小�E�序�Q�scriptlets�Q�组成。除此之外的其他东西都是模板文本�Q?A name=jakartastrutsckbk-CHP-3-ITERM-1548>template text�Q��?/EM>模板文本可以是�Q何不会被JSP转换处理的内宏V��h们通常会认为模板文本就是HTML 标记�Q�但是它其实是JavaScript 或者其他非JSP 处理的文本。JSP ��译器�ƈ不关心模板文本采用何�U��Ş式。因此，你可以象在HTML元素中��生文本一样容易地在JavaScript 函数中��生文本�?/P>
如果你��用JSP 来��生良构的�Q�well-formed�Q?A name=jakartastrutsckbk-CHP-3-ITERM-1550>XHTML, 那么动态JavaScript 模版文本必须使用jsp:text元素和CDATA section的方式结合来指定。具体信息参见Hans Bergsten的ONJava 文章�Q?A >http://www.onjava.com/pub/a/onjava/2004/04/21/JSP2part3.html�?/P>
�q�里的例子仅仅列��Z��很简单的使用场景。如果要讉K��的模型数据需要��用复杂的JavaScript数据�l�构�Q�比如，数组�Q�你可以使用�q�代标签�Q�比�?A name=jakartastrutsckbk-CHP-3-ITERM-1552>logic:iterate�?A name=jakartastrutsckbk-CHP-3-ITERM-1554>c:forEach来组装这些结构�?/P>
相关动作

下一�?.8或会使用�q�代标签来��生客��L��的JavaScript 数组�?/P>

铁手 2005-06-07 12:32 发表评论

铁手 — Mon, 30 May 2005 05:16:00 GMT
以下�?span class="bannerdescription">Ted Neward的一个blog�Q�旨在陈清多�q�来一直可能�؜淆的概念�Q�即“Web Services”是一个东西吗�Q?br> 他认�?其实��Z��可能都�؜淆了�Q�Web代表的是互操作性，而Services则是代表一�U�设计理念，即独立的、自�ȝ��、无耦合的组件模型。而“Web Service”仅是其中的一�U�结合方案而已�?br> 颇有见地�?br> 下面是摘录的原文�Q�其中精彩之处予以标出：原文可访�?http://www.neward.net/ted/weblog/index.jsp?date=20050525#1117011754831

Web + Services

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 LOT of bad decisions that will come to haunt us over the next five to ten years.)

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?

铁手 2005-05-30 13:16 发表评论

使用 WebSphere Application Server V6 构徏企业服务�ȝ��

铁手 — Fri, 27 May 2005 07:29:00 GMT

IBM Websphere 中国开发站�Ҏ��几篇新的Websphere V6中构建ESB的文章，目前已发�?��：
分别�?nbsp;�Q?br>
使用 WebSphere Application Server V6 构徏企业服务�ȝ�� —�?
�W? 部分 WebSphere V6 消息传递资源入�?/a>
�W? 部分�Q?a > 业务需求以及�ȝ��
�W?部分�Q?nbsp; ��单的 JMS 消息传递实�?/span>

跟踪�?....

铁手 2005-05-27 15:29 发表评论

Java �q�_��持久性机制的比较

铁手 — Tue, 24 May 2005 02:26:00 GMT

Java �q�_��持久性机制的比较

讉K��持久性数据是所有应用都需要考虑的一个重要方面。Java 语言严格的遵循了持久性数据和暂态性数据的分离�Q�将持久性管理留�l�了应用或者分层机制。SUN使用一�U�严格的比较机制��试和比较了Java�q�_��上的各种革新的持久性机制�?/P>
通过选择�Q�选出了一个有代表意义的几个系�l�来�q�行评�h和比较。这些机刉��通过OO7J的基准测试进行量化分析�?/P>
所有的��试环境都具有��够的内存�Q��得测试数据库完全可以在内存中�ȝ��Q�排除磁盘访问等��g的媄响，也是今天主要服务环境的通用内存定w��配置。OO7J的虚拟机变体讄��性能基线�Q�每一�U�机刉��和它�q�行比较。OPJ的PJama实现得到了��M��最高分。它只需要最��的源代码修改，甚至对OO7J的主体基本不需要，虽然它仅是一个原型实玎ͼ�却取得了最好的性能。但是它的确需要一个定制的虚拟机�?/P>
EJB 框架看�v来最�p�，需要最多的源代码修改和最坏的性能和可伸羃性�?/P>
JOS �?JBP�Q�虽然因为它们缺乏增量访问从而��得在��d��数据的时候性能也很�p�糕�Q�但是，他也仅需要很��的代码修改�q�能在数据在内存中的情况下全速运行�?/P>
JDBC �Ҏ��代码修改也有较大影响�Q�但是性能却是在JVM和数据库的边�~�交叉处的大量交互体现的很好。两个JDO 的变体则展现出JDO模型对不同外部数据存储的多能性。特别是JDO-TP 和其事务对象模型对关�p�L��据库工作的很好，同时允许源代码对基线保持最��的变更。�ƈ且， JDO 的性能也排在前列，一旦数据在内存中，�q�是合情合理的，比JDBC �?EJB而言也是如此�?/P>
虽然EJB CMP 的性能要优于EJB BMP�Q�其性能也差于JDO-TP很多。EJB性能差的原因�q�不清楚�Q�也应该注意刎ͼ�一些应用服务企业有很差的性能�Q�可能是容器实现的原因�?/P>
作�ؓ�l�论�Q�很昄��Q�持久性对应用代码的媄响是很宽的，也对�l�果�pȝ��的性能影响很大�? 如果在虚拟机一�U�得到支持，OPJ可望提供最有竞争力的性能。在另一个极端，EJB��g��很难辑ֈ�可接受的性能水��^�Q�除非应用对象模型发生戏剧性的变化�Q�从而避免在映射到EJB时��生的�l�粒度对象。虽然这些方法已�l�反映在标准的EJB设计模式中了�Q�但是其暗示着在应用程序的各个斚w��均要附加更多额外的努力。相反，JDO 试图在对应用设计的媄响最��的情况下达到合理的性能�Q�同时保持对外部数据源的中立。因此，当前�Q�JDO ��g��能够提供面向对象应用所需的最佳的��M��持久性机制。但是，目前�Q�SUN��了一个最新的实体Bean持久性规�?[Sun04]�Q�提交给 EJB3.0�Q�它可能更加接近于JDO 模型�?/P>

报告的原文可以在以下地址下蝲�Q?A >http://research.sun.com/techrep/2004/smli_tr-2004-136.pdf

同时�Q�这也是SUN首次公开披露EJB的性能问题。这也解释了��Z��么EJB一直得不到很好的广泛��用的原因�Q��E然还有它的复杂性和部��v的高成本性（需要昂�늚�EJB容器�Q�。作为J2EE规范中的一个重要的核心�l��g�Q�SUN的赌注押在了EJB3.0上面。EJB3.0相关的持久性机�Ӟ��JSR220�Q�吸收了JDO和oracle的TopLink的优点，�q�且可望提供向后兼容性和�q�移API�?/P>
虽然�Q�EJB从其规范和目标来说看上去很美。但是EJB3.0臛_��要今�q�晚些时候才能出场，目前我们能够使用什么呢?考察目前市面上的持久性框�Ӟ��l�合你的应用要求�Q�也不难得出选择。毕竟，应用来说�Q�性能�q�不是第一位的�?/P>
对于持久性框架的选择�Q�从应用和功能上�Ԍ��主要考虑以下斚w��Q?/P>

对O-R mapping框架的��用经验�?nbsp;
数据源（Data Source�Q�，必须支持不同的数据源�Q�包括关�p�L��据库和JCA体系�?
最好提供图形化的映��工��h��q�行对象和数据库表之间的映射�Q�自动生成XML配置文�g�?nbsp;
数据库支持，可以利用数据库的优势�Q�如存储�q�程�Q�触发器�Q�支持高�U�数据类型和数据库安全�?nbsp;
查询支持�Q�应该支持通过Java代码或者OO查询机制�Q�如EJB QL�Q�按例查询，标准SQL 来编写自��q��查询�?
锁定。必��L��持不同应用访问同一数据库时候的锁定机制�?nbsp;
�~�存。提供有效的�~�存基址�Q�减��网�l�和查询的开销�?nbsp;�q�支持不同节点的集群�?
支持到EJB 3.0的迁�U�R�?/LI>

目前�Q�JBOSS已经在AS 4.0中提供了EJB3.0的早期实现。可以参考�?A >http://www.jboss.org/products/ejb3

如果你不怕在Oracle数据库��^��C��锁定�Q�你打可使用Toplink�Q�这也是目前性能最好的POJO的持久性框架。Oracle也是EJB3.0的专家组�Q�将来肯定会提供�q�移的手�D�c�?你可以阅读这��文章：Preparing for EJB3.0. 地址�Q?A >http://www.oracle.com/technology/tech/java/newsletter/articles/toplink/preparing_for_ejb_3.html

注：

JOS

JOS�Q�称为Java对象序列化，是JDK 1.1 引入�?[Sun99]�Q�它是一�U�支持几乎所有对象到��的�~�码和从��解码的机制。他不是��Z��属性表的编码，而是��Z��文本的，对象序列使用标准的二�q�制�~�码格式。JOS 是Java�q�_��默认的持久性机�Ӟ��也被用来作�ؓ JAVA�q�程�Ҏ��调用RMI的参数编�l�协议。在最低层�ơ上�Q�JOS 构成了对基础�c�d��的编码和解码的��^台支持。但是，序列化遇��C��c�L��化的严重问题�Q�这也��得在Java1.4中引入了“JavaBean的长期持久化”的新系�l��?/P>
JDBC

JDK 1.1 也引入了Java数据库连�?JDBC) API [FEB03]作�ؓ使用标准的SQL语言在Java和关�p�L��据库之间的通信机制。JDBC为Java 向关�p�L��据库提供了一个强有力的蟩板，�q�且被��^��C��的很多API实现证明很成功。设计者很成功地将Java �~�程语言和SQL�q�行了嫁接，而且JDBC 对直接的数据库访问非常容易��用。然而，如果应用需要底层数据的对象视图的时候，比如�Q�将主键转换成相�{�的对象间的引用关系�Q�程序将便得非常复杂和容易出错。�ؓ了解册��个问题，有许多系�l�开发出来试图自动化�q�个��程�Q�这通常�U�Cؓ是对象关�p�L��（O-R Mapping�Q�。大多数开发环境都提供对这一机制的不同程度的支持�?JDBC API 也在发展�Q�近来支持直接将Java语言中的一个类映射到SQL的面向对象扩展中的相�{�类型�?/P>
JDO

在JDBC 开发的同时�Q�对象数据库��理�l?(ODMG)定义了一个它们的对象模型到Java语言的绑定[Ced96]�Q�而许多对象数据库厂商则提供了�q�种�l�定的实现。因为对象数据库�q�不像关�p�L��据库那样部��v普遍�Q�因此反映在�q�个�l�定上面也是不怎么成功。Java�C�֌��程�Q�JCP�Q�出现后�Q�这一努力被一个更�q�泛的徏议所替代�Q�即Java数据对象 (JDO) [JR03]。JDO 的目标是针对各种各样的底层数据存储，包括关系数据库，�q�向开发�h员呈��C��个类��g��LJS所定义的对象模型，但附加限制更��。而许多对象数据库厂商也支持JDO�?/P>
OPJ

�l�合�q�些努力�Q�SUN�?Glasgow 大学合作�Q�提��Z��一个Java�q�_��的正交持久化机制 (OPJ) [JA00]。这一�Ҏ��以极高的透明性支持变成语�a�的各个方面。从本质上讲�Q�OPJ ��d��了对JVM�E�_��内存的支持，也意味着�q�一对JVM 实现的要求根本上限制了其可接受性�?/P>

铁手 2005-05-24 10:26 发表评论

骡子力气比马大：一个ESB集成框架CodeHaus Mule

铁手 — Wed, 18 May 2005 05:22:00 GMT

Mule 是一个基于ESB架构理念的消息��^台。Mule 的核心是一个基于SEDA的服务容器，该容器管理被�U�Cؓ通用消息对象�Q�Universal Message Objects /UMO�Q�的服务对象�Q�而这些对象都是POJO。所有UMO和其他应用之间的通信都是通过消息端点�Q�message endpoint�Q�来�q�行的。这些端点�ؓ众多的分立的技术，比如Jms, Smtp, Jdbc, Tcp, Http, Xmpp, file�{�等�Q�提供了��单和一致的接口�?/P>
Mule 应用通常是由�|�络中的许多Mule 实例�l�成。每一个实例都是一个驻留一个或者多个UMO�l��g的轻量��容器。每一个UMO �l��g都有一个或者多个通过它（们）发送和接收事�g的端炏V�?BR>

容器通过UMO�l��g提供各种各样的服务，比如事务��理、事件�{换，路由�Q�事件关联、日志、审计和��理�{�等。Mule��对象构造从��理手段中分��d��来，通常��行框架和IoC/DI 容器�Q�如Spring, PicoContainer 或�?Plexus 可用�q�种��理手段来构��Z��的UMO �l��g�?/P>
很多��为， "Mule是一个Jms 实现"。实际上�Q�Mule 不是一个Jms server�Q�但是可以配�|�来使用��M��你觉得非常漂亮的Jms server。Mule 的理忉|��Q�如果已�l�有了稳定和�q�泛接受的实玎ͼ��׃��会直接实��C�Q何传输。例如，Mule ��重用了Axis �?GLUE 的SOAP栈而不是重新实��C��个。Mule 提供了一个一致的服务集来��理��M��c�d��的连接的事�g��、关联、事务、安全和审计�?/P>

下面是Mule Server �l��g的简单图�C�：

Mule Manager

Mule Manager是Mule server 实例的中�?也称��Z��个节�Ҏ��或者Mule Node)。其主要的角色是��理各种对象�Q�比如Mule实例的连接器、端点和转换器。这些对象然后被用来控制�q�出你的服务�l��g的消息流�Q��ƈ且�ؓModel和它所��理的组件提供服务�?/P>
Model

model 是管理和执行�l��g的容器。它控制�q�出�l��g的消息流�Q�管理线�E�、生命周期和�~�充池。默认的MuleModel是基于SEDA的，它��用一个有效的��Z��事�g的队列模型来获取的最大的性能和直通性�?/P>
UMO Components

UMO代表Universal Message Object�Q�它是一个可以接收来自于��M��地方的消息的对象。UMO �l��g��是你的业务对象。它们是执行引入的事件之上的具体业务逻辑的组件。这些组件是标准的JavaBean�Q�组件中�q�没有�Q何Mule特定的代码。Mule ��Z��你的�l��g的配�|�处理所有进出组件的事�g的�\由和转换�?/P>
Endpoints

Endpoint是Mule的通信能力的基��。一个Endpoint定义了两个或者多个组建应用或者存储库之间的通信渠道。�ƈ且提供了一个强大的机制来允�怽�的对象在一个统一的方式上再多�U�协议之上进行交谈。端点可以通过消息�q��o器、安全拦截器和事务信息进行配�|�来控制什么消息，在何�Ӟ��以及怎样通过端点�q�行发送和接收�?/P>
External Applications

外部应用可以使�Q何应用，从应用服务器到遗留的传统应用�Q�主机程序，或者C/S�pȝ��。基本上是�Q何可以��生和操纵数据的应用。因为Mule通过endpoints执行所有通信�Q�UMO �l��g�q�不打算在其中包含应用��生数据，以及应用��L��Q�以及��用传输协议的部分�?/P>

关键�Ҏ�?/STRONG>

��Z��J2EE 1.4的企业消息�ȝ��Q?Enterprise Service Bus (ESB)�Q�和消息代理�Q�broker�Q?
可插入性连接，比如Jms (1.0.2b �?1.1), vm (嵌入), jdbc, tcp, udp, multicast, http, servlet, smtp, pop3, file, xmpp�{?
支持��M��传输之上的异步，同步和请求响应事件处理机�?
支持Axis或�?A >Glue的Web Service.
灉|��的部�|�结构[Topologies]包括Client/Server, P2P, ESB 和Enterprise Service Network.
支持声明性和�~�程性事务，包括XA 支持
对事件的路由、传输和转换的断到端支持
Spring 框架集成。可用作ESB 容器�Q�而Mule c也可以很�Ҏ��的嵌入到Spring 应用中�?
使用��Z��SEDA处理模型的高度可伸羃的企业服务器
支持REST API 来提供技术独立和语言中立的基于web的对Mule 事�g的访�?
强大的基�?A >EIP模式的事件�\由机�?
动态、声明性的�Q�基于内容和��Z��规则的�\由选项
非入侵式的方式。�Q何对象都可以通过ESB 容器��理
强大的应用集成框�?
完整的可扩展的开发模�?/LI>

何时使用

一般在�q�些情�Ş下��用Mule -

集成两个或者多个需要互盔R��信的或者多个现有的�pȝ��.
需要完全和周围环境去耦合的应用，或者需要在�pȝ��中�׾~�不止一个组件的�pȝ��
开发�h员不知道未来是否会将其应用分发或者�׾~�需求的单VM 应用�?/LI>

��目地址�Q?A >http://mule.codehaus.org/

铁手 2005-05-18 13:22 发表评论

一�U�优雅的��行架构�Q�Struts+Spring+Hibernate (1)

铁手 — Fri, 29 Apr 2005 03:42:00 GMT

用java来徏立一个很有�h值的web 应用不是一个简单的��d��。在架构�q�个应用时要考虑很多的因素和问题。从更高的层�ơ来看，开发�h员面临着关于如何构徏用户接口�Q�何处驻留业务逻辑�Q�以及如何实现数据持久性这些问题。这3层都有各自的问题需要回�{�。而每一层又需要实现那些技术？应用如何设计来进行松散耦合�q�能�q�行灉|��变更�Q�应用架构是否允许某一层变更而不影响到其它的层次�Q�应用应该如何处理容器一�U�的服务比如事务�Q?/P>
在�ؓ你的应用创徏一个架构之前有许多问题需要澄清。幸�q�的是，有很多开发者都意识到这个问题，�q�徏立了很多框架来解册��些问题。一个良好的框架可以让开发�h员减轻重新徏立解军_��杂问题方案的负担和精力；它可以被扩展以进行内部的定制化；�q�且有强大的用户�C�֌�来支持它。框枉��常能很好的解决一个问题。然而，你的应用是分层的�Q�可能每一个层都需要各自的框架。仅仅解决UI问题�q�不意味着你能够很好的��业务逻辑和持久性逻辑和UI �l��g很好的耦合。例如，你不应该使具有JDBC代码的业务逻辑攑օ�控制器之中，�q�不是控制器应该提供的功能。一个UI 控制器应该是轻量化的�l��g�Q�由它代表对UI范围之外的其它应用层的服务调用。良好的框架自然地�Ş成代码分��ȝ��原则。更为重要的是，框架减轻了开发�h员从头构建持久层代码的精力，从而集中精力来应用逻辑上，�q�对客户端来说更为重要�?/P>
本文讨论了如何结合几个著名的框架来达到松散耦合�Q�如何设计你的架构，以及如何辑ֈ�各个层次的一致性设计。面临的挑战是，��框架整合�v来，以��每一层都向另外的层次以一�U�松散的方式来暴露接口，而不��底层功能��用的是什么技术。本文还讨论整合3�U�著名开源框架的一�U�策略。对表现层，我们使用Struts�Q�业务层使用Spring�Q�对于持久层我们使用的是Hibernate。你��可以取代这里的某个框架而��用你喜欢的框架已辑ֈ�同样的效果。图1昄��了框架被整合��h��Ӟ��从最高层�ơ看到的视图�?BR>

应用�?/STRONG>

许多设计良好的web 应用�Q�可以被按职责分为四层。这些层�ơ是表现层、持久层、业务层、和领域模型层。每一个层�ơ都有其独特的职责，不能把各自的功能与其它层�ơ相混合。每一个应用层都应该和其它层隔��d��来，但允�怋�用接口在层间�q�行通信。我们开始来看看每个层，�q�讨��Z��下它们各自都应该提供什么和不应该提供什么�?/P>
表现�?/STRONG>

一个典型的web 应用的末端是表现层。许多Java 开发者都知道Struts 提供了什么东�ѝ��然而，太多时候，耦合代码比如业务逻辑被放�q�org.apache.struts.Action中。所以，我们先�ȝ��一下Struts 之类的框架应该提供什么。下面就是Struts 的职责所在：

��理用户的请求和响应

提供一个控制�v来将调用委托��C��务逻辑和其他上游处�?/LI>
��来自于抛出例外的其他层的例外处理到Struts Action �?/LI>
�l�装可以在视图中表现的模型对�?/LI>
执行UI 校验

下面是一些经常可以��用Struts�q�行�~�码但是不应该和表现层关联的事情�Q?/P>

直接和数据库交互�Q�比如JDBC 调用

与应用相关的业务逻辑和校�?/LI>
事务��理

在表现层中引入这些类型的代码��导致类型耦合和维护负担�?/P>
持久�?/STRONG>

一个典型Web应用的另一端是持久层。这也是应用中最�Ҏ��很快失控的地斏V��开发者通常低估了自己构��q��持久层框架的挑战。一个定制的�Q�内部开发的持久层不仅需要大量的开发时��_��q�且通常�~�Z��功能和难以管理。目前有许多解决�q�些问题的开源对象关�p�L��?(ORM) 框架。特别地�Q?Hibernate 框架��允许Java中的对象-关系的持久性和查询服务。Hibernate 对已�l�熟悉了SQL 和JDBC API 的Java开发者来或具有中度的学习曲线。Hibernate 的持久对象基于POJO和Java ��集�Q�collections�Q�。此外，使用Hibernate 不和你的IDE接口。下面列��Z��你需要在持久性框架中�~�写的代码类型：

查询关系信息到对象中。Hibernate 是通过�U�CؓHQL的OO查询语言�Q�或者��用更有表现能力的规则API�Q�来完成�q�个工作的。除了��用对象而不是表�Q��用字�D�而不是列的方式，HQL非常�c�M��?SQL。也有一些新的特定的HQL 语言特征需要学习；但是�Q�它们是很容易理解和良好�~�写的。HQL 是一�U�用于查询对象的自然语言�Q�而对象，只需要很��的学习曲线吧�?

存储、更新和删除存储在数据库中的信息

高��的对象关�p�L��框架比如Hibernate支持大部分主��SQL数据库，它们支持�?子关�p�，事务�Q��承和多态�?/LI>

下面是应该在持久层避免的一些事情：

业务逻辑应该�|�于应用的更高层中。这里只允许数据讉K��Ҏ��?/LI>
不应该��持久逻辑和表现逻辑耦合。避免表现组件如JSP或者基于servlet的类中的逻辑直接和数据访问进行通信。通过��持久性逻辑隔离在其自己的层中，应用��具有更加灵�zȝ��修改性而不影响到其他层的代码。例如， Hibernate 可以使用其他持久框架和API代替�Q�而不需要修改其它层中的代码�?/LI>

业务�?/STRONG>

典型的Web应用的中间组件一般是业务层和服务层。从�~�程的角度来��_��service layer�l�常被忽略。这�U�类型的代码散布于UI表现层和持久层�ƈ不是不多见。这些都不是正确的地方因为它��D��了紧密耦合的应用和难以�l�护的代码。幸�q�的是，大多数框枉��解决了这个问题。这个空间内最��行的两个框架是Spring 和PicoContainer。它们都被视为是��h��非常��的��Q�footprint�Q��ƈ且决定如何将你的对象整合在一��L��微容器（microcontainer�Q�。这些框枉��建立在一�U�叫做依赖性注入（dependency injection�Q?(也称控制反�{�Q�inversion of control�Q�IOC�Q?的简单概念之上。我们将��x��Spring中通过针对命名配置参数的bean属性的setter 注入的��用。Spring 也允�怸��U�更加高�U�的构造器注入�Q�constructor injection�Q��Ş式作为setter injection 的可选替代。对象通过��单的XML 文�g�q�行�q�接�Q�该配置文�g包含对各�U�对象的引用�Q�比如事务管理处理器�Q�transaction management handler�Q?对象工厂�Q�包含业务逻辑的服务对象，以及数据讉K��对象(DAO)�?/P>
我们随后会用一些例子来澄清Spring中��用这些改变的方式�?/P>
业务层应该负责下面的问题�Q?/P>

处理应用的业务逻辑和业务校�?/LI>
��理事务

允许与其他层�q�行交互的接�?/LI>
��理业务�U�对象之间的依赖�?/LI>
加入了表现和持久层之间的灉|��性，以便它们不需要彼此进行直接通信

从表现层暴露上下文给业务层以获得业务服务

��理从业务层到表现层的实�?/LI>

领域模型�?/STRONG>

最后，因�ؓ我们要解军_��际的问题的web应用�Q�我们需要一套在不同的层间移动的对象。领域模型层包含的是表达实际业务对象的对象，比如Order, OrderLineItem, Product �{�等。这一层允许能让开发者不再构建和�l�护不必要的数据传输对象DTO来匹配其领域对象。例如， Hibernate允许你读取数据库信息��C��个领域对象的对象图中�Q�以便你可以在离�U�的情况下将其表现在UI层中。这些对象可以被更新�q�跨�q�表现层发送回去，然后�q�行数据库更新。另外，你不再需要将对象转变成DTO�Q�因为它们在不同的层间移动时可能会丢�׃��务。这�U�模型允许Java 开发者能够以OO风格的方式很自然的处理对象，而不用编写额外的代码�?/P>
整合一个简单的例子

到此�Q�应该对各种层次和组件有一个高层的理解了�Ş。可以开始一些实践了。再�ơ说明。我们的例子整合了Struts, Spring, 和Hibernate 框架。每个框枉��包含大量的内容细节，我们不会多述。我们的目的使用一个例子向你说明如何将它们整合在一��h��Z��个优雅的Web应用架构。实例将演示一个请求是如何得到各层的服务的。此应用的用户可以将一个订单保存在数据库中�q�且察看数据中的已有订单。进一步的增强允许��用��h��新和删除现有订单�?/P>
首先�Q�我们将常见我们的领域对象，因�ؓ它们是要和各层沟通的。这些对象将允许我们能够定义那些对象需要持久化�Q�那些业务逻辑需要提供，以及应该设计那些表现接口。接下来�Q�我们将使用Hibernate 来�ؓ领域对象配置持久层和定义对象关系映射。然后，我们��定义和配置我们的业务层。在完成�q�些�l��g后，我们��讨论如何��用Spring��这些层兌��h��。最后，我们��提供一个表现层�Q�它知道如何与业务服务层通信以及如何处理来自于其他层的例外�?/P>

铁手 2005-04-29 11:42 发表评论

狠狠色香婷婷久久亚洲精品,在线观看亚洲精品国产,亚洲码和欧洲码一码二码三码

企业服务�ȝ��(ESB)(7)

2.4.1 从单个项目层面引�?/a> ESB

2.4.2 跨广泛分布的企业传播ESB

企业服务�ȝ��(ESB)(6)

2.3.1 采用XML

2.3.2 采用Web ervices�q�实�?SOA

企业服务�ȝ��(ESB)(5)

2.2企业集成的目前状�?/a>

2.2.2 偶然架构

2.2.2.1 部门和组�l�问�?/a>

2.2.3 ETL�Q�批量传输，�?FTP

2.2.4 集成Broker

企业服务�ȝ��(ESB)(4)

2.1.1 IT开支的���势

2.1.3 法规遵从

2.1.3.1 电讯

2.1.3.3 政府

2.1.3.4 直通处�?/a> (STP)

2.1.3.5 ���频识别标签 (RFID)

企业服务�ȝ��(ESB)(3)

企业服务�ȝ��(ESB)(2)

1.6.11 作�ؓESB�?#8220;原生”数据�c�d��的XML

企业服务�ȝ��(ESB)(1)

1 企业服务�ȝ������?/h3>

RFID的领域应�?

RFID的领域应�?

此Slashdot不是那个Slashdot

EJB 3.0 vs Spring

Vendor Independence

Service Integration

Flexibility in Service Assembly

XML Versus Annotation

Declarative Services

Dependency Injection

Conclusions

�Q�各有所�ѝ��EJB�q�是针对高端�Q�Spring针对低端�Q�中间一部分重合�Q�大家两全其����?/EM>

�q�篇文章在OnJava一���骂壎ͼ��q�是开源的同志们比较多�ѝ��）

Acknowledgments

Struts�U�籍之第2�D�：�W?.7式： 动态��生JavaScript

�W?.7�? 动态��生JavaScript

问题

动作要领

动作变化

相关动作

使用 WebSphere Application Server V6 构徏企业服务�ȝ��

Java �q�_��持久性机制的比较

Java �q�_��持久性机制的比较

骡子力气比马大：一个ESB集成框架CodeHaus Mule

一�U�优雅的���行架构�Q�Struts+Spring+Hibernate (1)

2.1.1 IT开支的��势

2 .1.3.1 电讯

2 .1.3.3 政府

2 .1.3.4 直通处�?/a> (STP)

2 .1.3.5 ��频识别标签 (RFID)

1 企业服务�ȝ��?/h3>

�Q�各有所�ѝ��EJB�q�是针对高端�Q�Spring针对低端�Q�中间一部分重合�Q�大家两全其��?/EM>

�q�篇文章在OnJava一��骂壎ͼ��q�是开源的同志们比较多�ѝ��）

Struts�U�籍之第2�D�：�W?.7式：动态��生JavaScript

一�U�优雅的��行架构�Q�Struts+Spring+Hibernate (1)