chenweicai

　　答：规范内容包括Bean提供者，应用程序装配者，EJB容器，EJB配置工具，EJB服务提供者，系统管理员。这里面，EJB容器是EJB之所以能够运行的核心。EJB容器管理着EJB的创建，撤消，激活，去活，与数据库的连接等等重要的核心工作。JSP,Servlet,EJB,JNDI,JDBC,JMS.....

　　2、EJB与JAVA BEAN的区别?

　　答：Java Bean 是可复用的组件，对Java Bean并没有严格的规范，理论上讲，任何一个Java类都可以是一个Bean。但通常情况下，由于Java Bean是被容器所创建(如Tomcat)的，所以Java Bean应具有一个无参的构造器，另外，通常Java Bean还要实现Serializable接口用于实现Bean的持久性。Java Bean实际上相当于微软COM模型中的本地进程内COM组件，它是不能被跨进程访问的。Enterprise Java Bean 相当于DCOM，即分布式组件。它是基于Java的远程方法调用(RMI)技术的，所以EJB可以被远程访问(跨进程、跨计算机)。但EJB必须被布署在诸如Webspere、WebLogic这样的容器中，EJB客户从不直接访问真正的EJB组件，而是通过其容器访问。EJB容器是EJB组件的代理，EJB组件由容器所创建和管理。客户通过容器来访问真正的EJB组件。

　　2、EJB是基于哪些技术实现的?并说出SessionBean和EntityBean的区别，StatefulBean和StatelessBean的区别。

　　答：EJB包括Session Bean、Entity Bean、Message Driven Bean，基于JNDI、RMI、JAT等技术实现。

　　SessionBean在J2EE应用程序中被用来完成一些服务器端的业务操作，例如访问数据库、调用其他EJB组件。EntityBean被用来代表应用系统中用到的数据。

　　对于客户机，SessionBean是一种非持久性对象，它实现某些在服务器上运行的业务逻辑。

　　对于客户机，EntityBean是一种持久性对象，它代表一个存储在持久性存储器中的实体的对象视图，或是一个由现有企业应用程序实现的实体。

　　Session Bean 还可以再细分为 Stateful Session Bean 与 Stateless Session Bean ，这两种的 Session Bean都可以将系统逻辑放在 method之中执行，不同的是 Stateful Session Bean 可以记录呼叫者的状态，因此通常来说，一个使用者会有一个相对应的 Stateful Session Bean 的实体。Stateless Session Bean 虽然也是逻辑组件，但是他却不负责记录使用者状态，也就是说当使用者呼叫 Stateless Session Bean 的时候，EJB Container 并不会找寻特定的 Stateless Session Bean 的实体来执行这个 method。换言之，很可能数个使用者在执行某个 Stateless Session Bean 的 methods 时，会是同一个 Bean 的 Instance 在执行。从内存方面来看， Stateful Session Bean 与 Stateless Session Bean 比较， Stateful Session Bean 会消耗 J2EE Server 较多的内存，然而 Stateful Session Bean 的优势却在于他可以维持使用者的状态。

　　3、EJB与JAVA BEAN的区别?

　　答：Java Bean 是可复用的组件，对Java Bean并没有严格的规范，理论上讲，任何一个Java类都可以是一个Bean。但通常情况下，由于Java Bean是被容器所创建(如Tomcat)的，所以Java Bean应具有一个无参的构造器，另外，通常Java Bean还要实现Serializable接口用于实现Bean的持久性。Java Bean实际上相当于微软COM模型中的本地进程内COM组件，它是不能被跨进程访问的。Enterprise Java Bean 相当于DCOM，即分布式组件。它是基于Java的远程方法调用(RMI)技术的，所以EJB可以被远程访问(跨进程、跨计算机)。但EJB必须被布署在诸如Webspere、WebLogic这样的容器中，EJB客户从不直接访问真正的EJB组件，而是通过其容器访问。EJB容器是EJB组件的代理，EJB组件由容器所创建和管理。客户通过容器来访问真正的EJB组件。

　　EJB包括(SessionBean,EntityBean)说出他们的生命周期，及如何管理事务的?

