Introduction to Middleware Technologies

Introduction to Middleware Technologies

Introduction The integration of applications within and between business is made possible using middleware technology.

Learning Objectives Need for Middleware Client/Server Building Blocks
Generic Middleware Service-Specific Middleware RPC Middleware Message-oriented Middleware (MOM) Java RMI

Need For Middleware

Middleware Till 1980s most of computing was based on central host computers equipped with powerful processors and memory Users interact with the host through the terminals that capture keystrokes and send the information to the host Bottlenecks of this architecture are: Processing power is limited to that of central host system. Over dependence on the vendor for application software. Lack of support for GUI and access to multiple dBs Mainframes are an example of this architecture

Middleware With the advent of PCs the files are downloaded from the shared location, processed and uploaded back to the file server. The file server approach had a major drawback as it generated too much n/w traffic. However, with the emergence of the client/server architecture the computing power for process management was distributed between file and server For example, the client could query database server using relational database management systems through SQL The results of the query are send to the client which then manipulates and processes the data. SQL=Standard Query Language

Middleware This 2 tier client/server architecture has a scalability limitation as the server is unable to contain the load when the number of users grows beyond a certain limit. Moreover, any changes in applications or parameters would entail changes at all clients. To overcome these limitations, middle tier was added between the user system interface client environment and dB management server environment This middleware provides for connectivity across the heterogeneous platform. A middleware is in some way analogous to a middleman who acts as a translator between a 2 people speaking different languages. SQL=Standard Query Language

Middleware Some of the design constraints of a good client/server system are as follows: Facility to hide communication details Language and platform independency Enable processing on client or server or both Middleware has emerged as a solution to satisfy these constraints. Middleware is a distributed s/w that aids in transparent communication between client and server. It runs on both the client and the server as shown in the following figure SQL=Standard Query Language

Middleware Middleware Logical View Physical View Middleware Middleware

Middleware In the client/server model, the client requests for a service to be provided by the server. A proper s/w glue between client and server system is essential to support all interactions between them. Middleware serves this purpose. It plumbs 2 sides of an application and passes information between them. It is a software that seamlessly integrates two disparate entities – the client and the server. It includes all software needed to support interactions between the client and the server. It starts with the client API that invokes the service, covers the transmission of request over the n/w and the resulting response

Middleware Middleware thus manages the interaction between disparate applications across the heterogeneous computing platforms Middleware aids in business process integration, application integration, data integration, standards integration and platform integration. Middleware exists between the application and the OS and network services on a system node in the n/w Middleware services are sets of distributed software that provide an extension to the functional APIs provided by the OS and n/w services

Middleware(advantages)
This increased functionality allows an application to: Locate transparently across the n/w, provide interaction with another application or service. Be independent from n/w services Be reliable and available Scale up in capacity w/o losing functionality Be OS & PL transparent

Middleware-Based Operating System
The OS for distributed computing can be networked OS, distributed OS or middleware- based OS. Distributed OS A distributed OS performs the same function as a uni- proccessor OS, but it runs on multiple CPUs The goal of distributed OS is to hide and manage hardware resources. It is manages as a single system. Distributed OS may be multi-processor based or multi- computer based. Multiple computers are homogenous or heterogeneous is nature.

Distributed OS Structure Application Application Application Distributed Operating System Services

Networked OS Distributed OS try to realize full system transparency, whereas in networked OS multiple computers are connected in a network. The systems can be heterogeneous in nature The user explicitly maintains an account in each machine As nodes are independent of each other, they are easily extensible.

Networked OS Structure Application Application Application Network OS Network OS Network OS

Network OS The basic difference between a network OS and a distributed OS is that the network OS does not attempt to provide a single image view for any of its services. Its main goal is to offer local services to remote clients. The following are the characteristics of networked OS. The individual nodes are highly autonomous All distribution of tasks is explicit to the user It includes software for providing remote access services and file transfer Data/ device sharing is provided using networks The advantage of networked OS is its scalability and of distributed OS is its transparency and ease of use

Middleware-Based OS Distributed OS does not have independent computers and network OS does not have a single coherent view. Hence a middleware is added on top of network OS to combine the advantages of both distributed and network OS.

Networked OS Structure Application Application Application Middleware Operating System Services Network OS Network OS Network OS

Comparison of distributed, network and middleware-based OSs Item Distributed OS Network OS Middleware-Based OS Multi-processor Multi-computer Degree of Transparency Very High High Low Single OS Yes No Number of copies of OS 1 N Communication Mechanism Shared Memory Messages Files Model Specific Resource Management Global, central Global, distributed Per Node Scalability Moderately Varies Openness Closed Open

Middleware-Based OS (ORBExpress) Middleware further raises the level of programming of distributed applications, as developers need not worry about the platform or operating systems. Middleware is classified broadly as general middleware and service specific middleware based in whether it is generic or specifically provides a particular service Middleware services can be implemented in transaction-processing monitors, message servers, RPCs and Object Request Broker (ORB) or application servers.

Generic Middleware It acts as a substrate for all client/server interactions. It is analogous to a common translator who translated from Chinese, Spanish, French and Russian to English. Such a middleware includes the communication stacks for client/server communication, distributed directories for location, Authentication services for security, RPCs for accessing remote functionalities & Queuing services for asynchronous and loosely coupled communication. Distributed file services and print services fall under this category. Distributed Computing Environment is an example of generic middleware.

Distributed Computing Environment
In a heterogeneous distributed environment, a common set of distributed services should be available to the applications. The Open Software Foundation’s DCE is a rich s/w technology that enables the development of distributed applications across heterogeneous systems, taking advantage of open, distributed computing. DCE is a suite of integrated services available from a vendor neutral source that enables organizations to develop, use an maintain distributed applications across heterogeneous networks. It is used in WWW, stock markets, telecom services

Applications Time Service CDS Security Service DFS Diskless Support Remote Procedure Call Thread Service Local Operating System & Transport Service

The key services required for supporting distributed applications provided by DCE are Remote Procedure Call (RPC) Directory Service Security Service Time Service Threading Service Distributed File Service IDL Compiler Diskless Support

Remote Procedure Call (RPC) RPC between clients and servers facilitates efficient access of resources distributed across the network. It provides portability and network independence. At-most-once semantics over a connectionless protocol such as UDP is the default semantics of DCE RPC The protocol is as follows: Client sends request packet to server Server sends response packet to client which acknowledges to the client the receipt of the request packet by the server Client sends acknowledgement to server indication receipt of the response request

Remote Procedure Call (RPC) Like ONC RPC, DCE RPC solves the problem of different data representations on different systems by translating the local data representations into a common data representation called NDR (Network Data Representation). This is done using stubs generated by the interface definition language (IDL) compiler using IDL of the objects.

