1.1 Shortcomings of RPC
To meet the dynamic business needs in an organization, it becomes essential for the IT systems in the organization to collaboratively interact with each other in a real time fashion. As discussed in last chapter, customer profiles, product data, orders information, and service requests must be shared among the OiA, WMS, and CRM applications in order to serve the customers efficiently and satisfactorily. The approach using files, a common database, or network sockets provides a simple means to enable data sharing across applications, while RPC built upon network sockets introduces new concepts and features that make functionality sharing more computationally powerful and capable. These general-purpose integration concepts and features include:
- •
The concept of interface
- •
The concept of a service provider (i.e., server) at the application level
- •
The introduction of stub/proxy/skeleton, which shields programmers from the system and network programming at the fine-grained level
- •
The concept of marshalling/unmarshalling of arguments for transmission over the network
- •
The concept of platform independence via the use of external data representation (XDR), which encodes data in a machine-independent format
However, RPC does not provide all the fundamental and changing supports necessary for effectively implementing enterprise integration when heterogeneity and change become the norm. RPC inherently has the following major shortcomings due to its primitive design and technical limits at the time when it was introduced (Birrell & Nelson, 1984; Tanenbaum & van Steen, 2006):
- •
There is little room for code reuse. As the examples discussed in last chapter, the code for marshalling and unmarshalling and the code for network communication are buried inside the client and server applications.
- •
General speaking, RPC is not programming-language independent. For example, if a client is written in C and running on a Unix machine, while a server is written in Visual Basic and running on a Windows machine, RPC can’t make them share each other’s functionality in a straightforward way.
- •
Typically, RPC promotes point-to-point integration architecture, which could result in the egregious complexity of integrated systems in organizations. As the functions embedded in a server is what a client wants to invoke, the relationship between the client and the server is not peer-to-peer.
To have all silo-type applications integrated across business unit domains is the ultimate goal of implementing enterprise integration in the long run. Thus, the concepts and features introduced in RPC should ideally be able to address the data and functionality sharing issues in a heterogeneous computing environment. Figure 1 illustrates two different applications written in different languages while residing on different platforms. RPC provides no standard supports in addressing issues like lower level networks programming, data representation, communication protocols, error detection and recovery, transaction, and security in a heterogeneous computing environment.
Figure 1. A programmer’s view of implementation challenges between heterogeneous applications
As RPC can’t well address these heterogeneous integration challenges, obviously, the question becomes how the above-discussed shortcomings in RPC can be overcome. What kind of new approach is needed in order to make the general-purpose integration concepts and features more generic and practically well supported in heterogeneous IT systems, leading to improved reusability, scalability, and transparency of computing services?