　　SessionBean：Stateless Session Bean 的生命周期是由容器决定的，当客户机发出请求要建立一个Bean的实例时，EJB容器不一定要创建一个新的Bean的实例供客户机调用，而是随便找一个现有的实例提供给客户机。当客户机第一次调用一个Stateful Session Bean 时，容器必须立即在服务器中创建一个新的Bean实例，并关联到客户机上，以后此客户机调用Stateful Session Bean 的方法时容器会把调用分派到与此客户机相关联的Bean实例。

　　EntityBean：Entity Beans能存活相对较长的时间，并且状态是持续的。只要数据库中的数据存在，Entity beans就一直存活。而不是按照应用程序或者服务进程来说的。即使EJB容器崩溃了，Entity beans也是存活的。Entity Beans生命周期能够被容器或者 Beans自己管理。

　　EJB通过以下技术管理实务：对象管理组织(OMG)的对象实务服务(OTS)，Sun Microsystems的Transaction Service(JTS)、Java Transaction API(JTA)，开发组(X/Open)的XA接口。

　　4、EJB的角色和三个对象

　　答：一个完整的基于EJB的分布式计算结构由六个角色组成，这六个角色可以由不同的开发商提供，每个角色所作的工作必须遵循Sun公司提供的EJB规范，以保证彼此之间的兼容性。这六个角色分别是EJB组件开发者(Enterprise Bean Provider) 、应用组合者(Application Assembler)、部署者(Deployer)、EJB 服务器提供者(EJB Server Provider)、EJB 容器提供者(EJB Container Provider)、系统管理员(System Administrator)

　　三个对象是Remote(Local)接口、Home(LocalHome)接口，Bean类
5、EJB容器提供的服务

　　答：主要提供声明周期管理、代码产生、持续性管理、安全、事务管理、锁和并发行管理等服务。

　　6、EJB规范规定EJB中禁止的操作有哪些?

　　答：1.不能操作线程和线程API(线程API指非线程对象的方法如notify,wait等)，2.不能操作awt，3.不能实现服务器功能，4.不能对静态属生存取，5.不能使用IO操作直接存取文件系统，6.不能加载本地库.，7.不能将this作为变量和返回，8.不能循环调用。

　　7、remote接口和home接口主要作用

　　答：remote接口定义了业务方法，用于EJB客户端调用业务方法。

　　home接口是EJB工厂用于创建和移除查找EJB实例

　　8、bean 实例的生命周期

　　答：对于Stateless Session Bean、Entity Bean、Message Driven Bean一般存在缓冲池管理，而对于Entity Bean和Statefull Session Bean存在Cache管理，通常包含创建实例，设置上下文、创建EJB Object(create)、业务方法调用、remove等过程，对于存在缓冲池管理的Bean，在create之后实例并不从内存清除，而是采用缓冲池调度机制不断重用实例，而对于存在Cache管理的Bean则通过激活和去激活机制保持Bean的状态并限制内存中实例数量。

　　9、EJB的激活机制

　　答：以Stateful Session Bean 为例：其Cache大小决定了内存中可以同时存在的Bean实例的数量，根据MRU或NRU算法，实例在激活和去激活状态之间迁移，激活机制是当客户端调用某个EJB实例业务方法时，如果对应EJB Object发现自己没有绑定对应的Bean实例则从其去激活Bean存储中(通过序列化机制存储实例)回复(激活)此实例。状态变迁前会调用对应的ejbActive和ejbPassivate方法。

　　10、EJB的几种类型

　　答：会话(Session)Bean ，实体(Entity)Bean 消息驱动的(Message Driven)Bean

　　会话Bean又可分为有状态(Stateful)和无状态(Stateless)两种

　　实体Bean可分为Bean管理的持续性(BMP)和容器管理的持续性(CMP)两种

　　11、客服端调用EJB对象的几个基本步骤