Directory Service It allows clients to identify and locate servers by name. The DCE directory service is a central repository for information about resources in the distributed system. It provides a single naming model using X.500 The information consists of the name of the resource and its associated attributes. A DCE cell is a group of systems that share a namespace under a common administration. The DCE directory service consists of 3 parts

Directory Service Cell Directory Service (CDS) Manages a database of information about the resources in a group of machines called a DCE cell. It is a high performance distributed service that provides a consistent location-independent method for naming and using resources inside a cell. Can also be used for communication between cells. Enables DCE clients to locate compatible servers. Enables DCE clients to locate compatible servers. Each server can support 1 or more interfaces described in an IDL file. The server exports its interfaces and its network location to the CDS directory namespace. A client imports bindings for the server allowing the client to make calls to that server. The client act of binding a server is a logical association that allows the client to make an RPC to that server

Directory Service Cell Directory Service (CDS) The directory services supports a hierarchical namespace structure similar to that found in common file systems It consists of a root directory and a number of sub- directories. Within each directory, there can reside zero or more leaf entries. These entries contain structured information about the servers in the cell. Each directory in the CDS namespace can hold 4 types of entries: Directories, soft-links, clearinghouses & objects Softlinks: They are pointer to other entries in the namespace. Clearinghouses: They are used by the CDS replication mechanism. Objects: They are used to hold the information for entries in the namespace. They are used to store and retrieve server binding information There are 3 distinct subtypes of objects used by RPC to store and retrieve server-binding information: RPC Server Entry: This entry type stores the bindings of a server. Each server entry has its own unique name in CDS. RPC NS Group: A group holds an unordered collection of members that can be references to server entries or other groups. The entries in each subgroup will be recursively examined when a group is selected. RPC NS Profile: A profile holds an ordered collection of elements which can be references to server entries, groups or profiles. The elements are ordered into 8 priority bands. When searching a profile, each server entry, group and subprofile in a priority band is searched recursively for compatible server bindings. The bindings found in the highest priority band are returned first to the client, followed by lower priority bindings.

Directory Service Global Directory Service (GDS) Implements an international standard directory service and provides a global namespace that connects the local DCE cells into a universal hierarchy. The GDS client and server are based on the X.500 standard

Directory Service Global Directory Agent (GDA) The GDA is between the cell and the GDS. It facilitates inter-operability between cells. CDS needs to be able to contact at least on GDA to participate in the global naming environment. GDA helps CDS access names outside a cell. When CDS determines that a name is not in its own cell, it passes the name to a GDA, which searches the appropriate naming environment (DNS etc.) The GDA then returns information that enables the original CDS server to contact the CDS server in whose cell the name resides

Directory Service Global Directory Agent (GDA) GDS GDA CDS

Directory Service A directory service programming interface Both CDS and GDS are accesses using a single directory service API

Security Service It ensures access between clients & servers. It guarantees authenticity, integrity and privacy in communications. Its authentication service is based on Kerberos. Kerberos is a trusted service that validates the identity of a user or service. After a user is authenticated he must be authorized to use the system resources. The authorization service provides a simple, consistent way to manage access control information.

Time Service Different components can obtain clocks from different computers. This service facilitates precise, fault-tolerant synchronization of the system clocks throughout the n/w and reduces the load on the system administrator

Threading Service It provides multiple threads of execution capability It includes operations to create and control multiple threads of execution in a single process and to synchronize the access to global data within an application It thus facilitates multiple servers to access multiple clients simultaneously.

Distributed File Service It provides access to files across the n/w in a scalable, transparent, reliable, secure and efficient manner. As it provides a client/server model, it is easy to use and efficient. The benefits of the DFS are: Capability to interoperate with Sun’s Network File System (NFS) Improvement in performance due to caching of files Support for small and large group of users Secure RPC facilitates secure access to user files and directories

IDL Compiler It is a compiler for converting high level interface descriptions of the remote procedures into portable C-language source codes. Diskless Service It allows low-cost workstations to use disks on servers.

Service Specific Middleware
It is needed to accomplish a particular client/server type of service. Some of the service-specific middleware are listed as follows: Database Middleware: It allows direct access to data structures and provides interaction directly with databases. There are database gateways that provide a single system view of heterogeneous dBs. ETLC packages come under this middleware category Other examples are ODBC, ORACLE Glue, SQL etc.

continued Some of the service-specific middleware are listed as follows: OLTP Middleware: Transaction processing monitors provide tools and an environment for developing and deploying distributed applications that have to manage transactions. This is a type of message queuing, transaction scheduling and prioritization service where the client connects to the middle tier which in turn connects to the back-end dB The transaction is accepted by the monitor which queues it and then takes responsibility for managing it, thus relieving the client. It has the ability to connect to different DBMS in a single transaction irrespective of whether it is a flat file or non- relational DBMS. Examples are:? ATMI, Transactional RPC

continued Some of the service-specific middleware are listed as follows: Communication Middleware Sun RPC, ONC (Open N/W Connectivity) RPC RPCs enable the logic of an application to be distributed across the n/w The distributed program logic on remote systems can be executed like calling a local routine

continued Some of the service-specific middleware are listed as follows: MOM – Message Oriented Middleware Provides program-to-program data exchange enabling the creation of distributed applications. MOM in analogous to in the sense it is asynchronous and requires the recipients of messages to interpret their meaning and to take appropriate action It increases flexibility of architecture by enabling applications to exchange messages with each other without the need to bother about underlying OS etc. It is most appropriate for event driven applications Examples are PEERLOGIC and IBM’s MOM

continued Some of the service-specific middleware are listed as follows: Object-Specific Middleware CORBA, Microsoft’s DCOM These include ORBs which enable the objects that comprise an application to be distributed and shared across heterogeneous n/ws. It facilitates reusability and interoperability of distributed objects

continued Some of the service-specific middleware are listed as follows: Workflow Management Middleware Can track transactions from launch to landing Primarily focuses on the management of activity flow in a client/server system

continued Some of the service-specific middleware are listed as follows: Portals Front end integration through portals facilitates transactions between user’s desktops and back-end systems. Portals integrate portlets which can work independently

continued Some of the service-specific middleware are listed as follows: Internet-Specific Middleware It is a type of communication middleware It includes tools for communication such as HTTP, S- HTTP and SSL.

Client Server Building Blocks

Thin Clients+ Fat Clients+ Runs the client side of the application It runs on the OS that provides a GUI or an OOUI and that can access distributed services, wherever they may be. The client also runs a component of the Distributed System Management (DSM) element.

Servers Runs the server side of the application The server application typically runs on top of some shrink-wrapped server software package. The five contending server platforms for creating the next generation of client/server applications are SQL database severs, TP Monitors, groupware servers, Object servers and the Web server. The server side depends on the OS to interface with the middleware building block. The server also runs DSM component It may be a simple agent or a shared object database etc.

