EAI - RPC
Identification
Name: EAI - RPC
Category: Application/Technology
Version: v1.1
Modelling/Architecture Pattern: Architecture Pattern
Synonyms: Remote Procedure Call. Remote Procedure Invocation. RPI. Many references to SOA or ESB are references to this style of integration.
Contributor(s): Ed Walters
Attribution: This pattern is based on information in “Enterprise Integration Patterns” (Hohpe, Woolf 2003), supplemented by internet and Wikipedia searches.
Description
Context: The advent of networks and the internet makes it possible for applications to invoke functionality remotely, thus distributing the logic of an application into many 'moving parts', hosted if necessary on many different technologies. This style of application architecture promotes the re-use of published services.
Problem: The problem that recurs is the need to invoke a remote service in such a way that, to the application, it 'feels' like a local function call. EAI – RPC offers a solution to this type of functionality integration.
Trade-offs, Design Constraints (Forces): There are a number of forces to balance in this integration solution, such as: • Performance issues • Security issues • Coupling created with the services used • Robustness of networks and the implications of service failure • Scalability issues
Solution Structure: RPC is an integration pattern in which one application needs to invoke a service publicly exposed by another application in synchronous mode. In RPC there is a ‘client’ application and a ‘server’ application, which can communicate via a broker, called an RPC run-time system. In principle the arrangement is supposed to emulate making a local function call from the client’s perspective. Both the client and the server applications are registered with the RPC runtime system, which holds a registry of published services. Since the platforms for client and server could be quite different, their interface details are also held in the registry.
Solution Dynamics: In RPC the client application contacts the RPC system in synchronous mode requesting a service and passing any required parameters. Synchronous mode is necessary for certain application requirements, and the client is therefore blocked until the server replies. The RPC system invokes the requested service, using information from the registry. The system waits for a reply from the server which is then passed back to the client.
Layers/Aspects of the ArchiMate modelling language used: Applications/Technology.
Variants, Refinements and Combinations: Enterprise Service Bus (ESB). Service Catalogue.
Known Uses: This is a common pattern for distributed application systems and systems adhering to the SOA paradigm.
Other comments and references: An alternative or complementary approach to this pattern is the REST/HTTP pattern. Note that, given that most RPCs will be to 3rd party services, it would not be normal to include the details of the service provision in the architecture Model for the enterprise. If, however, the RPC is to an internal service, then those details should be known and documented.
Pattern Metamodel
Example(s)
![RPC_Example] In this example a CRM system needs to get the credit rating of a new customer. The enterprise uses an external credit agency for these purposes, which publishes a credit rating service.