love fish大鵬一曰同風起，扶搖直上九萬里

使用EJB3.O簡化EJB開發（轉）

Simplifying EJB Development with EJB3.0

使用EJB3.O簡化EJB開發
October 2004

Discussion 討論

Enterprise JavaBeans (EJB) was introduced for building distributed components. When it arrived it came with a promise to solve all issues and complexities of CORBA. EJB being the heart of J2EE went through several major revisions and got fattened with many features. Early on, most of the developers fell in love with EJB and used EJB in their application even it did not make any sense. “Blame it on EJB” has been the attitude for many developers when their projects did not scale well and they used EJB.

我們引入EJB來構造分布式的組件。它誕生之時是為了解決所有CORBA的問題和復雜性。經歷過幾次重要的版本更新和增加許多特性之后，EJB已經成為了J2EE的核心。在早期，很多開發人員沉迷于EJB甚至在沒有任何意義的情況下在他們的工程中使用EJB。而當他們發現所使用的工程并沒有質的變化后，譴責EJB成了一種趨勢。

Development of EJB was never easier and it became more complex with every release of EJB specification. EJB has been compared with an elephant due to its complexity and heavy weight nature. Many developers feel EJB is like an extra layer of sugar syrup on a doughnut. In an age where low carb and Atkins diet is craze, the EJB expert committee has no option but to produce a low carb incarnation of EJB thus simplifying the development of EJB. EJB 3.0 expert committee released a sample picture of the lightweight model during JavaOne 2004 when it announced release of first public draft of EJB 3.0 Specification.

開發EJB從來沒有變得簡單甚至在早期的EJB版本規范中變得更加復雜。EJB由于其的復雜性和重量級特性而被比作一只大象。學多開發人員感覺EJB象一個油炸圈餅上多余的一層甜糖漿。在現在low carb和Atkins diet大行其道的今天，EJB專家委員會也沒有選擇余地的發布了體現low carb的EJB規范來簡化EJB的開發。EJB3.0專家委員會在2004Javaone大會上發布了稱之為EJB3.0第一個公開規范的輕量級模型的范例圖。

At the first glimpse the new model for EJB looks pretty and in this article we will discuss how EJB 3.0 is trying to dress up in a smaller size pretty outfit to make it appealing for developers. In a follow up article we will discuss how EJB 3.0 is simplifying the persistence model.

第一眼看到EJB的新模型感覺很不錯。在這篇文章中我們將討論EJB3.0如何使用一個更小而精致的裝配來吸引開發者的。在接下來的文章中我們將來討論EJB3.0是怎樣簡化持久性模型的。

Cleaning up the Dirty Laundry 整理缺陷

Let us look at the complexities in the current EJB model before we dive down discussing the details what EJB 3.0 is bringing on to the table.

在我們開始對EJB3.0帶來的新特性進行討論之前，讓我們先分析一下現在EJB模型的復雜繁瑣。

• The current EJB model requires creation of several component interfaces and implementation of several unnecessary callback methods.
• 現在的EJB模型需要建立許多組件接口和實現許多不必要的回滾方法。
• The component interfaces require implementation of EJBObject or EJBLocalObject and handling of many unnecessary exceptions is required.
• 組件接口需要實現 EJBObject 或者 EJBLocalObject ，并且處理許多不必要的異常。
• The EJB deployment descriptor is complex and error prone.
• EJB 的部署描述復雜而容易出錯。
• The container managed persistence being based on the EJB model is again overly complex to develop and manage. There are several basic features missing such as a standard way to define a primary key using database sequence and EJBQL is very limited.
• 基于EJB模型的容器持久化管理的開發和管理過于復雜。許多基礎的特征未考慮到，比如使用數據庫序列和EJBQL定義一個主鍵的標準方法就非常有限。
• EJB components do not look like its Object Oriented as it has restrictions for using inheritance and polymorphisms.
• EJB 組件不像是面向對象的，比如在使用繼承和多態時就有太多限制。
• One major drawback of EJBs is that you cannot test EJB modules outside an EJB container and debugging an EJB inside the container is a nightmare for developers.
• 一個主要的EJB的缺點是你不能脫離EJB容器測試一個EJB模型且不能在容器內調試一個EJB，這對開發者無疑是一個可怕的事情。
• If you used EJB you know the complexities of looking up and invocation of EJB. It appears that you have to know minute details of JNDI to just use an EJB in your application.
• 如果你使用EJB你需要熟悉調用和查找EJB的復雜過程。顯然，你僅僅要在程序中使用EJB但你卻必須知道JNDI詳細的細節。

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業務接口。

