MOM Vs RPC
|
Feature |
MOM |
RPC |
|
Metaphor |
Post-office like |
Telephone like |
|
Client/Server time relationship |
Asynchronous. Clients and Servers may operate at different times and speeds |
Synchronous. Clients and Servers must run concurrently. Servers must keep up with clients. |
|
Client/Server Sequencing |
No fixed sequence |
Servers must first come up before clients can talk to them. |
|
Style |
Queued |
Call-Return |
|
Partners need to be available |
No |
Yes |
|
Load-balancing |
Single queue can be used to implement FIFO or priority based policy |
Requires a separate TP Monitor. |
|
Transactional Support |
Yes (Some Products) Message Queue can participate in the commit synchronization |
No. Requires a Transactional RPC. |
|
Message Filtering |
Yes |
No |
|
Performance |
Slow. An intermediate hop is required |
Fast |
|
Asynchronous processing |
Yes. Queues and triggers are required |
Limited. Requires threads and tricky code for managing threads. |
Remote Procedure Call
“RPCs are not procedure calls at all, they are truly process invocations. The invoked program runs across the wire in a different resource domain”
- A client process calls a function on a remote server and suspends itself until it gets back the results.
- Parameters are passed like in any ordinary procedure.
- The RPC, like an ordinary procedure is synchronous.
- The process (or threads) that issue the call waits until it gets the results.
- Under the covers, the RPC run-time software collects values for the parameters, forms a message, and sends it to the remote server.
- The server receives the request, unpacks the parameters, calls the procedure, and sends the reply back to the client.
- While RPCs make life easier for the programmer, they pose a challenge for the NOS designers who supply the development tools and run-time environments.
- The Common issues are:
How are the Server functions located and started?
- Server starts the process, when a remote invocation is received with necessary parameters and returns the response to the client.
- What happens when multiple clients invoke the same function? Now an environment is needed to start and stop servers, prioritize requests, perform security checks, and provide some form of load-balancing.
- Each incoming requests invokes a thread in the server side.
- A server loop is created to manage the pool of threads waiting for work rather than create a thread for each incoming request.
- TP Monitors are really need on the server side, which provides more functions than a NOS.
How are parameters defined and passed between the client and the server?
- The better NOSs provide an Interface Definition Language (IDL) for describing the functions and parameters that a server exports to its clients.
- An IDL compiler takes these descriptions and produces source code stubs (and header files) for both the client and server.
- These stubs can then be linked with the client and server code.
- The client stubs packages the parameters in an RPC packet, converts the data, calls the RPC run-time library and waits for the server’s reply.
- On the server side, the server stubs unpacks the parameters, calls the remote procedure, packages the results, and sends the reply to the client.
How are failures handled?
- Both the sides of the RPC can fail separately, it is important for the software to be able to handle all the possible failure combinations.
- If the server does not respond, the client side will normally block, timeout, and retry the call.
- The server side must guarantee only once semantics to make sure that a duplicate request is not re-executed.
- If the client unexpectedly dies after issuing a request, the server must be able to undo the effects of that transition.
How is security handled by the RPC?
- Modern NOSs, like DCE – make it easy to automatically incorporate their security features into the RPC.
- All you need to specify is the level of security required; then the RPC and security feature will cooperate to make it happen.
How does the client find its server?
- The association of a client with a server is called binding.
- The binding information may be hardcoded in the client.
- The client can find its server by consulting a configuration file or an environment parameter.
- A client can also find its server at run time through the network directory services. The server must, of course, advertise their services in the directory.
- The process of using the directory to find a server at runtime is called dynamic binding
- RPC can be used to find a server. The RPC client stub will locate a server from a list of servers that support the interface. This is called automatic binding.
How is data representation across systems handled?
- The problem here is that different CPUs represent data structures differently (Ex: bigendian Vs little endian)
- To maintain machine independence, the RPC must provide some level of data format translation across systems.
- Example: Sun RPC requires that clients convert their data to a neutral canonical format using the External Data Representation (XDR) APIs.
- In contrast, DCE’s Network Data Representation (NDR) service is multicanonical, meaning that it supports multiple data format representations.
- The client chooses one of these formats, tags the data with chosen format, and then leaves it up to the server to transform the data into a format it understands.
- In other words, the server makes it right. It lets the client to do translation, which makes the life easy for the server.
- With Sun, all clients look the same to the server: The Client makes it right.
RPC, Messaging and Peer to Peer
- Client/Server applications are split across address spaces, physical machines, networks and operating systems.
- All NOSs offer peer-to-peer interfaces that let applications communicate using close to the wire send/receive semantics.
- Most NOSs provide some form of RPC middleware that hides the wire.
- An alternative type of model – message queueing or simple MOM – incredibly helpful in situations when the tight synchronization is not needed between the clients and servers.
Communication Stacks
|
Application |
Messaging |
RPC |
Peer-to-Peer |
||||||||||
|
Named Pipes |
DCE |
SUN |
|||||||||||
|
Presentation |
|
NDR |
XDR |
|
|||||||||
|
Session |
Peer-to-peer service API |
||||||||||||
|
NetBIOS Sockets TLI CPI-C/APPC |
|||||||||||||
|
Transport |
Common Transport Semantics |
||||||||||||
|
NetBEUI |
TCP/IP |
SPX/IPX |
LU6.2 /APPN |
||||||||||
|
Network |
|||||||||||||
|
LLC |
IEEE802.2 |
||||||||||||
|
MAC |
NDIS (OR) ODI |
||||||||||||
|
IEEE 802.5 (Token Ring) |
IEEE 802.3 (Ethernet) |
SDLC |
ISDN |
||||||||||
|
Physical |
Fiber Optic |
Coax |
Twisted Pair |
||||||||||
- Each layer has a well-defined set of APIs and Protocols.
- With these mix-and-match can be done.
- Practically, an entire stack of from a single vendor.
- The lowest layer of the communication software belongs to the device drivers that provide an interface to several types of communication hardware adapters.
- Real products don’t have any notion of architectural boundaries or reference models – they just get a job done.
- At the lower layers, they interface to the hardware using MAC protocols defined by IEEE.
- The LLC provides a common interface to the MACs and a reliable link service for transmitting communication packets between two nodes.
- The transport layer provides end-to-end delivery service.
Introduction to the Distributed Computing Environment
CICS(R) Transaction Server for z/OS(R) supports DCE remote procedure calls.
In conjunction with the OS/390(R) Unix Systems Services DCE Base Services MVS/ESA(TM) and OS/390 Unix Systems Services DCE Application Support MVS/ESA CICS Feature products, CICS Transaction Server for z/OS enables a CICS program to act as a server for a DCE RPC. (Note that DCE RPC uses the DCE Security and Directory Services.) This is described in DCE remote procedure calls.
The main advantage of a DCE remote procedure call over a CICS DPL call is that you can call CICS programs from non-CICS environments.
This section tells you what the Distributed Computing Environment (DCE) is and why you might want to use it. For more detailed information, you should refer to the books listed in DCE remote procedure calls.
What is DCE?
DCE (Distributed Computing Environment) is an architecture defined by the Open Software Foundation (OSF) to provide an Open Systems platform to address the challenges of distributed computing. It is being ported to all major IBM(R) and many non-IBM environments. Note that all current DCE implementations use TCP/IP rather than SNA as their communication protocol.
The Distributed Computing Environment (DCE) is a software system developed in the early 1990s by a consortium that included Apollo Computer (later part of Hewlett-Packard), IBM, Digital Equipment Corporation, and others. The DCE supplies a framework and toolkit for developing client/server applications. The framework includes a remote procedure call (RPC) mechanism known as DCE/RPC, a naming (directory) service, a time service, an authentication service, an authorization service and a distributed file system (DFS) known as DCE/DFS.
History
DCE came about to a large degree as part of the Unix wars of the 1980s. After Sun Microsystems and AT&T worked together to produce UNIX System V Release 4 (SVR4), many of the other Unix vendors felt their own market opportunities were unduly disadvantaged. They quickly formed the Open Software Foundation (OSF) to compete with a BSD-based Unix that more closely matched their own offerings. OSF ended up introducing OSF/1, which was based on the Mach kernel and had relatively poor performance compared to SVR4, and was little used except by Digital.
As part of the formation of OSF, various members contributed many of their ongoing research projects. At the time, network computing was quite popular, and many of the companies involved were working on similar RPC-based systems. By re-building these various utilities on a single “official” RPC mechanism, OSF could offer a major advantage over SVR4, allowing any DCE-supporting system (namely OSF/1) to interoperate in a larger network.
The DCE system was, to a large degree, based on independent developments made by each of the partners. DCE/RPC was derived from the Network Computing System (NCS) created at Apollo Computer. The naming service was derived from work done at Digital. DCE/DFS was based on the Andrew File System (AFS) originally developed at Carnegie Mellon University. The authentication system was based on Kerberos, and the authorization system based on Access Control Lists (ACLs). By combining these features, DCE offers a fairly complete C-based system for network computing. Any machine on the network can authenticate its users, gain access to resources, and then call them remotely using a single integrated API.
Distributed computing never really caught on as much as had been hoped for in the late 1980s and early 1990s. The rise of the Internet, Java and web services stole much of its mindshare through the mid-to-late 1990s, and competing systems such as CORBA muddied the waters as well. Perhaps ironically, one of the major uses of DCE/RPC today are Microsoft’s DCOM and ODBC systems, which use DCE/RPC (in MSRPC) as their network transport layer.
OSF and its projects eventually became part of The Open Group, which released DCE 1.2.2 under a free software license (the LGPL) on 12 January 2005. DCE 1.1 was available much earlier under the OSF BSD license, and resulted in FreeDCE being available since 2000. FreeDCE contains an implementation of DCOM.
Architecture
The largest unit of management in DCE is a cell. The highest privileges within a cell are assigned to a role called cell administrator, normally assigned to the “user” cell_admin. Note that this need not be a real OS-level user. The cell_admin has all privileges over all DCE resources within the cell. Privileges can be awarded to or removed from the following categories : user_obj, group_obj, other_obj, any_other for any given DCE resource. The first three correspond to the owner, group member, and any other DCE principal respectively. The last group contains any non-DCE principal. Multiple cells can be configured to communicate and share resources with each other. All principals from external cells are treated as “foreign” users and privileges can be awarded or removed accordingly. In addition to this, specific users or groups can be assigned privileges on any DCE resource, something which is not possible with the traditional UNIX filesystem, which lacks ACLs.
Major components of DCE within every cell are:
- the security server that is responsible for authentication
- The Cell Directory Server (CDS) that is the respository of resources and ACLs and
- The Distributed Time Server that provides an accurate clock for proper functioning of the entire cell. Modern DCE implementations such as IBM’s are fully capable of interoperating with Kerberos as the security server, LDAP for the CDS and the Network Time Protocol implementations for the time server.
While it is possible to implement a distributed file system using the DCE underpinnings by adding filenames to the CDS and defining the appropriate ACLs on them, this is not user-friendly. DCE/DFS is a DCE based application which provides a distributed filesystem on DCE. DCE/DFS can support replicas of a fileset (the DCE/DFS equivalent of a filesystem) on multiple DFS servers – there is one read-write copy and zero or more read only copies. Replication is supported between the read-write and the read-only copies. In addition, DCE/DFS also supports what are called “backup” filesets, which if defined for a fileset are capable of storing a version of the fileset as it was prior to the last replication.
DCE/DFS is believed to be the world’s only distributed filesystem that correctly implements the full POSIX filesystem semantics, including byte range locking. DCE/DFS was sufficiently reliable and stable to be utilised by IBM to run the back-end filesystem for the 1996 Olympics web site, seamlessly and automatically distributed and edited worldwide in different timezones.
DCE is based on three distributed computing models:
Client/server
A way of organizing a distributed application
Remote procedure call
A way of communicating between parts of a distributed application
Shared files
A way of handling data in a distributed system, based on a personal computer file access model.
CICS(R) alone (without DCE) also supports distributed computing. See Distributed computing.
The rest of this section gives a high level view of the services provided by DCE.
Remote procedure call (RPC)
One way of implementing communications between a client and a server of a distributed application is to use the procedure call model. In this model, the client makes what looks like a procedure call, and waits for a reply from the server. The procedure call is translated into network communications by the underlying RPC mechanism. The server receives a request and executes the procedure, returning the results to the client.
In DCE RPC, you define one or more DCE RPC interfaces, using the DCE interface definition language (IDL). Each interface comprises a set of associated RPC calls (called operations), each with their input and output parameters. You compile the IDL, which generates data structure definitions and executable stubs for both the client and the server. The matching parameter data structures ensure a common view of the parameters by both client and server. The matching client and server executable stubs handle the necessary data transformations to and from the network transmission format, and between different machine formats (EBCDIC and ASCII).
You use the DCE Directory Service to advertise that your server now supports the new interface you defined using the IDL. Your client code can likewise use the Directory Service to discover which servers provide the required interface.
You can also use the DCE Security Service to ensure that only authorized client end users can access your newly defined server function.
Directory Service
The DCE Directory Service is a central repository for information about resources in the distributed system. Typical resources are users, machines, and RPC-based services. The information consists of the name of the resource and its associated attributes. Typical attributes could include a user’s home directory, or the location of an RPC-based server.
The DCE Directory Service consists of several parts: the Cell Directory Service (CDS), the Global Directory Service (GDS) 3 , the Global Directory Agent (GDA), and a Directory Service programming interface. The CDS manages a database of information about the resources in a group of machines called a DCE cell. The Global Directory Service implements an international, standard directory service and provides a global namespace that connects the local DCE cells into one worldwide hierarchy. The GDA acts as a go-between for cell and global directory services. Both CDS and GDS are accessed using a single Directory Service application programming interface (API).
Security Service
There are three aspects to DCE security: authentication, secure communications, and authorization. They are implemented by several services and facilities that together comprise the DCE Security Service. These include the Registry Service, the Authentication Service, the Privilege Service, the Access Control List (ACL) Facility, and the Login Facility.
The identity of a DCE user or service is authenticated by the Authentication Service. Communications are protected by the integration of DCE RPC with the Security Service. Communication over the network can be checked for tampering or encrypted for privacy. Finally, access to resources is controlled by comparing the credentials conferred to a user by the Privilege Service with the rights to the resource, which are specified in the resource’s Access Control List. The Login Facility initializes a user’s security environment, and the Registry Service manages the information (such as user passwords) in the DCE Security database.
Time Service
The DCE Time Service (DTS) provides synchronized time on the computers participating in a Distributed Computing Environment. DTS synchronizes a DCE host’s time with Coordinated Universal Time (UTC), an international time standard. DTS cannot keep the time in each machine precisely the same, but can maintain it to a known accuracy. DTS also provides services which return a time range to an application (rather than a single time value), and which compare time ranges from different machines. They can be used to schedule and synchronize events across the network.
File Service
The DCE File Service (DFS(TM)) allows users to access and share files stored on a File Server anywhere on the network, without having to know the physical location of the file. Files are part of a single, global namespace. A user anywhere on a network can access any file, just by knowing its name. The File Service achieves high performance, particularly through caching of file system data. Many users can access files that are located on a given File Server without a large amount of network traffic or delays.
The File Service is based on a personal computer view of files, and is not relevant to the CICS Transaction Server for z/OS(R) environment.
Threads
DCE Threads supports the creation, management, and synchronization of multiple threads of control within a single process. This component is conceptually a part of the operating system layer, the layer below DCE. If the host operating system already supports threads, DCE can use that software and DCE Threads is not necessary. Because all operating systems do not provide a threads facility and DCE components require threads be present, this user-level threads package is included in DCE.
DCE Remote Procedure Calls
This section gives an overview of how CICS(R) cooperates with the OS/390(R) Unix Systems Services DCE Base Services MVS/ESA(TM) and OS/390 Unix Systems Services DCE Application Support MVS/ESA CICS Feature products to enable a CICS program to act as a DCE server.
Refer to the following books for more information about the OS/390 Unix Systems Services DCE Base Services MVS/ESA product:
- DCE: Understanding the Concepts
- Introducing the z/OS(R) Distributed Computing Environment
- z/OS Distributed Computing Environment: Application Development Guide, for guidance information about developing the client code and using the Unix System Services DCE MVS/ESA base services.
- z/OS Distributed Computing Environment: Application Development Reference, for reference information about application programming interfaces (APIs).
Refer to the following books for more information about the OS/390 Unix Systems Services DCE Application Support MVS/ESA CICS Feature:
- OS/390 DCE Application Support Programming Guide, for information about how to install CICS remote procedure call server programs.
- z/OS Distributed Computing Environment: Application Support Configuration and Administration Guide, for information about the administration tasks that complement the programming tasks.
