Managing Distributed Objects and Services

Managing Distributed Objects and Services

DOI: 10.4018/978-1-4666-3910-2.ch004
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

To overcome the discovered shortcomings in a procedure-based programming language, object-oriented design (OOD) and object-oriented programming (OOP) emerged in the late 1980s and then became popular in 1990s. OOD/OOP has been widely applied in practice since the early years of 21st century. In this chapter, the need for distributed objects and messaging in enterprise applications is first discussed. As more and more distributed applications have been developed using OOP languages, integration practitioners have to understand how distributed objects and messaging based applications can be efficiently and cost-effectively designed and managed to meet the needs of enterprise integration in the long run. Moreover, there are many different programming languages that can be used to program object-oriented applications. Managing distributed objects in a heterogeneous computing setting is then fully explored. Finally, the middleware technology in support of effective management of distributed objects and services is articulated. Examples of leveraging middleware to manage distributed applications are provided.
Chapter Preview
Top

1. Review Of Rpc And Object-Oriented Design And Programming

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?

Complete Chapter List

Search this Book:
Reset