UNIT V - The OMG way-system object model Notes.ppt
- 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.
- 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).
- 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.
- 23. The Object Management Architecture Application objects. ORB. CORBAservices. CORBAfacilities.
- 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".
- 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
- 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