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 Components Developers (Enterprise Bean Provider) EJB component developers are responsible for developing EJB components that performs business logic rules, and the developed EJB components are packaged 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 ASSEMBLER Application Components is responsible for using a complete application system using various EJBs. 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 deployers are responsible for deploying the EJB-JAR file to 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) 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) EJB container provider provides the following features: Provide EJB deployment tools to provide an operational 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 system administrators are responsible for providing an enterprise-level 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 SESSION Beans that can be supported by the stateless session beans. The container can declare a stateless session beans. You can specify any session beans to any user. Entity Beans provides an object of 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. Introduction: The main steps of developing EJB 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;} getEJBHome () method allows you to get an associated 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: All methods 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. Javax.ejb.EJBHome following code shows the definition of the 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;} there is provided a two remove () method is used to delete an instance Enterprise bean. 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 of a Create () method, EJB specification Define the following naming conventions. 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 part must be displayed with bold: public interface atmhome extends javax.ejb.ejbhome {atm crete () 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;} remove this provides two () method To delete an instance of Enterprise Bean. 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 to perform seamless connections. 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 the APUSIC Application Server Note: The following uses Linux as an example to illustrate the installation process of the Apusic Application Server. 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 ServerApusic Application Server Trial Edition You can get from the following URL: http://www.apusic.com/download/enter.jsp After downloading, you can get a parcel file APUSIC .zip, select the installation directory, assume it installed to / usr, use the following command: CD / usrjar XVF apusic.zip / usr will appear under the APUSIC Application Server all programs are extracted to / usr / apusic under. Add the following path to classpath /usr/apusic/lib/apusic.jar $java_home/lib/tools.jar run Apusic Application Server Java -XMS64M com.apusic.server.main -root / usr / apusic
2. Defining the EJB Remote Interface Any EJB is called via Remote Interface, and EJB developers first define this EJB in the Remote Interface. All methods can be called by the outside. 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 the Home Interface EJB container Create an EJB instance via the EJB home interface, like the Remote Interface, and execute the Home Interface class is generated by the EJB generation tool. The following is the HELLOBEAN 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 CREATEXCEPTION, REMOTEEXCEPTION;
}
4. Write an EJB class 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;
//Mplement the methods in the sessionbean // 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 caled";
/ *** sets the session context. ** @Param sessionContext * / public void setsessionContext (sessioncontext ctx) {if (verbose) system.out.println ("setsessionContext caled); 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. When the client calls * HelloHome.create (), the container allocates an * instance of The ejbean and calls ejbcreate (). * / public void ejbcreate () {if (verbose) System.out.Println ("ejbcreate caled");} / *** **** Here is the business logic **** ** The getHello Just Return A "Hello World" string. * / public string getHello () throws remoteException {return ("Hello World");}}
5. Creating an EJB-JAR.XML file EJB-jar.xml file is the deployment description file of EJB, including various configuration information of EJB, such as 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 the configuration file of Hellobean: helloejb.hello.hellohomeejb.hello.Helloejb.Hello.HellobeansTatelessContainer
Hello *
Required
6. Compile and deploy the Java source file and compile the compiled Class and EJB-JAR.XML to hello.jar mkdir buildmkdir build / meta-infcp ejb-jar.xml build / meta-infjavac -d build * .javacd buildjar CVF Hello.jar meta-infread .. uses the EJB tool to generate JAR files that can be deployed to apusic application server: java com.apusic.ejb.utils.ejbgen -d /usr/apusic/classes/hello.jar build / hello .jar Add /usR/apusic/classes/hello.jar to ClassPath to join Hello.jar to the APusic Application Server configuration file. Add the following lines in /usr/apusic/config/server.xml:
Classes / hello.jar
Hellohellohome
Start server java -xms64m com.apusic.server.main -root / usr / apusic
7. Write a client call 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) Creating an EJB object via EJB Home Interface, and getting its Remote Interface call EJB method via Remote Interface
The following is an example of calling Hellobean from 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) 2000 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); (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);}}} Run HelloClient, you can get the following output: Hello World