Middleware Runs on both the client and server sides of an application This is broken into two categories Middleware for Data Integration ODBC, JDBC Middleware for system level process integration RPC, RMI, MOM Middleware is the nervous system of the client/server infrastructure This also has the DSM component

DSM Runs on every node in the client/server network. A managing workstation collects information from all its agents on the network and displays it graphically. The managing workstation can also instruct its agents to perform actions on its behalf.

These building blocks can be rearranged to use them in the following situations: 1. Client/Server for tiny shops and nomadic tribes - This is a building-block implementation that runs the client, the middleware software, and most of the business services on the same machine. It is the suggested implementation for the one-person shops, home offices, and mobile users with well-endowed laptops. It is easy to run the client and server portion of an application on the same machine. Vendors can easily package single-user versions of a client/server application. The business critical client/server application runs on one machine and does some occasional communications with outside servers to exchange data, refresh a database and send or receive mail and faxes. Ex: Internet.

These building blocks can be rearranged to use them in the following situations: 2. Client/Server for small shops and departments - This is the classic Ethernet client/single-server, building block implementation. It is used in small shops, departments, and branch offices. This is the predominant form of client/server today. The client/server architecture is particularly well-suited for the LAN-based single server establishments. It consists of multiple clients talking to a local server. This is the model used in small businesses. The single-server nature of the model tends to keep the middleware simple. The client only needs to look into a configuration file to find its server's name.

These building blocks can be rearranged to use them in the following situations: 2. Client/Server for small shops and departments - This is the classic Ethernet client/single-server, building block implementation. It is used in small shops, departments, and branch offices. This is the predominant form of client/server today. Security is implemented at the machine level and kept quite simple. The network is usually relatively easy to administer; it's a part-time job for a member of the group. There are no complex interactions between servers, so it is easy to identify failures- they're either on the client or on the local server.

These building blocks can be rearranged to use them in the following situations: 3. Client/Server for intergalactic enterprises - This is the multiserver building-block implementation of client/server. The servers present a single system image to the client. They can be spread out throughout the enterprise, but they can be made to look like they are part of the local desktop. This implementation meets the initial needs of intergalactic client/server computing. The client/server enterprise model addresses the needs of establishments with a mix of heterogeneous servers. These models are upwardly scalable. When more processing power is needed for various intergalactic functions, more servers can be added, or the existing server machine can be traded up for the latest generation of superserver machine.

These building blocks can be rearranged to use them in the following situations: 3. Client/Server for intergalactic enterprises – The servers can be partitioned based on the function they provide, the resource they control, or the database they own. The servers can be replicated to provide a fault-tolerant service or to boost an application's performance. Multiserver capability, when properly used, can provide an awesome amount of compute power and flexibility, in many cases rivaling that of mainframes. To exploit the full power of multiservers, we need low-cost, high-speed bandwidth and an awesome amount of middleware features –including * network directory services * network security * remote procedure calls and * network time services.

These building blocks can be rearranged to use them in the following situations: 3. Client/Server for intergalactic enterprises – Middleware creates a common view of all the services on the network called a single system image. Good software architecture for intergalactic enterprise client/server implementations is all about creating system "ensembles" out of modular building blocks. Intergalactic client/server is the driving force behind middleware standards as distributed objects and the Internet.

These building blocks can be rearranged to use them in the following situations: 4. Client/Server for a post-scarcity world - This model transforms every machine in the world into both a client and a server. Personal agents on every machine will handle all the negotiations with their peer agents anywhere in the universe. This dream is almost within reach. Every machine is both a client and a full-function server. Because every machine is a full-function server, it will run, at a minimum, a file server, database server, workflow agent, TP Monitor, and Web server - all connected via an ORB. This is in addition to all the client software and middleware. In next few years, a hundred million machines or more may be running almost all the forms of client/server software In this model instead of mobile agents, personal agents will be used.

Peer-to-Peer (P2P) Communications
In this model, there is no difference between client and server side of communication In this model, both the sides of the communication link use the same protocol interface for networked communication The protocol is symmetrical and masks the underlying network communication from the user Any computer can initiate a conversation with any other computer In a p2p network relationship, a computer on the network communicates with any other computer as its equal. Each computer is responsible for making its own resources available.

P2P communication is facilitated using sockets. Some of the commercial implementations of P2P protocols are: Unix Sockets Novell Netware IBM’s NetBIOS Named pipes

Sockets The communication between applications is handled using a data structure called socket Socket is a software abstraction used to represent the terminals of a connection between 2 machines. It provides a mechanism for the client to pass data to the server and for the server to listen and service the client requests. A socket is used to allow one process to speak to another Sockets provide an abstraction in the session layer of ISO-OSI networking model to hide the complexities of wire transmission.

Sockets The Berkeley socket interface is an application programming interface (API) to code applications performing communication between hosts or between processes on one computer, using the concept of an Internet socket. It can work with many different Input/output devices, although support for these depends on the operating- system implementation. This interface implementation is the original API of the Internet Protocol Suite (TCP/IP). It was first developed at the University of California, Berkeley for use on Unix systems. All modern operating systems now have some implementation of the Berkeley socket interface, as it became the standard interface for connecting to the Internet.

Sockets Socket interfaces are accessible at three different levels. The most detailed and powerful method is control at the raw socket level. Very few applications need the degree of control over communications that this provides, so raw sockets support was intended to be available only on computers used for developing Internet-related technologies. In recent years, most operating systems have implemented support for it, including Microsoft Windows.

Sockets Header Files The Berkeley socket interface is defined in several header files. The names and content of these files differ slightly between implementations. In general, they include: <sys/socket.h> : Core BSD socket functions and data structures. <netinet/in.h> : AF_INET and AF_INET6 address families and their corresponding protocol families PF_INET and PF_INET6. Widely used on the Internet, these include IP addresses and TCP and UDP port numbers. <sys/un.h> : PF_UNIX/PF_LOCAL address family. Used for local communication between programs running on the same computer. Not used on networks. <arpa/inet.h> : Functions for manipulating numeric IP addresses. <netdb.h> : Functions for translating protocol names and host names into numeric addresses. Searches local data as well as DNS.

Sockets API Functions This list is a summary of functions or methods provided by the Berkeley sockets API library: socket() creates a new socket of a certain socket type, identified by an integer number, and allocates system resources to it. bind() is typically used on the server side, and associates a socket with a socket address structure, i.e. a specified local port number and IP address. listen() is used on the server side, and causes a bound TCP socket to enter listening state. connect() is used on the client side, and assigns a free local port number to a socket. In case of a TCP socket, it causes an attempt to establish a new TCP connection.

