1.1 J2EE应用模型
J2EE提供了一个企业级的计算模型和运行环境用于开发和部署多层分布式结构的应用模型。该模型具有重用组件的能力、基于扩展标记语言(XML)的数据交换、统一的安全模式和灵活的事务控制。它通过提供企业计算环境所必需的各种服务，使得部署在J2EE平台上的多层应用，可以实现高可用性、安全性、可扩展性和可靠性。
1.1.1 J2EE框架
目前，Java 2平台有3个版本，它们是适用于小型设备和智能卡的Java 2平台Micro版（Java 2 Platform Micro Edition，J2ME）、适用于桌面系统的Java2平台标准版（Java 2 Platform Standard Edition，J2SE）、适用于创建服务器应用程序和服务的Java2平台企业版（Java 2 Platform EnterpriseEdition，J2EE）。
J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如"编写一次、随处运行"的特性、方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。
1.1.2 多层分布式结构的应用模型
J2EE平台采用一个多层次分布式的应用模式。这意味着应用逻辑根据功能被划分成组件，组成J2EE应用的不同应用组件安装在不同的服务器上，这种划分是根据应用组件属于多层次J2EE环境中的哪一个层次来决定的。图1展示了两个多层次J2EE应用划分成在下面的表中描述的不同层次。图1中表示的J2EE应用部分代表了J2EE应用组件。
• 运行在客户机器上的客户层组件
• 运行在J2EE服务器上的Web层组件
• 运行在J2EE服务器上的业务层组件
• 运行在EIS服务器上的企业信息系统层软件
如图1所示，J2EE应用可以由三或四个层次组成，J2EE多层次应用一般被认为是三层应用，因为它们是被分布在三个不同的地点：客户端机器、J2EE服务器和数据库或后端的传统系统服务器。三层架构应用是对标准的客户端/服务器应用架构的一种扩展，即在客户端应用和后台存储之间增加一个多线程应用服务器。
图1：多层应用
1.3 J2EE架构
通常，瘦客户端多层次应用是很难编写的，因为它包括很多行非常难以理解的代码，以处理交易和状态管理，多线程，资源池管理，以及其他复杂的低层次细节问题。基于组件的、与平台无关的J2EE应用的开发是很容易的，因为业务逻辑被组织成可重复使用的组件，而且J2EE服务器以容器(Container)的形式为每种类型的组件提供后台支持。由于你不必自己开发这些服务，你可以专注于解决你面临的业务问题。
1.3.1 容器（container）和服务
组件在部署时被安装在容器之中，是组件和特定平台底层功能之间的接口支持着组件。在Web，企业Bean或者应用客户端组件能够被执行以前，它必须被组装到J2EE应用里，并且被部署到它的容器里。组装流程包括设定J2EE应用中的每一个组件以及J2EE应用本身在容器之中的设置。容器的设置个性化了J2EE服务器对每个组件的后台支持，包括像安全性、交易管理、Java命名和目录接口查询，以及远程连接等等。这里是一些重点：
• J2EE安全模式，使你能够配置Web组件或企业Bean，使系统资源只能被授权的用户访问。
• J2EE交易模式，使你能够指定方法之间的关系，从而组成一个交易，这样交易中的所有方法将被作为一个单元对待。
• JNDI查询服务，为企业中多种命名和目录服务提供统一的接口，这样应用组件就可以访问命名和目录服务了。
• J2EE远程连接模式，管理客户端和企业Beans之间的底层通讯。在企业Bean被创建后，客户端调用它的方法，就像它在同一个虚拟机上一样。
实际上，J2EE架构提供可配置的服务，意思是在同一个J2EE应用中的应用组件可以根据他们部署的位置不同，表现不同。一个企业Bean可以通过不同的安全设置，是它在一个生产系统中获得一种层次的数据库数据访问，而在另一个生产系统中，则获得另一种数据库访问权限。
容器还管理着不可配置服务，如企业bean和Servlet的生命周期，数据库连接资源池，数据持续性（persistence），以及J2EE API中描述的访问J2EE平台的API。尽管数据持续性机制是一个不可配置服务，J2EE架构允许你在需要比缺省的容器管理的持续性机制更多的控制时，用你的企业Bean实现中的相应的代码覆盖原有的容器管理的持续机制。例如，你可以使用Bean管理的持续性机制来实现你自己的搜索方法，或创建个性化的数据库缓存。
1.3.2 容器类型
在部署过程之中，J2EE应用组件被安装在如下类型的J2EE容器中。本文中涉及的J2EE组件和容器参见图5。
企业JavaBeans(EJB)容器，为J2EE应用管理着所有的企业Beans。企业Bean和它们的容器运行在J2EE服务器上。
Web容器，为J2EE应用管理着所有的JSP页面和Servlet组件。Web组件和它们的容器运行在J2EE服务器上。
应用客户端容器，为J2EE应用管理着所有的应用客户端组件。应用客户端组件和它们的容器运行在客户端机器上。
applet容器，是Web浏览器和Java插件的组合，运行在客户端机器上。
图5：J2EE服务器和容器
1.3.3包装
J2EE组件是单独包装的，为部署而捆绑到J2EE应用中。每个组件，其相关的文件如GIF和HTML文件，或者服务器端应用类，以及部署描述，被集成一个模块并添加到J2EE应用中。J2EE应用是由一个或多个企业Bean，Web，或应用客户端组件模块组成的。最终企业解决方案可以使用一个J2EE应用或根据设计需要由两个或更多的J2EE应用组成。
一个J2EE应用以及它的每一个模块都有它自己的部署描述。部署描述是一个XML文本文件，带有.xml后缀，描述组件的部署设置。一个企业Bean的部署描述，例如，声明交易属性，和企业Bean的安全认证。由于部署描述的信息是可以声明的，这样它可以在无需修改Bean的源代码的情况下，进行修改。在运行时，J2EE服务器读取部署描述，并依次对组件进行操作。
J2EE应用以及相关的模块是在一个Enterprise Archive(EAR)中发送的。EAR文件是一个标准的JAR文件，以.ear后缀结尾。在GUI版的J2EE SDK应用部署工具集中，你先创建一个EAR文件，在添加JAR和WAR到EAR中。如果你使用命令行打包工具，则先创建JAR和WAR文件，然后创建EAR文件。J2EE SDK工具：
• 每个EJB JAR文件包含它的部署描述，相关文件和企业Bean的.class文件
• 每个应用客户端JAR包含它的部署描述，相关文件和应用客户端的.class文件
• 每个WAR文件包含它的部署描述，相关文件和servlet的.class文件以及JSP页面的.jsp文件
使用模块和EAR文件使使用一些相同的组件组装多个不同的J2EE应用成为可能。无需额外的编程，只是把不同的J2EE模块组装到J2EE EAR文件中。
1.4 J2EE API
Java 2平台标准版（J2SE）SDK在运行J2EE SDK时是必需的，它为编写J2EE组件提供核心API，核心开发工具，以及Java虚拟机。下面介绍科研管理系统中所涉及到的API。
1.4.1 企业JavaBeans技术 2.0
一个企业Bean是一段包含域和方法的代码体，用于实现业务逻辑的一个模块。你可以认为企业Bean是一个构建模块，可以单独使用或与其他企业Beans一起在J2EE服务器上执行业务逻辑。
由三种类型的企业Bean：Session Bean，实体Beans，和消息驱动Beans，这些在业务组件中描述过。有了实体Beans，你无需编写任何SQL代码或直接使用JDBC API执行数据库访问操作。EJB容器替你处理这些。当然，如果你不管因为任何原因，覆盖了却省的容器管理持续性机制，你将需要使用JDBC API。同样，如果你选用Session Beans访问数据库，你必须使用JDBC API。
1.4.2 JDBC 2.0 API
JDBC是为java语言定义的一个SQL调用级（CLI）界面，也就是说其中心在于执行基本的SQL声明和取回结果。在此基础上可以定义更高层次的API，其中的接口包括直接将基本表与JAVA中的类相对应，提供更多的通用查询的语义树表示，以及JAVA语言的嵌入式SQL语法等。
1.4.3 Java Servlet技术2.3
Java Servlet技术为你定义HTTP专用的servlet类。一个Servlet类扩展了服务器的能力，这个服务器存放着应用，而应用是以请求-响应编程模式被访问的。尽管Servlet可以响应任意形式的请求，但是它通常被用于扩展Web服务器存放的应用。
1.4.4 JavaServer Pages(JSP)技术 1.2
JSP页面技术是你能够在基于文本的文件中结合小段的Java编程语言代码和静态内容。一个JSP页面是一个基于文本的文件，它包含两种类型的文本：静态模板数据，它可以表示为任何基于文本的格式，如HTML、WML和XML；JSP元素，决定这个页面如何构造动态内容。
1.4.5 JavaMail技术1.2
很多互联网应用需要发送邮件进行确认，所以J2EE平台包含了与JavaMail服务提供商配合使用的JavaMail API，这样，应用组件可以使用它发送邮件。JavaMail API包含两个部分：一个是应用层接口，应用组件使用它发送邮件；一个服务提供商接口。
1.5 MVC设计模式
MVC设计模式起源于Smalltalk语言，它由以下三个部分组成：模型（model）,视图（view），控制器（Controller）。
Model ： 模型指的是真正完成任务的代码，包含应用系统的核心功能表示一个应用系统的数据，并且包含访问、维护和管理这些数据的逻辑。所有属于应用系统持久状态的数据都应该保存于模型对象里。模型提供的服务必须足够适用于不同的终端。一个模型聚集了相关的数据和操作，以提供一个详细而精确的服务;这些被封装在操作中的抽象事物的功能被模型化。一个模型的接口提供了访问和更新模型状态，执行封装在模型中的复杂进程的方法。模型服务被控制器访问，用于查询或更改模型的状态。当模型状态发生变化时，模型会通报给视图。对大多数Web应用程序而言，功能比界面感觉更重要。在模型同界面分离的情况下，代码即可实现可管理性和可重用性。例如，在一个保险应用程序中，模型就是处理计算保险费和同数据库交互的那些业务代码。模型通常也被称作业务逻辑。
View: 视图表示模型的状态，是应用系统的外观，当模型发生改变时，视图也将随之改变，以维持系统数据的一致性。在MVC模式下，通常的设计前提是界面任务较小。当然视图也应该具有一定的功能性并遵守可用性的约束，但视图界面不应当处理数据。事实上，视图的每一部分都只能包含采集数据的逻辑，并把采集到的数据传递给设计模式中的其他组成部分进行处理。
Controller:控制器是联系模型与视图之间的纽带，控制模型和视图之间的交互过程。它获取并翻译用户输入的动作，指定执行该动作的模型，或者根据用户的输入和执行的结果来选择下一个视图。
MVC通过建立一个“订购/通知”协议来分离视图和模型。视图必须保证它的显示正确地反映了模型的状态。一旦模型的数据发生变化，模型将通知有关的视图，每个视图相应地得到刷新自己的机会。这种方法可以让一个模型提供不同的多个视图表现形式，也能够为一个模型创建新的视图而无须重写模型。
1.5.1 MVC的优点
(1) 因为视图与模型分离，而且模型与视图之间没有直接依赖性，所以用户界面可以同时显示同一数据的多个视图。例如，Web应用程序中的多个页面可以使用同一模型对象。变化一传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。
(2)视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。
(3)模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。
(4) 潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。
1.5.2 MVC的缺点
(1)增加了系统结构和实现的复杂性。MVC模式引入了新的间接级别，因此稍微增加了解决方案的复杂性。它还增加了用户界面代码的事件驱动特性，调试用户界面代码会变得更加困难。
(2) 视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
(3)视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据.对未变化数据的不必要的频繁访问，也将损害操作性能。
(4)频繁更新的成本。将模型与视图分离并不意味着模型的开发人员可以忽略视图的特性。例如，如果模型发生频繁更改，则它可能向视图发出大量更新请求。一些视图(如图形显示)的显示可能需要一定时间。因此，视图可能滞后于更新请求。因此，在对模型进行编码时牢记视图是很重要的。例如，模型可以将多个更新作为单个通知发送到视图。
模型
查询状态
向视图通知模型 在模型的公共
状态中的改变 API中调用方法
视图 选择视图 控制器
用户动作/命令
方法调用
事件
图6 MVC的体系结构
1.6 Struts对MVC实现
模型（The Model）
Struts框架没有提供特定的模型组件。
视图（The View）
Struts框架中视图组件对应于一个简单的JSP文件，这个JSP文件包含了Struts定义的标签，几个JSP的标签是JSP文件中的重点。这些标签在Struts框架中定义，它使struts应用项目和控制器之间实现松耦合。
控制器（The Controller）
控制器是Struts框架中的中枢，它由org.apache.struts.action.ActionServlet这个servlet来贯彻和执行的。这个org.apache.struts.action.ActionServlet接收所有客户端的请求，并把请求委派到指定的Action类(用户扩展自org.apache.struts.action)。ActionServlet委派请求是基于客户端传入的URI。一旦Action类完成处理，ActionServlet根据Action返回的键值来决定在什么视图中显示Action的类处理结果。ActionServlet类似于一个创建Action对象的工厂，由Action对象去执行应用中实际的业务逻辑。控制器是Struts框架中最重要的部分。
[1] [2]
责任编辑 webmaster
发表评论 
打印本文
推荐本文
加入收藏
返回顶部
关闭窗口
