Internet Protocols and Applications I

1
Internet Protocols and Applications I
Incheon Paik
2
Some Protocols

• HTTP Communication
• Connectionless Communication
• Stateless Communication

(1) TCP Connection Request
(2) HTTP Request
Server
Client
(3) HTTP Response
(4) TCP Connection Close
3
Some Protocols

• HTTP Message
• Start Line Client Request Information /
  Response Status Information
• Message Header Additional Information for HTTP
  Message such as Date, Program Name, Version,
  Cookie, User Authentication, Cache
• Message Body Contents for Request or Response.
  In case of POST, Input data consists of data
  stream encoded in request message.

4
Some Protocols

• Client Request Message in HTTP
• Request HTTP Command, URI, and HTTP Version,
  Header NameHeader Value, Request Message Body
• HTTP Command GET, HEAD, POST/ OPTIONS, PUT,
  DELETE, LINK, UNLINK, TRACE
• Server Response Message in HTTP
• Response Message HTTP Version, Status Code,
  Code Description, Response Header, Response
  Message Body
• Response Status Code (Reference 100-199),
  (Success 200-299), (Redirection 300-399),
  (Incomplete 400-499), (Server Error 500-599)

5
Some Protocols

• HTTP Message Header
• HTTP Header Used for transmitting any kinds of
  information between client and server, Header
  Name Blank Header-value
• General Header Client Request, Server Response,
  Cache setup, Connection, Date, etc
• Client Request Header Client information and
  preferred data type, Accept Character set,
  encoding type, and authorization
• Response Header Server Information, Message
  processing methods for response message. Web
  server information, Cookie setup, authenticate
  information.
• Entity Header HTTP message body information,
  encoding method of message, contents length, MD5
  information, encoding method of contents
  transmission, MIME type

6
Some Protocols

• MIME Type
• As HTTP transmission deal with multimedia
  documents, pre-defined method to deal with that
  data by client should be described.
• MIME(Multipurpose Internet Mail Extension) Type
• Client Using Accept Header, Clients can define
  their preferred media type
• Server Describe MIME Type in Content-Type
  Header
• MIME Type form Type/Subtype (ex
  application/x-javascript)
• Standard MIME Type
• Text, Multipart, Message, Application, Image,
  Audio, Video

7
CGI Communication

• CGI(Common Gateway Interface)
• Transmit Messages by GET/POST Method
• Characteristics
• Extend Web Server, Dynamic Response, Only Install
  in Server Side
• Overhead, Security, Interactive pages, Cannot
  keep the connection Problems

Process 1
Process 1
Process 1
Web Server
CGI Program
Processes
8
Extended CGI

• ASP (Active Server Page) of Microsoft
• Combine HTML, Server side Script, and Server side
  Component
• Written in Jscript, VBScript, and run on IIS
  Server
• Can use COM Component
• Java Servlet and JSP
• Platform Independent, Safe and Effective Thread
  Service, Object Oriented Paradigm
• Easy to interoperate with Legacy Application
• JSP is similar to ASP, and provide HTML script
  language and JavaBeans Component
• Object Web
• CORBA (Common Object Request Broker Architecture)
• EJB (Enterprise JavaBeans)
• DCOM (Distributed Common Object Model)

9
AJAX (Asynchronous JavaScript And XML)
Classic Web Application Architecture
Ajax Architecture
10
Motivations of Servlet and JSP
Slide 9-18, Used the Material by Philippe Rochat

• Faster than CGI (no process creation overhead)
• Java is Internet oriented
• Servlet API
• Security
• Session support
• Code reuse and portability
• JDBC support
• Next step Enterprise Java Beans (EJB)

11
Object Web
RMI/IIOP
JSP
DBMS
EJB
HTML/XML
HTTP
Web Server
IIOP
CORBA
HTTP
Servlet
Applet
Legacy Application
12
Servlet and Servlet Container
Servlet Application 1
Servlet Application 2
Servlet Application N
Java Servlet API
Servlet Container 1
Servlet Container 2
Servlet Container N

• Servlet Container
• - To run servlet, there need to be JVM to run
  Java servlet class and
• servlet container to provide servlet
  applications with system service.
• Deliver HTTP request of a client to servlet
  application,
• and HTTP response of the servlet applcation to
  the client

13
How-to Write Servlet

• Very Similar to applet
• Must inherits
• HttpServlet
• Must implements one of
• doGet
• doPost
• doPut
• Receives
• HttpServletRequest
• HttpServletResponse

