Introduction of EJB Technology
The full name of the EJB is the Enterprise Java Bean. Is the commercial application component technology in Java. The role EJB component structure in EJB structure is a distributed computing structure based on component, and it is a component in Distributed Application System.
A complete EJB based distributed computing structure consists of six roles, which can be provided by different developers, and each role must follow the EJB specification provided by Sun to ensure compatibility with each other. These six roles are EJB component developers (Enterprise Bean Provider), application group (application assembler), Deployer (deployer), EJB server provider (EJB server-based Provider ), EJB container provider (EJB Container Provider), system administrator:
Analysis of each role in EJB
1, EJB Component Developer (Enterprise Bean Provider)
EJB component developers are responsible for developing EJB components that execute business logic rules, and the developed EJB components are packaged into Ejb-jar files. The EJB component developer is responsible for defining the remote and home interfaces of the EJB, writing the EJB class that executes the business logic, and providing the deployment file (deployment descriptor) to deploy the EJB. The deployment file contains the name of the EJB, the resource configuration used by the EJB, such as JDBC. The EJB component developer is a typical business application development domain expert.
EJB component developers do not need to be proficient in system-level programming, so there is no need to know some system-level processing details, such as transactions, synchronization, security, distributed computing, and so on.
2, application combination (application assembler)
The application portfolio is responsible for using a variety of EJB combinations for a complete application system. Application groups sometimes need to provide some relevant programs, such as in an E-commerce system, the application group needs to provide JSP (Java Server Page) program.
The application group must master the home and remote interfaces of the EJB used, but do not need to know the implementation of these interfaces.
3. Deployer (Deployer)
The deployer is responsible for deploying the Ejb-jar file into the user's system environment. The system environment contains some kind of EJB server and EJB Container. The deployer must ensure that all resources declared by the EJB component developer in the deployment file are available, for example, that the Deployer must configure the database resources required for the EJB.
The deployment process is two-step: The Deployer first uses the tools provided by EJB container to generate classes and interfaces that enable EJB container to leverage these classes and interfaces to manage EJBS in the running state. The Deployer installs the EJB components and other classes generated in the previous step into the EJB container. A deployer is an expert in an EJB running environment.
In some cases, the deployer also needs to understand the business methods that the EJB contains in order to write some simple program tests once the deployment is complete.
4. EJB Server Provider (EJB server-based Provider)
The EJB server provider is an expert in the system domain, proficient in Distributed transaction management, distributed object management, and other system-level services. EJB server providers are typically provided by operating system developers, middleware developers, or database developers.
In the current EJB specification, assuming that the EJB server provider and the EJB container provider are from the same developer, there is no interface standard defined between the EJB server provider and the EJB container provider.
5. EJB container provider (EJB Container Provider)
The EJB container provider provides the following features:
Provides an EJB deployment tool to provide a running environment for deployed EJB components. EJB Container is responsible for providing transaction management, security management and other services for EJB.
The EJB container provider must be a system-level programming expert and experience in a number of areas of application. The work of the EJB container provider focuses on developing a scalable container with transaction management capabilities integrated into the EJB server. The EJB container provider provides a standard set of Easy-to-use APIs for EJB component developers to access the EJB container so that EJB component developers do not need to know the various technical details in the EJB server.
The EJB container provider is responsible for providing a system monitoring tool for real-time monitoring of the EJB container and the state of the EJB component running in the container.
6, systems Administrator (System administrators)
The system administrator is responsible for providing an enterprise-level computing and network environment for EJB servers and containers.
The system administrator is responsible for monitoring the performance of EJB components using the monitoring management tools provided by the EJB server and container.
Third, EJB architecture:
The EJB distributed application is based on the object component model, and the low-level transaction services use API technology. EJB technology simplifies the development and configuration of enterprise application systems written in the Java language. EJB Technology defines a reusable set of components: Enterprise Beans. You can use these components to build your distributed application like a building block. When you write the code, the components are grouped into specific files. Each file has one or more enterprise Beans, plus some configuration parameters. Finally, these enterprise beans are configured on a platform loaded with EJB containers. Customers can navigate to a beans through these beans home interfaces and produce an instance of this beans. This allows the customer to invoke the beans application method and the remote interface.
EJB servers manage EJB containers and functions as a bridge between containers and low-level platforms. It provides the EJB container with the ability to access system services. For example: Database management and transaction management, or for other enterprise application servers. All EJB instances are running in the EJB container. The container provides a system-level service that controls the lifecycle of the EJB. Some of the Easy-to-use management tools in EJBs, such as the security--configuration descriptor (the deployment descriptor), define the different application functions that customers can access. The container achieves this effect by allowing only authorized clients to access these functions. The remote connectivity--container manages low-level communication issues for distant links and hides details of communications for enterprise Beas developers and customers. The EJB developer writes the application method in the same way as the local platform. Customers are also not aware that the method they are calling may be handled remotely. Life Cycle managment--Customer simply creates an instance of a enterprise beans and typically cancels an instance. The container manages the instance of enterprise beans, enabling the enterprise beans to achieve maximum performance and memory utilization. The container is able to activate and disable the enterprise beans so that many client-shared instance pools are maintained. Wait a minute. The trasction management-configuration descriptor defines the requirements for enterprise Beans transaction processing. The container manages the complex issues that manage distributed transaction processing. These transactions may have to update the database between different platforms. Containers make these transactions independent of each other and do not interfere with each other. Ensure that all update databases are successful, or that they are rolled back to the state before transaction processing.
EJB components are components of an enterprise-class application based on distributed transaction processing. All ejbs have the following characteristics: EJB contains the application logic of processing enterprise data. Defines the client interface for EJBS. Such an interface is not affected by containers and servers. Thus, when an EJB is assembled into an application, there is no need to change the code and recompile. EJB can be customized to a variety of system-level services, such as security and transaction processing characteristics, are not part of the EJB class. It is implemented by the tools that configure and assemble the application. There are two types of ejb:session beans and entity beans. Session beans is an object that is executed as a single user. As appropriate for the remote task request, the container produces an instance of the session beans. A session beans has a user. To some extent, a sessions bean represents its user for the server. Session beans can also be used for transactions that update shared data, but it does not directly depict these shared data. The life cycle of the session beans is relatively short. Typically, the session beans is alive only when the user keeps the conversation. Once the user exits, the session beans is no longer associated with the user. The session beans is considered instantaneous, because if the container crashes, the user must re-establish a new sessions object to continue.
The session bean typically declares interoperability or conversation with the user. That is, the session bean has mastered the user's information through the invocation of the method during the customer conversation. A session bean that has a state is called a stateful session bean. When the user terminates the interaction with the sessions beans. The conversation terminates, and the bean no longer owns the state value. The session bean may also be a stateless session bean. Stateless session beans does not grasp the information or status of its customers. The user is able to invoke the beans method to complete some operations. However, beans only knows the user's parameter variables when the method is called. When the method call completes, beans does not continue to hold these parameter variables. In this way, all instances of the stateless session beans are the same, unless it is in a method call. In this way, stateless session beans can support multiple users. The container can declare a stateless session beans. The ability to assign any session beans to any user.
Entity beans provides an object view of the data in the database. For example, a entity bean can simulate a row of related data in a database table. Multiple client can share access to the same entity bean. Multiple client can also access the same entity bean at the same time. Entity beans accesses or updates the underlying data through the context of the transaction. In this way, the integrity of the data can be guaranteed. Entity beans can survive relative to the duration of the teachings, and the state is continuous. As long as the data in the database exists, Entity beans is still alive. Rather than according to the application or service process. Even if the EJB container crashes, Entity beans is alive. The Entity beans lifecycle can be managed by the container or beans itself. If the container is controlled by the Entity beans to ensure the continuous issus. If managed by beans, you must write entity beans code, including calls to access the database.
Entity beans is identified by a primary key (a unique object identifier of the primary key). Typically, primary keys are the same as the primary keys that identify a single piece of data in a database, such as a row in a table. A primary key is the client's ability to locate a particular block of data.
Iv. Development of EJB
1, Class Introduction:
The main steps in developing EJB generally speaking, the whole development step (development, configuration, assembly) includes the following several aspects. Development: First you define three classes: The Bean class itself, the bean's local and remote interface classes. Configuration: Configuration includes generating configuration descriptors-This is an XML file, a property that declares the enterprise bean, a class file that has a bean bound (including stub files and skeleton files). Finally, these configurations are put into a jar file. You also need to define environment properties in the Configurator. Assemble applications: Includes installing enterprise beans into server servers to test connectivity across tiers. The program assembler combines several enterprise beans with other components. Combined into a complete application. Or combine several enterprise beans into a complex enterprise Bean. Manage Enterprise beans.
We must define and write some basic classes in the EJB. such as the Enterprise Bean class: This is the implementation of the internal application logic of the Enterprise bean. Write the Remote interface class for the Enterprise bean. Write the local interface class for the Enterprise bean. Describes the primary key class, where the primary key class is only required for entity beans. Specifies the name of the primary key in the configuration descriptor of the enterprise bean. The Enterprise beans provider defines the remote interface and the local interface, implementing the EJB class itself. The remote interface provides an interface for the application logic functions that the client invokes the EJB implementation. The home interface provides a way to generate and locate remote interface instances.
In the implementation of the enterprise bean itself class, there is no formal connection (e.g. inheritance relationship) between the local home interface and the remote remoted interface. However, the methods declared in the three classes must conform to the specifications defined in the EJB. For example, you declare an application's method or application logic in the Enterprise bean. This method is also declared in the Beans remote interface, so the two places must have the same name. The bean's implementation must have at least one create () method: Ejbcreate (). However, you can have multiple create () methods with different parameters. In the home interface, you must also have the same method definition (the number of parameters is the same). The Ejbcreate () method returns a container-managed persisted object. They both return a primary key value for container-managed persistence. However, the type of the return value in the corresponding create () method in home is a remote interface.
Note: The Ejbcreate method for implementing the entity bean is somewhat different. Entity beans can not define ejbcreate methods. Entity beans omit the Ejbcreate method if the entity is added to the database only through an application or through a database management program. The value returned by Ejbcreate is the primary key type. If the Ejbcreate method is a method of a container that manages persistent entity beans, its return value is a null type. If the entity Bean implements the persistence of bean management, the Ejbcreate method returns the value type, which is the primary key type. The task of the container is to combine the interface with the implementation class of the Enterprise bean. Ensure that the interfaces and implementation classes are relative at compile time and runtime.
An EJB implementation class in which interfaces are inherited from different base classes. A session bean must implement a base class Javax.ejb.SessionBean. The entity bean must implement the base class Javax.ejb.EntiyBean. The base classes for these ejbs are inherited from Javax.ejb.EnterpriseBean. and Javax.ejb.EnterpriseBean inherited from Java.io.Serializable. Each enterprise bean must have a remote interface. The remote interface defines the logical operations that the application requires the customer to invoke. These are public methods that can be invoked by the customer and are typically implemented by the enterprise Beans class. Note that customers of the Enterprise bean do not directly access the bean. Instead, it is accessed through a remote interface. The remote interface of the Enterprise bean class extends the common Java interface of the Javax.ejb.EJBObject class. And Javax.ejb.EJBObject is the base class for all remote interfaces. The code is as follows:
The Getejbhome () method allows you to obtain a related home interface. For the entity Bean, use the GetPrimaryKey () method to obtain the primary key value of the entity bean. Remove () can delete a enterprise bean. The specific semantics are explained in the context in the life cycle of various types of enterprise beans. Method GetHandle () returns a persistent handle to a enterprise bean instance. The Isindentical () method allows you to compare whether enterprise beans are the same.
2. Methods:
The methods in all remote interfaces must be declared public and must throw java.rmi.RemotException exceptions. In addition, all the methods defined in the remote interface must be valid in Rmi-iiop. For each method defined in the remote interface, there is a corresponding method in the enterprise Bean class. The corresponding method must have the same name, the same type and number of parameters, the same return value, and throw the same exception. The following code shows an ATM example of a session Bean's remote interface ATM. The inside declares an application method transfer (). The bold section represents what must be in the EJB specification. The remote interface must extend the Javax.ejb.EJBObject class. Each method of the enterprise bean that is invoked from the client must be declared in the remote interface. The Transfer () method throws two surprises. Where the insufficientfundsexception exception is an application-defined accident.
Public interface Atm extends javax.ejb.ejbobject{public void Transfer (String Source, string Target, float amount) Throws ja Va.rmi.RemoteException, Insufficientfundsexception;}
The home interface must define one or more of the Create () methods. Each of these create () methods must be named Create. Also, its parameters, whether type or quantity, must correspond to the Ejbcreate () method inside the Bean class. Note that the Create () method in the home interface is different from the return value type of the Ejbcreate () method in the Bean class. The home interface of the entity Bean also contains the Find () method. Each home interface extends the Javax.ejb.EJBHome interface. The following code shows the definition of the Javax.ejb.EJBHome interface:
There are two remove () methods available to remove instances of the enterprise bean. The first remove method is to remove an instance of a enterprise bean by using a handle. The second Remove method deletes an instance of a enterprise bean through a primary key. In many enterprise bean instances, the handle uniquely identifies an instance. A handle has the same lifetime as the enterprise bean it references. Considering an entity object, a client can regain an instance of the corresponding enterprise bean through a handle. A handle can correspond to multiple instances of a enterprise bean object. For example, a handle is still valid even if the host where the enterprise bean object is located crashes, or if the enterprise bean object moves between different machines. The handle here is a serialized handle and is similar to the reference of a string-typed CORBA object in CORBA. The second remove operation in the EJBHome interface determines the enterprise bean to be deleted through its primary key. A primary key can be any type that extends the Java object class, but you must implement the Java serializable interface. Primary keys are the primary way to identify entity beans. Typically, a primary key is a keyword in a database that uniquely defines the data represented by an entity bean.
Method Getejbmetadata () returns the metadata interface of the enterprise bean object. This interface allows the customer to obtain metadata information for the enterprise bean. Metadata information may be used when developing tools to compile linked applications, or when configuration tools are configured. The Javax.ejb.EJBMetadata interface provides access to the Javax.ejb.EJBHome interface, home class, remote interface, and a method to obtain a primary key. A Issesson () method is also provided to determine whether the object being placed on this home interface is a session bean or an entity bean. The Isstatelesssession () method indicates whether the session bean is stateful or stateless. The code below shows the code for the definition section of the Javax.ejb.EJBMetadata interface.
Public javax.ejb; public interface Ejbmetadata{ejbhome Getejbhome (); Class Gethomeinterfaceclass (); Class getremoteinterfaceclasss (); Class Getprimarykeyclass (); Boolean issession (); Boolean isstatelessssession ();}
For each create () method, the EJB specification defines the following naming conventions. Its return value is the type of remote interface for the session bean. The name of the method can only be create (). Each ejbcreate () method in the session Bean class must have a create () corresponding to it. The type and number of parameters for each create () method must correspond to the ejbcreate () square in the session Bean class. Method must throw the java.rmi.RemoteException exception. Method must throw the javax.rmi.CreateExeption exception. The parameters of the Create () method are used to initialize the new session Bean object. The following code shows a different create () method for a session bean object, where the necessary parts are shown in bold:
There are two remove () methods available to remove instances of the enterprise bean. The first remove method is to remove an instance of a enterprise bean by using a handle. The second Remove method deletes an instance of a enterprise bean through a primary key. In many enterprise bean instances, the handle uniquely identifies an instance. A handle has the same lifetime as the enterprise bean it references. Considering an entity object, a client can regain an instance of the corresponding enterprise bean through a handle. A handle can correspond to multiple instances of a enterprise bean object. For example, a handle is still valid even if the host where the enterprise bean object is located crashes, or if the enterprise bean object moves between different machines. The handle here is a serialized handle and is similar to the reference of a string-typed CORBA object in CORBA.
The second remove operation in the EJBHome interface determines the enterprise bean to be deleted through its primary key. A primary key can be any type that extends the Java object class, but you must implement the Java serializable interface. Primary keys are the primary way to identify entity beans. Typically, a primary key is a keyword in a database that uniquely defines the data represented by an entity bean. Method Getejbmetadata () returns the metadata interface of the enterprise bean object. This interface allows the customer to obtain metadata information for the enterprise bean. Metadata information may be used when developing tools to compile linked applications, or when configuration tools are configured. The Javax.ejb.EJBMetadata interface provides access to the Javax.ejb.EJBHome interface, home class, remote interface, and a method to obtain a primary key. A Issesson () method is also provided to determine whether the object being placed on this home interface is a session bean or an entity bean. The Isstatelesssession () method indicates whether the session bean is stateful or stateless. The code below shows the code for the definition section of the Javax.ejb.EJBMetadata interface.
Public javax.ejb; public interface Ejbmetadata{ejbhome Getejbhome (); Class Gethomeinterfaceclass (); Class getremoteinterfaceclasss (); Class Getprimarykeyclass (); Boolean issession (); Boolean isstatelessssession ();}
V. Programming environment for EJB:
1. Use JBuilder
JBuilder and EJB container can be seamlessly connected. The JBuilder and inprise application servers include all the tools for developing and configuring enterprise beans, as well as the libraries needed: running and managing enterprise bean containers, naming services, transaction services, Java databases, Develop the APIs needed for enterprise beans, an enhanced JAVA-TO-IIOP compiler, support for value types and RMI signals, and so on.
JBuilder also provides a tool and wizard for rapid development of application enterprise beans. With simple and intuitive steps, the wizard helps you build a enterprise Bean. Set some defaults for yourself, creating a bean template, where we can add our own application logic. JBuilder also provides an EJB interface Generation Wizard. The wizard generates a remote interface and a home interface based on the public method of the enterprise bean. JBuilder also provides a Configurator wizard to help us step through the creation of an XML descriptor file. and centralizes the generated stubs into a jar file.
2, the use of JBuilder outside the integrated environment:
If you use a different integration environment (IDE) than others. To determine the container tools that are in use with the integrated environment IDE. Also verify that the IDE supports the appropriate version of the EJB specification, and whether it supports the EJB's API correctly.
To determine the version of JD to the supported EJB container. You can check the installation instructions for Inprise to determine which version of the EJB container supports JDK.
When configuring the Enterprise bean, you must use the tools provided by the Inprise application server. These tools are able to edit and modify the Inprise configuration descriptor provided by Third-party agents. You can also verify the configuration descriptor and be able to validate the bean's source code.
六、一个 Simple Hello Example
1. Install apusic application Server
Note: The following is an example of Linux to illustrate the installation process for Apusic application server. For installation of other platforms, refer to the Apusic Application Server installation manual.
Download Jdk1.3,apusic Application server must be running in the environment above jdk1.3. The latest JDK can be downloaded from the following sites.
Http://java.sun.com
Download Apusic Application Server
Apusic Application Server Beta can be obtained from the following URLs:
http://www.apusic.com/download/enter.jsp
After the download is complete, you can get a package file Apusic.zip, select the installation directory, and assume the installation to/usr below, then use the following command:
Cd/usr
Jar XVF Apusic.zip
A directory apusic,apusic Application server has been uncompressed to/usr/apusic under/usr.
Add the following path to the Classpath
/usr/apusic/lib/apusic.jar
$JAVA _home/lib/tools.jar
Run Apusic application Server with the following command
java-xms64m Com.apusic.server.main-root/usr/apusic
2. Define EJB Remote interface (Interface)
Any EJB is invoked through a remote interface, and the EJB developer first defines all the methods in the remote interface that the EJB can be invoked by the outside world. Classes that perform remote interface are generated by the EJB build tool.
The following is a remote Inteface program for Hellobean:
Package Ejb.hello;import java.rmi.remoteexception;import java.rmi.remote;import javax.ejb.*;p ublic Interface Hello Extends Ejbobject, Remote {//this method just get ' Hello world ' from Hellobean.public String Gethello () throws Remoteexcep tion;}
3. Define Home Interface
The EJB container creates the EJB instance through the EJB's home interface, and like the remote interface, the class that executes the home interface is generated by the EJB build tool.
The following is Hellobean's home interface program:
Package Ejb.hello;import Javax.ejb.*;import Java.rmi.remote;import java.rmi.remoteexception;import java.util.*;/*** This is extremely simple it declares only* one create Method.*/public interface Hellohome extends interface EJBHome {Publi C Hello Create () throws Createexception,remoteexception}
4. Write EJB class \ r
In the EJB class, the programmer must give a concrete implementation of the remote method defined in remote interface. The EJB class also includes some of the methods that must be implemented in the EJB specification, all of which have a more unified implementation template, and programmers only need to expend their energy on the implementation of specific business methods.
Here's the code for Hellobean:
Package Ejb.hello;import javax.ejb.*;import java.util.*;import java.rmi.*;p ublic class Hellobean implements Sessionbean {static final Boolean verbose = true;private transient sessioncontext ctx;//Implement the methods in the Sess ionbean//interfacepublic void Ejbactivate () {if (verbose) System.out.println ("ejbactivate called"); public void Ejbremove () {if (verbose) System.out.println ("Ejbremove called"); public void Ejbpassivate () {if (verbose) System.out.println ("ejbpassivate called"); /*** Sets the session context.** @param sessioncontext*/public void Setsessioncontext (Sessioncontext ctx) {if (verbose) Sy Stem.out.println ("Setsessioncontext called"); this.ctx = CTX;} /*** This method corresponds to the Create method in* the home interface hellohome.java.* the parameter the sets me Thods are* identical. When the client calls* hellohome.create (), the container allocates an* instance of the Ejbean and calls (). ejbcreate IC void Ejbcreate () {if (verbose) System.out.println ("EjbcreatE called ");} /*** * * * is the BUSINESS LOGIC Gethello just return a "Hello World" String.*/public string Gethello () thro WS Remoteexception{return ("Hello World");}
5. Create ejb-jar.xml files
The Ejb-jar.xml file is a deployment description file for EJBS that contains various configuration information for the EJB, such as stateful beans (Stateful beans) or stateless beans (stateless beans), transaction types, and so on. For more information on Ejb-jar.xml files, see the EJB specification. The following are the configuration files for Hellobean:
<?xml version= "1.0"? ><! DOCTYPE Ejb-jar Public '-//sun Microsystems inc.//dtd Enterprise JavaBeans 1.2//en ' "http://java.sun.com/j2ee/dtds/ Ejb-jar_1_2.dtd "><ejb-jar><enterprise-beans><session><ejb-name>hello</ejb-name >
6. Compiling and Deploying \ R
Compile Java source files and package compiled class and ejb-jar.xml to Hello.jar
mkdir Build
mkdir Build/meta-inf
CP Ejb-jar.xml Build/meta-inf
javac-d Build *.java
CD Build
Jar CVF Hello.jar Meta-inf EJB
Cd..
Build a jar file that can be deployed to run in Apusic application Server using the EJB tool:
Java com.apusic.ejb.utils.ejbgen-d/usr/apusic/classes/hello.jar Build/hello.jar
Add/usr/apusic/classes/hello.jar to Classpath
Add Hello.jar to the Apusic application server configuration file. Add the following lines to/usr/apusic/config/server.xml:
Start server \ r
java-xms64m Com.apusic.server.main-root/usr/apusic
7. Write client invoke program \ r
You can invoke Hellobean from Java Client,jsp,servlet or another EJB.
There are several steps to invoking an EJB:
Get EJB home Interface via Jndi (Java naming Directory Interface)
Create an EJB object from the EJB home Interface and get its remote Interface
Invoking EJB methods via remote interface
Here's an example of invoking Hellobean from a Java client:
Package Ejb.hello;import Javax.naming.context;import Javax.naming.initialcontext;import java.util.Hashtable;import Javax.ejb.*;import java.rmi.remoteexception;/*** @author Copyright (c) by Apusic, Inc. All Rights Reserved.*/public class Helloclient{public static void Main (string args[]) {string url = ' rmi://localhost:6888 ' ; Context initctx = null; Hellohome Hellohome = null;try{hashtable env = new Hashtable (); Env.put (Context.initial_context_factory, " Com.apusic.jndi.InitialContextFactory "); Env.put (Context.provider_url, URL); initctx = new InitialContext (env); catch (Exception e) {System.out.println ("Cannot get initial context:" + e.getmessage ()); System.exit (1);} Try{hellohome = (hellohome) initctx.lookup ("Hellohome"); Hello hello = hellohome.create (); String s = Hello.gethello (); System.out.println (s);} catch (Exception e) {System.out.println (E.getmessage ()); System.exit (1);}}}
Running Helloclient, you get the following output:
Hello World
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
