Service-based enterprise integration model easy to get started, part 2nd: Further Introduction to the evolution of basic concepts

Introduction

The 1th and 2nd parts of this series mainly explore the development of enterprise integration patterns, introduce some basic concepts, and highlight integration patterns based on Service Oriented Architecture (SOA). Part 1th describes two early patterns: Data sharing (socket programming) and RPC, which explores the concepts of service providers and service consumers, platform independence, and connectivity.

To improve the capabilities of RPC, we now introduce the following two methods:

A distributed object, also known as an object request agent, Broker,orb: This approach focuses on code reuse and language independence.

Asynchronous messaging: This approach solves the tight coupling problem between applications.

Let's first take a look at the distributed object approach because it is more closely related to RPC. Currently, most application servers are based on ORB technology.

Distributed objects: Object Request Broker

The implementation of distributed object technology has three main types. One of these is language independence and platform independence, the so-called common Object Request Broker Architecture (Common object requests broker Architecture,corba). Other technologies are dependent on language or platform and language. Java Remote Method Invocation (RMI) is an example of a language-dependent technology, while the Microsoft Distributed Object Component Model (DCOM) and the Ibm® system Object Model (SOM) are examples of platform-dependent technologies.

Now we'll go into the details of CORBA, because it's the most common (language-independent) technology, and products from different vendors and based on this technology can be used together. For example, an orb based IBM Websphere®application Server can communicate with application servers for many other vendors.

In addition to introducing object-oriented benefits such as inheritance, polymorphism, and encapsulation, CORBA introduces a number of new features. The most important possibility is to count the orb, the Orb extracts code for marshaling input and output parameters and code for communicating from client and server applications to independent software components. In addition, the ORB provides a device for obtaining a reference to a remote object in order to invoke methods on that remote object.

This separation allows multiple applications to reuse the same code and to allow some degree of separation between applications by removing the application from point-to-point integration. Removing an application from point-to-point integration may be the first step in the development of an ESB concept. Figure 1 illustrates this scenario, which shows that multiple applications on the same computer can communicate with each other using the same ORB and can communicate with applications on different computers.

Figure 1. Multiple applications communicate with each other through the ORB, demonstrating code reuse and indirect communication through the ESB (first step in the direction of the ESB)

Figure 2 shows the basics of how the orb works. When an application needs to use a service from another component, it first obtains a reference to the object that provided the service. When an object reference is obtained, the client application can invoke the method on that object, which is like a local object.

Figure 2. Method calls using the Orb on a remote object, including getting a remote object reference