JavaEE轻量级解决方案.docx

JavaEE轻量级解决方案.docx

《JavaEE轻量级解决方案.docx》由会员分享，可在线阅读，更多相关《JavaEE轻量级解决方案.docx（12页珍藏版）》请在冰豆网上搜索。

JavaEE轻量级解决方案

Java,EE轻量级解决方案

　　篇一：

ESB解决方案

　　ESB解决方案问题描述

　　在商业激烈竞争的今天，很多企业，特别是大型企业都应用了IT技术来提高企业竞争力，提高公司的运作效率与资源利用率等，而技术的更迭，业务变化等等造成了企业内部多种异构应用软件、平台、系统共存的局面。

这些系统、平台可能使用不同的通信协议，或者是不同格式的数据，互相之间交换数据、通信显然十分困难。

如果企业还需要与外部其他系统交互，则还面临着需要调查其他系统的结构，通信协议等等问题。

这些都是企业系统集成所面临的问题与困境。

　　近年来，也出现了一些解决集成问题的技术，例如EAI（EnterpriseApplicationIntegration），B2B（Business-2-Business），SOA（ServiceOrientedArchitecture）以及WebService，这些解决方案能够解决一些问题，但是往往有以下诟病：

或者有专利保护，需要支付昂贵费用，实现起来耗时费力，或者是一次性定制的，花费成本高，后期难以维护，系统扩展不灵活。

　　什么是ESB

　　ESB全称为EnterpriseServiceBus，即企业服务总线。

它是传统中间件技术与XML、Web服务等技术结合的产物。

ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。

ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。

从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。

　　ESB的五个基本功能：

　　1）服务的MetaData管理：

在总线范畴内对服务的注册命名及寻址管理功能。

　　2）传输服务：

必须确保通过企业总线互连的业务流程间的消息的正确交付，传输还包括基于内容的路由功能。

　　3）中介：

提供位置透明性的服务路由和定位服务；多种消息传递形式；支持广泛使用的传输协议。

　　4）多种服务集成方式：

如JCA，Web服务，Messaging，Adaptor等。

　　5）服务和事件管理支持：

如服务调用的记录、测量和监控数据；提供事件检测、触发和分布功能。

　　ESB的八个扩展功能：

　　1）面向服务的元数据管理：

他必须了解被他中介的两端,即服务的请求以及请求者对服务的要求，以及服务的提供者和他所提供的服务的描述；

　　2）Mediation：

它必须具有某种机制能够完成中介的作用，如协议转换；

　　3）通信：

服务发布、订阅，响应请求，同步异步消息，路由和寻址等；

　　4）集成：

遗留系统适配器，服务编排和映射，协议转换，数据变换，企业应用集成中间件的连续等。

　　5）服务交互：

服务接口定义，服务实现的置换，服务消息模型，服务目录和发现等。

　　6）服务安全：

认证和授权、不可否认和机密性、安全标准的支持等；

　　7）服务质量：

事务，服务的可交付性等；

　　8）服务等级：

性能、可用性等。

　　ESB中最常提到的两个功能是消息转换和消息路由。

解决方案选择

　　方案

　　目前实现了ESB的产品有很多，选取具有代表性的几种为例，如：

　　WebSphereEnterpriseServiceBus（IBM的基于WebSphere的解决方案，基于ServicecomponentArchitecture，SCA，商业产品）；

　　ApacheServiceMix（JavaBusinessIntegration，JBI规范的一种实现，它包涵了许多JBI组件，这些组件支持多种协议，比如JMS,HTTP,FTP,FILE等。

同时也实现了EIP，规则和调度。

早在几年前，它就已经成为了Apache的顶级项目，开源）；

　　Mule（一个基于ESB架构理念的消息平台，它是可升级的、高分布式的对象代理，可以通过异步传输消息技术来无缝的处理服务与应用之间的交互。

目前分开源与商业两个版本）

　　OpenESB（Sun公司支持下的一个开源项目，其核心是基于JBI规范的实现。

