CORBA IIOP Luk Stoops VUB programming lab CORBA

CORBA & IIOP Luk Stoops - VUB programming lab

CORBA & IIOP z. Common Object Request Broker Architecture z. Internet Inter ORB Protocol z. Object communication via the internet

Intro. . . z. At this moment the internet is a huge set of distributed (html) documents. z. The next logical step in evolution: distributed applications. z= computer programs running on different computers at the same time. z. The different pieces that constitutes the total application are called objects.

User views view 1 view 2 ordering chair bed view 3 Ontology layout combinations transactions Distributed Persistent Business Objects Repository DBMS Physical storage ODBMS

Object Communication Invoice Price? 100 EUR Bed View 1 Draw yourself OK Bed Separation of concerns

Intro. . . z. The objects communicates with each other by sending messages. z. A universal specification of this kind of messages is proposed by the Object Management Group (OMG) z= CORBA http: //www. omg. org

Intro z. One possible channel to send and receive these messages is the internet. z. The protocol that implements the CORBA specification in the internet environment (TCP/IP) is called IIOP Internet Inter-ORB Protocol.

Distributed Object Programming z. Several communicating programs. z. Written in different programming languages. z. Running on different operating systems. z. Create distributed applications that interact as though they were implemented in a single programming language on one computer.

Distributed Object Programming (cont. ) z. CORBA also brings the advantages of object-oriented techniques to a distributed environment. z. It allows programmers to design a distributed application as a set of cooperating objects and to re-use existing objects in new applications

Object Request Broker z. CORBA defines a standard architecture for Object Request Brokers (ORBs). z. ORB is a software component that mediates the transfer of messages from a program to an object located on a remote network host. z. ORB to hide the underlying complexity of network communications from the programmer.

Object Request Broker

Objects in CORBA z. CORBA objects are just standard software objects implemented in any supported programming language. z. CORBA supports several languages, including Java, C++ and Smalltalk.

IDL z. CORBA object has a clearly-defined interface, specified in the CORBA Interface Definition Language (IDL). z. Interface definition specifies what member functions are available to a client, without making any assumptions about the implementation of the object.

IDL (cont. ) z. To call member functions on a CORBA object, a client needs only the object’s IDL definition. z. Client does not need to know details. yprogramming language. ythe location of the object in the network. yoperating system on which the object runs.

Structure of a CORBA Application z. Define the interfaces to objects in your system, using CORBA IDL. z. Compile these interfaces using an IDL compiler. z. IDL compiler generates Java from IDL definitions. yclient stub code. yserver skeleton code.

client stub code server skeleton code

Implementation Repository z. If the client has not accessed the object before, the ORB refers to a database, known as the Implementation Repository. z. Determine exactly which object should receive the function call. z. ORB then passes the function call through the server skeleton code to the target object.

The Structure of a Dynamic CORBA Application z. Client programs can only call member functions on objects whose interfaces are known at compile-time. z. If a client wishes to obtain information about an object’s IDL interface at runtime, it needs an alternative, dynamic approach to CORBA programming.

Interface Repository z. Database that stores information about the IDL interfaces implemented by objects in your network. z. Client program can query this database at runtime. z. Client can then call member functions on objects using the Dynamic Invocation Interface (DII).

Dynamic Invocation Interface

Dynamic Skeleton Interface z. CORBA also supports dynamic server programming. z. CORBA program can receive function calls through IDL interfaces for which no CORBA object exists. z. Dynamic Skeleton Interface (DSI) y. Server can examine the structure of these function calls and implement them at runtime.

Dynamic Skeleton Interface

The Object Management Architecture z Application objects. z ORB. z CORBAservices. z CORBAfacilities.

The Object Management Architecture

CORBAservices z. Naming Service. z. Trader Service. z. Object Transaction Service. z. Security Service. z. Event Service.

CORBAfacilities z. Horizontal CORBAfacilities. y. User interface. y. Information management. y. Systems management. y. Task management facilities. z. Vertical CORBAfacilities. y. Standard IDL specifications for market sectors such as healthcare and telecommunications.

ORB Interoperability z. Allow communication between different implementations of the CORBA standard. z. General Inter-ORB Protocol (GIOP). z. OMG defines a specialisation of GIOP that uses TCP/IP as the transport layer. This specialisation is called the Internet Inter ORB Protocol (IIOP).

IIOP z. This protocol is mapped on the internet transport protocol TCP which uses the internet network protocol IP. z. To explain the IIOP protocol we will first tackle the underlying TCP/IP protocol. z. In order to explain protocols in general the finite state machine model is a very useful tool.

Finite State Machine Models z. To represent realistic protocols and the programs that implement them z. Graphical representation showing the relevant transitions from one state to another.

The wolf, the Goat and the Cabbage 2 (24 = 16)

Unstable States z. State 3 and 12 are both instable because the goat will eat the cabbage. z. State 6 and 9 are instable as well because the wolf will eat the goat. z. State 7 and 8 are also instable because, depending on who is most hungry, only the wolf will remain there with or without the cabbage.

Finite State Machine Model

Solutions

TCP/IP z. TCP (Transmission Control Protocol) z. Provide a reliable end-to-end byte stream over an unreliable network. z. Accepts user data streams. z. Breaks them up into pieces not exceeding 64 K bytes (usually 1500 bytes). z. Sends each piece as a separate IP "datagram".

