A better way to integrate your Java client applications
This article originally published in the Architects Corner section of our LANSA Review customer magazine Issue 24, 2002.
LANSA Integrator Remote Function Invocation (RFI) is middleware that makes remote integration as easy as coding with local objects. The Java client developer creates and works with local objects and then sends these objects to the remote LANSA Java Service Manager (JSM) server, the remote service uses a local copy of these objects to supply data to the host program. The host program can also create new objects and return a copy to the Java client program for local processing.
Advantages of the LANSA Integrators RFI service are:
- Java programs do not need to know anything about where the data resides.
- Accessing data is faster because the RFI service requires no remote database connections using JDBC or similar database access methods.
- There is no need for an exchange of XML documents and the implicit overhead of creating and interpreting the XML.
LANSA Integrator RFI is a fast and simple approach to send/receive data to/from remote programs.
Java integration can be difficult
Java is an excellent Business-to-Business (B2B) environment but there are a number of organizational reasons why the integration of an existing server application with a Java application can be difficult.
Skill differences cause delays and errors
Java is an Object-Oriented language. Many traditional IBM i server applications are procedural, not Object-Oriented. Integration causes these very different programmer worlds to collide. Delays result from the learning curve.
Too many chiefs can make B2B integration a nightmare
Today, IT applications often need to be integrated with external systems. Whether it is a supplier system connecting with customer systems or a central IT system integrating with departmental systems, often no one manager has total control over the integration standards used. The result can be a nightmare of complex integration standards. Many organizations are using Java as a standard but, when you integrate a remote system, you could access your server with any of JDBC, RMI, EJB or LANSA Integrator's RFI. Poorly designed integration can result in ongoing performance and maintenance problems.
Java Database Connectivity API (JDBC)
JDBC is based on ODBC but adapted for Java. The JDBC API provides support for sending SQL query and update statements to a database server. JDBC primarily allows data access, leading you to code business rules in the remote application. This duplicates the business rules you already have on the server, creating maintenance issues. JDBC can be slow because high network traffic results from frequent database access across the network.
LANSA Integrator RFI reuses your existing business rules. All object access proceeds via your business rules. Network traffic is reduced because RFI sends/receives only an object across the network. The object is only ever decomposed on the host into its constituent physical files and fields.
Remote Method Invocation (RMI)
Unlike JDBC, RMI is remote program access rather than only remote data access.
RMI is similar to a Client/Server Remote Procedure Call (RPC) except that RMI is for objects and RPC is for procedural programs.
With an RPC, your remote program calls a program stub locally that acts as a proxy for the real server program. Calling parameters are passed over the network to the server program for execution and results are returned to the proxy for ultimate return to the originating program. RMI is the action of invoking a remote interface on a remote object. Passed parameters are objects rather than data structures.
Performance is affected if application design requires numerous method calls. In the current RMI implementation, a new socket connection is created for every remote method invocation. Establishing a network connection can take a significant proportion of the total execution time of the remote method. RMI can be complex to deploy. While programming for RMI is relatively straightforward, a complex administrative solution is required to support the runtime environment. Also, the developer needs to write the program to handle the client proxy for the server object.
LANSA Integrator RFI is easier to deploy. It is faster because it sends/receives a whole object and not just a method invocation.
In this example, we have a Java client application, which receives customer orders that we want processed by a server-based application. How do you do that with RFI, and what Java skills are needed? Only the Java application requires Java coding skills.
The Java application assembles the order details such as customer number, items ordered and quantities in a Java order object. This order object is passed to LANSA Integrator RFI. The Java application does not need to understand how the files are physically implemented on the server. Also, it does not matter to the server how the Java application obtains the order details.
Your LANSA RDML program (or 3GL equivalent) on the server
Your program receives the order details in the order object from RFI and processes the order using native and efficient database commands. Only your server application needs to know how the files are physically organized. It might, for example, write the order header information such as customer number to the order header file and write the order detail information such as product number and quantity to the order details file. If there are any validation errors from LANSA Repository Business Rules then these messages could be placed in an application working list and sent via RFI to the Java application to handle appropriately.
Before your server program can send and receive objects, you must define a mapping of the fields and lists to the Java variables used by the Java application. This mapping definition is used by the LANSA Integrator RFI service called DataSource when copying data. The Java program can then create, send, and receive objects.
Ease of maintenance
File physical details are contained within your server application. You can change physical organization without affecting your Java program. For example, your company might merge with another and move your order-related files to the new company's system but you could mask that from the Java program if you wanted. Similarly, your Java application can change how it obtains and assembles orders without affecting your server application. For example, you could change from using JSPs/HTML in a Browser to using an XML transaction to gather order details.
RFI means your data access uses native commands and network traffic is minimized because much of the processing is done on the server.
If the object sent or received contains all the data for a single logical transaction, then RFI is very fast because all the I/O is local and not across the network. In contrast, since JDBC is working at a file level not an object level, there is a lot more processing to be done in a JDBC-based application. As a result, there is also more network traffic to send/retrieve each file's details.