Short description

The ERP CORBA interface provides infrastructure for remote, direct, and synchronous communication between the ERP system and CORBA clients. Using the interface, CORBA clients can call up special ERP functions. These functions are always implemented as background applications and can be called up independently of the concrete input/output channel, i.e. irrespective of the actual interface or communication technology. As the implementer of a background application is shielded from the specific technology used for the call-up, reusability in case of future extensions or changes in communication technology is ensured. CORBA is one of the technologies integrated in the ERP system.

The present document contains the description of the ERP system’s CORBA interface and that of the remote BIS interface using CORBA.

By means of the ERP CORBA interface, the ERP system is always called up from outside. The other direction, i.e. calling up other CORBA servers from within the ERP system, is not covered by the ERP CORBA interface and, thus, not described here in any detail. It is basically governed by the CORBA server to be used and its interfaces. In such cases, it also makes sense to use the ORB implementation, JacORB, that is delivered with the ERP system.

Target group

Users of the CORBA server interface; developers of background applications that can be called up remotely. A deeper understanding of CORBA and its functioning is required.

Definitions of terms

CORBA
The abbreviation stands for Common Object Request Broker Architecture, a specification developed by the OMG (Object Management Group) in 1992 that facilitates communication of a program’s components (objects) with the objects of other programs. Communication is even possible if two programs are written in different programming languages or run on different platforms. To this end, the platform-independent Interface Definition Language (IDL) was defined. When CORBA is applied, a program calls up objects with the help of an ORB (Object Request Broker). For this, it is not necessary to know and understand the structures of the program to which the object belongs. CORBA was designed to be used in object-oriented environments.

Logon (session)
The execution of background applications requires a runtime environment that provides all functions of the ERP system engine (e.g. persistence service). When background applications are executed remotely, such an environment must be explicitly created by logging on. Parameters for the logon are: the name of the system user, their password, and the name of the active OLTP database (optional). These parameters cannot be changed for the duration of the session.

Stateless call-up
A stateless call-up of a background application is a remote call-up that starts with a new instance of the background application being created; afterwards, the run() method of that background application is executed; and upon termination of the call-up, the application instance is released again.

Stateful call-up
A stateful call-up of a background application is a series of remote call-ups that starts with a new instance of the background application being created, consists of several call-ups of the background application’s run() method, and ends with an explicit call for the release of the background application.

CORBA clients

Supported CORBA implementations

On the server side, the ERP CORBA interface uses the ORB implementation JacORB. This is an open-source ORB implementation for Java, which provides high performance and stability while requiring few resources. However, CORBA clients are not limited to the use of JacORB; other implementations may generally be used as well.

The following table shows the CORBA implementations that are officially supported for clients, depending on the operating systems that the client and the ERP CORBA server run on.

JDK ORB refers to the CORBA implementation delivered with the JDK.

Other CORBA implementations – notably for other programming languages than Java – have not been tested and are not officially supported.

System components of a client

A CORBA client needs a suitable CORBA implementation as well as the classes generated from the IDL. Which components are necessary depends on the CORBA implementation. They are described in the following for JacORB.

JacORB

A Java client using JacORB requires the following components:

• Libraries jacorb.jar, avalon-framework.jar, and logkit.jar in the classpath
  (included in the ERP system installation; required JARs may differ for JacORB versions higher than 2.2.1)
• JacORB configuration file jacorb.properties in the classpath
  (is part of the application code)
• CORBA interface classes in the classpath
  (classes generated from the IDL file; are included in the system engine in the com.cisag.pgm.external.corba package or can be generated from the IDL file)

For productive clients, it is recommended to install the described components separately from the ERP system in order to avoid any dependency from the ERP installation. Test clients, in contrast, may directly use the JacORB version available in the ERP installation.

Further information on JacORB can be found under http://www.jacorb.org.

ERP CORBA server

As defined by the CORBA specification, the ERP system provides its own CORBA server (the ERP CORBA server). This server, in turn, makes the ERP CORBA interface available.

For each application server of the ERP system, a maximum of one ERP CORBA server can be started. One ERP CORBA server can process queries from any number of CORBA clients. Within an application server of the ERP system, the ERP CORBA server can be started either automatically when the application server is started or manually at any later time.