14
Life-Cycle

• Instantiation
• Init()
• Service()
• Done()

15
Session

• public void doGet(HttpServletRequest request,
  HttpServletResponse response)
• HttpSession session request.getSession(true)
• session.setAttribute(dataName, dataValue)
• Enumeration e session.getAttributeNames()

16
Examples

• Refer to Apache Tomcat
• When you install Apache Tomcat,
• http//localhost8080/servlets-examples/

17
Cookies

• public void doGet(HttpServletRequest request,
  HttpServletResponse response)
• Cookie cookies request.getCookies()
• response.addCookie(c)

18
Pros and Cons

• Cons
• HTML embedded in Java source file
• Pros
• Power of Java Platform
• Speed
• Portability across servers and DBs

19
More

• At sun
• http//java.sun.com/products/servlet/index.html
• Apache
• http//jakarta.apache.org/tomcat/
• Lbdpc15
• TomCat documentation

20
Execution of JSP
Handler Request
JSP Request
JSP Handler Servlet
Servlet Container
Web Browser
Web Server
Servlet Invocation
JSP File Check
Java file Compile
Class Loading
JSP file Compile
JSP Servlet
Class File (.class)
JSP File (.jsp)
Java File (.java)

• A user requests .jsp file through URL.
• Web server requests JSP handler to process .jsp
  file
• JSP/Servlet container pass the corresponding
  .jsp file to JSP handler servlet
• JSP Handler Servlet
• Check JSP file, execute the existing .class
  servlet when no change
• When there was change, generate .java source
  code from .jsp
• Compile the java source
• when .class file was generated normally, execute
  the servlet.

21
JSP

• Allows HTML embedded tags
• lthtmlgt
• ltjspuseBean id"cart" scope"session"
  class"sessions.DummyCart" /gt
• ltjspsetProperty name"cart" property"" /gt
• lt
• cart.processRequest(request)
• gt
• ltFONT size 5 COLOR"CC0000"gt
• ltbrgt You have the following items in your cart
• ltolgt
• lt
• String items cart.getItems()
• for (int i0 iltitems.length i)
• gt
• ltligt lt itemsi gt
• lt
• gt
• lt/olgt

22
Examples

• Refer to Apache Tomcat
• When you install Apache Tomcat,
• http//localhost8080/jsp-examples/

23
Introduction toCommon Object Request Broker
Architecture(CORBA)
24
Contents

• Overview of distributed programming challenges
• Overview of CORBA architecture
• CORBA programming with Java ORB
• WWW, Java and CORBA
• GIOP and IIOP
• Trends in Internet

25
Introduction

• Developing distributed applications whose
  components collaborate efficiently, reliabley,
  transparently, and scalably is hard.
• To help address this challenge, the Object
  Management Group(OMG) is specifying the CORBA
• OMG is a consortium of 700 more strong computer
  compaines and universities.
• Netscape, Sun, HP, DEC, Mircrosoft, IBM,
  Visigenic, IONA, etc.

26
History of OMG CORBA

• 1991 CORBA version 1.1 published
• 1992 - 1996 CORBA Core and Interoperability
  Architecture Communications
• 1994 CORBA 2.0 published, including
  Interoperable Specification
• 1994 - 1996 CORBAservices Basic Services for
  Object-Oriented Application
• May, 1996 CORBA Task Force issues Secure
  Interoperability Protocol
• 1995 - CORBAfacilities Application
  level Data Manipulation Storage

27
History of OMG CORBA

• 1997 CORBA version 2.1 Identify
  Problems
• 1998 CORBA 2.2 Portable Object
  Adapter Management of Lifetime Server Object,
  Portability
• CORBA 2.3 Object By Value
• 1999 CORBA 3 Internet Integration,
  QoS, CORBA Component Architecture

28
Source of Complexity

• Distributed application development exhibits both
  inherent and accidental complexity
• Inherent Complexity results from fundamental
  Challenges in the distributed application domain,
  e.g.,
• Addressing the impact of latency
• Detecting and recovering from partial failures of
  networks and hosts
• Load balancing and service partitioning
• Consistent ordering of distributed events

29
Source of Complexity

• Accidental complexity results from limitations
  with tools and techniques used to develop
  distributed applications.
• Lack of type-safe, portable, re-entrant, and
  extensible system call interfaces and
  component libraries
• Inadequate debugging support
• Widespread use of algorithmic decomposition
• Fine for explaining network programming
  concepts and algorithms but inadequate for
  developing large-scale distributed applications
