This document provides an overview of CORBA (Common Object Request Broker Architecture) and IIOP (Internet Inter-ORB Protocol). It discusses how CORBA allows distributed objects to communicate by defining standard protocols like IIOP that uses TCP/IP. It also explains key CORBA concepts like IDL (Interface Definition Language) for defining object interfaces, ORBs (Object Request Brokers) that allow communication between objects, and how IIOP maps CORBA messages to TCP.

1. CORBA
&
IIOP
Luk Stoops - VUB programming lab

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

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

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

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

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

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

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

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

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

11. Object Request Broker

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

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

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

15. Structure of a CORBA Application
Define the interfaces to objects in your
system, using CORBA IDL.
Compile these interfaces using an IDL
compiler.
IDL compiler generates Java from IDL
definitions.
client stub code.
server skeleton code.

16. client stub code
server skeleton code

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

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

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

20. Dynamic Invocation Interface

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

22. Dynamic Skeleton Interface

23. The Object Management
Architecture
 Application objects.
 ORB.
 CORBAservices.
 CORBAfacilities.

24. The Object Management
Architecture

25. CORBAservices
Naming Service.
Trader Service.
Object Transaction Service.
Security Service.
Event Service.

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

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

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

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

30. The wolf, the Goat and the Cabbage
0 ---- FWGC
1 ---C FWG-
2 --G- FW-C
3 --GC FW--
4 -W-- F-GC
5 -W-C F-G-
6 -WG- F--C
7 -WGC F---
8 F--- -WGC
9 F--C -WG-
10 F-G- -W-C
11 F-GC -W--
12 FW-- --GC
13 FW-C --G-
14 FWG- ---C
15 FWGC ----
2
(24 = 16)

31. Unstable States
State 3 and 12 are both instable because
the goat will eat the cabbage.
State 6 and 9 are instable as well because
the wolf will eat the goat.
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.

32. 0 ---- FWGC
1 ---C FWG-
2 --G- FW-C
3 --GC FW--
4 -W-- F-GC
5 -W-C F-G-
6 -WG- F--C
7 -WGC F---
8 F--- -WGC
9 F--C -WG-
10 F-G- -W-C
11 F-GC -W--
12 FW-- --GC
13 FW-C --G-
14 FWG- ---C
15 FWGC ----
Finite State Machine Model

33. Solutions

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

35. Layer Model
HTTP IIOP

36. IP
Best-effort service
Header fields (subset)
type of service (speed - reliability)
total length
identification (datagram id)
fragmenting info
time to live
source and destination address

37. TCP/IP
IP (Internet Protocol).
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.
TCP must furnish the reliability that most
users want and that IP does not provide.

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

39. Connections
Connections are identified by the socket
identifiers at both ends (socket1, socket2).
Port numbers below 256 : well-known ports
reserved for standard services
FTP (21)
TELNET (23)
HTTP (80)
All TCP connections are full-duplex and
point-to-point.

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

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

42. 20-byte Header

43. Sliding Window Protocol
Sender transmits a segment
starts a timer.
Segment arrives
receiving TCP entity sends back a segment
bearing an acknowledgement number
(next sequence number it expects to receive).
If the sender's timer goes off before the
acknowledgement is received, the sender
transmits the segment again.

44. Finite State Machine Client
event/action pair

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

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

47. Delayed Duplicates
The internet can lose, store and duplicate
packets.
Congested subnet
Each packet times out and is retransmitted two
or three times.
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.

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

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

50. Closing a TCP Connection
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.
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.

51. Closing a TCP Connection
Pair of two simplex connections.
Send a TCP segment with the FIN bit set.
FIN is acknowledged? -> direction is closed.
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

52. Finite State Machine
Client Closing a Connection
ESTABLISHED

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

54. Finite State Machine
Server Closing a Connection

55. Complete
FSM
Client
Server
Abnormal

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

60. IIOP Message Formats
Seven message types are defined.
 A common message header.
message size
GIOP version number
the byte ordering
a flags field indicating whether or not more
fragments follow
the message type

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

62. Messages

63. Setting up a Connection
Connection
Request
Orderly
Shutdown
2
Orderly Shutdown
1
Abortive
Disconnect
No TCP
Connection
connection request
rejected
client + server closing
server close
client close
client close
server close
accept
TCP Connection
CloseConnection
Ready
Request
LocateRrequest
CancelRequest
LocateReply
Request (response required)
Request (frag)

64. Sending Messages
TCP Connection
Locate
Reply
Fragmented
Prepare
Reply
Request
Response Req.
Fragmented
Request
Fragments
Ready
Request
last fragment
LocateRrequest
CancelRequest
last fragment
last fragment
LocateReply
Request (response required)
Request (frag)
Reply (frag)
Reply
CancelRequest
CancelRequest CancelRequest
CancelRequest

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