Layer Model HTTP IIOP

IP z. Best-effort service z. Header fields (subset) ytype of service (speed - reliability) ytotal length yidentification (datagram id) yfragmenting info ytime to live ysource and destination address

TCP/IP z. IP (Internet Protocol). z. The IP layer gives no guarantee that datagrams will be delivered properly, so it is up to TCP to time out and retransmit them as need be. z. TCP must furnish the reliability that most users want and that IP does not provide.

TCP Service z. Sender and receiver create end points, called sockets. z. Each socket has a socket number. y. IP address of the host. y 16 -bit number local to that host (a port). z. Socket may be used for multiple connections at the same time.

Connections z. Connections are identified by the socket identifiers at both ends (socket 1, socket 2). z. Port numbers below 256 : well-known ports reserved for standard services y. FTP (21) y. TELNET (23) y. HTTP (80) z. All TCP connections are full-duplex and pointto-point.

TCP Connections z. Full duplex: traffic can go in both directions at the same time. z. Point-to-point: each connection has exactly two end points. z. TCP connection is a byte stream, not a message stream. z. IIOP and HTTP protocol is responsible to delimit the messages on that stream.

The TCP Protocol z. Every byte on a TCP connection has its own 32 -bit sequence number. z. Sending and receiving TCP entities exchange data in the form of segments. z. Segment consists of a fixed 20 -byte header followed by zero or more data bytes.

20 -byte Header

Sliding Window Protocol z. Sender transmits a segment ystarts a timer. z. Segment arrives yreceiving TCP entity sends back a segment bearing an acknowledgement number x(next sequence number it expects to receive). z. If the sender's timer goes off before the acknowledgement is received, the sender transmits the segment again.

Finite State Machine Client event/action pair

States Client z CLOSED no connection is active or pending started to open a connection z ESTABLISHED normal data transfer state z FIN WAIT 1 application has said it is finished z FIN WAIT 2 other side has agreed to release z TIMED WAIT wait for all packets to die off z SYN SENT

TCP Client z. Send a segment SYN = 1 , ACK = 0 z. Reply with SYN = 1 , ACK = 1 z. Acknowledge with a new ACK = 1 z. This method of making a connection is called a three-way handshake. z. We will find us now in the state ESTABLISHED.

Delayed Duplicates z. The internet can lose, store and duplicate packets. z. Congested subnet y. Each packet times out and is retransmitted two or three times. y. Some of the packets might get stuck in a traffic jam inside the subnet and take a long time to arrive, that is, they are stored in the subnet and pop out much later.

Delayed Duplicates z. Attacking delayed duplicates y. Restricting the lifetime of the packets y. Using three-way handshakes y. Discarding duplicates z. Establishing a connection sounds easy, but is actually surprising tricky. z. Releasing a connection is even worse.

The Two-Army Problem Does a protocol exist that allows the blue armies to win?

Closing a TCP Connection z. If neither side is prepared to disconnect until it is convinced that the other side is prepared to disconnect too, the disconnection will never happen. z. In practice, one is usually prepared to take more risks when releasing connections than when attacking white armies, so the situation is not entirely hopeless.

Closing a TCP Connection z. Pair of two simplex connections. z. Send a TCP segment with the FIN bit set. z. FIN is acknowledged? -> direction is closed. z. In a normal disconnect procedure we need 4 segments, FIN-ACK-FIN-ACK but it is possible that the first ACK and the second FIN both resides in the same segment

Finite State Machine Client Closing a Connection ESTABLISHED

New States z LISTEN The server is waiting for an incoming call z SYN RCVD A connection request has arrived; wait for ACK z CLOSE WAIT Other side has initiated a release z LAST ACK Wait for all packets to die off

Finite State Machine Server Closing a Connection

Complete FSM Client Server Abnormal

HTTP Message Format z. GET get a document y. GET if modified since. . . z. HEAD get the header of a document z. PUT write a document z. POST append to a document z. DELETE z. LINK z. UNLINK

IIOP Message Formats z. Seven message types are defined. z A common message header. ymessage size y. GIOP version number ythe byte ordering ya flags field indicating whether or not more fragments follow ythe message type

Client - Server Architecture z. Messages are exchanged between clients and servers. z. A client is an agent that opens connections and originates requests. z. A server is an agent that accepts connections and receives requests.

Messages

Setting up a Connection connection request No TCP Connection rejected client + server closing client close Connection Request server close Abortive Disconnect accept Orderly Shutdown 1 server close client close TCP Connection Request Locate. Reply Request (response required) Ready Request (frag) Cancel. Request Locate. Rrequest Orderly Shutdown 2 Close. Connection

Sending Messages TCP Connection Request Locate. Reply Request (response required) Cancel. Request Locate. Rrequest Ready Request (frag) Request Fragments last fragment Locate Cancel. Request last fragment Request Response Req. Fragmented Cancel. Request Reply last fragment Prepare Reply (frag) Reply Fragmented

Bibliography z. Tanenbaum, Andrew S. : Computer Networks third edition, Prentice Hall 1996 z. The Common Object Request Broker: Architecture and Specification Revision 2. 2, Feb. 1998 z. Orbix. Web Programmer’s Guide IONA Technologies PLC November 1997 http: //www. iona. com