Manual start

For manual start, the tool shell command strscs (article: Start ERP CORBA Server) is available. Likewise, the ERP CORBA server can be stopped at any time using the tool shell command endscs (article: Stop ERP CORBA Server).

The syntax of the two commands is as follows:

strscs [-host:<text>] -port:<int> [-timeoutInterval:<duration>] 
  -host:<text>	                ORB host.
  -port:<int>	                ORB port.
..-timeoutInterval:<duration>	Timeout interval. Default: 30000. 

If the –host parameter is not specified, the ERP system uses a default. In the tool shell, the host used is always indicated in a message. In case of connection problems, specify the host to be on the safe side. The timeout interval is specified in milliseconds and can be set as described above.

endscs [-waitForCompletion:<boolean>] 
  -waitForCompletion:<boolean> Wait for the completion of all re-quests. Default: true.

Automatic start

In order to start the CORBA server together with the application server of the ERP system, the following properties are available to be added to the server.properties file of the application server as required:

• cisag.sys.kernel.corba.CorbaServerAutostart=true, false, default false
  Indicates whether the CORBA server is to be started automatically.
• cisag.sys.kernel.corba.CorbaServerHost=<host>
  Host of the CORBA server for automatic start.
• cisag.sys.kernel.corba.CorbaServerPort=<port>
  Port of the CORBA server for automatic start.
• com.cisag.sys.kernel.corba.CorbaServerTimeoutIntervalSeconds=<time>, default 30 Duration in seconds of the interval after which it is checked whether the client opening a session is still available. This value is only relevant for automatic start.

More detailed information on the mentioned and further properties can be found in the ERP properties article.

Usable ports

Every operating system has restrictions concerning the ports that can be used for the ERP CORBA server. Those have to be considered when choosing the ports.

See also http://java.sun.com/j2se/1.4.2/docs/guide/idl/tutorial/GScompile.html, as of March 2006.

ERP CORBA interface

CORBA clients can use the ERP CORBA interface to call up functions of the ERP system through CORBA. It is possible to call up both background applications delivered in the standard version and background applications that are the result of adaptations.

IDL interface description

The IDL of the ERP CORBA interface is stored as development object of the file category under the name com.cisag.pgm.external.corba.Corba-IDL. Within the file system of an ERP system installation, the IDL is contained in the following file: $SEMIRAMIS_HOME/files/com/cisag/pgm/external/corba/Corba.idl

In the ERP system engine, the Java classes generated from the IDL are located in the namespace com.cisag.pgm.external.corba. These classes can be used for an external CORBA client written in Java that works with the JacORB version delivered with the ERP system. If other ORB implementations or versions are used, new classes have to be generated from the IDL. For this purpose, the ORB implementation used contains appropriate tools. For other programming languages than Java follow the instructions of the respective ORB implementation.

The IDL contains the technical description of the CORBA interface and is the starting point for the development of an external CORBA client.

Within a release of the ERP system, the IDL is very stable. Future changes to the interface will mostly be enhancements and performance-related adaptations but no changes to the basic procedure (session manager, session, application).

Mapping of data types

The CORBA interface supports some of the data types that the ERP system supports on the server side for callable background applications.

Background applications that are explicitly developed for external call-up may only use the supported data types. External call-up of existing background applications only makes sense if the data types of all required parameters are supported.

The following data types are supported for the call-up of background applications via CORBA and their mapping in IDL or for a CORBA Java client:

Unless predefined in IDL or Java, the data types on the client side are stored in the

com.cisag.pgm.external.corba package. Data types not listed are not supported by the ERP CORBA interface even if they are used on the server side as parameters in background applications.

Timestamp

Timestamps (primitive timestamp data type of the ERP system) can be presented on the CORBA side with the IDL data type long long. On the server side, however, automatic mapping to the Java data type java.util.Date that is used for timestamps in the ERP system is not performed. Mapping in accordance with the Java method currentTimeMillis() must be executed individually in the background application of the ERP system.

Suitable constants for +∞, -∞, and an invalid timestamp are defined in the IDL interface CorbaDatatypeConstants

CisObjects and parts