Metadata Annotations 元數據描述

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 marked 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來替代部署描述文件。

Using POJOs and POJIs 使用 POJOs 和 POJIs

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中實現任何回滾容器都會調用這些方法。

The only exception is the ejbRemove method in Stateful Session bean where you can use Remove annotation to annotate a Stateful session bean business method. If you use of this annotation it will hint the container to remove the Stateful session bean instance after the completion (normal or abnormal) of the annotated method. For example, you can specify the following to remove a Stateful Session Bean instance after checkOut method is executed.

唯一的異常是在你可以使用 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.

無疑擺脫部署描述將使得新的開發者開發更加容易，但是如果使用不當這也將造成管理上的可怕問題。

Simplifying Container Managed Persistence 簡化持久化容器管理

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的細節做更多的驗證。

?

Simplifying Client View for EJBs 簡化EJB客戶端

Using EJBs i.e. to lookup and invoke is very complex even if EJB is collocated in the application. J2EE 1.4 and EJB 3.0 spec is working on to simplify the client ’s view of EJBs.

即使應用中EJB是序列化的，使用EJB也就是尋找和調用也是非常復雜的。J2EE 1.4 和 EJB 3.0規范致力于簡化EJB客戶端。

If you want to use an EJB presently you have to define the ejb-ref or ejb-local-ref in the deployment descriptor, lookup the EJB and then invoke. If we want to invoke our HelloWorld EJB, following is the simplest way you can invoke an EJB with the current implementation.

如果目前你希望使用EJB你必須在部署描述中定義EJB引用或者EJB本地引用，尋找到EJB然后調用。如果我們希望調用HelloWorld 的EJB，你可以按照下面的簡單方法調用EJB使用已存在的實現。

First define the EJB references in the deployment descriptor as follows:

如下在部署描述中找到EJB指示的定義

<ejb-ref>

? <ejb-ref-name>HelloWorldEJB</ejb-ref-name>

? <ejb-ref-type>Session</ejb-ref-type>

? <home>hello.HelloWorldHome</home>

? <remote> hello.HelloWorld</remote>

? </ejb-ref>

Then lookup the EJB as follows. You have to explicitly handle exceptions for EJB lookup and creation of a bean instance.

然后按照如下方法尋找EJB.你需要明確處理EJB查找和建立一個bean實例時的異常。

try

? {

??? Context context = new InitialContext();

??????? HelloWorldHome helloHome =

??????? ? (HelloWorld)PortableRemoteObject.narrow(context.lookup

???? ("java:comp/env/ejb/HelloWorldEJB"), HelloWorldHome.class);

??????? HelloWorld hello = helloHome.create();

??????? ? ....

?? }

??? catch(RemoteException e)

??????? {

??????? ? System.err.println("System/communication error: " + e.getMessage());

??????? }

??????? catch(NamingException e)

??????? {

??????? ? System.err.println("Communication error: " + e.getMessage());

??????? }

??????? catch(CreateException e)

??????? {

??????? ? System.err.println("Error creating EJB instance: " + e.getMessage());

??????? }

As an alternative to environment variables, EJB 3.0 proposes a way to use setter injection to lookup and invoke EJBs.

如一個環境變量的變化一樣，EJB3.0建議使用安放injection的方法查找和調用EJB.

Following is way our HelloWorldEJB can be looked up in another EJB by using setter injection.

下面我們使用安放injection的方法在另一個EJB查找HelloWorldEJB。

@Inject private void setSessionContext(SessionContext ctx)

? {

? this.ctx = ctx

? }

? ...

? myHello = (HelloWorld)ctx.lookup("java:comp/env/ejb/HelloWorldEJB");

If you look at the code above carefully the setSessionContext method is annotated with @Inject to specify that dependency injection be used for this method. The injected methods will be invoked by the container to set the EJBContext before any business method be called on that EJB.

如果你仔細查看上面的代碼，它依賴的injection使用 @Injectset 來的指定對 SessionContext 方法的annotations。injection 方法將可以在業務方法被EJB調用前被容器調用來設定EJBContext。

Another direct example to inject the HelloWorld session bean would be to simply have @EJB public HelloWorld myHello and this would cause myHello to be injected with an instance of the HelloWorld bean.

另一個injected 的HelloWorld會話bean的直接的范例可以簡化為使用

@EJB public HelloWorld myHello ，這將使得myHello被HelloWorld bean的實例injected 。

You can use dependency injection to lookup any type of environment and resource references such as DataSource, JMS, Mail, Web Service, etc.

你可以使用依賴的injection來查詢任何類型的環境和資源參考如DataSource, JMS, Mail, Web Service等等。

Testability Usability Outside Container 容器外部測試可行性

A major concern for the current EJB developers is not only development of EJBs is complex but also testing is a nightmare. An EJB container is required is to develop and test the EJBs and the developers have to be familiar with the final deployment platform to perform testing. This may not be a major issue for many enterprise developers but is an issue for ISVs who work on supporting multiple vendors and they have to maintain multiple environments to do the testing of their EJBs. The EJB 3.0 spec promises to provide the ability to test outside the container but this is currently missing in the draft specification.

一個現在EJB開發者所關注的不僅僅是EJB開發的復雜，也包括了測試的可怕之處。開發和測試EJB必須需要一個EJB容器并且開發人員必須熟悉最終部署平臺才可以執行測試。這對于許多只在一個主要平臺開發的企業開發人員來說不是主要問題，但是對于支持多個開發商平臺并且要在維護的多個環境中測試EJB的ISV們來說是個大問題。EJB3.0規范承諾將提供在容器外測試的功能，但是這點在這次的規范中遺漏掉了。

Conclusion 結論

Although there are a lot of missing information about packaging, assembly and gory details of APIs, the proposals made in EJB 3.0 drafts looks very promising for enterprise java developers. These will certainly help remove the complexities from developers view by passing those to the container vendors. It is to be seen how the container vendors implement these and make EJB 3.0 a compelling option to develop enterprise applications.

雖然還有很多關于打包，裝配和重要的API細節沒有在這個規范中提及，但是諸多的建議使得EJB3.0規范讓企業級Java開發人員看起來是恨有前途的。通過這些無疑是從開發人員到服務供應商都將幫助減少開發的復雜性。下面就要看服務提供商們怎么實現，并使得EJB3.0成為企業級應用一個引人矚目的選擇。

Author Bio 作者自述

Debu Panda is a principal product manager of Oracle Application Server development team, where he focuses his efforts on the EJB container and Transaction Manager. He has more than 13 years of experience in the IT industry and has published articles in several magazines and has presented at many technology conferences.

Debu Panda 是Oracle應用服務開發小組的主要管理者，他的在EJB容器和事務管理上取得過很多成就。他已經有13年的IT產業的經驗并在多家雜志和技術出版社刊登過很多著作。

?

翻譯問題：

由于部分英文名詞未敢枉自翻譯，所以留英文原詞在文中

Cleaning up the Dirty Laundry?? 整理缺陷

low carb

Atkins diet

metadata annotations 元數據描述

Simplifying Client View for EJBs 簡化EJB客戶端

dependency injection??????? 依賴型injection

setter injection??????????? 安放injection

ISV? Independent software vendor 獨立軟件供應商

posted on 2006-06-30 11:46 liaojiyong 閱讀(429) 評論(0)  編輯  收藏 所屬分類: EJB