CN100428166C

CN100428166C - Processing method for use in client terminal having an access to EJB through remote interface and device therefor

Info

Publication number: CN100428166C
Application number: CNB2006101673822A
Authority: CN
Inventors: 苏葩娜; 墨迪
Original assignee: Huawei Technologies Co Ltd
Current assignee: Zhang Xiaohong
Priority date: 2006-12-31
Filing date: 2006-12-31
Publication date: 2008-10-22
Anticipated expiration: 2026-12-31
Also published as: CN1996256A

Abstract

The invention provides a method and device for customer end remote interface access of EJB for processing, with the method composed of local calling to handle the access for EJB of the customer end when the JVM marker of the enterprise Java component is identical with the JVM marker, using local calling to handle objects to handle the access to said EJB of the customer end. It mainly comprises JVM deciding module, local calling handle module. Using this method and device, it can solve the relatively low performance of the remote call of the EJB customer end to service end EJB, improving the time consuming feature calling remote access visit.

Description

Method and device for processing EJB accessed by client calling remote interface

Technical Field

The invention relates to the field of computer application, in particular to a method and a device for processing a client calling a remote interface to access an EJB.

Background

An EJB (enterprise Java component) client may call a remote interface or a local interface to access the EJB, and an EJB container is responsible for creating and managing the EJB. The processing mode of the EJB container is different when the EJB client calls the remote interface and the local interface.

The EJB client's call to the local interface is only used when the EJB client and EJB container run on the same JVM (Java virtual machine). In this case, the EJB container handles native calls just as normal Java method calls. The processing mode can effectively improve the performance of the EJB container.

Calls to the remote interface by an EJB client are treated as remote calls, in which case, regardless of whether the EJB client is in the same JVM as the EJB, a series of remote call processing will be performed, which typically includes routing the call through an underlying ORB (object request broker) to a particular EJB container, encoding and decoding of incoming and return parameters and finding the appropriate server to process the request, and so on. If the EJB client and the EJB are in the same JVM, processing such as encoding and decoding of input parameters and output parameters is not necessary.

The processing method of the EJB container when the EJB client in the prior art calls the remote interface and the local interface has the following defects:

a Web client is a common client for EJB applications, and Web clients and EJB applications are typically in the same JVM. At this time, the call to the EJB by the web client is still treated as a remote call, and the EJB container still performs some unnecessary protocol-related operations, resulting in very low performance of the remote call to the EJB by the web client.

The CORBA (Common Object request broker Architecture) scheme provided by JDK (JaVa development kit) supports optimization of EJB client calls in the same JVM. The JDK CORBA realizes that whether the EJB client call and the server EJB call are in the same JVM or not is distinguished by using a CORBA interface, and when the EJB client call and the server EJB call are in the same JVM, the EJB client call in the same JVM is optimized.

In the process of implementing the present invention, the inventor finds that the CORBA scheme provided by JDK at least has the following technical problems: the optimization effect of this method will fail when multiple ORBs are running in one JVM, different ORBs are used by the EJB client, and these different ORBs are in the same JVM as the server-side EJB call. In this case, although the EJB client and the server EJB call are in the same JVM, the EJB client call to the server EJB application is still treated as a remote call, and the EJB container still performs some unnecessary protocol related operations, resulting in poor performance of the EJB client remote call to the server EJB.

Disclosure of Invention

The embodiment of the invention aims to provide a method and a device for processing a client to call a remote interface to access an EJB, so that the problem of low performance of remote calling of the EJB client to a server EJB can be solved.

The purpose of the embodiment of the invention is realized by the following technical scheme:

a method for processing client calling remote interface to access enterprise Java component EJB includes the following steps:

A. when a client calls a remote interface to access an enterprise Java component EJB, the client obtains a Java virtual machine JVM identifier of an EJB server end and a JVM identifier of the client through an agent description object, wherein the JVM identifier is a specified universal unique identifier UUID of a JVM, and the JVM identifier of the EJB server end is determined to be consistent with the JVM identifier of the client;

B. the enterprise Java component EJB uses a local call processing object to process the client's access to the EJB.

The step A specifically comprises the following steps:

