Simplifying Developers view
简化开发者的观点
If you developed an EJB with the latest specification you realize how difficult is develop a simple EJB like HelloWorld EJB. You need at least two interfaces, a bean class and a deployment descriptor. Most of the developers wondered why do I need all these. IDEs like Oracle JDeveloper, Eclipse and XDoclet made the life simple for developers for doing these mundane tasks however still it was the responsibility of developer to compile these classes and package the deployment descriptor before the EJB can be deployed in your container of choice.
如果你使用现有版本的EJB你会懂得开发一个如HelloWorld的简单的EJB程序是多么困难。你至少需要两个接口，一个bean类和一个部署描述文件。大多数的开发者希望知道为什么我需要所有这些。IDEs(开发环境工具)象Oracle的JDeveloper, Eclipse和XDoclet简化了开发者的做这些普通的工作开发周期，可是在EJB在你部署到所选择的容器中之前，编译类和打包部署文件依然是开发人员的工作。
EJB 3.0 is trying to address the complexities by:
EJB3.0试图从以下方面简化复杂性：
• Removing need of interfaces and deployment descriptors and these may be generated by the container using metadata annotations
• 不必定义接口和部署的描述文件，这些可以由容器使用metadata annotations生成。
• Use regular Java classes as EJBs and regular business interfaces for EJBs
• 使用常用的Java类作为EJB的类和常用的EJB业务接口。
简化开发者的观点
If you developed an EJB with the latest specification you realize how difficult is develop a simple EJB like HelloWorld EJB. You need at least two interfaces, a bean class and a deployment descriptor. Most of the developers wondered why do I need all these. IDEs like Oracle JDeveloper, Eclipse and XDoclet made the life simple for developers for doing these mundane tasks however still it was the responsibility of developer to compile these classes and package the deployment descriptor before the EJB can be deployed in your container of choice.
如果你使用现有版本的EJB你会懂得开发一个如HelloWorld的简单的EJB程序是多么困难。你至少需要两个接口，一个bean类和一个部署描述文件。大多数的开发者希望知道为什么我需要所有这些。IDEs(开发环境工具)象Oracle的JDeveloper, Eclipse和XDoclet简化了开发者的做这些普通的工作开发周期，可是在EJB在你部署到所选择的容器中之前，编译类和打包部署文件依然是开发人员的工作。
EJB 3.0 is trying to address the complexities by:
EJB3.0试图从以下方面简化复杂性：
• Removing need of interfaces and deployment descriptors and these may be generated by the container using metadata annotations
• 不必定义接口和部署的描述文件，这些可以由容器使用metadata annotations生成。
• Use regular Java classes as EJBs and regular business interfaces for EJBs
• 使用常用的Java类作为EJB的类和常用的EJB业务接口。
EJB 3.0 depends heavily on metadata annotations. Metadata annotation being standardized under JSR 175 and will be part of J2SE 5.0. Annotation is a kind of attribute oriented programming and similar to XDoclet. However unlike XDoclet that requires pre-compilation, annotations are compiled into the classes (depending upon what the @Retention is set to) by the Java compiler at compile-time. In developer’s point of view, annotations are modifiers like public and can be used in classes, fields, methods, parameters, local variables, constructors, enumerations and packages.You can use annotations in your Java code by specifying attributes that can be used for either generating code, documenting code or providing special services such as enhanced business-level security or special business logic during runtime. The goal of J2EE 1.5 (5.0) is to simplify development using annotations and hence it will come up with its set of annotations. Annotations are ed with @ as follows:
EJB3.0非常倚重Metadata Annotations。Metadata Annotations已经成为JSR 175标准并且将是J2SE 5.0的一部分。Annotations是一种对象变成的属性，非常类似与XDoclet。可是不像XDoclet那样需要预先编译，Annotations由Java编译器在需要编译的时候编译。（依赖于@Retention的开始时间）。在开发人员的观点，Annotations就如同一个公有的并可以作为类，域，方法，参数，本地变量，构造，枚举和包一样使用的修改量。你可以在你的Java代码中附带特殊的属性使用Annotations来生成代码，自动编写文档代码，或者提供如在运行期间增强业务层安全或特殊业务逻辑的特殊服务。J2EE1.5(5.0)的目标是简化开发人员使用Annotations因此而可能产生一套的Annotations模板。Annotations使用@来标记，如下：
@Author("Debu Panda")
@Bean
public class MySessionBean
The goal of EJB 3.0 is to simplify development and hence use metadata annotations to generate several artifacts like interfaces and use annotations instead of deployment descriptors.
EJB3.0为了简化开发因此使用Metadata Annotations来产生许多如接口一样的人为因素和使用Annotations来替代部署描述文件。
•现在的EJB模型需要建立许多组件接口和实现许多不必要的回滚方法。”把“callback”翻译成“回滚”不妥把？
把“artifacts”翻译成“人为因素”不妥吧？
那应该翻译为什么合适？请教一下
把“callback”翻译成“回滚”不妥把？
是不是应该翻译为回叫，收回还是复查？
如garbage collection
callback在事务中是翻译为回滚，但是这里我也不知道什么词合适
In canonical terms, JavaBeans and interfaces often referred as Plain Old Java Objects (POJOs) and Plain Old Java Interfaces (POJIs) respectively. The EJB class and interface will now resemble POJO and POJI respectively. The requirement of the unnecessary artifacts like home interface is being removed.
在规范条件中，JavaBeans和接口经常分别的涉及到简单Java对象(POJOs)和简单Java接口(POJIs)。这些不必要的如Home接口的人为因素已经被去掉。
The developer has to either implement one of the EJB interfaces (SessionBean, EntityBean or MessageDrivenBean) in javax.ejb package or use annotation in the bean implementation class. You can either use Stateless, Stateful, MessageDriven or Entity to annotate your bean class. For example, if you define a stateless EJB as HelloWorld you define the EJB as follows:
开发人员必须在javax.ejb包中实现一个EJB接口（会话bean，实体bean或消息驱动bean）或者选择在bean的实现类中使用Annotation。你可以使用无状态，状态，消息驱动或者实体去注释一个bean类。例如，如果你定义一个无状态EJB作为HelloWorld,你可以如下定义EJB：
@Remote
@Stateless public class HelloWorldBean {
public String sayHello(String s)
{ System.out.println("Hello: "+s; }
}
The interfaces for EJBs either remote or local do not have to implement EJBObject or EJBLocalObject. You have to either supply the business interface for your EJB and implement that interface in your bean class or have it generated during the deployment. Interfaces are optional for Entity beans however required for SessionBean and MessageDrivenDriven. If you do not implement an interface for your session bean, a bean interface will be generated for you. The type of generated interface either local or remote is dependent on the annotation you used in the bean class. If you look at the above code example, it is very clear that @Remote is used to generate a remote interface for the HelloWorld bean. If needed, you may have both remote and local interfaces for your EJB.
EJB的接口无论远程的还是本地的都不必再实现EJBObject和EJBLocalObject。你要么为EJB提供业务接口并且实现bean类中的接口，要么需要在部署的时候生成这些接口。虽然会话bean和消息驱动bean的接口是必须的，但是实体bean的接口是可选的。如果你没有为你的会话bean实现一个接口，那么它会自动为你生成一个。所生成的接口是本地的还是远程的取决于你在bean类中的Annotations。如果你仔细看看上面的代码范例，@Remote很明显是用来为你的HelloWorld生成一个远程接口。如果需要，你可以在你的EJB中同时生成远程和本地接口。
From the above example, it is very clear that the developer do not have to a lot of mundane tasks such as defining interfaces and implementing callback methods.
在上面的例子中，很明显开发人员不必再做那些如定义接口和实现回滚方法等这些普通的工作。
The name of the generated interface is derived from the name of the bean implementation class. Generated interfaces are well and good for developers. However, I do not see any benefit of generating interfaces as most IDE like Oracle JDeveloper generates these on fly.
生成接口的名字来源于bean实现类的名字。生成接口对开发人员来说非常有用。但是我并没有看到任何如Oracle 的JDeveloper的这些IDE立即实现这种生成接口功能。
This is not clear from the draft what is client side requirement for EJB lookup and it is not clear, how do we get hold of these interfaces those are required to invoke this EJB? I will recommend against using a generated interface for few reasons:
规范中没有明确EJB查找时客户端的需求是什么，也没有明确我们如何保持这些EJB需要调用的接口。基于以下几个情况下的原因我将不推荐使用生成接口：
• The name of generated interface will be derived from the bean name
• 生成接口的名字来源于bean的名字
• You may not be willing to expose some methods in the EJB in the interface and the generated interface may expose all methods by default.
• 如果你不愿意在EJB中暴露出一些方法而生成接口将默认暴露出所有的方法。
• You need the interface at the client side to invoke the EJB.
• 你需要在客户端使用接口来调用EJB.
Removing need for Callback methods去掉回滚方法的需求。
EJB 2.1 and prior releases required implementation of several lifecycle methods such as ejbPassivate, ejbActivate, ejbLoad, ejbStore, etc. for every EJB even if you do not need those. For example, ejbPassivate is not required for a stateless session bean still you require to implement that method in your bean class. As EJB 3.0 now resembles regular Java classes implementation of these lifecycle methods have been made optional. If you implement any callback method in the EJB then container will invoke that method.
EJB2.1和更早版本需要实现很多即使对于每个EJB你不需要的一些生命周期的方法，如ejbPassivate, ejbActivate, ejbLoad, ejbStore等等。例如,在无状态会话bean中不需要ejbPassivate但是你还是得实现它的方法。现在EJB3.0中类似的常用Java类实现这些生命周期的方法都变成为可选择的。如果你在EJB中实现任何回滚容器都会调用这些方法。
唯一的异常是在你可以使用Remove的annotations时一个状态会话bean的业务方法的ejbRemove方法是状态会话bean。如果你使用这个annotations它将在完成annotations方法后（无论正常或非正常）提示容器移除状态会话bean实例。例如，你可以指定以下的方式去在checkOut方法执行后移除一个状态会话bean实例。
@Stateful public class Cart {
...
...
@Remove public void checkOut() {
...
}
}
Annotations vs. deployment descriptors
Annotations与部署描述的比较
As we discussed earlier deployment descriptors will no longer be required for EJBs and annotations will be used instead. The default values for each attribute in the deployment descriptor will be chosen and developers do not have to specify these attributes unless they want a value other than the default value. These can be specified using annotations in the bean class itself. The EJB 3.0 specification is defining a set of metadata annotations for use by developers such as bean type, type of interfaces, resource references, transaction attributes, security, etc. For example, if we want to resource reference for a particular EJB then we will define as follows:
在前面我们讨论到EJB中不再需要部署描述而由annotations代替。每个部署描述的属性都将被选择一个默认值，而开发人员在直到他们想改变这些属性的默认值之前不必为这些属性指定值。这些也能用来为bean的类自身指定使用的annotations。EJB3.0规范为开发人员使用bean类型，接口类型，资源引用，事务属性，安全等等定义了一组metadata annotations。例如，如果我们可以如下为一个特殊的EJB定义使用资源引用：
@Resource(name="jdbc/OracleDS", resourceType="javax.sql.DataSource")
J2EE vendors such as Oracle, BEA, IBM will add annotations for attributes in their vendor specific deployment descriptors and developers will use these to avoid using deployment descriptors. This looks very attractive for developers as the nasty XML descriptors they hated most gets out of their way but this introduces few problems and we need to be careful before embracing annotations.
J2EE的提供商如Oracle, BEA, IBM将增加属性annotations在他们指定的部署描述中，开发人员将可以使用这些annotations去避免使用部署描述。这看起来对开发人员十分具有吸引力，特别对XML描述是已经感到厌恶的开发人员，他们早就恨透并想脱离老的那种描述方式，但依然有一些问题使得我们在正式使用annotations时需要谨慎对待。• This defeats the goal of portability of applications because if an EJB uses a vendor specific deployment descriptor this cannot be just changed without having to recompiling/repackaging the EJBs.
• 它违背了我们轻便应用程序的目标，因为如果一个EJB如果使用一个提供商指定的部署描述，在重新编译或打包EJB的时候它必须多次改变。
• The deployment descriptors provided a holistic view of EJB modules to the assembler/deployer (ejb-jar) without having to look at individual the EJBs and they tweaked these as per the deployment requirement and if descriptors are not available or not generated until the end of deployment this could be a nightmare for them.
• 部署描述对EJB模板提供了全局观点使得组装和部署的时候不必考虑单独的EJB，他们将每个部署需求拧在一起，并且在部署完成之前描述是无效或者不可自动生成的。这对部署员来说是个可怕的事情。
• Deployment descriptors were used by the tools to identify the EJBs in an EJB module and were very useful when you try to migrate from one container to another.
EJB 3.0 spec also proposes a way to override the annotations in the deployment descriptors. However details of overriding annotations is missing in the specification.
• 部署描述在EJB模板中被相关工具用来定义EJBs，当你试图整合一个和另一个容器的时候非常有用。EJB3.0规格同样主张在部署描述中使用重载annotations的方式。可是在规范里并没有提到重载annotations的细节。
There is no doubt that getting rid of deployment descriptors will make the life easier for new developers but this may become a management nightmare if not used carefully.
无疑摆脱部署描述将使得新的开发者开发更加容易，但是如果使用不当这也将造成管理上的可怕问题。
CMP entity bean is getting a major overhaul in EJB 3.0 to make it compelling for developers. Persistence frameworks like OracleAS TopLink, open source Hibernate have become darling of developing persistence framework for J2EE applications that has disliked Entity beans for its complexity and heavyweight in nature. EJB 3.0 is adopting a lightweight persistence model like TopLink and Hibernate to simplify the container managed persistence and this sounds compelling for developers. Let us do a quick look on the plans for entity beans and we will discuss about the details of the persistence improvement in another article.
CMP实体bean将成为EJB3.0使得开发人员强制使用的一个主要的检查方式。持久化框架象如OracleAS TopLink, 开源的Hibernate已经成为不像实体bean本质上的复杂和重量级的开发J2EE持久化框架应用的被大家喜爱的方式。 EJB3.0采纳了如TopLink和Hibernate轻量级的持久化模式来简化容器持久化管理，这些听起来更让开发人员们欣喜。让我们简单的浏览一下实体bean的计划，我们将在另外的文章中讨论持久化改进的细节。
Entity beans are being reincarnated as POJOs and there will be no component interfaces required for entity beans. Entity beans will now look as pure objects as this will also support inheritance and polymorphism.
实体bean作为POJOs已经改头换面，实体bean将不在需要组件接口。实体bean现在看起来是支持继承和多态的纯粹的对象。
Following is the source code for an entity bean:
下面的是关于实体bean源代码
@Entity public class Employee{
private Long empNo;
private String empName;
private Address address;
private Hashmap projects = new Hashmap();
private Double salary;
@Id(generate=SEQUENCE) public Long getEmpNo() {
return empNo;
}
protected void setEmpNo(Long empNo) {
this.empNo = empNo;
}
public String getEmpName() {
return EmpName;
}
public void setEmpName(String EmpName){
this.EmpName = EmpName;
}
@Dependent public Address getAddress() {
return address;
}
public void setAddress(Address address) {
this.address = address;
}
public Set getProjects() {
return projects;
}
public void setProjects(Set projects) {
this.projects = projects;
}
public Double getSalary() {
return salary;
}
public void setSalary(Double salary) {
this.salary = salary;
}
....
}
If you look at the code, you will find that the bean class is a concrete class and not an abstract class the current entity bean.
如果你仔细看这些代码，你可以发现在现在的实体bean中bean类是一个具体的类而不再是一个抽象类。
There are several improvements are being made for the query capabilities in EJB QL and support of SQL queries in the entity beans. A new EntityManager API similar to Hibernate and a simplified version of TopLink’ Session API is being proposed to manipulation of entity beans i.e. creation, removal, finding of entity beans.
EJB QL和实体bean的SQL查询做了多项改进。类似于Hibernate的新的实体管理API和简化版的TopLink的会话API被建议用来处理实体bean的操作，也就是实体bean的创建，释放，查找。
We will closely examine the details of the proposed CMP entity beans in a followup article.
我们将在深入的文章中进一步对建议CMP实体bean的细节做更多的验证。
我会将最新的讨论总结在我的blog中
http://blog.csdn.net/yiboo回调
恩。。
我会写出来放在blog上
放在http://blog.csdn.net/yiboo
用我自己的话形容 EJB: 共产主义总是要实现的，只不过你我等不到那一天了。