　　答：设置JNDI服务工厂以及JNDI服务地址系统属性，查找Home接口，从Home接口调用Create方法创建Remote接口，通过Remote接口调用其业务方法

  bin                   启动和关闭JBoss的脚本
  client                客户端与JBoss通信所需的的Java库（JARs）
  docs                  配置的样本文件（数据库配置等）
  doc/dtd               在JBoss中使用的各种XML文件的DTD。
  lib                   一些JAR，JBoss启动时加载，且被所有JBoss配置共享。（不要把你的库放在这里）
  server                各种JBoss配置。每个配置必须放在不同的子目录。子目录的名字表示配置的名字。JBoss包含3个默认的配置：minimial，default和all。
  server/all            JBoss的完全配置，启动所有服务，包括集群和IIOP。
  server/default        JBoss的默认配置。在没有在JBoss命令航中指定配置名称时使用。
  server/default/conf   JBoss的配置文件。
  server/default/data   JBoss的数据库文件。比如，嵌入的数据库，或者JBossMQ。
  server/default/deploy JBoss的热部署目录。放到这里的任何文件或目录会被JBoss自动部署EJB、WAR、EAR，甚至服务。
  server/default/lib    一些JAR，JBoss在启动特定配置时加载他们。 (all和minimial配置也包含这个和下面两个目录。）
  server/default/log    JBoss的日志文件。
  server/default/tmp    JBoss的临时文件。

启动时可用-c参数指定要启动的配置：run.bat -c config-name

三个基本class
EJB最少也需要三个class, remote interface, home interface, and bean implementation(bean行为).

1. remote interface 用来揭示EJB对外的一些方法.在这个例子中,the remote interface 就是org.jboss.docs.interest.Interest.

2.home interface 是用来规定怎样创建一个实现remote interface的bean. 在本例中home interface 是 org.jboss.docs.InterestHome.

3.bean implementation 是提供方法的实现,这些方法在上述两种interface中都有规定了,在本例中是两个方法: calculateCompoundInterest和create().

这个bean implementation 是 org.jboss.docs.interest.InterestBean.

这些classes必须打包进一个JAR文件中,JAR文件中包含了目录结构和包的层次.在本例中,这些classes是在包org.jboss.docs.interest, 这样他们需要在目录org/jboss/docs/interest/ 下.

部署发布描述器ejb-jar.xml和jboss.xml
在JAR文档创建之前,还需要一个叫META-INF的目录,这是存放部署发布描述器的(一般叫ejb-jar.xml).大部分商用EJB Server提供图形化工具来编辑这个 描述器.在JBoss中需要手工:

在本例中,一个包中只有一个EJB 这样就不用描述多个EJB之间是怎样交互的.

尽管对于所有的EJB服务器,ejb-jar.xml部署描述器的格式是一样的(更多精确的定义可以从sun得到DTD).它并没有规定所有的必须的信息,比如如何将EJB-NAME和JNDI naming service联系起来.

缺省情况下,JNDI name将使用在ejb-jar.xml中<ejb-name>XXX</ejb-name>中的XXX来使用EJB的home interface.

但是如果有多个EJB,在ejb-jar.xml中,在<ejb-name>XXX</ejb-name>中XXX就不能用同一个名字了,一般格式是"[application name]/[bean name]".

那么如果再按照缺省情况,JNDI name就可能找不到你的应用程序的入口了,因此我们要特别规定一下.这就需要在jboss.xml中规定:

这样,你所有叫Interest文件都被梆定到JNDI name:interest/Interest下面

jndi.properties
虽然有了上面你的应用程序和JNDI name的梆定,但是一旦部署发布到JBoss服务器上,你还需要一个jndi.properties文件,以告诉调用你程序的客户端请求到哪里去初始化JNDI naming service.

在本例中,客户端请求将寻找Interest 这个bean, 然后得到这个bean的home interface. home interface是用来得到这个bean的remote interface.最后,客户端请求将通过remote interface来使用由EJB提供的功能.

greet
  +-- Greet.java
  +-- GreetHome.java
  +-- GreetBean.java
META-INF
  +-- ejb-jar.xml
  +-- jboss.xml

package greet;
import javax.ejb.EJBObject;
import java.rmi.RemoteException;
/**
 * 这个接口为‘Greet’定义了远程接口
public interface Greet extends EJBObject 
{
    public double calculateMagic(double seed) throws RemoteException;
}

package greet;
import java.io.Serializable;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
public interface GreetHome extends EJBHome 
{
 Greet create() throws RemoteException, CreateException;
}

package greet;
import java.rmi.RemoteException; 
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
public class GreetBean implements SessionBean 
{
 public double calculateMagic(double seed) {
  System.out.println ("Someone called `calculateMagic!'");
return seed * Math.random();
 }
 public GreetBean() {}
public void ejbCreate() {
 System.out.println("Create Greet EJB.");
}
public void ejbRemove() {
 System.out.println("Remove Greet EJB.");
}
public void ejbActivate() {
 System.out.println("Activate Greet EJB");
}
 public void ejbPassivate() {
  System.out.println("Passivate Greet EJB");
 }
/**
* Set context for `Greet' EJB
*/
 public void setSessionContext(SessionContext sc) {
  System.out.println("Set context for Greet EJB");
 }
}

