J2EE——J2EE的十三种技术

J2EE——J2EE的⼗三种技术
引⾔
J2EE的⼗三种技术在⽹上⼀搜多的是，⽐如附录中的那篇⽂档就已经涵盖的很全了，但是作为应⽤级开发者并不⼀定要对这⼗三种技术都掌握，⽽且这⼗三种技术中哪些重要哪些不重要也存在⼀定的区别，所以我对⼀些重要的技术提炼出来放在概要⾥，⽅便读者快速掌握，⽽且学习也好有偏重
概要
这个也可以作为学习Java的路线，其实Java主要的技术包括Java基础部分，也就是⾯向对象，集合，界⾯，线程，⽂件以及⽹络；以及往⽹页⽅⾯⾛的JSP，Servlet，JS，其实如果读者接触过JSP和Servlet，就知道他们俩其实是⼀个东西，jsp其实最终也是会翻译成servlet，⼀个jsp会对应⼀个class；与数据库打交道的JDBC，Oracle；最后可以加上⼀个SSH，三⼤框架，⽤的还⽐较多
除了上⾯说的常⽤的之后还有⼀些不常⽤的，⽐如JNDI，Java命名和⽬录接⼝，这个我们实际上⼀般只是⽤它，往往都不会⾃⼰去开发，感觉并不算重点
另外EJB，企业级Java Bean，跟Hibernate很像，但有逐渐被Hibernate淘汰的趋势，其实这些技术都是存在⼀个演化过程，在原有的技术基础上改良⽽得，后⾯的SSH框架以及其他框架都是如此，针对某⼀⽅⾯的改良。

Java事务这块的技术，JTA和JTS，JTA是事务体系，JTS是事务服务，这个也是很底层的东西，应⽤级开发⽤的⽐较少，应⽤开发者⼀般只管⽤就⾏了
附录
J2EE的⼗三种技术（规范）
Java数据库连接（JDBC）
JDBC API以⼀个统⼀的⽅式访问各种数据库。

与ODBC类似，JDBC将开发者和私有数据库之间的问题隔离开来。

由于它建⽴在Java上，因此JDBC可以提供平台⽆关的数据库访问。

JDBC定义了4种不同的驱动，具体来说，包括有：
类型1：JDBC-ODBC桥
在JDBC刚产⽣时，JDBC-ODBC桥是⾮常有⽤的。

通过它，开发者可以使⽤JDBC来访问⼀个ODBC数据源。

缺点是，它需要在客户机器上安装有⼀个ODBC驱动，该机器通常是应该运⾏微软Windows系统的。

使⽤这⼀类的驱动器，你就会失去JDBC平台⽆关的好处。

此外，ODBV驱动器需要客户端的管理。

类型2：JDBC-native驱动桥
JDBC-native驱动桥提供了⼀个建筑在本地数据库驱动上的JDBC接⼝--没有使⽤ODBC。

JDBC驱动将标准
的JDBC调⽤转变为对数据库API的本地调⽤。

使⽤类型2的驱动也会失去JDBC平台⽆关性的好处，并且需要安装客户
端的本地代码。

类型3：JDBC-network桥
JDBC-network桥不需要客户端的数据库驱动。

它们使⽤⽹络-服务器中层来访问⼀个数据库。

这会引出诸如负载均衡、连接池等技术，数据缓冲也是可能的。

由于类型3的驱动通常可带来相对⼩的下载时间，它是平台⽆关的，并且不需要客户端的安装和管理，因此很适合⽤作Internet的应⽤。

类型4：纯Java驱动
类型4使⽤纯Java数据库驱动来提供直接的数据库访问。

由于类型4驱动运⾏在客户端，并且直接访问数据库，因此运⾏在这个模式暗⽰要使⽤⼀个两层的体系。

要在⼀个n层的体系中使⽤类型4的驱动，可以通过⼀个包含有数据访问代码的EJB，并且让该EJB为它的客户提供⼀个数据库⽆关的服务。

Java命名和⽬录接⼝（Java Naming and Directory Interface，JNDI）
JNDI是Java Naming and Directory Interface 的简写，中意为：Java命名及⽬录接⼝，它是为了对⾼级⽹络应⽤开发中的使⽤的⽬录基础结构的访问。

实际上这个⽬录是⼀个特殊的数据库，提供了对存储数据的快速访问，不象传统的⽬录服务访问⽅式-你必须提供不同的API接⼝去访问不同的⽬录服务（如：LDAP，NIS，ADS等），⽽它提供了⼀种标准的API来访问类型不同的⽬录。