when a client calls a remote interface to access the EJB through a naming service, the naming service entity returns an agent description object entity to the client;

the agent description object entity obtains the JVM identifier of the EJB server end from the inside of the agent description object entity, and obtains the JVM identifier of the client from the JVM identifier manager object according to the JVM identifier of the EJB server end;

and the agent description object entity determines that the JVM identifier of the EJB server side is consistent with the JVM identifier of the client side.

The step A is also preceded by:

the EJB container creates a proxy description object entity and binds the proxy description object entity to a naming service entity;

and assigning a Universal Unique Identifier (UUID) for a Java Virtual Machine (JVM) used by the EJB server side, and setting the UUID in the proxy description object entity.

The step B specifically comprises the following steps:

the method comprises the steps that a client establishes a proxy object containing an EJB component of a local call processing object, when the client calls the proxy object, the proxy object delegates the local call processing object contained in the proxy object to process the access of the client to the EJB, and the EJB is an EJB which is in the same JVM as the client.

C. when the client calls the remote interface to access the enterprise Java component EJB, comparing whether the JVM identifier of the EJB server end is consistent with the JVM identifier of the client, and when the JVM identifier of the EJB server end is consistent with the JVM identifier of the client, turning to the step D; otherwise, turning to the step E;

D. the enterprise Java component EJB uses a local call processing object to process the client's access to the EJB;

E. the EJB uses a remote call processing object to process the client's access to the EJB.

The step E specifically comprises the following steps:

the client creates a proxy object containing an EJB component of a remote call processing object, when the client calls the proxy object, the proxy object delegates the contained remote call processing object to process the access of the client to the EJB, and the EJB is an EJB which is not in the same JVM as the client.

An apparatus for handling a client invoking a remote interface to access an EJB, comprising: the JVM determining module and the local calling processing module; wherein,

the JVM determining module is used for obtaining a JVM identifier of an EJB server side and a JVM identifier of a client side through an agent description object when the client side calls a remote interface to access an EJB, wherein the JVM identifier is an appointed UUID of the JVM; determining whether the JVM identifier of the EJB server side is consistent with the JVM identifier of the client side;

and the local call processing module is configured to use a local call processing object to process access to the EJB by the client when the JVM determining module determines that the JVM identifier of the EJB server is consistent with the JVM identifier of the client, where the EJB is an EJB in the same JVM as the client.

The device further comprises:

and the remote call processing module is used for processing the access of the client to the EJB by using a remote call processing object when the JVM determining module determines that the JVM identifier of the EJB server side is not consistent with the JVM identifier of the client, wherein the EJB is an EJB which is not in the same JVM as the client.

The JVM determination module includes:

the naming service submodule is used for receiving a signal that a client calls a remote interface to access the EJB and returning a pre-created proxy description object to the client;

and the proxy description object submodule is used for obtaining the JVM identifier of the EJB server from the inside of the proxy description object submodule, obtaining the JVM identifier of the client from the JVM identifier manager object, comparing whether the JVM identifier of the EJB server is consistent with the JVM identifier of the client or not, notifying the local call processing module when the comparison result is yes, and notifying the remote call processing module when the comparison result is no.

It can be seen from the technical solutions provided in the embodiments of the present invention that, in the embodiments of the present invention, a process of accessing an EJB by using a remote interface by a client in the same JVM is processed by using a local call processing object, so that the performance of the client, such as time consumption for calling the remote interface to access the EJB, can be greatly improved, and no operation related to a protocol is generated. The embodiment of the invention can save hardware cost for users.

Drawings

FIG. 1 is a process flow diagram of a method according to an embodiment of the invention;

FIG. 2 is a schematic diagram of an EJB container passing an EJB client call to a local interface in the form of a direct Java method call;

FIG. 3 is a schematic processing flow diagram of an embodiment of a method according to the present invention;

fig. 4 is a schematic structural diagram of an apparatus according to an embodiment of the present invention.

Detailed Description

The embodiment of the invention provides a method and a device for processing EJB accessed by a client calling a remote interface, wherein a local calling processing object is used for processing the process of accessing the EJB by the client in the same JVM using the remote interface.