javac *.java -classpath \
/usr/jb_tom/jboss/lib/ext/jboss-j2ee.jar:.

根据EJB规范，要想将EJB成功地部署到EJB服务器上，必须为EJB服务器提供相应的部署描述符。部署描述符对所要部署的EJB进行了说明，包括该EJB的远程描述符、本地描述符和Bean类等信息。由于EJB服务器只有在获得这些基本信息后才能正确完成EJB的部署，因此编写EJB描述符是开发EJB时必不可少的一个环节。

对于不同的EJB服务器来说，部署同一EJB时所需的部署描述符可能并不相同。在JBoss平台上，任何将要被部署的EJB都必须提供ejb-jar.xml和jboss.xml两个文件，这两个文件均位于JAR包中的META-INF目录下，用于对将要部署的EJB进行简要的说明。

ejb-jar.xml

ejb-jar.xml是EJB规范定义的标准部署描述符，在任何EJB服务器上部署EJB时都需要用到该部署描述符。本例中用到的ejb-jar.xml代码如下所示：

<?xml version="1.0" encoding="Cp1252"?> <ejb-jar> <description>jBoss test application </description> <display-name>Test</display-name> <enterprise-beans> <session> <ejb-name>GreetEJB</ejb-name> <home>greet.GreetHome</home> <remote>greet.Greet</remote> <ejb-class>greet.GreetBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Bean</transaction-type> </session> </enterprise-beans> </ejb-jar>

jboss.xml

虽然ejb-jar.xml对所有的EJB服务器都是通用的，但它并没有为EJB服务器提供将要被部署的EJB的全部信息。为了能够对EJB的部署进行更灵活的控制，大部分EJB服务器都要求EJB开发者同时提供另外一个文件来对将要部署的EJB进行描述，在JBoss中该文件为jboss.xml，它也位于JAR包中的META-INF目录中。jboss.xml中可以对EJB对应的JNDI名字以及相应的持久性进行说明，在本例中用到的jboss.xml如下所示：

<?xml version="1.0" encoding="ISO-8859-1"?> <jboss> <enterprise-beans> <session> <ejb-name>GreetEJB</ejb-name> <jndi-name>GreetingEJB</jndi-name> </session> <secure>false</secure> </enterprise-beans> <resource-managers/> </jboss>

开发EJB的最后一步是将其中所有的类文件和相应的部署描述符压缩成JAR包，然后部署到EJB服务器上。在本例中，JAR包的生成可以通过下面这条命令来实现：