Sockets API Functions This list is a summary of functions or methods provided by the Berkeley sockets API library: accept() is used on the server side. It accepts a received incoming attempt to create a new TCP connection from the remote client, and creates a new socket associated with the socket address pair of this connection. send() and recv(), or write() and read(), or sendto() and recvfrom(), are used for sending and receiving data to/from a remote socket. close() causes the system to release resources allocated to a socket. In case of TCP, the connection is terminated. gethostbyname() and gethostbyaddr() are used to resolve host names and addresses. IPv4 only.

Sockets API Functions This list is a summary of functions or methods provided by the Berkeley sockets API library: select() is used to prune a provided list of sockets for those that are ready to read, ready to write, or that have errors. poll() is used to check on the state of a socket in a set of sockets. The set can be tested to see if any socket can be written to, read from or if an error occurred. getsockopt() is used to retrieve the current value of a particular socket option for the specified socket. setsockopt() is used to set a particular socket option for the specified socket.

Sockets Types of Sockets There are 3 types of sockets Stream Sockets: SOCK_STREAM It provides byte-by-byte stream communication It facilitates sequenced, reliable, bi-directional communication of data. Datagram Sockets: SOCK_DGRAM It is used for datagram transmission It is used in connectionless protocol including information such as sequence numbers Each packet of data is called a datagram It provides no ordering, so sequence numbers are used It provides an unreliable and bi-directional means of communication

Sockets Types of Sockets There are 3 types of sockets Raw Interface Sockets: SOCK_RAW It is a raw interface It is provided for more detailed control of messages Using it, users can define their own protocol.

Sockets Client/Server Communication using TCP Connection Oriented Protocol Socket() Bind() Listen() Accept() Write() Process() Read() Close() * Creating a TCP socket, with a call to socket(). * Binding the socket to the listen port, with a call to bind(). Before calling bind(), a programmer must declare a sockaddr_in structure, clear it (with memset()), and the sin_family (AF_INET), and fill its sin_port (the listening port, in network byte order) fields. Converting a short int to network byte order can be done by calling the function htons() (host to network short). * Preparing the socket to listen for connections (making it a listening socket), with a call to listen(). * Accepting incoming connections, via a call to accept(). This blocks until an incoming connection is received, and then returns a socket descriptor for the accepted connection. The initial descriptor remains a listening descriptor, and accept() can be called again at any time with this socket, until it is closed. * Communicating with the remote host, which can be done through send() and recv() or write() and read(). * Eventually closing each socket that was opened, once it is no longer needed, using close().

Sockets Client/Server Communication using UDP Connection-Less Protocol Socket() Bind() Recvfrom() Sendto() Process() Read() This infinite loop receives any UDP datagrams to port 7654 using recvfrom(). It uses the parameters: * socket * pointer to buffer for data * size of buffer * flags (same as in recv or other receive socket function) * address struct of sending peer * length of address struct of sending peer.

Sockets Some of the implementations of communication protocols are: Unix / Windows Sockets Novell Netware IBM’s NetBIOS Named Pipes This infinite loop receives any UDP datagrams to port 7654 using recvfrom(). It uses the parameters: * socket * pointer to buffer for data * size of buffer * flags (same as in recv or other receive socket function) * address struct of sending peer * length of address struct of sending peer.

RPC Remote Procedure Calls

Remote Procedure Call (RPC)
Masks remote function calls as being local Client/server model Request/reply paradigm usually implemented with message passing in RPC service Marshalling of function parameters and return value Caller RPC Service RPC Service Remote Function 1) Marshal args 2) Generate ID 3) Start timer message 4) Unmarshal 5) Record ID call(…) fun(…) 8) Unmarshal 9) Acknowledge 6) Marshal 7) Set timer

RPC Timeline Client Server Request Blocked Blocked Computing Reply
Spring 2002 CS 461

RPC - History RPC = Remote Procedure Call Birell and Nelson (1980s)
calling procedures on remote machines basis for two tier systems start of the developement of distributed systems basis for middleware, EAI and web services

RPC – How it works I interface for procedures Compilation of IDL
IDL (Interface Definition Language) Compilation of IDL Result of compilation client and server stub for every defined procedure interface headers

RPC - IDL Compilation - result
development environment client process server process IDL client code IDL sources server code language specific call interface language specific call interface IDL compiler client stub server stub interface headers

RPC – How it works II client process server process client server
procedure call server procedure dispatcher selects stub server stub (un)marshal (de)serialize receive (send) client stub locate (un)marshal (de)serialize send (receive) communication module communication module

RPC - binding static binding hard coded stub simple efficient
not flexible stub recompilation necessary if the location of the server changes use of redundant servers not possible

RPC - binding dynamic binding name and directory server
load balancing IDL used for binding flexible redundant servers possible

name and directory server
RPC - dynamic binding client process server process client procedure call server procedure 3 13 11 10 client stub bind (un)marshal (de)serialize find send receive server stub register (un)marshal (de)serialize receive send 8 1 communication module communication module dispatcher selects stub 12 4 9 7 12 12 5 6 2 name and directory server

RPC - Heterogeneity RPC hides heterogeneity of a system
x servers, y clients 2*x*y stubs, for each combination too much, not efficient solution: common form of representation mapped in IDL (platform independent) x+y stubs need to be implemented

RPC - Extensions conventional RPC: sequential execution of routines
client blocked until response of server asynchronous RPC – non blocking client has two entry points(request and response) server stores result in shared memory client picks it up from there

RPC - Transparency + programmer aware of distribution, performance and reliability issues + error detection is easier no need to worry about details simplicity less opportunities to cause errors

RCP Components Protocol Stack Stubs
BLAST: fragments and reassembles large messages CHAN: synchronizes request and reply messages SELECT: dispatches request to the correct process Stubs Caller Callee (client) (server) Return Return Arguments Arguments value value Client Server stub stub Request Reply Request Reply RPC RPC protocol protocol Spring 2002 CS 461

Bulk Transfer (BLAST) Unlike IP, tries to recover from lost fragments
Sender Receiver Fragment 1 Fragment 2 Fragment 3 Fragment 5 Fragment 4 Fragment 6 SRR Unlike IP, tries to recover from lost fragments Strategy selective retransmission aka partial acknowledgements Spring 2002 CS 461

BLAST Details Sender: after sending all fragments, set timer DONE
if receive SRR, send missing fragments and reset DONE if timer DONE expires, free fragments Spring 2002 CS 461

BLAST Details (cont) Receiver:
when first fragments arrives, set timer LAST_FRAG when all fragments present, reassemble and pass up four exceptional conditions: if last fragment arrives but message not complete send SRR and set timer RETRY if timer LAST_FRAG expires if timer RETRY expires for first or second time if timer RETRY expires a third time give up and free partial message Spring 2002 CS 461

BLAST Header Format MID must protect against wrap around
TYPE = DATA or SRR NumFrags indicates number of fragments FragMask distinguishes among fragments if Type=DATA, identifies this fragment if Type=SRR, identifies missing fragments Spring 2002 CS 461

Request/Reply (CHAN) Guarantees message delivery
Synchronizes client with server Supports at-most-once semantics Simple case Implicit Acks Client Server Request 1 Request 2 Reply 2 Reply 1 … Client Server Request ACK Reply Spring 2002 CS 461

CHAN Details Lost message (request, reply, or ACK)
set RETRANSMIT timer use message id (MID) field to distinguish Slow (long running) server client periodically sends “are you alive” probe, or server periodically sends “I’m alive” notice Want to support multiple outstanding calls use channel id (CID) field to distinguish Machines crash and reboot use boot id (BID) field to distinguish Spring 2002 CS 461

CHAN Header Format typedef struct { u_short Type; /* REQ, REP, ACK, PROBE */ u_short CID; /* unique channel id */ int MID; /* unique message id */ int BID; /* unique boot id */ int Length; /* length of message */ int ProtNum; /* high-level protocol */ } ChanHdr; u_char type; /* CLIENT or SERVER */ u_char status; /* BUSY or IDLE */ int retries; /* number of retries */ int timeout; /* timeout value */ XkReturn ret_val; /* return value */ Msg *request; /* request message */ Msg *reply; /* reply message */ Semaphore reply_sem; /* client semaphore */ int mid; /* message id */ int bid; /* boot id */ } ChanState; Spring 2002 CS 461

Synchronous vs Asynchronous Protocols
Asynchronous interface send(Protocol llp, Msg *message) deliver(Protocol llp, Msg *message) Synchronous interface call(Protocol llp, Msg *request, Msg *reply) upcall(Protocol hlp, Msg *request, Msg *reply) CHAN is a hybrid protocol synchronous from above: call asynchronous from below: deliver Spring 2002 CS 461

Dispatcher (SELECT) Address Space for Procedures
Dispatch to appropriate procedure Synchronous counterpart to UDP Implement concurrency (open multiple CHANs) Caller SELECT CHAN call deliver send Callee upcall Server Client Address Space for Procedures flat: unique id for each possible procedure hierarchical: program + procedure number Spring 2002 CS 461

Simple RPC Stack BLAST ETH IP SELECT CHAN Spring 2002 CS 461

SunRPC IP implements BLAST-equivalent
except no selective retransmit SunRPC implements CHAN-equivalent except not at-most-once UDP + SunRPC implement SELECT-equivalent UDP dispatches to program (ports bound to programs) SunRPC dispatches to procedure within program Spring 2002 CS 461

SunRPC Header Format XID (transaction id) is similar to CHAN’s MID
Server does not remember last XID it serviced Problem if client retransmits request while reply is in transit Data MsgType = CALL XID RPCVersion = 2 Program Version Procedure Credentials (variable) Verifier (variable) 31 MsgType = REPLY Status = ACCEPTED Spring 2002 CS 461

Presentation Formatting
Marshalling (encoding) application data into messages Unmarshalling (decoding) messages into application data Data types we consider integers floats strings arrays structs Application data Presentation encoding decoding Message … Types of data we do not consider images video multimedia documents Spring 2002 CS 461

Difficulties Representation of base types
floating point: IEEE 754 versus non-standard integer: big-endian versus little-endian (e.g., 34,677,374) Compiler layout of structures (126) (34) (17) (2) Big- endian Little- High address Low 1 Spring 2002 CS 461

Taxonomy Data types Conversion Strategy
base types (e.g., ints, floats); must convert flat types (e.g., structures, arrays); must pack complex types (e.g., pointers); must linearize Conversion Strategy canonical intermediate form receiver-makes-right (an N x N solution) Application data structure Marshaller Spring 2002 CS 461

Properties of RPC Language-level pattern of function call
easy to understand for programmer Synchronous request/reply interaction natural from a programming language point-of-view matches replies to requests built in synchronisation of requests and replies Distribution transparency (in the no-failure case) hides the complexity of a distributed system Various reliability guarantees deals with some distributed systems aspects of failure

Failure Modes of RPC Invocation semantics supported by RPC in the light of: network and/or server congestion, client, network and/or server failure note DS independent failure modes RPC systems differ, many examples, local was Mayflower Maybe or at most once (RPC system tries once) Error return – programmer may retry Exactly once (RPC system retries a few times) Hard error return – some failure most likely note that “exactly once” cannot be guaranteed

Disadvantages of RPC Synchronous request/reply interaction
tight coupling between client and server client may block for a long time if server loaded leads to multi-threaded programming at client slow/failed clients may delay servers when replying multi-threading essential at servers Distribution Transparency Not possible to mask all problems RPC paradigm is not object-oriented invoke functions on servers as opposed to methods on objects fork(…) join(…) remote call

Messaging Message Oriented Middleware

Message oriented communication
RPCs, i.e., enhance access transparency but they are not always appropriate to distributed system. Persistence and Synchronicity Different types of communications

Persistent communication
2-20 General organization of a communication system in which hosts are connected through a network Example : system. If the target server is unreachable, the local one continue to store messages ( in contrast with a transient communication method).

Persistence and Synchronicity in Communication
2-22.1 Persistent asynchronous communication Persistent synchronous communication

2-22.2 Transient asynchronous communication (one way RPC) Receipt-based transient synchronous communication

Delivery-based transient synchronous communication at message delivery(asynchronous RPCs) Response-based transient synchronous communication (RPCs)

Message passing communication
The need for persistent communication services is clear in developing middleware for large-scale distributed applications. Only transient or persistent communications, like only synchronous or asynchronous communications, are not sufficient! Message passing communication

What is a message? Anything can be a message : string, object, XML, JSON Arbitrary interaction patterns possible 1-1, n-n, with replies, with no replies

Messaging Models Publish and Subscribe ( 1-> many ) (pub/sub)
Topic Subscriber Publisher Publish and Subscribe ( 1-> many ) (pub/sub) Queue Receiver Sender Point-to-Point ( 1-> 1 ) (p2p, PTP)

Interaction Styles Two main mode of message consumption on the receiver: Blocking (synchronous, pull mode) with MessageConsumer.receive() Non-blocking (asynchronous, push mode) with: MessageListener.onMessage(..) 115

Active Reception (Pull)
Typically used with point-to-point queues Producer Queue Consumer send(m1) Put message into queue send(m2) receive() Consume message m1 send(m3)

Passive Reception (Push)
Typically used with 1-n communication (Publish/Subscribe) Producer Consumer Consumer Broker publish(m1) Pass message to broker send(m1) publish(m2) send(m1) Dispatch message to all consumers send(m2) send(m2) publish(m3)

Message oriented persistent communications Message-Queuing Model basic idea: applications communicate by inserting messages in specific queues 2-26 Four combinations for loosely-coupled communications using queues.

Message-Queuing Model
Basic interface to a queue in a message-queuing system. Primitive Meaning Put Append a message to a specified queue Get Block until the specified queue is nonempty, and remove the first message Poll Check a specified queue for messages, and remove the first. Never block. Notify Install a handler to be called when a message is put into the specified queue.

General Architecture of a Message-Queuing System (1)
The collection of queues is distributed across multiple machines queue names db The relationship between queue-level addressing and network-level addressing.

General Architecture of a Message-Queuing System (2)
A message-queuing system with routers (or relays) can solve the problem of a static large scale system queue- to-location mapping 2-29

Message Brokers it converts incoming messages to a format compatible with the destination application 2-30 The general organization of a message broker in a message-queuing system. It is generally not considered an integral part of the queuing system.

Data Stream (1) Sometime timing is crucial for communication… asynchronous, synchronous and isochronous mode for data stream Setting up a stream between two processes across a network.

Data Stream (2) Setting up a stream directly between two devices.

Data Stream (3) An example of multicasting a stream to several receivers.

Specifying QoS (1) Time dependent requirements are expressed as QoS
Characteristics of the Input Service Required maximum data unit size (bytes) Token bucket rate (bytes/sec) Toke bucket size (bytes) Maximum transmission rate (bytes/sec) Loss sensitivity (bytes) Loss interval (sec) Burst loss sensitivity (data units) Minimum delay noticed (sec) Maximum delay variation (sec) Quality of guarantee A flow specification.

Specifying QoS (2) The principle of a token bucket algorithm
A token is a fixed number of bytes that an application can pass to the network. Tokens are buffered in buckets

Setting Up a Stream Resources required for streaming: bandwidth, buffers, processing capacity
Resource reSerVation Protocol The basic organization of RSVP for resource reservation in a distributed system. Receiver-initiated protocol

Synchronization Mechanisms (1)
The principle of explicit synchronization on the level data units. The application is responsible for synchro.

Synchronization Mechanisms (2)
The principle of synchronization as supported by high-level interfaces. 2-41

RPC vs. MOM Feature RPC Advantage MOM Client/Server model
Unlimited clients and servers with multiple brokers running anywhere in the network Multiple clients with multiple servers restricted to limited number of queues on pre-determined servers in the network. Client/Server relationship Synchronous with Asynchronous possible. Clients and Servers designed to run concurrently. Clients can choose not to wait on Server response by using asynchronous option. Asynchronous. Clients and Servers may operate at different times and speeds, response to Client is not guaranteed (synchronous not possible). Also, message queue backups can cause performance problems. Platform Support Unlimited; every vendor in the world supports RPC. Limited platform support for MOMs Communication Listen, Connect, Accept NA Post a message then wai

RPC vs. MOM Feature RPC Advantage MOM Administration and Monitoring
Many different commercially available monitors. None Scalability Easily done by starting additional servers based on load. Very difficult to scale because there is no way to distribute queues dynamically. Load-balancing Can be accomplished with performance monitors and application management systems. Requires a monitor to manage more than as single queue. Single queue can be used to implement FIFO or priority based policy Transactional Support Yes; easily supported with RPC. Limited (Some Products) Message Queue can participate in the commit synchronization

RPC vs. MOM Feature RPC Advantage MOM Message Filtering No Yes
No Yes Performance Very Fast Very Slow. An intermediate hop is required Asynchronous processing Yes; easily implemented with callback. NONE Yes. Queues and triggers are required

Java RMI Remote Method Invocation

Remote Method Invocation
Java RMI is a mechanism that allows a Java program running on one computer to apply a method to an object living on a different computer. RMI is an implementation of the of the Distributed Object programming model—similar to CORBA, but simpler and specialized to the Java language. The syntax of the remote method invocation looks like an ordinary Java method invocation. The remote method call can be passed arguments computed in the context of the local machine. It can return arbitrary values computed in the context of the remote machine. The RMI runtime system transparently communicates all data required. In some ways Java RMI is more general than CORBA—it can exploit Java features like object serialization and dynamic class loading to provide more complete object-oriented semantics.

RMI (1) The Java Remote Method Invocation Application Programming Interface (API), or Java RMI, is a Java application programming interface that performs the object-oriented equivalent of remote procedure calls (RPC). The original implementation depends on Java Virtual Machine (JVM) class representation mechanisms and it thus only supports making calls from one JVM to another. The protocol underlying this Java-only implementation is known as Java Remote Method Protocol (JRMP). In order to support code running in a non-JVM context, a CORBA version was later developed.

RMI (2)

RMI (3) Usage of the term RMI may denote solely the programming interface or may signify both the API and JRMP, whereas the term RMI-IIOP denotes the RMI interface delegating most of the functionality to the supporting CORBA implementation. The programmers of the original RMI API generalized the code somewhat to support different implementations, such as a HTTP transport. Additionally, the ability to pass arguments "by value" was added to CORBA in order to support the RMI interface. Still, the RMI-IIOP and JRMP implementations do not have fully identical interfaces.

RMI (4) RMI functionality comes in the package java.rmi, while most of Sun's implementation is located in the sun.rmi package. Jini (IBM) offers a more advanced version of RMI in Java. It functions similarly but provides more advanced searching capabilities and mechanisms for distributed object applications.

RMI (5a) Fundamental Idea (1)
Rely on the same programming paradigm for distributed applications as for centralized applications In procedural languages, we will rely on the notion of Remote Procedure Call (RPC) In object-oriented language, we will rely on the notion of Remote Method Invocation (RMI)

RMI (5b) Fundamental Idea (2)

RMI (6)

RMI (7)

RMI (8)

RMI (9) In Java, Remote method invocation is integrated in the standard class library, via packages such as java.rmi, java.rmi.server, etc. In addition , Sun’s Java Development Kit (JDK) includes a set of tools for supporting RMI, e.g., rmic, rmiregistry, etc. We can distinguish three distinct times when building rmi-based applications, namely development, deployment and execution.

RMI (10) Execution time The server object registers its name & proxy in the naming service (rmi registry) The client object obtains a proxy of the server object via that naming service The client object can then invoke the server proxy, which will then forward the invocation to the server object

RMI (11) Server side: create & bind

RMI (12) Client Side: lookup & use

RMI (13) Calendar Application

RMI (14) Development time Define the interface of the remote service
Implement the client and server classes in a decoupled way, thanks to the interface Use javac to compile all above sources Use the rmic compiler to create the proxy of the remote class for you

RMI (15) Argument Passing Rules
An argument or a return value can be a primitive type, a local serializable object (i.e, implementing java.io.Serializable), or a remote object. A primitive type value is passed by copy. A local object is also passed by copy, using standard object serialization. A remote object is passed by reference, i.e., its proxy is passed rather than the object itself.

RMI (16) Deployment time Start the rmi registry
Start the server process Start the client process

RMI (17) Checkup On the server we have: whereas on the client we have:
CalendarServer theServer= new CalendarServer(); whereas on the client we have: CalendarService calServ = (CalendarService) Naming.lookup(calServName); why this difference? Where are calendars located? How does the client get access to calendars? How do we communicate with the rmi registry ?

RMI (19) RMI callbacks (1) A remote object does not need to be registered in the naming service to be remotely accessible, e.g., DayCalendarImpl. The client can also make an object remotely accessible to the server, allowing the latter to asynchronously call back the client, e.g., to notify the client that a new event was scheduled on some calendar.

RMI (20) Dynamic code download (1)
The Java platform allows for the dynamic download of classes from any URL (Uniform Resource Locator) The proxy is located on the client but it conceptually belongs to the server Because we have a Java Virtual Machine on both the server and the client, it is possible to have the proxy move from the server to the client at runtime (dynamic code download) Dynamic code download can be used not only for proxies but for any Java class

RMI (21) Security viewpoint
From a security viewpoint, downloading classes is a critical action (i.e., potentially dangerous) For this reason, when code download is activated (via the java.rmi.server.codebase property), the Java Virtual Machine requires a security manager to be installed The security policy enforced by the security manager can be expressed declaratively in a security policy file

RMI (22) Distributed Garbage Collection
The Java platform transparently extends garbage collection to distributed objects. This extension is known as Distributed Garbage Collection (DGC). A remote object is collected when there no longer exists any remote or local references to it Any object referenced by the naming service (rmi registry) is not collected

RMI (23) Unreferenced vs. finalized
By implementing the Unreferenced interface, a remote object can ask to be notified when there no longer exists any remote references to it In the unreferenced() method, the remote object is given the opportunity to release some resources, e.g., the remote reference on a another remote object

RMI (24) Limitations of DGC An implementation of DGC should ensure
Safety, which implies not collecting too early Liveness, which implies eventually collecting Due to its inherent decentralized nature, the implementation of DGC is based on reference counting, which poses several issues: It does not deal properly with circular references It does not deal properly with asynchronous systems Partial solution: the notion of lease

RMI (25) The notion of lease
A lease is a remote reference with a validity limited in time In Java, remotes references are actually leases If the client does not renew its lease before the associated timeout expires, the reference counter on the server side is decremented Leases are automatically managed for you, i.e., the renewal is automatic as long as the client is alive and the remote reference exists

A Simple Use of RMI

The Remote Interface In RMI, a common remote interface is the minimum amount of information that must be shared in advance between “client” and “server” machines. It defines a high-level “protocol” through which the machines will communicate. A remote interface is a normal Java interface, which must extent the marker interface java.rmi.Remote. Corollaries: because the visible parts of a remote object are defined through a Java interface, constructors, static methods and non-constant fields are not remotely accessible (because Java interfaces can’t contain such things). All methods in a remote interface must be declared to throw the java.rmi.RemoteException exception.

A Simple Example A file MessageWriter.java contains the interface definition: import java.rmi.* ; public interface MessageWriter extends Remote { void writeMessage(String s) throws RemoteException ; } This interface defines a single remote method, writeMessage().

java.rmi.Remote The interface java.rmi.Remote is a marker interface.
It declares no methods or fields; however, extending it tells the RMI system to treat the interface concerned as a remote interface. In particular we will see that the rmic compiler generates extra code for classes that implement remote interfaces. This code allows their methods to be called remotely.

java.rmi.RemoteException
Requiring all remote methods be declared to throw RemoteException was a philosophical choice by the designers of RMI. RMI makes remote invocations look syntactically like local invocation. In practice, though, it cannot defend from problems unique to distributed computing— unexpected failure of the network or remote machine. Forcing the programmer to handle remote exceptions helps to encourage thinking about how these partial failures should be dealt with. See the influential essay: “A Note on Distributed Computing” by Waldo et al, republished in The Jini Specification:

The Remote Object A remote object is an instance of a class that implements a remote interface. Most often this class also extends the library class java.rmi.server.UnicastRemoteObject. This class includes a constructor that exports the object to the RMI system when it is created, thus making the object visible to the outside world. Usually you will not have to deal with this class explicitly—your remote object classes just have to extend it. One fairly common convention is to name the class of the remote object after the name of the remote interface it implements, but append “Impl” to the end.

A Remote Object Implementation Class
The file MessageWriterImpl.java contains the class declaration: import java.rmi.* ; import java.rmi.server.* ; public class MessageWriterImpl extends UnicastRemoteObject implements MessageWriter { public MessageWriterImpl() throws RemoteException { } public void writeMessage(String s) throws RemoteException { System.out.println(s) ;

Compiling the Remote Object Class
To compile classes that implement Remote, you must use the rmic compiler. The reasons will be discussed later. For example: sirah$ rmic MessageWriterImpl

Client and Server Programs
We have completed the Java files for the remote object class itself, but we still need the actual client and server programs that use this class. In general there are some pieces of administrivia one has to deal with—publishing class files and installing security managers. We initially make the simplifying assumption that both client and server have copies of all class files for MessageWriter (e.g., they may share access through shared NFS directories). Then “publishing class files” is not an issue, and we also don’t need a security manager, because all code is “local”, and therefore trusted.

A Server Program We assume the file HelloServer.java contains the class declaration: import java.rmi.* ; public class HelloServer { public static void main(String [] args) throws Exception { MessageWriter server = new MessageWriterImpl() ; Naming.rebind(“messageservice”, server) ; }

Remarks This program does two things:
It creates a remote object with local name server. It publishes a remote reference to that object with external name “MessageWriter”. The call to Naming.rebind() places a reference to server in an RMI registry running on the local host (i.e., the host where the HelloServer program is run). Client programs can obtain a reference to the remote object by looking it up in this registry.

A Client Program We assume the file HelloClient.java contains the class declaration: import java.rmi.* ; public class HelloClient { public static void main(String [] args) throws Exception { MessageWriter server = (MessageWriter) Naming.lookup( “rmi://sirah.csit.fsu.edu/messageservice”) ; server.writeMessage(“Hello, other world”) ; }

Remarks Again the program does two things:
It looks up a reference to a remote object with external name “MessageWriter”, and stores the returned reference with local name server. Finally (!), it invokes the remote method, writeMessage(), on server. The call to Naming.lookup() searches in a remote RMI registry. Its argument is a URL, with protocol tag “rmi”. This example assumes the remote object lives on the host “sirah”, and has been registered in the default RMI registry (which happens to listen on port 1099) on that machine.

Compiling and Running the Example
Compile HelloServer and HelloClient on their respective hosts, e.g.: sirah$ javac HelloServer merlot$ javac HelloClient Either ensure client and server share the current directory, or copy all files with names of the form MessageWriter * .class to the client’s current directory.

Running HelloClient/HelloServer

The Mechanics of Remote Method Invocation

Is RMI a Language Extension?
Invocation of a method on a remote object reproduces the “look and feel” of local invocation very well. But the internal mechanics of remote invocation are much more complex than local invocation: Arguments—which may be objects of arbitrary complexity—are somehow collected together into messages suitable for shipping across the Internet. Results (or exceptions) are similarly shipped back. Perhaps surprisingly, RMI involves no modification to the Java language, compiler, or virtual machine. The illusion of remote invocation is achieved by clever libraries, plus one relatively simple “post-processor” tool (rmic).

Exchanging Remote References
A powerful feature of distributed object models like RMI is that references to other remote objects can be passed as arguments to, and returned as results from, remote methods. Starting with one remote object reference (presumably obtained from an RMI registry) a client can, for example, obtain references to additional remote objects—returned by methods on the first one.

Example: a Printer Registry
Suppose we are on a LAN and we need to get a Java driver for one of several available printers: public interface Printer extends Remote { void print(String document) throws RemoteException ; } public interface PrinterHub extends Remote { Printer getPrinter(int dpi, boolean isColor) throws RemoteException ; A client might initially obtain a PrinterHub reference from the RMI registry. The remote object contains some table of printers on the network. An individual Printer interface is returned to the client, according to specifications given in getPrinter(). Jini takes an approach similar to this.

Remote References have Interface Type
This is a powerful feature, but there is one interesting restriction: If a particular argument or result of a remote method itself implements Remote, the type appearing in the method declaration must be a remote interface. The declared type of an RMI argument or result cannot be a remote implementation class. At the “receiving end” this reference cannot be cast it to the implementation class of the remote object. A ClassCastException will occur if you try.

Stubs What this tells us is that “remote references” are not literally Java references to objects in other virtual machines. In fact they are Java references to local objects that happen to implement the same remote interfaces as the remote objects concerned. The local Java object referenced is an instance of a stub class.

Some Important Parts of RMI
Stubs. Each remote object class has an associated stub class, which implements the same remote interfaces. An instance of the stub class is needed on each client. Client-side remote invocations are “actually” local invocations on the stub class. Serialization. Arguments and results have to be “marshaled”—converted to a representation that can be sent over the Net. In general this is a highly non-trivial transformation for Java objects. Serialization is also used for distributing stubs. The Server-side “Run-time System”. This is responsible for listening for invocation requests on suitable IP ports, and dispatching them to the proper, locally resident, remote object.

Architecture Internet Client Server Call stub method locally
Call remote object method locally Send marshaled arguments RMI “Run-time” System Remote Object Stub Client Code Send marshaled result or exception Return value or throw exception Return value or throw exception

The Role of rmic The only “compiler” technology peculiar to RMI is the rmic stub generator. The input to rmic is a remote implementation class, compiled in the normal way with javac (for example). The stub generator outputs a new class that implements the same remote interfaces as the input class. The methods of the new class contain code to send arguments to, and receive results from, a remote object, whose Internet address is stored in the stub instance.

Example Operation of rmic
An earlier example of a remote implementation class: public class MessageWriterImpl extends UnicastRemoteObject implements MessageWriter { . . . public void writeMessage(String s) throws RemoteException { } We issue the command: rmic –keep MessageWriterImpl The flag –keep causes the intermediate Java source to be retained.

The Generated Stub Class
public final class MessageWriterImpl_Stub extends java.rmi.server.RemoteStub implements MessageWriter, java.rmi.Remote { . . . public MessageWriterImpl_Stub(java.rmi.server.RemoteRef ref) { super(ref); } public void writeMessage(java.lang.String $param_String_1) throws java.rmi.RemoteException { try { ref.invoke(this, $method_writeMessage_0, new java.lang.Object[] {$param_String_1}, L); }

Remarks on the Stub Class
The stub class includes an inherited field ref, of type RemoteRef. Essentially the stub class is just a wrapper for this remote reference. Remote methods are dispatched through the invoke() method on ref. This is passed an array of Objects holding the original arguments (in general it also returns an Object). It is also passed arguments to identify the particular method to be invoked on the server. Essentially the stub wrapper is providing compile-time type safety. The actual work is done in library classes that don’t know the compile-time type in advance.

Marshalling of Arguments
Objects passed as arguments to invoke() must be marshaled for transmission over the network. Java has a general framework for converting objects (and groups of objects) to an external representation that can later be read back into an arbitrary JVM. This framework is Object Serialization.

Overview of CORBA Common Object Request Broker Architecture

What is CORBA? Architecture for interoperable distributed computing
Based on the OMG’s Object Management Architecture Internet Interoperability Protocol (IIOP) Language mappings (OMG IDL) Integrated and reusable services

CORBA Timeline Object Management Group founded 1989 CORBA 1.x (91-93)
Experimental, architecture focused, IDL CORBA 2.0 (1996) Interoperability and COM integration CORBA 2.1 (1997) Security, language mappings

CORBA Timeline CORBA 2.2 (1998) CORBA 2.3 (1999) CORBA 2.4 (2001)
DCOM interoperability, POA, IDL/Java CORBA 2.3 (1999) Objects by value, RMI/IIOP, language binding enhancements CORBA 2.4 (2001) Quality of service enhancements, asynchronous messaging, real-time support

CORBA Architecture Based on OMA Reference Model ORB
Application Objects Domain Objects The ORB serves as the common backbone on which many discrete services can be integrated ORB Object Services Common Facilities

CORBA Model Components
Object Request broker Object Services Common Facilities Domain Interfaces Application Interfaces Application Objects Domain Objects ORB Common Facilities Object Services

Object Request Broker (ORB)
Enables object to transparently make and receive requests and responses “...like a telephone exchange, providing the basic mechanism for making and receiving calls…” ORB

Object Services & Facilities
Collection of interfaces and objects Services Support functions for implementing and using objects i.e. life cycle Facilities Services that many applications may share, but are not fundamental i.e. system management Object Services Common Facilities ORB

Domain & Application Objects
Domain Interfaces OMG Domain Special Interest Groups (SIGs) Market vertical specific services Application Objects Vendor provided or custom object implementation Top layer in Reference Model, not standardized by OMG Application Objects Domain Objects ORB

Internet Inter ORB Protocol (IIOP)
Transport protocol Defines inter ORB communication Runs on top of TCP/IP Defines CORBA messages IIOP is a specification Vendors must implement to be “CORBA-compliant” Allows for multi-vendor interoperability

DCOM Distributed Component Object Model Microsoft

Introduction to Middleware Technologies

Similar presentations

Presentation on theme: "Introduction to Middleware Technologies"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Introduction to Middleware Technologies

Similar presentations

Presentation on theme: "Introduction to Middleware Technologies"— Presentation transcript:

Similar presentations

About project

Feedback