CORBA

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. User views view 1 view 2 view 3 Ontology ordering layout chair transactions bed combinations Distributed Persistent Business Objects Repository DBMS ODBMS Physical storage

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

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 codeserver 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 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. 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 • CLOSEDno connection is active or pending • SYN SENTstarted to open a connection • ESTABLISHED normal data transfer state • FIN WAIT1 application has said it is finished • FIN WAIT2other 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.