CisObjectRepresentation and CisObjectRepresentationList are available from Comarch ERP Enterprise 4.4-PC-01. They are used to call up background applications that use transient CisObjects and parts as parameters. CisObjectRepresentation is meant for transfer of a CisObjects or part. CisObjectRepresentationList transfers a sorted collection of CisObjects or parts. 

Transferring  CisObjects and parts via CORBA creates a copy that contains the attribute values of the CisObjects or part at the time of the transfer.

An instance of CisObjectRepresentation comprises the name of the respective development object and the attributes of the instance:

• className: full name of the development object (business object or part)
• values: attribute names and values in the form of a CorbaParameterList

In case of CisObjects containing parts, the corresponding attribute value in the CorbaParameterList values is an instance of the CisObjectRepresentation that stands for the part.

During transfer from the client to the ERP system, the specified attributes are transferred. Attributes not specified are replaced in the ERP system by technical defaults and forwarded as such to the background application. Regarding transfer to the client, it solely depends on the background application whether attributes are specified in the CisObject.

Data types that are not supported by the CORBA interface cannot be transferred as attribute values of CisObjects or parts. Also note that GUIDs contained in CisObjects and parts are not automatically converted into a readable identification in case of transfer as CisObjectRepresentation. The interface of a background application to be developed can be kept lean by using special parts containing only the necessary attributes, instead of business object instances.

Functioning of a CORBA client

When implementing a CORBA client, you can use the sample clients delivered with the ERP system as reference. In the following, the steps required to establish a CORBA connection and to call up background applications are described.

Establishing a connection

Before a connection to the ERP CORBA server can be established, the ORB needs to be initialized. After that, the connection is established by creating a reference to the CorbaSessionManager object. A corbaloc: address is to be used for this, which is a string with the following format:

corbaloc::<host>:<port><SEMIRAMIS_CORBA_SESSION_MANAGER>

The elements host and port are the host name and port of the ERP CORBA server to which the connection is to be established. The third parameter is the value of the constant CorbaConstants.SEMIRAMIS_CORBA_SESSION_MANAGER from the IDL.

Session and authentication

Logon to the ERP system can be realized by means of the CorbaSessionManager, which generates a session in the ERP system. The signature is as follows: CorbaSessionManager::createSession (client, sessionParameters).

The client parameter is an object that is generated on the CORBA client side and implements the CorbaClient interface from the IDL. This object will be called up on the CORBA client by the ERP system in order to verify that the CORBA connection is still up. For this verification to work, it must be ensured that the CORBA server can reach the CORBA client under the IP address previously provided by the CORBA client.

In the parameter sessionParameters, the user name, the password of the user, and the OLTP database for the logon must be specified. User name and password will be checked as with any interactive logon. That means, in particular, that the user must be assigned to the system and must have the necessary authorizations in the system.

The result contains a CorbaSession object representing the session for the client as well as potential messages.

Logging off from a session is done with the following method:

CorbaSessionManager::logoutSession()

Calling up applications

From the CorbaSession object, a CorbaApplicationManager object is derived that can be used to call up background applications in the ERP system.

Parameters are transferred by means of CorbaParameterList objects. To enable transferring parameters for a call-up, a new CorbaParameterList object needs to be created: CorbaSession::createParameterList()

The call-up parameters are to be set in that object.

If a background application is to be called up in the ERP system in a stateless manner, a single call-up of the following method is sufficient: CorbaApplicationManager::callApplication()

Result of the method is a parameter list with return values as well as messages. If the parameter list is given as null, this means, by convention, that the call-up failed. The respective causes can be gathered from the messages. If the parameter list is not zero, the meaning depends on the background application called up. In general, it could also mean that the call-up was not successful. This would be the case if the background application called up provides detailed information on an error situation.

For stateful call-ups, the application needs to be generated first: CorbaApplicationManager::createApplication()

Afterwards, it can be called up several times with different parameters: CorbaApplicationManager::runApplication()

Just like stateless call-ups, stateful call-ups return a parameter list with return values. The meaning of zeros and messages is similar in both cases.

When the application of the stateful call-up is no longer needed, it must be released with: CorbaApplicationManager::releaseApplication().

For the exact signatures and the utilization of the methods, please refer to the IDL and the sample clients.