• Continuous rediscovery and reinvention of core
  concepts and components

30
Motivation for CORBA

• Simplifies application interworking
• CORBA provides higher level integration than
  traditional "untyped TCP byte streams "
• Provides a foundation for higher-level
  distributed object collaboration
• e.g., Windows OLE and the OMG Common Object
  Service Specification(COSS)
• Benefits for distributed programming
  similar to OO languages for
  non-distributed programming
• e.g., encapsulation, interface inheritance, and
  object-based exception handling

31
CORBA Contributions

• CORBA addresses two challenges of developing
  distributed system
• Making distributed application development no
  more difficult than developing centralized
  programs.
• Easier said than done due to
• Partial failures
• Impact of latency
• Load balancing
• Event Ordering
• Providing an infrastructure to integrate
  application components into a distributed system
• i.e., CORBA is an "enabling technology"

32
CORBA Bank Example (Old Version)

• Ideally, to use a distributed service, we'd like
  it to look much like a non-distributed service
• public static void main(String args)
• Bank.AccountManager manager Bank.AccountManager_
  var.bind(My Bank")
• Bank.Account account manager.open(name)
• float balance account.balance()
• System.out.println ("The balance in " name
  "'s account is " balance)

33
CORBA Bank Interface

• We need to write an OMG IDL. Interface for our
  Bank object
• This interface is used by both clients and
  servers
• // Bank.idl
• module Bank
• interface Account
• float balance()
• interface AccountManager
• Account open(in string name)

34
CORBA is Software Bus

• CORBA provides a communication infrastructure for
  a heterogeneous, distributed collection of
  collaborating objects.

35
Related Works

• Related technologies for application integration
  include
• Traditional RPC
• Provides "procedural" integration of application
  serveices
• Doesn't provide object abstractions
• Does not address inheritance of interfaces
• Widows OLE/COM
• Traditionally limited to desktop application

36
CORBA Components

• The CORBA specification is comprised of several
  parts
• 1. An Object Request Broker (ORB)
• 2. Basic Object Adapter (BOA), Portable Object
  Adapter(POA)
• 3. An Interface Definition Language (IDL)
• 4. A Static Invocation Interface (SII)
• 5. A Dynamic Invocation Interface (DII)
• 6. A Dynamic Skeleton Interface(DSI)
• 7. Interface and implementation repositories
• 8. Programming language mappings
• 9. An Interoperability Spec(GIOP and IIOP)
• Other documents form OMG descirbe common object
  services built upon CORBAservices
• e.g. , Event services, Name services, Lifecycle
  service

37
CORBA Architecture
38
CORBA Architecture

• The ORB is the foundation of all other CORBA
  services and facilities

39
Object Request Broker

• The Object Request Broker(ORB) is the central
  component in CORBA
• An ORB provides mechanisms for invoking methods
  on local/remote objects
• ORB mechanisms automate
• Object location, creation, activation and object
  management
• Message exchange between objects
• CORBA ORB provides security also.

40
Interface Definition Language (IDL)

• Developing flexible distributed applications
  on heterogeneous platforms requires a strict
  separation of interface from implementation(s)
• Benefits of using an IDL
• Ensure platform independence
• e.g., Windows NT to UNIX
• Enforce modularity
• e.g., must separate concerns
• Increase robustness
• e.g., reduce opportunities for network
  programming errors
• Enable language independence
• e.g., C, Smalltalk, COBOL to C, Java

41
CORBA IDL

• OMG IDL is an object-oriented interface
  definition language
• Used to specify interfaces containing operations
  and attributes
• OMG IDL support interface inheritance (both
  single and multiple inheritance)
• OMG IDL is designed to map onto multiple
  programming languages
• e.g., C, C, Smalltalk, COBOL, Modula 3, DCE,
  Java, etc.
• OMG IDL is similar to Java interfaces, class and
  C class

42
OMG IDL Compiler

• A OMG IDL compiler generates client stubs and
  server skeletons
• Stubs and skeletons automate the following
  activities (in conjunction with the ORB)
• Client proxy factories
• Prameter marshalling/demarshalling
• Implementation class interface generation
• Object registration and activation
• Object location and binding

43
Producing IDL file, Client, and Object
Implementation
44
Application Interfaces

• Interfaces described using OMG IDL may be
  application-specific, e.g.,
• Databases
• Spreadsheets
• Spell checker
• Network manager
• Air traffic control
• Documents
• Medical imaging systems
• Objects may be defined at any level of
  granularity
• e.g., from fine-grained GUI objects to multi-mega
  byte multimedia "Blobs"

45
OMG IDL Features

• OMG IDL is a superset of C, Java, etc.
• Note, it is not a complete programming language,
  it only defines interfaces
• OMG IDL supports the following features
• Modules
• Interfaces
• Operations
• Attributes
• Inheritance
• Basic types(e.g., double, long, char, etc).
• Arrays
• Sequence
• Struct, enum, union, typedef
• Consts
• Exceptions

46
Static Invocation Interface(SII)

• The most common way of using OMG IDL involves
  the "Static Invocation Interface" (SII)
• In this case, all the methods are specified in
  advance and are know to the client and the
  server via proxies
• proxies are also known as surrogates
• The primary advantage of the SII is its
  simplicity, typesafety, and efficiency

47
Dynamic Invocation Interface (DII)

• A less common way of using OMG IDL involves the
  "Dynamic Invocation Interface" (DII)
• The DII enables objects and their methods to be
  specified and called at run-time
• Uses meta-data stored in an "Interface
  Repository"
• The DII is more flexible than the SII apporach,
  e.g.,
• It supports tools tools like a MIB browser that
  may not know all their components or operations
  at compile-time
• It also enables the use of deferred synchronous
  invocation
• The DII is also more complicated and less
  typesafe and efficient.

48
Dynamic Skeleton Interface (DSI)

• The "Dynamic Skeleton Interface" (DSI) provides
  analogous functionality for the server-side that
  the DII provides on the client-side
• It is defined in CORBA 2.0 primarily for using
  building ORB "Bridges"
• The DSI lets server code handle arbitrary
  invocations on CORBA objects

49
Object References

• An "Object reference" is an opaque handle to an
  object
• Object references amy be passed among processes
  on separate hosts
• The underlying CORBA ORB will correctly convert
  object references into a form that can be
  transmitted over the network
• Presumably by converting it to a "stringfied"
  reference
• The ORB passes the receiver's implementation a
  pointer to a proxy in its own address space
• This proxy refers to the object's implementation
• Object references are a powerful feature of CORBA
• e.g., supports "peer-to-peer" interactions

50
Object Adaptor

• CORBA "object adaptors" provide services for
  binding object references to their associated
  object implementations
• Several types of object adaptors are available
• Basic Object Adaptor(BOA)
• Objects and object references are known to the
  ORB
• Thus, an object implementation has to explicitly
  register objects to be activated
• Object-Oriented Database Adaptor(OODA)
• This adapter uses a connection to an o-o db to
  access the objects stored in it.
• Since the OODB provides the emthods and
  persistent storage, object may be registerd
  implicitly.

51
Object Adaptor

• Creation and Analysis of Object Reference
• Method Invocation
• Interaction
• Activation and Deactivation of Object and
  Implementation
• Matching to Object Implementation According to
  Object Reference
• Registration of Object
• Problem of BOA
• Inconsistency of Specification
• Difference of BOA Implementation
• Problem in Server Portability

52
Portable Object Adaptor

• Allow the Persistent Object
• Allow more Object Implementation
•  
• Characteristics
• Map an Object Reference to the Servant that
  Implements that object
• Allow Transparent Activation of Objects
• Associate Policy Information With Objects
• Make a CORBA object persistent over several
  server process lifetimes
• Object ID Namespace
• Policy of Multi-Threading, Security, Object
  Management
• Multi POA with different policy and name space
  exist in a server

53
EXAMPLE

• Bank Example
• Bank server maintains the user's account
• Clients can request to open his account and to
  ask his balance via CORBA interfaces and CORBA
  run-time
• Since the server(s) and the clients are
  distributed, the solution must work across LAN
  and WAN environments

54
Initial OMG IDL Bank Specification

• // Bank.idl
• module Bank
• interface Account
• float balance()
• interface AccountManager
• Account open(in string name)

55
Compiling the Interface Definition

• Running the Bank module definition through the
  IDL compiler generates client stubs and server
  skeletons
• The client stub acts as a proxy and handles
  object binding and parameter marshalling from
  requestor
• The server skeleton handles object registration,
  activation, and parameter demarshalling from
  target
• CORBA allows two ways to associate an object
  implementation to a generated IDL skeleton
• 1. BOAImpl -gt uses the Class form of the Adapter
  pattern(inheritance)
• 2. TIE -gt uses the Object form of the Adapter
  pattern (object composition)

56
Object Activation, invocation by the BOA
57
Main Server Program

• Developer Can Register or Activate the Objects on
  Server according to Policy
• // Server.java
• import org.omg.PortableServer.
• public class Server
• public static void main(String args)
• try
• // Initialize the ORB.
• org.omg.CORBA.ORB orb org.omg.CORBA.ORB.in
  it(args,null)
• // get a reference to the root POA
• POA rootPOA POAHelper.narrow(orb.resolve_i
  nitial_references("RootPOA"))
• // Create policies for our persistent POA
• org.omg.CORBA.Policy policies
• rootPOA.create_lifespan_policy(LifespanPolicyValue
  .PERSISTENT)

58
Main Server Program (Continued)

• // Create myPOA with the right policies
• POA myPOA rootPOA.create_POA(
  "bank_agent_poa", rootPOA.the_POAManager(),
  policies )
• // Create the servant
• AccountManagerImpl managerServant new
  AccountManagerImpl()
• // Decide on the ID for the servant
• byte managerId "BankManager".getBytes()
• // Activate the servant with the ID on myPOA
• myPOA.activate_object_with_id(managerId,
  managerServant)
• // Activate the POA manager
• rootPOA.the_POAManager().activate()
• System.out.println(myPOA.servant_to_referenc
  e(managerServant) "
  is ready.")
• // Wait for incoming requests
• orb.run()
• catch (Exception e)
  e.printStackTrace()

59
A Client Program

• // Client.java
• public class Client
• public static void main(String args)
• // Initialize the ORB.
• org.omg.CORBA.ORB orb org.omg.CORBA.ORB.init
  (args,null)
• // Get the manager Id
• byte managerId "BankManager".getBytes()
• // Locate an account manager. Give the full
  POA name and the servant ID.
• Bank.AccountManager manager
• Bank.AccountManagerHelper.bind(orb,
  "/bank_agent_poa", managerId)
• // use args0 as the account name, or a
  default.
• String name args.length gt 0 ? args0
  "Jack B. Quick"
• // Request the account manager to open a
  named account.
• Bank.Account account manager.open(name)
• // Get the balance of the account.
• float balance account.balance()
• // Print out the balance.
• System.out.println
• ("The balance in " name "'s account is
  " balance)

60
Implementing the Object

• // AccountManagerImpl.java
• import org.omg.PortableServer.
• import java.util.
• public class AccountManagerImpl extends
  Bank.AccountManagerPOA
• public synchronized Bank.Account open(String
  name)
• // Lookup the account in the account
  dictionary.
• Bank.Account account (Bank.Account)
  _accounts.get(name)
• // If there was no account in the dictionary,
  create one.
• if(account null)
• // Make up the account's balance, between 0
  and 1000 dollars.
• float balance Math.abs(_random.nextInt())
  100000 / 100f
• // Create the account implementation, given
  the balance.
• AccountImpl accountServant new
  AccountImpl(balance)

61
Implementing the Object

• try
• // Activate it on the default POA which
  is root POA for this servant
• account Bank.AccountHelper.narrow(_defau
  lt_POA().servant_to_reference(accountServant))
• catch (Exception e)
• e.printStackTrace()
• // Print out the new account.
• System.out.println("Created " name "'s
  account " account)
• // Save the account in the account
  dictionary.
• _accounts.put(name, account)
• // Return the account.
• return account
• private Dictionary _accounts new Hashtable()
• private Random _random new Random()

62
Run Example

• Activate OSAGENT
• Server Side
• ltpromptgt java Server
• Server Activation
• Client Side
• ltpromptgt java Client Account Name
• Client can receive the response from Server

63
OMG IDL Mapping Rules

• The CORBA specification defines mappings from
  CORBA IDL to various programming language
• e.g., C, C, Java, Smalltalk
• Mapping OMG IDL to Java
• Each module is mapped to package
• Each interface within a module is mapped to
  abstract class or fully implemented class
• Each operation is mapped to a Java method with
  appropriate parameters
• Each read/write attribute is mapped to a pair of
  get/set methods
• A read-only attribute is only mapped to a single
  get method

64
Binding a Client to a Target Object

• Three typical steps
• 1. A CORBA client (requestor) obtains an "object
  reference" from a server
• e.g., May use a naming service or a locator
  service
• 2. This object reference serves as a local proxy
  for the remote target object
• 3. The client may then invoke methods on its
  proxy
• Recall that object references may be passed as
  parameters to other remote objects

65
Experiences with Java ORBs

• ORB Interoperability
• Visigenics Black Widow(now, VisiBroker) supports
  the CORBA 2.0 IIOP
• DSTC provide a permanent ORB Interoperability
  showcase
• Java language binding for CORBA
• Development time can be significantly reduced
  when using Java instead of C
• Portability
• Java ORB profit from Java portability
• Performance
• Now, Java ORBs do not perform very well(about 20
  times longer)
• But, faster compiler (e.g., Just-in Time
  Compiler) will solve it
• Applet clients vs. CGI based clients
• Middleware advantages
• automatic generation of stub code
• separating interfaces from implementations
• automatic type checking

66
Internet Inter-ORB Protocol(IIOP)

• Interoperability Via ORB-to-ORB
• ORB Interoperability Architecture
• Example of CORBA 2.0 Interoperability
• Interoperable Object Reference
• General Inter-ORB Protocol(GIOP)
• Internet Inter-ORB Protocol (IIOP)

67
Interoperability Via ORB-to-ORB

• All of the clients connected to ORB 1 can access
  object implementations in both ORB 1 and ORB 2
• The same condition holds for clients connected to
  ORB 2
• This architecture scales to any number of
  connected ORBs

68
Interoperability via ORB-to-ORB
69
ORB Interoperability Architecture

• Immediate bridging
• two domains talk directly to each other over a
  single bridge that translate whatever parts of
  the message require it.
• fast and efficient but inflexible and require a
  lot of bridges
• Mediated bridging
• All domains bridge to a single common protocol
• common protocol is IIOP
• the number of bridge types only grows as fast as
  the number of different domains.
• this conforms to the backbone configuration of
  most large, multiprotocol networks mediated
  bridging configures naturally in these networks.

70
Example of CORBA 2.0 Interoperability
71
Interoperable Object Reference (IOR)

• Specialized Object Reference
• Be used by an application in the exact same way
  that an object reference is used
• allows an application to make remote method calls
  on a CORBA object
• An application which obtain IOR, it can access
  the remote CORBA object via IIOP
• The application constructs a GIOP message and
  sends it
• The IOR contains all the information needed to
  route the message directly to the appropriate
  server

72
General Inter-ORB Protocol (GIOP)

• Goal
• Widest possibility, availability, Simplicity,
  Scalability, Lowcost, Generality, Architectural
  neutrality
• GIOP consists of three specification
• The Common Data Representation (CDR) definition
• Trasnfer syntax, mapping from data types defined
  in OMG IDL to a bicanonica, low-level
  representation for transfer between agents.
• SPEC takes into account byte ordering and
  alignment

73
General Inter-ORB Protocol (Continued)

• GIOP message formats
• carry requests, locate object implementations,
  and manage communication channels.
• Message Header
• include magic number, version number, byte
  order, message type, message size
• Seven Messages
• Be sent by the client Request, CancelRequest,
  LocateRequest
• Be sent by Server Reply, LocateReply,
  CloseConnection
• Both may send MessageError

74
General Inter-ORB Protocol (Continued)

• GIOP transport requirements
• a connection-oriented protocol
• reliable delivery (byte order must be preserved,
  and acknowledgment of delivery must be available)
• participants must be notified of disorderly
  connection loss
• the model of initiating a connection must meet
  certain requirements

75
Internet Inter-ORB Protocol (IIOP)

• The mapping of the GIOP message transfer to
  TCP/IP connections is called IIOP
• GIOP can map to Novell IPX and OSI also
• TCP/IP Connection Usage
• Servers must listen for connection requests.
• A client needing a objects services must
  initiate a connection with the address specified
  in the IOR, with a connection request
• The listening server may accept or reject the
  connection.
• Once a connection is accepted, the client may
  send Request, LocateRequest, or CancelRequest
  messages by writing to the TCP/IP socket it owns
  for the connection.

76
CORBA Common Services

• Basic Services to build distributed object system
• Naming, Event, Persistence, Life Cycle,
  Concurrency, Externalization, Relation,
  Transaction, Timing, License, Security,Property,
  Query, Trader, Collection, Startup, Interface
  type Version Management Services

77
CORBA Common Facilities

• Software Components to provide some application
  function
• Horizontal facilities, Vertical facilities
• Horizontal facilities Compound Presentation,
  Compound Interchange, Internalization, Time
  Operations, Mobile Agent, System Management
• Vertical facilities Healthcare, Financial
  Facilities.