据说，使⽤完整的SDK可以开发那些JNDI还不⽀持的⽬录服务提供者。

JNDI是J2EE的⼀个API，提供了⼀套标准的接⼝，以定位⽤户、机器、⽹络、对象、以及服务。

例如，你可以使
⽤JNDI来定位内部⽹中的⼀台打印机，你也可以使⽤它来定位Java对象或连接到⼀个数据库。

JNDI可以⽤
于EJB、RMI-IIOP、JDBC中。

它是⽹络查找定位的标准⽅法。

JNDI API被⽤来访问命名和⽬录服务。

它提供⼀个相容的模式来访问和操作企业范围⼤的资源，例如⼀个应⽤服务器中的DNS、LDAP、本地⽂件系统或者对象。

在JNDI中，⼀个⽬录结构中的每⼀个节点被称为context。

每⼀个JNDI的名字都是与⼀个context相对的，没有⼀个绝对名字的概念。

⼀个应⽤可以使⽤InitialContext类来得到它的第⼀个context：
Context ctx = new InitialContext();
通过这个初始的context，应⽤就可以经过⽬录树定位到需要的资源或者对象。

例如，假定你已经在WebLogic Server中配置了⼀个EJB，并且在myApp.myEJB中绑定了home接⼝。

EJB的客户端，在得到这样⼀个初始
的context后，然后就可以使⽤以下的代码来定位到home接⼝：
MyEJBHome home = ctx.lookup( "myApp.myEJB" );
⼀旦你得到你所需对象的⼀个引⽤--在这个例⼦中，就是EJB的home接⼝--然后你可以调⽤它上⾯的⽅法。

为了在⼀个context中查找到⼀个对象，JNDI还提供⽅法可以做到：
插⼊或者绑定⼀个对象到⼀个context中。

在你配置⼀个EJB时，这是⾮常有效的⽅法；
从⼀个context中移去⼀个对象
列出⼀个context中的所有对象
创建和删除subcontexts
企业Java Beans（Enterprise Java Beans，EJB）
J2EE其中⼀个引⼈注⽬的技术是EJB。

它提供了⼀个架构来开发和配置到客户端的分布式商业逻辑，因此可以明显减少开发扩展性、⾼度复杂企业应⽤的难度。

EJB规范定义了EJB组件应该如何及何时与它们的容器交互。

由容器来负责提供普通的服务，例如⽬录服务、事务管理、安全、资源池和容错。

EJB规范定义了三类基本的bean：
会话beans（session beans）：会话beans为业务流程建模，由于他们通常表⽰执⾏某个动作，因此可以把它们当作是动词。

这个执⾏的动作可以是任何事情，例如增加数量，访问数据库，调⽤其它系统，调⽤其它企业Bean。

我们可
以举出很多的例⼦，包括⼀个计价引擎，⼀个⼯作流引擎，⼀个⽬录引擎，⼀个信⽤卡认证中⼼，或⼀个⽹上证券交易引擎。

实体beans（Entity beans）：这是持久保存数据的代表--典型的是存储在数据库中--因此在服务器崩溃后数据仍然存在。

多个客户端可以使⽤EJB来表⽰同样的数据。

实体beans为企业数据建模，由于它们表⽰数据对象（就是缓存数据库信息的Java对象），因此可以把它们当作名词。

实体beans的例⼦包括⼀种产品，⼀项订单，⼀个雇员，⼀张信⽤卡，或⼀⽀股票。

会话beans典型的⽅式是通过实体beans来实现业务⽬标的，例如⼀个证券交易引擎（会
话beans）处理股票（实体beans）。

Message-Driven beans：Message-Driven beans也表⽰动作，这⼀点上它类似于会话beans。

它们之间的不同点在于你只能够通过发送消息给Message-Driven beans的⽅式来调⽤它们。

Message-Driven beans的例⼦包括了接受股票交易消息的beans，信⽤认证消息，或⼯作流消息。

这些Message-Driven beans也可以调⽤其它的企业beans。

接着，我们讨论⽆状态和有状态
⽆状态的beans（Stateless beans）：这是⼀个单⼀使⽤的服务，不维护任何的状态，在服务器崩溃时也不再存在，⽽且⽣存期也相对地短。

例如，⼀个⽆状态的session bean可能⽤作执⾏温度转换。