Whether a background application requires a stateless or stateful call-up depends on the concrete implementation of that application. For simple cases that need and return only a few parameters and resources, such as verifying an external key or storing a simple object, stateless applications are sufficient.

If large volumes of data are to be transferred, a stateful application can be used, for instance, to split the data query into blocks by performing several call-ups. This procedure is applied, amongst others, when calling up the export and import applications.

Releasing server-side CORBA objects

In CORBA, the lifespan of objects accessible through CORBA is not controlled by the CORBA implementation but managed for each application in the respective CORBA server.

To this end, the ERP CORBA interface provides for the explicit release of any CORBA objects no longer used; this release has to be performed by the client.

The following methods are available:

• CorbaParameterList::release()
  Releases the CorbaParameterList and any contained CorbaParameterLists. Release is required for all  CorbaParameterLists generated by the client as well as for the CorbaParameterLists returned by the CORBA interface, unless they are contained in other CorbaParameterLists. After the call-up, it is no longer possible to access the CorbaParameterList.
• CorbaMessageQueue::release()
  Releases the CorbaMessageQueue. Release is required for all CorbaMessageQueues that are returned by the CORBA interface. After the call-up, it is no longer possible to access the CorbaMessageQueue or any contained messages.
• CorbaApplicationManager::releaseApplication()
  Releases the indicated application.

The objects may only be released when the client no longer needs them.

Additionally, when closing a CORBA session, all CORBA objects of this session are automatically released. This is sufficient for CORBA sessions that only remain active for a very short time. Clients that keep sessions open for a long time, however, need to explicitly release server-side objects in order to avoid memory leaks.

Remote BIS interface using CORBA

The remote BIS interface consists of three background applications that can be called up through the CORBA interface.

Use cases

The background applications of the remote BIS are optimized for a scenario where both the initiation of the actual process and the transfer are performed exclusively via CORBA. This is regularly the case when there is no other way to exchange the payload between the CORBA client and the CORBA server.

The background applications are described in the following sections.

If, however, the CORBA client and the CORBA server have access to, for instance, a shared file system or the Knowledge Store, it might be sensible to directly store or retrieve the payload from there. This procedure has the following advantages:

• The load on the CORBA connection is reduced as less data needs to be transferred.
• The transfer of the data can be performed asynchronously to the actual process.
• It is possible to import linked files, e.g. files for attributes of the BLOB category.

To use this kind of call-up, you can perform a stateless CORBA call-up of the background applications described in the article Programming interfaces for data exchange, or call them up directly by means of the callApplication method of the CorbaApplicationManager.

Background applications

In the following, the actions, parameters, and return parameters for the background applications of the remote BIS are described.

A process in the remote BIS – irrespective of whether it is an import, an export, or a search – consists of several application call-ups aimed at the same application instance (stateful call-up). In block transfer of the data, the input parameters are specified and the first block of results is returned within the first call-up. All subsequent call-ups then deliver a further block.

The application instance must be generated beforehand. For this, the CORBA IDL contains the constants:

• CorbaRemoteImport.APPLICATION_NAME
• CorbaRemoteExport.APPLICATION_NAME, and
• CorbaRemoteSearch.APPLICATION_NAME

which have to be indicated as application name when generating the application instance.

Likewise, the CORBA IDL contains the actions, parameter names, and valueset constants for the applications as constants. They are located in the IDL interfaces:

• CorbaRemoteImport,
• CorbaRemoteExport, and
• CorbaRemoteSearch

When developing CORBA clients, these constants should be used.

In the below interface description, the data types of the parameters are given as Java or ERP system-specific data types. For a CORBA client, the respective client-side data types have to be used. This means for a CORBA client developed in Java that CorbaParameterList is to be used instead of CisParameterList.

Remote import with CORBA

Within the scope of an import process, the import data is transferred to the ERP system in blocks as XML document. Regarding the size of the data blocks to be imported, it needs to be considered that the CORBA client determines the size of the blocks transferred to the ERP system. Sensible values are between 250 kB and 1,000 kB. If the block size selected is too big, the main memory of the ERP system’s application server may be overloaded. A smaller block size requires a lot of roundtrips and, due to latency, leads to considerably increased transfer times.

