Enterprise Information Integration (EII) Via a Powerful Integration Tool
By Brian Livingston, Product Development
Table of Contents
Remote Procedure Calls 2
SQL-Based Remote Procedure Calls 2
CONNX Solutions’ RPCs 6
Enterprise application integration is one of the highest business priorities today. Many companies seeking to broaden their enterprise IT architecture to meet changing business requirements are faced with the dilemma of supporting legacy data sources and their associated legacy applications. In most cases, those applications continue to be vital to the operation of a department, and to the business as a whole. However, the limited interoperability and inter-application communications capabilities of many
legacy applications poses a challenge to any integration effort. Standards such as the SQL query language have made it possible to bridge access to legacy data from new and advanced enterprise business solutions via middleware data integration tools. Yet in many cases access to the data is not enough. The many years and countless dollars (for hardware, software, development, and consulting services) spent developing solutions that solve individual business problems often make the cost of developing new or modernized applications prohibitive. Integration via remote procedure calls can ad- dress those challenges by providing new programmatic interfaces to hard-to-extend applications and by enabling existing applications not only to interoperate, but also to be orchestrated through new business logic and process rules.
Remote Procedure Calls
A Remote Procedure Call (RPC) extends the notion of a local procedure call to a networked procedure call. An RPC is a powerful tool in a distributed application environment. Based on the client-server model, an RPC executed in a client application ultimately executes a procedure in a non-local address space. The caller may be executing a procedure on the local ma- chine or on disparate systems with a network connecting them. An RPC mechanism isolates the calling application from the physical and logical elements of the data communications mechanism. An RPC is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure. In many cases, the remote procedure may actually execute a chain of applications on the host system.
SQL-Based Procedure Calls
SQL access is the defacto standard for most of the reporting, analysis and web access tools on the market today. The SQL query language standard has made it possible to access flat file-based legacy enterprise data ( Adabas, VSAM, RMS, C-ISAM, DISAM, etc. ) in a relational manner. Middleware solutions, such as those provided by CONNX, exemplify this type of capability. SQL access involving heterogeneous joins between disparate, relational, and non- relational data sources are made possible. Having SQL access to RPCs is a powerful tool that can bring new value to existing applications. An RPC can consist of something as simple as running a command, such as ‘SHOW TIME’ on a VMS server, or as sophisticated as executing a Fortran routine on an IBM mainframe. The ability to incorporate values returned from an RPC into a SQL query offers powerful control and access methods to existing applications and data systems. SQL-based RPCs are powerful integration commands that can be utilized in strategies to preserve existing investments.
CONNX Solutions RPCs
By providing a SQL-based interface such as that found in the CONNX application, RPCs are now available from .NET, JDBC, OLE DB and ODBC applications. The CONNX SQL RPC implementation is unique, designed for ease of use, and provides the ability to join the results of RPCs with other relational and non-relational data sources in a relational manner. Additional- ly, CONNX now supports RPCs for IBM mainframes, in particular the ability to remotely execute a CICS transaction. Input and output is automatically marshaled through the COMMAREA when the CICS transaction is executed. CONNX SQL RPCs are defined as separate tables to the CONNX Data Dictionary. Over 400 data types are available for automatic conversion of input and output fields to the RPC functions via CONNX. Data for input fields is specified as criteria in the WHERE clause of the SQL statement, and the output fields come back as normal result columns.
CONNX Solutions RPCs Continued...
Figure 1 below shows a very simple VMS based RPC that displays the current time. Figure 2 shows that this RPC returns a single column of data. Execution of the RPC is as simple as executing a SQL statement, as shown in Figure 3. RPCs that accept input parameters can also be easily executed through SQL statements, as shown in Figure 4. The query below looks like a simple query against a table, but, in fact, it is executing an RPC, and sending the value
‘ALWAO’ as input to the RPC. The output of the RPC is the data returned from the execution of the remote procedure, in this case a customer name retrieved from a VAX Basic RMS access routine. RPCs can be executed through JDBC connections as well, extending the reach of RPC to any platform that supports Java. If you have existing business logic on the host platform that you want to preserve and take advantage of through your new application, SQL-based RPC is the right technology for the job.