有状态的bean：它提供了⼀个传统的与客户端交互的⽅法，存储客户端的状态。

在线购物车就是这样⼀个有状
态session ean的典型例⼦。

有状态session beans在服务器崩溃时也不再存在，⽽且⽣存期也相对地短，并且每个实例只可以⽤在⼀个单⼀的线程中。

JavaServer Pages (JSPs)
或许你已经对微软的Active Server Pages (ASPs)⾮常熟悉；JSP也是类似的技术，不过它是平台⽆关的。

它们都是设计来帮助web内容开发者使⽤相对较少的代码就可以创建动态的⽹页。

web设计者即使不懂得编程，也可以使⽤JSP来创建动态的⽹页。

JavaServer Page是HTML代码和Java代码的混合。

在客户请求页⾯的时候，服务器就会处理Java代码，然后返回HTML页⾯给浏览器。

你可以也听过JHTML，它是⼀个旧的标准，现在已经被JSP取代了。

WebLogic Server不但⽀持JSP，还⽀
持JHTML。

不过，在默认设置下，WebLogic Server是不⽀持JSP的（对于5.1版本）。

你必须编
辑weblogic.properties来激活web服务器，对于JSPServlet来说，也是这样。

Java servlets
servlets提供的功能⼤部分JSP相同，它采⽤的是⼀个有点不同的⽅法。

JSP中⼤部分是HTML代码，其中只有少量的Java代码，⽽servlets则相反，它完全使⽤Java编写，并且产⽣HTML代码。

servlet是⼀个在服务器上运⾏的Java⼩程序，它可以扩展Web服务器的功能。

这些服务器端的应⽤可以在被请求时动态执⾏，与传统Web服务器上的CGI Perl脚本差不多。

CGI脚本和servlet的⼀个主要不同是：CGI脚本对于每次请求都启动⼀个全新的进程--需要额外的系统开销--⽽servlet的执⾏只要在servlet引擎内启动⼀个独⽴的线程就性了。

因此Servlet的扩展性也更好。

在开发servlet时，你通常都要扩展javax.servlet.http.HttpServlet类，并且覆盖它的⼀些⽅法。

感兴趣的⽅法包括有：
service(): 作为command-specific⽅法的⼀个调度程序
doGet(): 处理来⾃⼀个客户的HTTP GET请求
doPost(): 处理来⾃⼀个客户的HTTP POST请求
还有⼀些其它的⽅法来处理不同类型的HTTP请求--可参考HttpServlet API的⽂本来得到更多相关的信息。

Java IDL/CORBA
通过Java的IDL⽀持，开发者可以将Java与CORBA集成。

他们可以创建能配置在⼀个CORBA ORB中的Java对象，也可以创建作为配置在其它ORB内的CORBA对象客户端的Java类。

对于通过Java将你的新应⽤和以前的系统集成，后者提供了⼀个另外的⽅法。

Java事务体系（JTA）/Java事务服务（JTS）
JTA定义了⼀个标准的API，应⽤可以通过它来访问事务监控器。

JTS是CORBA OTS事务监控器的⼀个基本实现。

JTS指定了⼀个事务管理器的实现（Transaction Manager），这个管理器在⼀个⾼级别上⽀持Java事务API（JTA）规范，并且在⼀个低级别上实现了OMG OTS规范的Java映射。

⼀个JTS事务管理器为应⽤服务器、资源管理器、standalone应⽤和通信资源管理器提供事务服务。

JavaMail和JavaBeans激活架构（JavaBeans Activation Framework，JAF）
JavaMail是⼀个⽤来访问邮件服务器的API。

JavaMail API提供了⼀套抽象类来模型化⼀个邮件系统。

⽀
持SMTP和IMAP服务器。

JavaMail通过使⽤JavaBeans Activation Framework (JAF) 来处理MIME加密的邮件附件。

MIME字节流
和Java对象间可以互相转化。

⼤多数的应⽤⽆需要直接使⽤JAF。

Java信使服务（Java Messaging Service，JMS）
JMS是⼀个⽤来和⾯向信息的中层通信的API。

它不但⽀持点对点的域，也⽀持发布/订阅域，并且提供对担保信息传送、事务信息传送、持久信息和durable subscribers的⽀持。

对于将你的应⽤和以前的backend系统集
成，JMS提供了另外⼀个⽅法。

扩展标记语⾔（Extensible Markup Language，XML）
Struts+Spring+Hibernate（ssh）。