The embodiment of the present invention is described in detail below with reference to the accompanying drawings, and a processing flow of the method according to the embodiment of the present invention is shown in fig. 1, and includes the following steps:

step 1-1, the EJB container creates a proxy description object and binds the proxy description object to a naming service.

When an EJB deployment is completed, the EJB container creates a corresponding proxy description object and binds the proxy description object to the naming service. The proxy description object is a wrapper object of the proxy object that contains information about the services that the EJB object can provide and can be used to help generate the proxy object. The proxy object holds a reference to the call handling object for handling all method calls.

If an EJB has both a remote interface and a local interface, the EJB container will create two proxy description objects respectively and bind to the corresponding naming service respectively. One of the two proxy description objects contains a remote call processing object for processing a remote call, and the other proxy description object contains a local call processing object for processing a local call.

The remote call processing object and the local call processing object comprise common objects, and the EJB client can access the deployed EJB objects created by the EJB container through the common objects. As shown in fig. 2, all EJB client calls to the local interface pass through to the EJB container in direct Java method calls.

Step 1-2, when the EJB client calls the remote interface, judging whether the JVM identifier contained in the proxy object is consistent with the local JVM identifier of the client; if yes, executing the step 1-3; otherwise, steps 1-4 are performed.

When an EJB is deployed, the system assigns a unique UUID (universal unique identifier) to the JVM used by the EJB server. The UUID is a 16-bit character string, is generated by adopting a universal unique identification algorithm according to the network card address and the timestamp of the system, can generate unique UUIDs for multiple system JVM instances or multiple JVM instances of the same system, and is arranged in a calling processing object in an agent object.

The proxy object comprises a call processing object, and the client uses the call processing object through the proxy object. If the calling processing object is directly used by the client, the client can distinguish whether the calling processing object is remotely called or locally called. The proxy object can mask the client's perception of either the remote call processing object or the local call processing object. And the proxy object contains all the business methods of the EJB component, so that the client can feel that the EJB object is used (whether the EJB object is called remotely or locally) just as the local object is used.

When the client calls the remote interface and searches the EJB through the naming service, the proxy description object bound in the naming service is converted into a proxy object, and the proxy object acquires the UUID corresponding to the JVM identifier set in the call processing object. Then, judging whether the UUID is consistent with the local JVM identification of the client, if so, executing the step 1-3; otherwise, steps 1-4 are performed. The local JVM identifier of the client is used to identify the client, i.e., the UUID of the client, which is generated by the UUID algorithm and generated and maintained by the JVM identifier manager.

And step 1-3, processing the call of the client to the remote interface through a local call processing object.

When the UUID and the local JVM identifier are consistent, it indicates that the client call to the remote interface occurs in the same JVM, and the present invention refers to the remote call in this case as a remote-local call, so that the proxy object delegates the local call processing object included in the proxy object to process the remote-local call.

And step 1-4, processing the call of the client to the remote interface through a remote call processing object.

When the UUID is not consistent with the local JVM identifier, it indicates that the call of the client to the remote interface does not occur in the same JVM, and thus, the proxy object delegates the remote call processing object included in the proxy object to process the call of the client to the remote interface.

The client comprises: a web client, or a java application that uses the services provided by the EJB component.

A specific application example of the method according to the embodiment of the present invention has a processing flow as shown in fig. 3, and includes the following steps:

31. the client application looks up the EJB object to the client side CORBA client according to the specified JNDI (Java naming and directory interface) name.

32. The CORBA client looks up the EJB object to the naming service.

33. The naming service returns the proxy description object to the CORBA client. The proxy description object is a description object of an EJB object, and the CORBA client obtains a JVM identifier of the server, namely a UUID of the server through the proxy description object.

34. And the CORBA client reads the Proxy object from the Proxy description value factory, and the Proxy description value factory is used for reading the corresponding Proxy description value from the server side by the Proxy description object.

35. The proxy description value factory reads the class name of the EJB object from the proxy description object.

36. The proxy description object retrieves the local JVM identification of the client, i.e., the UUID of the client, from the JVM identification manager object, which is generated and maintained by the JVM identification manager.

37. The proxy description object checks whether the JVM ID of the server is consistent with the local JVM ID.