For the event that import errors occur, you can define whether the incorrect data is to be corrected in the ERP system or an error file to be returned to the client. For correction within the ERP system, the Workflow Management notification is used as described in the article Introduction: Data exchange.

In case of correction within the ERP system, the error file is generated in the folder kstore://<WorkPane>/Import/RemoteErrorFiles in the Knowledge Store. As work pane, the standard work pane of the database where the data was imported is used. The folder should not be used for any other purposes.

A filter to be applied in an import process must have been created and stored beforehand in the Import data application. The name of that filter needs to be indicated. For more information, refer to the Import data article.

Actions and parameters

The background application for imports can be called up by means of the following actions:

The procedure of an import with an error file being returned is as follows:

1. The import process is started with the PROCESS action.
2. For further blocks, the action PROCESS_NEXT_BLOCK is called up as often as necessary.
3. To complete the import, PROCESS_LAST_BLOCK is called up. If no error occurred during import, the process is finished.
4. If errors occurred during import and an error file exists, this error file will be returned block by block upon call-up of the action GET_ERROR_FILE_NEXT_BLOCK. If you do not wish to have the error file transferred, call up CLOSE instead.

PROCESS action

The following parameters are available:

Return values: Empty parameter list.

An error occurred if the returned parameter list is null or the method requiresAttention() delivers true for the CorbaMessageQueue. In that case, the import process cannot be continued.

PROCESS_NEXT_BLOCK action

The following parameter is available:

Return values: Empty parameter list.

An error occurred if the returned parameter list is zero or the method requiresAttention() delivers true for the CorbaMessageQueue. In that case, the import process cannot be continued.

PROCESS_LAST_BLOCK action

The following parameter is available:

Return values in detail: tu tu

Whether the import was successful can be determined by calling up the method requiresAttention()  for the CorbaMessageQueue.The CorbaMessageQueue contains the messages that are part of what is returned by the application call-up.

• If the method requiresAttention() delivers the value false, the import was successful. The import process is completed.
• If the method requiresAttention() delivers the value true, an error occurred during import.
  • Pay attention to the messages returned.
  • Error cases can be differentiated by the returned counts. You will find a description of this in the article Introduction: Data exchange.
  • The return parameters tell you if an error file is available for transfer to the client. The error file can be transferred in subsequent call-ups using the action GET_ERROR_FILE_NEXT_BLOCK.

GET_ERROR_FILE_NEXT_BLOCK action

Call-up with empty parameter list.

Return values:

If there is no error file, zero is returned as value instead of the parameter list. It is possible that the last block of the error file does not contain any data. Therefore, the Content parameter is optional, and the client must verify whether it is contained in the parameter list returned.

CLOSE action

Call-up and return values: Empty parameter list.

Remote export with CORBA

For export processes, the following is specified: the name of the business entity to be exported, the database whose data should be exported, an optional filter, and restricting parameters. This data determines the number of business entity instances to be exported and can be specified either by an OQL search with selection parameters and sort order or by a dynamic OQL string that fulfills the same purpose.

A filter that is to be applied in an export process must have been created and stored beforehand in the Export data (or Import data) application. The name of that filter needs to be indicated. For more information, please refer to the articles Import data and Export data.

The XML document with the exported business entity instances is transferred to the client in blocks. The size of those blocks is about 500 kB.

Actions and parameters

The background application for export can be called up by means of the following actions:

The export procedure is as follows:

1. The EXPORT action transfers the parameters for the export. The result is the first block.
2. As long as there are further blocks, they are transferred by means of the action EXPORT_NEXT_BLOCK. If there is no further block, the export process is completed.
3. In order to export the XML scheme, it is sufficient to call up the GET_SCHEMA action once.

EXPORT action

The following parameters are available:

Return values:

An error occurred if the returned parameter list is zero or the method requiresAttention() delivers true for the CorbaMessageQueue. In that case, the export process cannot be continued. If no business entity instance could be exported because, e.g., no instance met the search parameters, the return parameters Content and ContentLength do not exist.

EXPORT_NEXT_BLOCK action

Call-up: Empty parameter list

Return values:

