Abstract:
A method for processing a communication socket request begins by generating a socket request by a virtual machine running on a server. The virtual machine examines the socket request and determines whether the socket is identified by a host name or by an Internet Protocol (IP) address. The socket request is forwarded to a host environment if the socket is identified by a host name or by an IP address other than a predetermined IP address of the host environment, and the host environment creates the socket. The server processes the socket request if the socket is identified by the predetermined IP address of the host environment, and the server creates the socket. In one implementation, the virtual machine is a Java virtual machine and the server is a Java server.

Description:
FIELD OF INVENTION 
       [0001]    The present invention is related to providing socket connections in a computer system, and in particular, to providing a socket connection between a Java server and a host environment. 
       BACKGROUND 
       [0002]    An application written in the Java programming language is designed to be executed on a Java Virtual Machine (JVM). There are different JVMs for different computer operating systems, such as Microsoft Windows, Mac OS, Linux, and Master Control Program (MCP). 
         [0003]    In an MCP environment, the MCP operating system controls all job initiation and termination, data access (file input/output (IO) and management), and network access (sockets). Applications are deployed to the MCP file system and sockets are opened from the MCP environment. Java command parameters are entered on the MCP to initiate a “Java proxy” on the MCP. In this sense, a proxy is a software agent that performs a function or operation on behalf of another application or system while hiding the details involved. In this case, the other application is the JVM, which is subsequently initiated on a Java server. The command parameters entered on the MCP are passed to the JVM. Depending on the implementation, the Java server may be running on a specialized processor (e.g., a Java processor) or on a different operating system (e.g., a Windows system). 
         [0004]    In a current implementation, the JVM is isolated in the sense that it is unable to make any direct external connections and must utilize the host environment for all external connections. For example, where the JVM is running on a Windows environment and the host environment is running the MCP OS, the JVM does not use the Windows socket functionality (i.e., the WinSock library) but routes all socket requests to the MCP OS. To achieve this, the JVM implements a socket redirection mechanism which routes the socket requests from the JVM to the MCP OS. One use of the socket redirection is to resolve host names specified in a uniform resource locator (URL), for example, when the JVM wants to access an external database. 
       SUMMARY 
       [0005]    The MCP file system is used for all data and user Java programs. The Windows file system is used for temporary files or for fixed content, such as Windows font files, Java archive (JAR) files, and files to support the execution environment. 
         [0006]    One type of JVM is an “eMode JVM,” which supports the ALGOL programming language and its extensions. In the eMode JVM, a getFileSystem( ) Java native method is used to create the MCPFileSystem in the Java Runtime Environment (JRE). The MCPFileSystem is a modified version of the WinNTFileSystem that supports a dual MCP/Windows file system environment, allowing directory management functions to apply to either the MCP file system or the Windows file system. A modified version of the standard C Runtime Library is used to support the dual file system, allowing calls to MCP or to Windows depending on the target file name. 
         [0007]    The Windows environment on which the JVM is actually run is integrated with the MCP environment. In particular, files, sockets, native functions (i.e., Java Native Interface (JNI)), and other functions are supported by software running in both the Windows environment and the MCP environment. 
         [0008]    For file IO and file management functions, the JVM uses the underlying C/C++ functions, e.g., open, read, and print. To avoid extensive JVM patching, the underlying C Runtime library is modified to call the appropriate OS environment to allow JVM IO to function with minor modifications. To make a network connection external to the JVM, the JVM utilizes the host environment to create a socket for the connection. The JVM implements a socket redirection mechanism which routes the socket requests from the JVM to the host environment. 
         [0009]    The socket redirection mechanism in the JVM can effectively be bypassed when connecting to an application running in the MCP environment if the socket request uses a numeric Internet Protocol (IP) address for the socket endpoint instead of a host name. The socket redirection functionality recognizes that the IP address was specified and uses the Java server&#39;s built-in socket mechanism (e.g., if the Java server is running the Windows OS, then the WinSock library is used) to create the socket. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    A more detailed understanding of the invention may be had from the following description of a preferred embodiment, given by way of example, and to be understood in conjunction with the accompanying drawings, wherein: 
           [0011]      FIG. 1  is a block diagram showing a construction of a host environment interacting with a Java server environment; 
           [0012]      FIG. 2  is a flowchart showing the operation of the environment shown in  FIG. 1 ; and 
           [0013]      FIG. 3  is a flowchart showing the operation of a worker thread. 
       
    
    
     DETAILED DESCRIPTION 
       [0014]      FIG. 1  is a block diagram of a system  100  showing a host environment  102  interacting with a Java server environment  104 . The host environment  102  shown in  FIG. 1  is an MCP system. The MCP system is exemplary, and the principles of the present invention are applicable to any host environment running any operating system.  FIG. 2  is a flowchart of a method  200  showing the operation of the system  100 . The operation of the system  100  will be described in conjunction with  FIGS. 1 and 2  simultaneously. 
         [0015]    The host environment  102  includes a Java support library  110 , a Java process  112 , a plurality of Java worker threads  114 , a Java IO library  116 , a Java sockets library  118 , a plurality of other Java support processes  120 , and a data storage  122 . The Java server environment  104  includes a JVM  130 , a C runtime library  182 , a socket redirect library  134 , an interconnect library  136 , a data storage  138 , a monitor service process  140 , and a connection pool  142 . 
         [0016]    In operation, once the Java server environment  104  is started (step  202 ), the monitor service  140  attempts to communicate with the Java support library  110  to control the Java server environment  104 . Once the Java support library  110  is initiated, it offers an open connection, which allows the monitor service  140  to establish a control dialog (step  204 ). After the control dialog is successfully created, Java applications can be executed. 
         [0017]    To start a Java application, the Java process  112  is run on the host environment  102  (step  206 ). The Java process  112  is the host environment&#39;s “proxy” for the JVM  130 . The Java process  112  links to the Java support library  110  and starts establishing a session. The Java support library  110  sends a message to the monitor service  140  through the control dialog to start the session and initiate the JVM  130 . As part of this communication, the Java command parameters are passed from the Java process  112  to the monitor service  140 . Upon successfully establishing the session, the monitor service  140  initiates the JVM  130  on the Java server  104  (step  208 ). 
         [0018]    The JVM&#39;s first step is to initialize the C Runtime Library (CRT)  132 . In an MCP environment, the C Runtime Library is a modified version of the Microsoft Visual C Runtime Library, MSVCRT. The CRT  132  contains the low level functions for file open, read, write, close, etc. After initializing its internal file management tables, the CRT  132  establishes a connection back to the host environment  102  through the interconnect library  136  (step  210 ). The interconnect library  136  provides a marshaling mechanism for converting Intel data into eMode data. The Intel data is in a different format than the eMode data, and needs to be converted via the marshaling mechanism to be usable in both environments. 
         [0019]    The CRT  132  is modified to redirect all IO calls to the host environment  102 , so that all of the IO is performed in the host environment  102 . The Java applications are installed in the host environment  102 , and by redirecting the IO to the host environment  102 , file management advantages (such as more secure applications) are gained. This allows the Java server environment  104  to be isolated, because all the files and all the sockets (anything that is an external view) are represented on the host environment  102 . Naming conventions are provided to simplify the redirection via a JAVA_BOOT directory, so some files can reside on the Windows side and eliminate having to go back and forth to the host environment  102  for the files. 
         [0020]    For example, MCP files are identified by the MCP POSIX (Portable Operating System Interface) naming convention, e.g., /-/J2EE/DIR/JRE/LIB/ . . . . A Java application, however, can specify a filename by its relative path name, e.g., RT.JAR, prior to performing a low-level IO call to the JVM file system routines to establish the fully normalized file name. 
         [0021]    The initial connection from the CRT  132  through the interconnect library  136  causes the Java support library  110  to instruct the Java process  112  to create a worker thread  114  (step  212 ). The initial connection from the CRT  132  is used to retrieve various system information, such the initiating user&#39;s USERCODE (user ID) and the location of the data storage  122  containing the JRE and the current directory setting. It also enables the Java IO support library  116  to build its file management tables, which are used to support the IO functions in the host environment  102 . 
         [0022]    A worker thread  114  is initiated by the Java process  112  when required by the JVM  130  and is invoked using standard MCP IPC (inter-process communication). The worker thread  114  is passed an integer which identifies the worker thread and is used to create a unique name for the thread&#39;s communication path. A worker thread  114  waits for a message and calls a JVM support library  116 - 120  to service the request. 
         [0023]      FIG. 3  is a flowchart of a method  300  showing the operation of a worker thread  114 . Once created, the worker thread  114  opens a communication path via the Java support library  110  and the interconnect  136  to the JVM  130  (step  302 ). If there is an error in opening the communication path (step  304 ), the worker thread exits (step  306 ). After opening the communication path, the worker thread  114  waits for a message from the JVM  130  (step  308 ). If the worker thread encounters an error while waiting for a message (step  310 ), the worker thread exits (step  306 ). When the worker thread  114  receives a message, it calls the appropriate support library  116 - 120  to handle the request contained in the message (step  312 ). If there is an error in calling the support library, the worker thread returns an error response to the JVM (step  316 ). The worker thread  114  receives a response from the called library and sends the response to the message from the JVM  130  that sent the request (step  316 ). If there are no errors, the worker thread  114  waits for additional messages from the JVM  130  (step  308 ) as described above. 
         [0024]    Referring back to  FIGS. 1 and 2 , depending on the request, the worker thread  114  calls a library  116 - 120  to process the request (step  214 ). In the system information example, the worker thread  114  calls the Java IO library  116 , which handles all the file IO and file management requests in the host environment  102 . The Java IO library  116  gathers the requested information and returns a response to the Java support library  110  through the worker thread  114 . The Java support library  110  sends the response to the interconnect library  136 , where the data is marshaled from eMode format into Intel format. The response is returned to the CRT  132 , which forwards the response to the JVM  130 . 
         [0025]    As the JVM  130  continues to initialize, it opens various files, such as the MCPLocales file, located in the JRE in the data storage  122  on the host environment  102 . Requests to open files on the host environment  102  are routed through the interconnect library  136 , through the Java support library  110 , to a worker thread  114 , and to the Java IO library  116 . The Java IO library  116  performs the requested service and returns the response. 
         [0026]    For performance reasons, some files are located on the Java server  104 , including the RT.JAR and TOOLS.JAR files. The location of these files is specified by the reserved family name JAVA_BOOT (on the data storage  138 ). Using the JAVA_BOOT directory permits various Java Archive (JAR) files, such as the TOOLS.JAR file, to be identified in a current path parameter using the host environment&#39;s naming conventions. The JAVA_BOOT directory is a JRE directory that is read-only from Java applications. The JAVA_BOOT area is defined as the entire directory tree under the location pointed to by the registry value ImagePath for the currently executing JVM. To access files in the JAVA_BOOT area, a Java program uses a path that starts with /-/JAVA_BOOT. The JVM file system implementation substitutes the Windows Java home directory for /-/JAVA_BOOT in the path name. For example, to include the TOOLS.JAR file in a class path, the reference would be: /-/JAVA_BOOT/lib/tools.jar. 
         [0027]    Another special directory on the Java server  104  is the JAVA_WORK directory, which is mapped to a directory on the Java server  104  in such a way that each host environment user has a separate work area and cannot access any other user&#39;s work areas. In one implementation, the JAVA_WORK directory is mapped based on the user&#39;s running USERCODE. For security reasons, each host environment user has a different subdirectory under the JAVA_WORK directory. In this implementation, it is not possible for a Java program running under one user ID to access a Windows file created by a Java program running under a different user ID. 
         [0028]    To access files in the JAVA_WORK area, a Java program uses a path that starts with /-/JAVA_WORK. The JVM file system implementation substitutes the Windows work area parent directory, followed by a file name separator character (/), followed by the host environment user name, for /-/JAVA_WORK in the path name. For example, assume that the JAVA_WORK registry value contains the value E:\JavaWork/Area. A Java program run by user JBOSSUSER may reference the path /-/JAVA_WORK/tmpldeployfile. This path accesses the Windows file E:\JvaWorkArea\JBOSSUSER\tmp\deployfile. 
         [0029]    The user&#39;s view of the disk areas on the Java server is restricted to the JAVA_BOOT and JAVA_WORK directories. As an example, in JBoss (a Java-based application server), the user can set the working directory to the JAVA_WORK directory. This places the workload onto the Windows side, so that back and forth access to the host environment  102  is not needed. Reducing the cross-environment access for file IO also creates a performance benefit by speeding up certain IO operations of the Java program. A further performance benefit can be gained by placing transaction and log services on the Windows side, thereby further reducing host environment access. 
         [0030]    As the JVM  130  continues its initialization process, a socket is opened by calling the socket redirect library  134 , which is a substitute for the standard WinSock library. The socket requests are routed through the interconnect library  136 , like file requests to a worker thread  114 , which in turn calls the Java sockets library  118  on the host environment  102 . This library call invokes a link to a socket support library on MCP for the actual socket handling. Because requests for IO and socket functions can happen asynchronously, the interconnect library  136  maintains a connection pool  142  on the Java server  104 . There is a one-to-one correlation between a connection and a worker thread  114 , but subsequent requests to read a file, for example, do not necessarily go to the same connection and worker thread  114 . 
         [0031]    As the Java application continues its execution, additional requests can be made of host environment  102  resources. In an MCP implementation, several different libraries  122  have been created, including JAVAPRIV, JAVARUNTIME, JAVAREALMLIB, JAVAMCPFILELIB, JAVACOMSLIB, and JAVATIMELIB. 
         [0032]    Access to the host environment  102  is based on the privileges associated with the user (in MCP, this is the user&#39;s initiating USERCODE). The monitor service  140  runs on the Java server  104  as a global service and all JVMs are initiated with that same global user identifier. All requests for MCP resources are handled by the initiating Java process  112  through the Java support library  110  connection manager and the worker threads  114 . 
         [0033]    Upon termination of the JVM  130  (steps  216  and  218 ), the monitor service  140  sends the JVM&#39;s exit code to the Java support library  110 , which instructs the Java process  112  and all worker threads  114  to terminate (step  220 ). When the Java process  112  terminates, it returns the exit code to the MOP OS, which inserts it into the task&#39;s TASKVALUE. 
         [0034]    Socket Redirection 
         [0035]    As described above, all socket requests are routed through the interconnect library  136 , which in turn calls the Java sockets library  118  on the host environment  102 . This library call invokes a link to a socket support library on the host environment  102  for the actual socket handling. 
         [0036]    Implementing socket requests in this manner effectively isolates the JVM  130  in the sense that it is unable to make any direct external connections and must make all external connections through the host environment  102 . For example, where the JVM  130  is running on the Windows OS and the host environment  102  is running the MCP OS, the JVM  130  does not use the Windows socket functionality (i.e., the WinSock library), but routes all socket requests to the MCP OS. To achieve this, the JVM  130  uses the socket redirect library  134  which routes the socket requests from the JVM  130  to the MCP OS. One use of the socket redirection functionality is to resolve host names specified in a uniform resource locator (URL), for example, when the JVM  130  wants to access an external database. 
         [0037]    For communication with applications running in the host environment  102 , the socket redirection can effectively be bypassed if the socket request uses a predetermined numeric Internet Protocol (IP) address of the host environment  102  for the socket endpoint instead of its host name. While the host environment  102  may have multiple IP addresses associated with it, one of those addresses may be selected and used as the predetermined IP address. The socket redirect library  134  recognizes that the predetermined IP address of the host environment  102  was specified in the socket request and uses the Java server&#39;s built-in socket mechanism (e.g., the WinSock library on the Windows OS) to create the socket. The socket redirect library  134  interprets all socket requests. If the socket request includes a host name, the socket request is passed to the host environment  102  to resolve the host name. If the socket request includes the predetermined numeric IP address of the host environment, the socket redirect library calls the socket library functions of the Java server  104 . If the socket request includes any other numeric IP address, the socket request is redirected to the host environment  102 . 
         [0038]    Specifying the predetermined numeric IP address of the host environment provides a performance benefit because the socket requests can be handled by the Java server  104  and they do not have to be passed to the host environment  102  and through several support libraries. An additional performance benefit comes from the fact that a host name does not have to be resolved (not requiring access to a domain name server to resolve the domain name). 
         [0039]    As one example, suppose the JVM  130  wants to access a database residing on the host environment  102 . The JVM  130  uses a Java database connectivity (JDBC) driver and specifies the database&#39;s location in a URL, by host name or by IP address. If the host name is used, then the socket redirect library  134  forwards the request to the host environment  102  to resolve the host name prior to accessing the database. If the predetermined numeric IP address of the host environment is used, the socket redirect library  134  accesses the Java server&#39;s socket mechanism, bypassing the host name resolution. The performance benefit of using the IP address is more noticeable if the JVM  130  accesses the database frequently over a period of time. 
         [0040]    Supporting Multiple Java Servers 
         [0041]    The Java support library  110  maintains a list of available Windows environments. When the Java process  112  calls an initiate function, the Java support library  110  assigns a Windows environment to handle the program. The Java support library  110  identifies each JVM by a combination of a process identifier (PID) from the Java server  104  of the JVM  130  and a process number from the host environment  102  (when using MCP as the host environment, this is referred to as a MIX number) of the Java process  112 . Multiple concurrent executions of the Java process  112  are identified by this number. The Java support library  110  retrieves relevant environment information for the job. The Java support library  110  creates a message containing the initiate request, job parameters, socket number, and environment information. This message is sent to the Java monitor service  140  in the Java server environment  104 . The initiate function returns successfully upon receipt of an acknowledgement from the monitor service; otherwise, it returns an error. 
         [0042]    The Java monitor service  140  receives the initiate message from the Java support library  110  and deciphers the message, translating data as necessary. It builds an environment block from the environment information and socket number in the message. It creates a process to start the JVM  130 , passing the job parameters as the command line and the environment block. 
         [0043]    Runtime Support 
         [0044]    MCP runtime functions are accessed by sending messages to the MCP OS. The JVM  130  calls a function in an interface DLL to access the MCP. This interface DLL creates a message to handle the function, converting any data as needed. The message is sent by calling a function in a communication DLL, which maintains a list of available worker threads  114  that handle requests. If no worker threads  114  are available, the DLL sends a message to the Java process  112  identified by its dialog ID to request a new worker thread  114 . When a worker thread  114  is available, the DLL sends the function request message to that worker thread  114 . 
         [0045]    Termination 
         [0046]    The Java program may terminate in one of three ways: normal termination, forced termination, or fault termination. 
         [0047]    Normal termination occurs when the Java program terminates without an exception. It may have an error, but not one that causes an abnormal termination. Before normal termination, the JVM  130  sends a terminate message containing any exit codes for the process to the Java process  112 . It then closes the communication channel and exits. 
         [0048]    When a worker thread  114  receives the terminate message, it calls a function in the Java support library  110  to process the message. This function saves any exit codes and changes its state to terminating. When the communication channel closes, the Java process  112  terminates with the specified exit code. When the Java process  112  terminates, the Java support library  110  frees all resources assigned to that instance of the Java process  112 . 
         [0049]    Forced termination occurs when the Java process  112  is terminated unexpectedly, e.g., with a DS (discontinue) command from the MOP OS. Terminating the Java process  112  closes the communication channel. The JVM  130  terminates when the channel is closed. 
         [0050]    Fault termination occurs when the JVM  130  terminates unexpectedly. The Java monitor service  140  tracks the state of the JVM  130 . When the JVM  130  terminates unexpectedly, the monitor service  140  sends an abort message to the Java support library  110  containing error information on how the JVM  130  terminated. 
         [0051]    The Java support library  110  receives the abort message and saves the error information. The Java process  112  calls a function to retrieve this information. If the function is called before the message is received, the function waits a reasonable amount of time to receive that information before returning. 
         [0052]    When the communication channel closes without receiving a terminate message, the Java process  112  calls the function in the Java support library  110  to retrieve the error information. Upon return from the function, the Java process  112  terminates and displays the error information. 
         [0053]    Java Monitor Service 
         [0054]    The state of a Java server environment  104  and its jobs (i.e., JVMs) may be monitored through the Java monitor service  140 , which runs on the Java server  104  (Windows, for example) to handle Java support. The monitor service  140  receives a message on its port, deciphers the message, and performs the appropriate action. It may retrieve information from the Windows OS, from a configuration database, or from a running JVM  130 . The monitor service  140  communicates management information with the host environment  102  and logs relevant events in the Windows application log. 
         [0055]    The monitor service  140  automatically begins when the Java server  104  starts. After initializing, the monitor service  140  attempts to connect to the Java support library  110  on the host environment  102  and logs the result of this attempt. If the attempt fails, the monitor service  140  periodically retries the connection (without logging) until successful. Once successful, the monitor service  140  sends a connection message to the host environment  102 . This message contains the Java server number and the dialog number. 
         [0056]    Once the connection is established, the monitor service  140  reads its control dialog for management messages, sending responses as appropriate. These management messages include:
       Initiate—This message initiates the execution of a JVM  130 . The monitor service  140  uses the information in the message to create a process to run the JVM  130 . It sends an InitiateAck response once the JVM  130  has started. The monitor service  140  waits for the JVM  130  to complete and examines the result If the JVM  130  terminates abnormally, it sends an abort message to the host environment  102 .   Status—This message requests the monitor service  140  to send configuration information and system status information.   Terminate JVM—This message requests the monitor service  140  to terminate a JVM  130 .   Dump—This message requests the monitor service  140  to cause the JVM  130  to perform a memory dump.   Job Info—This message requests the monitor service  140  to send detailed JVM process information.       
 
         [0062]    The monitor service  140  may also make requests of the Java support library  110  or provide unsolicited status information to the Java support library  110 . These management messages include:
       JVM Terminated—This message tells the Java support library  110  that a JVM  130  has terminated.   Status Request—This message is used as a “heartbeat” to monitor the connection to the host environment  102 . The lack of a response or an error response indicates that the connection has been lost. This message is also used to exchange time synchronization messages with the host environment  102 . This allows the Java server  104  to maintain the same system time as the host environment  102 .       
 
         [0065]    Java Support Library 
         [0066]    The Java support library  110  runs on the host environment  102  to handle Java function management. Under MCP, this is a CONTROL library that starts during MCP initialization. Once initialized, the Java support library  110  listens on its port for management messages from the monitor service  140 , sending responses as appropriate. Messages handled by the Java support library  110  include:
       Status Request—This message contains the configuration information and system status of a Java server  104 . The Java support library  110  updates its information with the information in the status request message and records the time the message is received. If a status request message is not received from an overdue Java server  104 , the Java support library  110  marks the Java server  104  as down and stops scheduling jobs on that Java server.   JVM Terminated—This message is received when a JVM  130  terminates abnormally. The Java support library  110  records any error information returned in the message for later retrieval by the initiating program.       
 
         [0069]    The Java support library  110  also provides functions to interact with the Java process  112  and the worker threads  114 , including:
       Initiate—This function is called by the Java process  112  to initiate a JVM  130 . The Java support library  110  examines its list of Java servers  104  and assigns a server to perform the job. The Java servers  104  may be assigned using one or more methods: round-robin, least-busy, or user-assigned. The Initiate message is built and sent to the Java server  104 . The Java support library  110  waits a reasonable amount of time to receive an InitiateAck response. If the response is not received, or if it returns with an error, the function returns an unsuccessful response. If the response returns OK, the function returns the socket number with a successful response.   Terminate—This function is called when a Java process  112  is terminating. The Java support library  110  marks the corresponding JVM  130  as terminating and send a Terminate JVM message to the monitor service  140 .   Aborted—This function is called when the communication channel to the worker threads  114  is closed without receiving a terminate message. The Java support library  110  marks the corresponding JVM  130  as aborting. If any error information is recorded with the process, it is returned. If not, the library  110  waits a reasonable amount of time to receive the abort message from the Java server  104 . If the abort message is received, the function returns the error information. If it does not receive the abort message, the function returns with an unsuccessful response.       
 
         [0073]    C Runtime Library 
         [0074]    The C Runtime Library (CRT) exports a full set of file IO functions that can operate on either the Windows file system or the MCP file system. The file system decision is based on the full path name passed to an open function and the subsequent file descriptor value. 
         [0075]    The CRT uses an internal table to manage and track file descriptors. When a file is opened, an entry is added to the internal table, using the table index as the file descriptor returned to the application. The actual file descriptor is stored in the table along with some additional file information obtained from the OS. An indicator is added to the table to identify the OS where that file exists. In this way, the CRT can make the appropriate calls to MCP to handle the IO requests. File descriptors 0, 1, and 2 are reserved for STDIN, STDOUT and STDERR and need not be opened before use; they are automatically mapped to the MCP environment. 
         [0076]    Windows Interconnect DLL 
         [0077]    Service requests from the JVM  130  are intercepted and handled by the MCP OS. The Windows interconnect DLL  136  is invoked to format the parameters into a message to send to the MCP OS. This DLL has an entry point function (EPF) for every service that can be invoked. The EPF converts its parameters into eMode formats and stores them into a message. Knowledge of the message format for each service request is shared between the EPF and the corresponding function in the Java support libraries  116 - 120  within the MCP environment  102 . The EPF formats the results into Intel format and returns them to the caller. 
         [0078]    Two functions are provided in the interconnect DLL  136  to manage the communication paths for worker threads  114 . The first function selects an available communication path and a worker thread  114  to send the message. This routine maintains a list of available paths. It selects one path, removes it from the available list, and assigns it to this function call. If no communication path is available, the function sends a message to the Java process  112  to create another communication path. The second function releases an in-use path for reassignment by placing it in the available list. The EPF uses these two functions to obtain a path to a worker thread  114 . The communication paths and the corresponding worker threads  114  are closed and destroyed when they are no longer needed. 
         [0079]    It is noted that the present invention may be implemented in a variety of systems and that the various techniques described herein may be implemented in hardware or software, or a combination of both. Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone (without the other features and elements of the preferred embodiments) or in various combinations with or without other features and elements of the present invention. While specific embodiments of the present invention have been shown and described, many modifications and variations could be made by one skilled in the art without departing from the scope of the invention. The above description serves to illustrate and not limit the particular invention in any way.