OpenESB可运行在Glassfish应用服务中，同时NetbeansIDE也为OpenESB提供了拖拽式的开发工具，这是其他开源ESB不可匹敌的。

）选型

　　考虑到有稳定社区维护的开源产品，如ServiceMix，具有高可靠性与低成本代价两个较大优势，以及在市场上的应用率以及呼声较高，最终将选择对象锁定到ServiceMix与Mule两个产品。

在开源产品中，两者在网络上呼声最高，将两者对比的文章很多。

下面摘选《作者谈开源ESB》一文中的书两位作者TijsRademakers，JosDirksen对两者的对比：

　　InfoQ：

您认为，对于MuleESB和ServiceMix，它们各自的优缺点是什么？

在使用时有何建议？

JD：

二者都有优缺点。

我喜欢ServiceMix的模型，它让热部署新的集成流程变得容易，并且事实上它是基于标准的。

尽管JBI标准没有获得太多的青睐，但它是一个相当不错的规范，当你理解JBI时，它会让你对ServiceMix很容易上手。

我很喜欢有可热插拔的集成组件，特别是它们是可以热部署的。

包含Camel也是ServiceMix的一个亮点。

我真的喜欢可以用DSL去开发集成（来自:

小龙文档网:

Java,EE轻量级解决方案）流程。

ServiceMix的不足之处跟它的优点是有关联的。

JBI规范确实引入了另一个困难级别，对XML的关注并不见得总是适合你在集成领域中遇到的需求。

另一方面，Mule让集成流程的创建变得容易和简单。

它有非常广泛的路由器，易于扩展，并有很多可选的开箱即用的连通性、路由和转换。

使用Mule，使你能够在数分钟内让相当复杂的集成流程启动并运转起来。

然而，Mule也有缺点。

尽管不是很大，但是对我个人而言，它的一个最大的缺点就是没法热部署新的集成流程。

如果Mule集成OSGi或者其他方法，就能很容易的更新集成流程，这将是一个大大的加分点。

　　TJ：

当前，ServiceMix被分成了两个项目，ServiceMix/和ServiceMix4。

我们书中使用ServiceMix（基于JBI），但我们对ServiceMix4（基于OSGi，支持JBI）也有一个简短的介绍。

因此，ServiceMix和MuleESB之间的主要不同点就是，ServiceMix是基于JBI，而MuleESB实现了基于Java的定制模型。

但是这些ESB间还有很多共同点（支持Spring，通过CXF支持Web服务，XML配置）。

但是，让我们着重谈谈不同点。

　　MuleESB是一个以Java为中心的ESB，这让Java开发者能很容易地上手。

它拥有强大的XML模式集合，它们创建了一个真正清洁可读的XML配置并提供了代码补全支持。

当你想实现一项转换逻辑或者路由逻辑时，你能够很轻易地开发出一个简单的Java类/Springbean/脚本文件，把它引入到XML配置中。

如果必须要指出Mule的一个不足之处，那就是缺乏对于热部署的支持。

　　ServiceMix是一个以JBI为中心的ESB，它提供了大量的JBI组件，比如JMS，Web服务，Camel以及BPEL组件。

当然，你也可以使用来自其它基于JBI的ESB的JBI组件，诸如PEtALS和我们书中介绍的OpenESB。

ServiceMix为每个JBI组件都提供了一个简易的XML配置语言，为部署你的集成解决方案提供了热部署功能。

ServiceMix的一个缺点是进入JBI的学习曲线。

因此，问题实际就是：

在Mule和ServiceMix

　　之间，你更愿意选择哪一个？

。

ServiceMix提供了JBI支持，BPEL集成，关注XML消息和热部署功能。

Mule提供了以Java为中心的模型，支持jBPM，支持消息无关，没有热部署功能。

　　JD：

选择使用哪一个，其实取决于你的需求。

当你面临的是关注XML标准的集成场景时，ServiceMix就是个不错的选择。

如果你需要低级别的集成，Mule可能是个好的选择。

这两个ESB都是不错的开源集成解决方案，对于大多数集成问题都能很好地解决。

　　InfoQ：

为什么你们最终选择了ServiceMix和Mule，而不是其他选择？

对ApacheSynapse或者Spring集成（SpringIntegration）有何建议？

　　TJ：

ServiceMix和Mule是活跃社区中成熟开源ESB的绝佳范例，它们代表了基于JBI的ESB和以Java为中心的ESB的方法。

我们还会考虑其他替代方法，ApacheSynapse就是最主要的替代者。

顺便说一句，在本书中，我们已经包含了ApacheSynapse以及Spring集成的例子。

ApacheSynapse是面向Web服务的ESB的典范，它是基于ApacheAxis2的。

当你一门心思想要获得WS-*支持和Rest支持时，Synapse显然是一个你需要考虑的ESB。

我发现Spring集成是个不错的框架，可以跟ApacheCamel相媲美。

它们都对Hohpe和Woolf描述的企业集成模式提供了支持，这样无需单独的集成容器，你就能很轻易地将你的Java应用程序集成进来。

因此，在不需要引入中心ESB容器，在应用程序级别实现集成功能情况下，这些框架非常有用。

　　JD：

我个人没有过多接触Spring集成，为了体验它，我们正在用它做一个很小的项目。

目前为止，我们对它印象还不错。

它是相当轻量级的解决方案，可以轻易地与我们编写的其余Spring应用程序相结合。

在我们开始写这本书时，开源ESB社区还不如现在成熟，而且现在有了更成熟的解决方案。

　　两者各有千秋，我们选取了ServiceMix作为ESB解决方案进行研究，版本。

SERVICEMIX相关SERVICEMIX简介

　　Features

　　ServiceMixislightweightandeasily,hasintegratedandcanberunattheedgeofthenetwork（insideaclientorserver）,asastandaloneESBproviderorasaservicewithinanotherESB.YoucanuseServiceMixinJavaSEoraJavaEEapplicationserver.

　　ServiceMixusestoprovideremoting,clustering,reliabilityanddistributed

　　failover.

　　ServiceMixiscompletelyintegratedinto,whichallowsyoutodeployJBIcomponentsandservicesdirectlyintoGeronimo.ServiceMixisbeingJBIcertifiedaspartoftheGeronimoproject.

　　OtherJ2EEapplicationserversServiceMixhasbeenintegratedwithinclude,withmoretofollow.

　　?

JBIContainer

　　ServiceMixincludesacompleteJBIcontainersupportingallpartsoftheJBIspecificationincluding:

　　NormalizedMessageServiceandRouter

　　JBIManagementMBeans

　　AntTasksformanagementandinstallationofcomponents

　　fullsupportfortheJBIdeploymentunitswithhot-deploymentofJBIcomponents

　　ServiceMixalsoprovidesasimpletouseClientAPIforworkingwithJBIcomponentsandservices.

　　Inaddition,ServiceMixprovidesanimplementationofWSNotification.

　　?

JBIComponents

　　ServiceMixincludesmanyJBIcomponentsincludingHTTP,JMS,BPEL,Rules,andmanymore...

　　以上摘自ApacheServiceMix官方网站的介绍。

JBI消息规范

　　要理解ServiceMix，首先必须弄懂JBI规范。

以下摘自《JBI消息规范-第二部分》。

　　JBI规范-规格化消息路由NMR

（一）

　　规格化消息路由从JBI组件（服务殷勤或绑定组件）接收消息交换ME并将其路由到适当的组件进行处理。

[Thismediatedmessage-exchangeprocessingmodeldecouplesserviceconsumersfromproviders,andallowstheNMRtoperformadditionalprocessingduringthelifetimeofthemessageexchange.]

　　本章中使用

　　中的术语而不是。

　　本节介绍NMR架构中的几个关键概念。

NMR的目标是[ThegoaloftheNMRistoallowcomponentsactingasserviceproducersandconsumerstointeroperatewithoneanotherinapredictablefashion,using

　　篇二：

JavaEE开发四大常用框架

　　JavaEE开发四大常用框架

　　Struts

　　Struts是一个基于SunJ2EE平台的MVC框架，主要是采用Servlet和JSP技术来实现的。

Struts框架可分为以下四个主要部分，其中三个就和MVC模式紧密相关：

　　1、模型（Model），本质上来说在Struts中Model是一个Action类（这个会在后面详细讨论），开发者通过其实现商业逻辑，同时用户请求通过控制器（Controller）向Action的转发过程是基于由文件描述的配置信息的。

　　2、视图（View），View是由与控制器Servlet配合工作的一整套JSP定制标签库构成，利用她们我们可以快速建立应用系统的界面。

　　3、控制器（Controller），本质上是一个Servlet，将客户端请求转发到相应的Action类。

　　4、一堆用来做XML文件解析的工具包，Struts是用XML来描述如何自动产生一些JavaBean的属性的，此外Struts还利用XML来描述在国际化应用中的用户提示信息的（这样一来就实现了应用系统的多语言支持）。

　　Spring

　　Spring是轻量级的J2EE应用程序框架。

　　Spring的核心是个轻量级容器（container），实现了IoC（InversionofControl）模式的容器，Spring的目标是实现一个全方位的整合框架，在Spring框架下实现多个子框架的组合，这些子框架之间彼此可以独立，也可以使用其它的框架方案加以替代，Spring希望提供one-stopshop的框架整合方案。

　　Spring不会特別去提出一些子框架来与现有的OpenSource框架竞争，除非它觉得所提出的框架夠新夠好，例如Spring有自己的MVC框架方案，因为它觉得现有的MVC方案有很多可以改进的地方，但它不强迫您使用它提供的方案，您可以选用您所希望的框架来取代其子框架，例如您仍可以在Spring中整合您的Struts框架。

　　Spring的核心概念是IoC，IoC的抽象概念是「依赖关系的转移」，像是「高层模组不应该依赖低层模组，而是模组都必须依赖于抽象」是IoC的一种表现，「实现必须依赖抽象，而不是抽象依赖实现」也是IoC的一种表现，「应用程序不应依赖于容器，而是容器服务于应用程序」也是IoC的一种表现。

　　Spring的架构性的好处

　　Spring能有效地组织你的中间层对象,无论你是否选择使用了EJB。

如果你仅仅使用了Struts或其他的包含了J2EE特有APIs的framework，你会发现Spring关注了遗留下的问题。

Spring能消除在许多工程上对Singleton的过多使用。

根据我的经验，这是一个主要的问题，它减少了系统的可测试性和面向对象特性。

　　Spring能消除使用各种各样格式的属性定制文件的需要,在整个应用和工程中，可通过一种一致的方法来进行配置。

曾经感到迷惑，一个特定类要查找迷幻般的属性关键字或系统属性,为此不得不读Javadoc乃至源编码吗？

有了Spring，你可很简单地看到类的JavaBean属性。

倒置控制的使用（在下面讨论）帮助完成这种简化。

Spring能通过接口而不是类促进好的编程习惯，减少编程代价到几乎为零。

　　Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs。

在Spring应用中的大多数业务对象没有依赖于Spring。

　　使用Spring构建的应用程序易于单元测试。

　　Spring能使EJB的使用成为一个实现选择,而不是应用架构的必然选择。

你能选择用POJOs或localEJBs来实现业务接口，却不会影响调用代码。

　　Spring帮助你解决许多问题而无需使用EJB。

Spring能提供一种EJB的替换物，它们适于许多web应用。

例如,Spring能使用AOP提供声明性事务而不通过使用EJB容器，如果你仅仅需要与单个的数据库打交道，甚至不需要JTA实现。

　　Spring为数据存取提供了一致的框架,不论是使用JDBC或O/Rmapping产品（如Hibernate）。

　　Spring确实使你能通过最简单可行的解决办法解决你的问题。

这些特性是有很大价值的。

Spring能做什么？

　　Spring提供许多功能,在此我将快速地依次展示其各个主要方面。

　　任务描述：

　　首先,让我们明确Spring范围。

尽管Spring覆盖了许多方面，但我们已经有清楚的概念，它什么应该涉及和什么不应该涉及。

　　Spring的主要目的是使J2EE易用和促进好编程习惯。

　　Spring不重新开发已有的东西。

因此，在Spring中你将发现没有日志记录的包,没有连接池,没有分布事务调度。

这些均有开源项目提供（例如CommonsLogging用来做所有的日志输出，或CommonsDBCP用来作数据连接池）,或由你的应用程序服务器提供。

因为同样的的原因，我们没有提供O/Rmapping层，对此，已有有好的解决办法如Hibernate和JDO。

Spring的目标是使已存在的技术更加易用。

例如,尽管我们没有底层事务协调处理，但我们提供了一个抽象层覆盖了JTA或任何其他的事务策略。

　　Spring没有直接和其他的开源项目竞争，除非我们感到我们能提供新的一些东西。

例如，象许多开发人员，我们从来没有为Struts高兴过，并且感到在MVCwebframework中还有改进的余地。

在某些领域，例如轻量级的IoC容器和AOP框架，Spring有直接的竞争，但是在这些领域还没有已经较为流行的解决方案。

（Spring在这些区域是开路先锋。

）

　　Spring也得益于内在的一致性。

　　所有的开发者都在唱同样的的赞歌,基础想法依然是ExpertOne-on-OneJ2EE设计与开发的那些。

　　并且我们已经能够使用一些主要的概念,例如倒置控制，来处理多个领域。

　　Spring在应用服务器之间是可移植的。

　　当然保证可移植性总是一次挑战，但是我们避免任何特定平台或非标准化,并且支持在WebLogic，Tomcat，Resin，JBoss，WebSphere和其他的应用服务器上的用户。

　　Spring的核心即是个IoC/DI的容器，它可以帮程序设计人员完成组件之间的依赖关系注入，使得组件之间的依赖达到最小，进而提高组件的重用性，Spring是个低侵入性（invasive）的框架，Spring中的组件并不会意识到它正置身于Spring中，这使得组件可以轻易的从框架中脱离，而几乎不用任何的修改，反过来说，组件也可以简单的方式加入至框架中，使得组件甚至框架的整合变得容易。

　　Spring最为人重视的另一方面是支持AOP（Aspect-OrientedProgramming），然而AOP框架只是Spring支持的一个子框架，说Spring框架是AOP框架并不是一件适当的描述，人们对于新奇的AOP关注映射至Spring上，使得人们对于Spring的关注集中在它的AOP框架上，虽然有所误解，但也突显了Spring的另一个令人关注的特色。

　　Spring也提供MVCWeb框架的解決方案，但您也可以将自己所熟悉的MVCWeb框架与Spring解合，像是Struts、Webwork等等，都可以与Spring整合而成为进用于自己的解決方案。

Spring也提供其它方面的整合，像是持久层的整合如JDBC、O/RMapping工具（Hibernate、iBATIS）、事务处理等等，Spring作了对多方面整合的努力，故说Spring是个全方位的应用

　　程序框架。

　　Hibernate

　　Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了轻量级的对象封装，使得Java程序员可以使用对象编程思维来操纵数据库。

Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化。

它还可以应用在任何使用JDBC的场合，既可以在Java的客户端程序实用，也可以在Servlet/JSP的Web应用中使用

　　Hibernate的工作方式

　　Hibernate不会对您造成妨碍，也不会强迫您修改对象的行为方式。

它们不需要实现任何不可思议的接口以便能够持续存在。

惟一需要做的就是创建一份XML“映射文档”，告诉Hibernate您希望能够保存在数据库中的类，以及它们如何关联到该数据库中的表和列，然后就可以要求它以对象的形式获取数据，或者把对象保存为数据。

与其他解决方案相比，它几乎已经很完美了。

　　由于本文只是一篇介绍性的文章，所以不会引入构建和使用Hibernate映射文档的具体例子（我在《Hibernate:

ADeveloper'sNotebook》一书的头几章中已经介绍了一个例子）。

此外，在网上和Hibernate的在线文档中，还可以