38. If the JVM identifier of the server is consistent with the local JVM identifier, the client and the server are in the same JVM, and then the EJB container creates a local call processing object.

39. If the JVM identifier of the server is inconsistent with the local JVM identifier, the client and the server are in different JVMs on behalf of each other, and then the EJB container creates a remote call processing object.

310. The agent description value factory retrieves the corresponding call processing object from the agent description.

311. The proxy description value factory creates a proxy object that is a proxy object for an EJB object that contains the call handling object.

312. The proxy description value factory returns the created proxy object to the CORBA client.

313. The CORBA client returns the received proxy object to the client application.

314. The client application calls the services provided by the EJB object. The proxy object will take over this call.

315. When the EJB container creates a remote local call, the proxy object delegates the local call handler to take over the call.

316. The local call processing object calls the EJB container to obtain the result.

317. And the EJB container returns the calling result to the local calling processing object.

318. The local call processing object returns the call result to the proxy object.

319. The proxy object returns the call result to the client application.

According to the processing flow of the method described in the above embodiment of the present invention, the present invention uses the UUID sent from the server to distinguish whether the client call is in the same JVM as the server, because the JVM identifier is unique, whether the client uses the same ORB or a different ORB, is considered as a remote-local call.

Under the condition of remote-local calling, JDK CORBA realizes dependence on ORB, but the invention does not depend on ORB and does not use CORBA interface; JDK CORBA implementations require the stubs to be placed into the environment variables, but the present invention does not require the stubs to be placed into the environment variables.

The JDK CORBA implementation uses a CORBA server to operate the EJB, and the servant routes the call to the container that created the EJB object. The present invention calls the container directly to perform the operation. Therefore, compared with JDK CORBA, the performance of the invention is better.

The schematic structural diagram of the apparatus for processing the EJB accessed by the remote interface called by the client according to the embodiment of the present invention is shown in fig. 4, and includes the following modules:

a JVM determining module, configured to determine that the JVM identifier of the EJB server is consistent with the JVM identifier of the client, indicating that the client and the EJB run in the same JVM, where the JVM determining module includes: a naming service submodule and an agent description object submodule;

and the local call processing module is used for processing the access of the client to the EJB by using a local call processing object, and the EJB is the EJB which is confirmed by the JVM confirmation module and is positioned in the same JVM as the client.

And the remote call processing module is used for processing the access of the client to the EJB by using a remote call processing object, wherein the EJB is an EJB which is not in the same JVM as the client.

The naming service submodule in the JVM determining module is configured to receive a signal that a client calls a remote interface to access the EJB, and return a pre-created proxy description object to the client;

the proxy description object submodule in the JVM determining module is configured to obtain a JVM identifier of an EJB server from inside the proxy description object, obtain a JVM identifier of the client from a JVM identifier manager object, compare whether the JVM identifier of the EJB server is consistent with the JVM identifier of the client, notify the local call processing module when a comparison result is yes, and notify the remote call processing module when the comparison result is no.

After the method and the device of the embodiment of the invention are applied, the remote invocation of the EJB can be optimized, and the performance of the remote invocation of the EJB is effectively improved. Before and after the method of the embodiment of the invention is applied, a schematic diagram of the performance comparison of a specific application example of the remote invocation of the EJB is shown in the following table 1:

table 1:

in the above specific application example, as shown in table 1, the performance of the remote-local call of the present invention is improved by 10 times compared with the performance of the existing remote call.

The above description is only for the preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present invention are included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for processing a client calling a remote interface to access an enterprise Java component EJB, is characterized by comprising the following steps:

2. The method according to claim 1, wherein the step a specifically comprises:

3. The method of claim 1, wherein step a is preceded by:

4. The method according to any one of claims 1 to 3, wherein step B specifically comprises:

5. A method for processing a client calling a remote interface to access an enterprise Java component EJB, is characterized by comprising the following steps:

6. The method according to claim 5, wherein the step E specifically comprises:

7. An apparatus for handling a client invoking a remote interface to access an EJB, comprising: the JVM determining module and the local calling processing module; wherein,

8. The apparatus of claim 7, further comprising:

9. The apparatus of claim 8, wherein the JVM determining module comprises: