EJB core technology and its application
I. Introduction to EJB Technology
The full name of EJB is Enterprise Java Bean. It is a commercial application component technology in Java. The role EJB component structure in the EJB structure is a component-based distributed computing structure, which is a component in a distributed application.
A complete EJB-based distributed computing structure consists of six roles, which can be provided by different developers, and every role must follow the EJB specification provided by Sun to ensure compatibility between each other. Sex. These six characters are EJB component developers, Application ASSEMBLERs, deployers, EJB server providers, EJB container providers (EJB container providers, System administrator:
Second, the analysis of each role in EJB
1, EJB component developer (Enterprise Bean Provider)
EJB component developers are responsible for developing EJB components that performs business logic rules, and the EJB components developed into EJB-JAR files. The EJB component developer is responsible for defining the EJB's REMOTE and HOME interface, writing EJB Class, executing business logic, providing deployment descriptor. The deployment file contains the name of EJB, and the resource configuration used by EJB, such as JDBC, etc. EJB Components Developers are typical business application development field experts.
EJB component developers do not need to be proficient in system-level programming, so you don't need to know some system-level processing details, such as transactions, synchronization, security, distributed calculations.
2, Application Components (Application Assembler)
Application portfoliors are responsible for using various EJB combined a complete application system. Application portfoliors sometimes need to provide some related programs, such as in an e-commerce system, application portfoliors need to provide JSP (Java Server Page).
Application portfoliors must master the EJB HOME and REMOTE interface used, but do not need to know the implementation of these interfaces.
3, deployer (deployer)
Deployers are responsible for deploying the EJB-JAR file into the user's system environment. The system environment contains some EJB Server and EJB Container. Deployers must guarantee that all resources declared by the EJB component developer in the deployment file, for example, deployers must configure the database resources required for EJB.
Deployment procedures Two steps: Deployers first use the tools provided by EJB Container to generate some classes and interfaces, so that EJB Container can use these classes and interfaces to manage EJBs in operation. Deployers Install the EJB component and other classes generated in the previous step to EJB Container. Deployers are an expert in an EJB operating environment.
In some cases, deployers need to understand the business methods included in EJB in deployment to write some simple program tests after deployment.
4, EJB server provider (EJB Server Provider)
The EJB server provider is an expert in the system, proficient in distributed transaction management, distributed object management, and other system-level services. EJB server providers are generally provided by operating system developers, middleware developers, or database developers.
In the current EJB specification, assume that the EJB server provider and the EJB container provider come from the same developer, so no interface criteria between the EJB server provider and the EJB container provider are defined.
5, EJB container provider (EJB Container Provider)
The EJB container provider provides the following features:
Provide EJB deployment tools to provide a running environment for deploying EJB components. The EJB container is responsible for providing transaction management, safety management such as EJB.
The EJB container provider must be a system-level programming expert, but also have some experience in the application. The work of the EJB container provider is mainly focused on the development of a retractable and transaction management functionality in the EJB server. EJB container providers provide a set of standards for EJB component developers, easy-to-use API access to EJB containers, so that EJB component developers do not need to understand various technical details in the EJB server. The EJB container provider is responsible for providing system monitoring tools to monitor EJB containers in real time and the state of EJB components running in the container.
6. System administrator
The system administrator is responsible for providing an enterprise-class computing and network environment for EJB servers and containers.
System administrators are responsible for monitoring the operation of EJB components using the Monitoring Management Tools provided by EJB servers and containers.
Third, EJB architecture:
The EJB distributed application is an API technology based on the object component model, the low-level transaction service. EJB technology simplifies the development and configuration of enterprise application systems written in Java language. EJB technology defines a set of reusable components: Enterprise Beans. You can take advantage of these components, build your distributed application like wood. When you write the code, these components are combined into a specific file. Each file has one or more Enterprise Beans, plus some configuration parameters. Finally, these Enterprise Beans are configured to a platform with EJB containers. Customers are able to locate a beans through these beans's Home interface, and generate an instance of this beans. In this way, customers can call Beans Application and Remote Interface.
The EJB server manages EJB containers and functions as bridges of the container and low-level platforms. It provides the ability to access system services to the EJB container. For example: the management and transaction management of the database, or for other Enterprise application servers. All EJB instances run in the EJB container. The container provides a system-level service that controls the life cycle of EJB. There are some easy-to-use management tools in EJB, such as: The Deployment Descriptor defines different application functions that customers accessible. The container reaches this effect by accessing these functions that only allow authorized customers. The Remote Connectivity-Container manages the low-level communication Issues for remote links, and has hidden communications details for Enterprise Beas developers and customers. EJB developers are like a local platform when writing application methods. Customers are not clear that the methods they call may be processed remotely. Life Cycle Managing - Customer Create an instance of Enterprise Beans and typically cancel an instance. The container manages instances of Enterprise Beans, enabling Enterprise Beans to maximize the maximum efficiency and memory utilization. The container can activate and make Enterprise Beans to maintain the instance pool shared by many customers. and many more. The TRASCTION Management-Configuration Description Defines the needs of the transaction processing of Enterprise Beans. The container manages complex Issues that manages distributed transactions. These transactions may have to update the database between different platforms. The container makes each of these transactions independently and does not interfere with each other. Ensure that all updated databases are successful, and whether they are rolled back to the state before transaction.
The EJB component is a component of an enterprise-class application based on distributed transactions. All EJBs have the following features: EJB contains application logic for processing corporate data. Define the EJB customer interface. Such interfaces are not affected by the containers and servers. Thus, when an EJB is set to an application, do not change the code and recompile. EJB can be customized for various system-level services, such as security and transactional characteristics, are not belonging to the EJB class. Instead, it is implemented by a tool for configuring and assembling an application. There are two types of EJB: Session Beans and Entity Beans.Session Beans are an object that is performed as a single user. As a corresponding to the remote task request, the container generates an instance of a session beans. A session beans have a user. From a certain extent, a session bean represents the user of the user. Thesession beans can also be used for transactions, it can update the shared data, but it does not depict these Shared data. The life cycle of Session Beans is relatively short. Typically, the session beans are only living when the user keeps a session. Once the user quits, Session Beans will no longer be associated with the user. Session Beans is seen as instantaneous because if the container crashes, the user must re-establish a new session object to continue the session. Session bean is typical to declare interoperability or session with users. That is, the session bean masters the user's information through the customer session. A stateful session bean called a stateful Session bean. When the user terminates interoperability with the session beans. The session is terminated, and the bean no longer has a status value. Session bean may also be a stateless session bean. The stateless session beans do not have information or status of its customers. Users can call Beans to complete some operations. However, Beans only knows the user's parameter variable when the method is called. Beans do not continue to maintain these parameter variables after the method call is completed. Thus, all instances of all stateful session beans are the same unless it is in the method call. In this way, the stateless session beans can support multiple users. The container can declare a stateful session beans. You can specify any Session Beans to any user.
Entity Beans provides a view of the data in the database. For example: an Entity bean can simulate a line of data in a database table. Multiple clients can share access to the same entity bean. Multiple Client can also access the same Entity Bean.EnTity Beans to access or update the underlying data through the context of the transaction. In this way, the integrity of the data can be guaranteed. Entity Beans can survive the time of relatively long, and the status is continuous. Entity Beans has always survive as long as the data in the database exists. Not in accordance with the application or service process. Even if the EJB container crashes, Entity Beans is also survived. The Entity Beans life cycle can be managed by the container or Beans. If the container is controlled to ensure continuous ISSUS for Entity Beans. If you manage it yourself by Beans, you must write the code of Entity Beans, including access to the database.
Entity Beans is identified by the primary key (a unique object identifier) of Primary Key). Typically, the primary key is the same as one of the data in the identity database, such as one line in a table, and the primary key. The primary key is that the client is able to locate a specific data block.
Fourth, develop EJB
1, class introduction:
The main steps of developing EJBs Generally, the entire development step (development, configuration, assembly) includes the following aspects. Development: First, you must define three classes: Bean class itself, BEAN's local and remote interface classes. Configuration: The configuration includes generating a configuration descriptor - this is an XML file that declares the attribute of Enterprise Bean, binds the bean's class file (including the stub file and the Skeleton file). Finally, put these configurations in a JAR file. It is also necessary to define environmental properties in the configurator. Assembly application: Includes Enterprise Beans to the Server server to test the connection of each layer. The program assembly combines several Enterprise Beans with other components. Combine into a complete application. Or combine several Enterprise Beans into a complex ENTERPRISE BEAN. Manage Enterprise Bean.
We must define and write basic classes in EJB. Such as Enterprise Bean: This is the implementation of Enterprise Bean internal application logic. Write the remote interface class for Enterprise Bean. Write the local interface class for Enterprise Bean. Description Primary key, primary key class is only required for Entity Beans. Specify the name of the primary key in the Configuration Descriptor of Enterprise Bean. The Enterprise Beans provider defines the remote interface and the local interface to implement the EJB class itself. The client invoked the EJB implemented interface in the Remote Interface. The HOME interface provides a way to generate and locate the Remote interface instance.
In the implementation of the Enterprise Bean itself, there is no formal connection between the local home interface, and the remote Remote interface (such as inheritance relationship). However, the methods declared in three classes must abide by the specification defined in EJB. For example: You declare an application method or application logic in Enterprise Bean. This method is also declared in the Remote interface of Beans, then these two places must be the same name. There must be at least one crete () method in the implementation of the bean: ejbcreate (). However, there can be 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). EjbcReate () method returns a persistent object for container management. They all returns a host key value for container management persistence. However, the type of return value in the corresponding CREATE () method of Home is the Remote interface.
Note: The EJBCREATE method implemented by the entity bean is a bit different. Entity Beans may not define the EJBCREATE method. If the entity is applied to the database through the application or through the database management program, the entity bean omits the EJBCREATE method. The value returned by EJBCREATE is the primary key type. If the EJBCREATE method is a method of managing persistence of persistence, its return value is a null type. If the entity bean implements the persistence of bean management, the EJBCREATE method is the primary key type of the returned value. The task of the container is to combine the implementation classes of each interface and Enterprise Bean. Ensure that the interfaces and implementations are corresponding when compiling and running.
EJB's implementation class, each interface should be inherited from different base classes. A session bean must realize the base class javax.ejb.sessionBean. The entity bean must realize the base class javax.ejb.entiybean. These EJB base classes are inherited from Javax.ejb.EnterpriseBean. Javax.ejb.EnterpriseBean is inherited from java.io.serializable. Every Enterprise Bean must have a Remote interface. The Remote Interface defines the logical operation that the application specifies the customer call. These are some public methods that can be called by the customer, usually implemented by the Enterprise Beans class. Note that Enterprise Bean's customers do not directly access beans. Instead, it is accessed through the Remote interface. The Remote interface of the Enterprise Bean class extends the public Java interface of the Javax.ejb.EJBObject class. Javax.ejb.ejbObject is the base class for all Remote interfaces. Code is as follows: package javax.ejb; public interface EJBObject extends java.rmi.Remote {public EJBHome getEJBHome () throws java.rmi.RemoteException; public Object getPrimaryKey () throws java.rmi.RemoteException; public void Remove () throws java .rmi.remtoeexception, java.rmi.removeexception public handle getHandle () throws java.rmi.RemoteException; Boolean isidentical (EJBOBJECT P0) throws java.rmi.RemoteException;}
The getejbhome () method allows you to get a related HOME interface. For entity beans, the primary key value of entity beans is obtained by getPrimaryKey () method. Remove () can delete an Enterprise Bean. Specific semantics are explained in context in the life cycle of various different types of Enterprise Beans. Method GetHandle () returns a persistent handle of an Enterprise Bean instance. The isindentical () method allows you to compare if Enterprise Beans is the same.
2, method:
The method in all Remote interfaces must be declared as public (public) and must throw java.rmi.RemoteXception. In addition, the parameters defined in all Remote interfaces must be valid in RMI-IIOP. For each method defined in the Remote interface, there must be a corresponding method in the Enterprise Bean class. Corresponding methods must have the same name, the same type, and quantity parameters, the same return value, and also throw the same exception. The following code showed an ATM example of the Remote interface ATM of the session bean ,. Declare an application method TRANSFER (). The black body part indicates that some content must be in the EJB specification. The REMOTE interface must expand the javax.ejb.ejbobject class. Each method from the Enterprise Bean call from the client must be declared in the Remote interface. The transfer () method throws two accidents. The InsufficientFundSexception exception is an accident defined by the application.
Public interface Atm extends javax.ejb.EJBObject {Public void transfer (String Source, String Target, float amount) Throws java.rmi.RemoteException, InSufficientFundsException;} Home interface must define one or more of the Create () method. Each such CREATE () method must be named CREATE. Also, its parameters, whether it is a type or quantity, it must correspond to the EJBCREATE () method in the bean class. Note that the return value type of the EJBCREATE () method in the home interface in the Home interface is different. The Home interface of the entity bean also includes a Find () method. Each HOME interface extends the Javax.ejb.ejbHome interface. The following code shows the definition of the javax.ejb.ejbhome interface:
package javax.ejb; public interface EJBHome extends java.rmi.Remote () {void remove (Handle handle) throws java.rmi.RemoteException, RemoveException; void remove (Object primarykey) throws java.rmi.RemoteException, RemoveException; EJBMetaData getEJBMetaData ( "THROWS RemoteException; HomeHandle GethomeHandle () THROWS RemoteException;
Here, two remove () methods are provided to delete instances of Enterprise Beans. The first Remove method is to remove an instance of an Enterprise Bean through a handle. The second REMOVE method deletes an instance of an Enterprise Bean through a primary key. In numerous Enterprise Bean instances, the handle is uniquely identified an instance. A handle has the same lifetime as the Enterprise Bean it references. Considering an entity object, the customer can re-obtain an instance of the corresponding Enterprise Bean through a handle. A handle can correspond to multiple instances of an Enterprise Bean object. For example, even if the host where the Enterprise Bean object is located, or the ENTERPRISE BEAN object moves between different machines, the handle is still valid. The handle here is a Serialized handle, a reference to a CORBA object serialized with characters in CORBA. The second REMOVE operation in the EJBHOME interface determines the Enterprise Bean to be deleted through its primary key. The primary key can be any type of the Java Object class, however, you must implement Java serializable interface. The primary key is the main method of identifying the entity bean. Typically, the primary key is a keyword in the database, uniquely defining data represented by entity beans.
Method GeTejbMetadata () returns the Metadata interface of the Enterprise Bean object. This interface allows customers to get metadata information for Enterprise Beans. When developing tools to compile link applications, or when configuring tools to configure, Metadata information may be used. Javax.ejb.ejbmetata interface provides a method of obtaining a javax.ejb.ejbhome interface, home class, remote interface, and a primary key. A iSSSSON () method is also provided to determine that the object in which this HOME interface is session bean or an entity bean. The isStateLessSession () method indicates that this session bean is status or stateless. The following code shows the code for the defined section of the javax.eb.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 convention. Its return value is the type of Remote interface of the session bean. The name of the method can only be CREATE (). Every ejbcreate () method in the session bean class must have a CREATE () corresponding. The type and quantity of the parameters of each CREATE () method must correspond to the EJBCREATE () method in the session bean class. Methods must throw java.rmi.RemoteException. Methods must throw javax.rmi.createexeption. The parameter of the CREATE () method is used to initialize the new session bean object. The following code shows the different CREATE () methods of a session bean object, where the parts must be displayed:
public interface AtmHome extends javax.ejb.EJBHome {Atm create () throws java.rmi.RemoteException, javax.ejb.CreateException; Atm create (Profile preferredProfile) Throws java.rmi.RemoteExeption, javax.ehrows java.rmi.RemoteException, RemoveException Ejbmetadata getejbmetadata () throws remoteException; HomeHandle GethomeHandle () throws RemoteException;}
Here, two remove () methods are provided to delete instances of Enterprise Beans. The first Remove method is to remove an instance of an Enterprise Bean through a handle. The second REMOVE method deletes an instance of an Enterprise Bean through a primary key. In numerous Enterprise Bean instances, the handle is uniquely identified an instance. A handle has the same lifetime as the Enterprise Bean it references. Considering an entity object, the customer can re-obtain an instance of the corresponding Enterprise Bean through a handle. A handle can correspond to multiple instances of an Enterprise Bean object. For example, even if the host where the Enterprise Bean object is located, or the ENTERPRISE BEAN object moves between different machines, the handle is still valid. The handle here is a Serialized handle, a reference to a CORBA object serialized with characters in CORBA. The second REMOVE operation in the EJBHOME interface determines the Enterprise Bean to be deleted through its primary key. The primary key can be any type of the Java Object class, however, you must implement Java serializable interface. The primary key is the main method of identifying the entity bean. Typically, the primary key is a keyword in the database, uniquely defining data represented by entity beans. Method GeTejbMetadata () returns the Metadata interface of the Enterprise Bean object. This interface allows customers to get metadata information for Enterprise Beans. When developing tools to compile link applications, or when configuring tools to configure, Metadata information may be used. Javax.ejb.ejbmetata interface provides a method of obtaining a javax.ejb.ejbhome interface, home class, remote interface, and a primary key. A iSSSSON () method is also provided to determine that the object in which this HOME interface is session bean or an entity bean. The isStateLessSession () method indicates that this session bean is status or stateless. The following code shows the code for the defined section of the javax.eb.ejbmetadata interface.
Public javax.ejb; Public interface EJBMetaData {EJBHome getEJBHome (); Class getHomeInterfaceClass (); Class getRemoteInterfaceClasss (); Class getPrimaryKeyClass (); Boolean isSession (); Boolean isStatelesssSession ();}
Five, EJB programming environment:
1, use jbuilder
JBuilder and EJB Container are seamlessly connected. JBuilder and Inprise application servers include tools for developing and configuring Enterprise Beans, and libraries required: Run and Manage Enterprise Beans, Naming Services, Transaction Services, Java Databases, APIs needed to develop Enterprise Beans, an enhancement Java-to-IIOP compiler, support value type, and RMI signal, etc.
JBuilder also provides a tool and wizard for fast development applications Enterprise Beans. By simple and intuitive steps, the wizard helps you build an Enterprise Bean. I set some default values, generated the template of the bean. Only, 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 Enterprise Bean. JBuilder also provides a wizard of a configurator to help us build an XML descriptor file step by step. And generate the Stubs to a JAR file. 2. Use an integrated environment other than JBuilder:
If you use other integrated environments (IDEs). To determine the container tools that integrated analog environment IDE. Also verify that the IDE supports the corresponding version of the EJB specification, and it is necessary to determine if it is correctly supporting the EJB API.
To determine the version of the JD to the supported EJB container. You can determine the version of the support JDK supported by the EJB container by checking the installation instructions of the Inprise.
When configuring Enterprise Beans, you must use the tools provided by the INPRISE application server. These tools can edit and modify the INPRISE configuration descriptor provided by third-party agents. It is also possible to verify the configuration descriptor to verify the source code of the bean.
Six, a simple Hello example
1, install APUSIC APPLICATION Server
Note: The following is the installation process of the APusic Application Server as an example. For other platforms, please refer to the APUSIC Application Server installation manual.
Download JDK1.2, Apusic Application Server must run in a JDK 1.2 environment. You can download the latest JDK from the following site.
http://java.sun.com;
Download APusic Application Server
The APUSIC Application Server trial version can be obtained from the following URL:
http://www.apusic.com/download/enter.jsp;
After the download is complete, you can get a parcel file apusic.zip, select the installation directory, assume it to install it to / usr, use the following command:
CD / USR
JAR XVF APUSIC.ZIP
A directory APUSIC will appear under the USR, and all programs of the APUSIC Application Server are extracted under / usr / apusic.
Add the following path to ClassPath
/usr/apusic/lib/apusic.jar
$ Java_home / lib / Tools.jar
Run the APUSIC Application Server with the following command
Java -XMS64M com.apusic.server.main -root / usr / apusic
2. Define EJB Remote Interface (Remote Interface)
Any EJB is called via Remote Interface, and EJB developers first define this EJB can be called all methods of being called in the Remote Interface. The class executing the Remote Interface is generated by the EJB generation tool.
The following is the Remote Inteface program of HelloBean:
package ejb.hello; import java.rmi.RemoteException; import java.rmi.Remote; import javax.ejb *;.. public interface Hello extends EJBObject, Remote {// this method just get "Hello World" from HelloBean public String getHello () Throws RemoteException;} 3, Define Home Interface
The EJB container creates an EJB instance via the HOME interface of EJB, like the Remote Interface, and executes the Home Interface class is generated by the EJB generation tool.
The following is the HELLOBEAN's Home Interface:
package ejb.hello; import javax.ejb *;. import java.rmi.Remote; import java.rmi.RemoteException; import java.util *;. / ** * This interface is extremely simple it declares only * one create method. * / Public interface hellohome extends ejbhome {public hello create () throws createException, RemoteException;
4, write EJB classes
In the EJB class, the programmer must give the specific implementation of the remote approach defined in the Remote Interface. The EJB class also includes a method that must be implemented in some EJB specification. These methods have a more unified implementation template, and the programmer only costs in the implementation of the specific business method.
The following is the Hellobean code:
package ejb.hello; import javax.ejb *;. import java.util *;. import java.rmi *;. public class HelloBean implements SessionBean {static final boolean verbose = true; private transient SessionContext ctx; // Implement the methods in the SessionBean // interface public 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) System.out.println ( "setSessionContext called"); this.ctx = ctx;.} / ** * This method corresponds to the create method in * the home interface HelloHome.java * The parameter sets of the two methods are * Identical. By client calls * hellohome.create (), The contactail allocates an * instance of the ejbean and calls ejbcreate (). * / Public void ejbcreate () { IF (Verbose) System.Out.println ("Ejbcreate Called");} / ** * **** Here Is The Business Logic ***** * The GetHello Just Return A "Hello World" string. * / public String getHello () throws remoteexception {return ("Hello World");}} 5, create an ejb-jar.xml file
The EJB-JAR.XML file is the deployment description file of EJB, including the various configuration information of EJB, such as the state bean (Stateful Bean), stateless bean (STATELESS BEAN), trading type, etc. See the EJB specification for more information on EJB-JAR.XML files. The following is a Hellobean profile:
Compile the Java source file and package Class and EJB-JAR.XML to Hello.jar after compiling
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 ..
Generate the JAR file that can be deployed to the APusic Application Server with 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 in /usr/apusic/config/server.xml:
Start server
Java -XMS64M com.apusic.server.main -root / usr / apusic
7, write client call programs
You can call Hellobean from Java Client, JSP, Servlet, or other EJB.
Calling EJB has the following steps:
Get the EJB Home Interface by JNDI (Java Naming Directory Interface) to create an EJB object via EJB Home Interface and get its Remote Interface
Call EJB method via Remote Interface
The following is an example of calling Hellobean from Java Client:
[code] 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) 2000 by apusic, incm. 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);
}
}
} [/ Code] Run HelloClient, you can get the following output:
Hello World