It is possible that the last block does not contain any data. Therefore, the Content parameter is optional, and the client must verify whether it is contained in the parameter list returned. All potential error cases have to be checked in the same way as with the EXPORT action. (see EXPORT action).

GET_SCHEMA action

The following parameters are available:

Return values:

An error occurred if the returned parameter list is zero or the method requiresAttention() delivers true for the CorbaMessageQueue. In that case, the process cannot be continued.

CLOSE action

Call-up and return values: Empty parameter list.

Remote search with CORBA

The search function is based on an OQL search. To restrict the search result, the selection fields of the OQL search can be used. Also, a sort order for the result may be indicated. The result of the search contains the return fields of the OQL search in each result row.

The search result is transferred page by page with each page being transferred after a separate application call-up.

In contrast to import and export, the search offers both a user-specific and a technical format for the selection parameters and the search results.

Actions and parameters

The following actions are available:

The procedure of a search with all search pages being returned is as follows:

1. Call-up using the SEARCH action and indicating the search parameters. The first result page is returned.
2. All other result pages are to be queried by means of the action SEARCH_NEXT_PAGE.

SEARCH action

The following parameters are available:

For the two formatting parameters, constants include:

• FORMAT_USER_DEPENDENT – user-specific format
• FORMAT_TECHNICAL – technical format

Return values:

An error occurred if the returned parameter list is zero or the method requiresAttention() delivers true for the CorbaMessageQueue. In that case, the process cannot be continued.

SEARCH_NEXT_PAGE action

Call-up with empty parameter list.

Return values:

An error occurred if the returned parameter list is

zero or the method requiresAttention() delivers true for the CorbaMessageQueue. In that case, the process cannot be continued.

EXISTS action

The following parameters are available:

Return values:

An error occurred if the returned parameter list is zero  or the method requiresAttention() delivers true for the CorbaMessageQueue. In that case, the search process cannot be continued.

CLOSE action

Call-up and return values: Empty CisParameterList.

Sample clients

With the ERP system, test clients are delivered that demonstrate the use of remote BIS interfaces. These test clients are part of the application code. If you have licenses for the system’s development kit SDK, the source code is also included.

The test clients can be called up from the tool shell as well as independently from the application server of the ERP system. Follow the instructions under Starting the test client and use the below names as tool name or class name.

Some test clients have parameters beyond those described in the CORBA Interface article. These additional parameters are documented in the source code and the JavaDoc.

The following test clients are available:

• Export
  Tool name: CorbaRemoteExportTestClient
  Java class: com.cisag.app.system.corba.log.CorbaRemoteExportTestClient
• Scheme export
  Tool name: CorbaRemoteSchemaExportTestClient
  Java class: com.cisag.app.system.corba.log.CorbaRemoteSchemaExportTestClient
• Import
  Tool name: CorbaRemoteImportTestClient
  Java class: com.cisag.app.system.corba.log.CorbaRemoteImportTestClient

• Search
  Tool name: CorbaRemoteSearchTestClient
  Java class: com.cisag.app.system.corba.log.CorbaRemoteSearchTestClient

The source code for the CORBA test client written in Java is available through the Development objects application.

The classes are documented in detail in the source code. Please note that the sample implementations use the generated classes from the ERP system engine as well as some classes of the PGM interface so that they can be called up easily with and without tool shell. When creating a stand-alone CORBA client, these components are not needed.

Procedure

To execute the test client, follow these instructions.

Starting the server

In the tool shell of the ERP system: strscs –host:localhost –port:2000

Starting the test client

The test client is included in the standard package as a number of development objects. Besides the Java classes, an application of the Tool category is defined for it. The test client is started on the tool shell by means of: CorbaTestClient -host:localhost -port:2000 -userName:<user> -password:<password> -oltpDatabaseName:<OLTP database>

The background application called up remotely by the test client transfers the incoming application parameters as return values in the call-up result. In addition, it sends a message of the error category. Return values and error message are output in the console.

It is also possible to call up the test client from outside the tool shell. To do so, you only have to include JacORB (jacorb.jar, avalon-framework.jar, and logkit.jar), the ERP system engine, and the application code into the class path. The call-up then looks as follows:

java com.cisag.app.system.corba.log.CorbaTestClient
-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
-Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton
-cp <class path>
-host:<host>
-port:<port>
-userName:<user>
-password:<password>
-oltpDatabaseName:<OLTP database>

Error messages

Should you receive an error message like: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No check the parameters of CORBA server and CORBA client as well as the communication between them. If errors occur during logon of the CORBA client or when executing the background applications on the ERP system’s application server, they are stored in message logs depending on their severity and can be viewed there.

CORBA and firewalls

CORBA realizes an object-oriented and therefore state-based architecture. A basic principle in this is the independence of objects from the concrete place where they are made available. As a result, there are two essential requirements for the communication between a CORBA server and a CORBA client:

• Since client and server interchange object references, the client must be able to actively forward call-ups to the server and, in turn, the server must be able to actively forward call-ups to the client. Thus, the roles of client and server are virtually irrelevant after the initial setup of the connection.
• As per definition, object references and the objects addressed by them constitute a state. Consequently, a stateful communication protocol needs to be used.

Problems with communication between CORBA clients and CORBA servers are often caused by firewalls that are positioned en route between client and server in the network. Mostly, firewalls only let certain network protocols pass so that dialog logon to the ERP system is possible through https://, but a CORBA client cannot access the ERP system via iiop://.

With CORBA, it poses more of a problem to pass firewalls than with other network protocols. This is because of the protocol used and has the following reasons:

• CORBA implementations themselves assign port numbers at runtime. Since these port numbers are not predictable, they cannot be configured as permitted ports in port-based firewalls.
• When transferred through the network, object references contain an IP address and a port number so that the corresponding object can be directly addressed by the ORB implementation on the receiving side. Using NAT (network address translation) on a router or firewall, however, leads to a computer being addressed in different network segments with different addresses; as a consequence, an IP address transferred in the protocol is no longer valid on the receiving side.
• CORBA often uses callbacks from the server to the client. For this, the client must be accessible to the server, which is prevented by many firewalls.

For security reasons, it is not advisable to forgo the use of firewalls. To solve the above problems, different vendors offer so-called application security gateways. These are products specifically tailored for CORBA that provide authentication, security, and routing mechanisms not on the IP address level but on the level of CORBA object references.

Protection against resource bottlenecks

Every session that a client opens in the ERP system via CORBA uses resources such as memory, computing time, and database connections of the application server to which the client connects. If a scenario requires many clients that are all continuously connected to the CORBA server, resource bottlenecks may occur. In such a case, critical resources are primarily the CORBA sessions (and the database connections). From the time of its creation, every CORBA session occupies a thread in the ERP system, i.e., heap memory for the thread stack and native resources depending on the operating system. When processing a CORBA request, the ORB uses a thread from its pool to receive the request and then forwards it to the ERP system’s thread. If processing the CORBA request requires reading data from the database, database connections are temporarily occupied as well.

Memory, threads, and database connections are limited resources on the application server. A resource bottleneck causes longer processing times for CORBA call-ups. In the worst case, the stability of the application server as a whole may be at risk.

There are several options to avoid resource bottlenecks. The basic idea behind all of them is to coordinate the access to critical resources in order to prevent too many concurrent accesses.

The first solution (Figure 1) uses several CORBA servers, i.e., application servers of the ERP system, among which the client accesses are distributed. This reduces the memory consumption of each application server. However, this solution may put a high load on the database if many requests reach the application servers at the same time.

The second solution (Figure 2) uses a stand-alone process that is independent from the ERP system (CORBA Proxy Queue). The clients’ requests are sent to this process which puts them in a queue and then forwards a limited number of the requests at once to the ERP system. Thus, the number of CORBA sessions and the number of database connections in the ERP system are limited. The CORBA Proxy Queue acts as both CORBA server and CORBA client. Therefore, such a queue can be implemented in any language, depending on the use case.

For both of the solutions described, it is assumed that each process is executed on a separate computer and has, therefore, exclusive access to that computer’s limited resources. A CORBA Proxy Queue should also always be operated on a separate computer.

Right from the development stage of a CORBA connection to the ERP system, tests should be carried out taking the expected number of clients into account. Doing so enables you to determine whether measures for resource protection are required in the specific case.