jar cf greetejb.jar greet/*.class META-INF/*.xml

该命令将greet目录下的.class文件和META-INF目录下的.xml文件压缩成greetejb.jar文件。如果想知道生成的JAR包是否正确地包含了所有的文件，可以用命令：

jar cvf greetejb.jar

0 Sun May 24 15:32:10 CST 2002 META-INF/
68 Sun May 24 15:32:10 CST 2002 META-INF/MANIFEST.MF
1007 Sun May 24 14:35:46 CST 2002 greet/GreetBean.class
209 Sun May 24 14:35:46 CST 2002 greet/Greet.class
251 Sun May 24 14:35:46 CST 2002 greet/GreetHome.class
493 Sun May 24 08:40:00 CST 2002 META-INF/ejb-jar.xml
303 Sun May 24 08:43:22 CST 2002 META-INF/jboss.xml

cp greetejb.jar /usr/jb_tom/jboss/deploy/

[INFO,ContainerFactory] Deploying GreetEJB
[INFO,GreetEJB] Initializing
[INFO,GreetEJB] Initialized
[INFO,GreetEJB] Starting
[INFO,GreetEJB] Started

EJB存在的价值在于为其客户提供相应的服务，EJB客户包含的范围相当广泛，可以是另外的EJB、普通的JavaBean、JSP页面、Applet或者标准的Java应用程序。GreetClient.java是已经部署好的EJB的客户程序，其完整的源码如下所示：

import javax.naming.*; import java.util.Hashtable; import javax.rmi.PortableRemoteObject; import greet.*; class GreetClient { public static void main(String[] args) { System.setProperty("java.naming.factory.initial", "org.jnp.interfaces.Naming ContextFactory"); System.setProperty("java.naming.provider.url", "localhost:1099"); try { // Get a naming context InitialContext jndiContext = new InitialContext(); System.out.println（"Got context"）; Object ref = jndiContext.lookup("GreetingEJB"); System.out.println("Got reference"); GreetHome home = (GreetHome) PortableRemoteObject.narrow (ref, GreetHome.class); Greet greet = home.create(); System.out.print("The magic number from server is "); System.out.println(greet.calculateMagic(123.456)); } catch(Exception e) { System.out.println(e.toString()); } } }

用下面的命令对EJB客户端程序进行编译：

javac GreetClient.java \ -classpath /usr/jb_tom/jboss/lib/ext/jboss-j2ee.jar:.

如果一切正常，就可以运行客户端程序来对EJB进行测试了，命令如下：

java -cp \ $CLASSPATH:/usr/jb_tom/jboss/client/jboss-client.jar:. \ GreetClient

小结

本文以一个无状态的会话Bean为例，讲述了在JBoss平台上开发和部署EJB的全过程，对JBoss的安装、EJB的创建、EJB的部署及EJB的测试做了简要介绍。作为一个开放源码的EJB服务器，JBoss已经开始被越来越多的企业所接受，基于JBoss的成功案例屡见不鲜。有关JBoss的更多信息，请访问JBoss的网站http://www.jboss.org。

Java

Description

Executes a Java class within the running (Ant) VM or forks another VM if specified.

If odd things go wrong when you run this task, set fork="true" to use a new JVM.

As of Ant 1.6.3, you can interact with a forked VM, as well as sending input to it via the input and inputstring attributes.

Parameters

Parameters specified as nested elements

arg and jvmarg

Use nested <arg> and <jvmarg> elements to specify arguments for the Java class and the forked VM respectively. See Command line arguments.

sysproperty

Use nested <sysproperty> elements to specify system properties required by the class. These properties will be made available to the VM during the execution of the class (either ANT's VM or the forked VM). The attributes for this element are the same as for environment variables.

syspropertyset

You can specify a set of properties to be used as system properties with syspropertysets.

since Ant 1.6.

classpath

Java's classpath attribute is a PATH like structureand can also be set via a nested classpath element.

bootclasspath

The location of bootstrap class files can be specified using this PATH like structure- will be ignored if fork is not true or the target VM doesn't support it (i.e. Java 1.1).

since Ant 1.6.

env

It is possible to specify environment variables to pass to the forked VM via nested env elements. See the description in the section about exec

Settings will be ignored if fork is disabled.

permissions

Security permissions can be revoked and granted during the execution of the class via a nested permissions element. For more information please see permissions

When the permission RuntimePermission exitVM has not been granted (or has been revoked) the System.exit() call will be intercepted and treated like indicated in failonerror.

Note:
If you do not specify permissions, a set of default permissions will be added to your Java invocation to make sure that the ant run will continue or terminated as indicated by failonerror. All permissions not granted per default will be checked by whatever security manager was already in place. exitVM will be disallowed.

Settings will be ignored if fork is enabled.

since Ant 1.6.

assertions

You can control enablement of Java 1.4 assertions with an <assertions>subelement.

Assertion statements are currently ignored in non-forked mode.

since Ant 1.6.

A nested I/O Redirectorcan be specified. In general, the attributes of the redirector behave as the corresponding attributes available at the task level. The most notable peculiarity stems from the retention of the <java> attributes for backwards compatibility. Any file mapping is done using a null sourcefile; therefore not all Mappertypes will return results. When no results are returned, redirection specifications will fall back to the task level attributes. In practice this means that defaults can be specified for input, output, and error output files.

Errors and return codes

Similarly, if failonerror="false" and fork="false" , then <java>must return 0 otherwise the build will exit, as the class was run by the build JVM.

JAR file execution

The parameter of the jar attribute is of type File; that is, the parameter is resolved to an absolute file relative to the base directory of the project, not the directory in which the Java task is run. If you need to locate a JAR file relative to the directory the task will be run in, you need to explicitly create the full path to the JAR file.

When using the jar attribute, all classpath settings are ignored according to Sun's specification.

Examples

				       <java classname="test.Main">
         <arg value="-h"/>
         <classpath>
           <pathelement location="dist/test.jar"/>
           <pathelement path="${java.class.path}"/>
         </classpath>
       </java>

		

				       <java jar="dist/test.jar"
           fork="true"
           failonerror="true"
           maxmemory="128m"
           >
         <arg value="-h"/>
         <classpath>
           <pathelement location="dist/test.jar"/>
           <pathelement path="${java.class.path}"/>
         </classpath>
       </java>

		

				       <java
           dir="${exec.dir}"
           jar="${exec.dir}/dist/test.jar"
           fork="true"
           failonerror="true"
           maxmemory="128m"
           >
         <arg value="-h"/>
         <classpath>
           <pathelement location="dist/test.jar"/>
           <pathelement path="${java.class.path}"/>
         </classpath>
       </java>

		

				  <java classname="test.Main"/>
		

				  <java classname="test.Main"
        fork="yes" >
    <sysproperty key="DEBUG" value="true"/>
    <arg value="-h"/>
    <jvmarg value="-Xrunhprof:cpu=samples,file=log.txt,depth=3"/>
  </java>

		

				  <java classname="ShowJavaVersion" classpath="."
        jvm="path-to-java14-home/bin/java" fork="true"
        taskname="java1.4" >

		

Note: you can not specify the (highly deprecated) MSJVM, "jview.exe" as the JVM, as it takes different parameters for other JVMs, That JVM can be started from <exec> if required.

package proxy;
/**
 *
 * @author chen
 *
 */
public interface Subject {
 abstract public void request();
 abstract public void request2();
}


package proxy;

/**
 *
 * @author chen
 *
 */
public class RealSubject implements Subject {
 
 public RealSubject(){
 }

 public void request() {
  // TODO Auto-generated method stub
  System.out.println("From real subject.request().");
 }
 
 public void request2() {
  // TODO Auto-generated method stub
  System.out.println("From real subject.request2()");
 }
}

package proxy;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

/**
 *
 * @author chenweicai
 *
 */
public class DynamicSubject implements InvocationHandler {
 
 private Object sub;
 
 public DynamicSubject(){
 }
 
 public DynamicSubject(Object obj){
  this.sub = obj;
 }

 public Object invoke(Object proxy, Method method, Object[] args)
   throws Throwable {
  // TODO Auto-generated method stub
     System.out.println("before calling " + method);
     method.invoke(sub,args);
     System.out.println("after calling " + method);
  return null;
 }

}


package proxy;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Constructor;
import java.lang.reflect.Proxy;

/**
 *
 * @author chen
 *
 */
public class Client {
 static public void main(String[] args)
        throws Throwable{
    RealSubject rs = new RealSubject();  //在这里指定被代理类
    InvocationHandler ds = new DynamicSubject(rs);  //初始化代理类
    Class cls = rs.getClass();
  
    //以下是分解步骤
    /*Class c = Proxy.getProxyClass(cls.getClassLoader(),cls.getInterfaces()) ;
    Constructor ct=c.getConstructor(new Class[]{InvocationHandler.class});
    Subject subject =(Subject) ct.newInstance(new Object[]{ds});*/
  
    //以下是一次性生成
    Subject subject = (Subject) Proxy.newProxyInstance(cls.getClassLoader(),
    cls.getInterfaces(),ds );

    subject.request2();
   }
}