The Future of Internet

1
The Future of Internet Distributed Objects

• Incheon Paik
• National key Laboratory of Software Development
  Environment

2
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

3
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.

4
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

5
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

6
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

7
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

8
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"

9
CORBA Bank Example

• 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("Bank of China")
• Bank.Account account manager.open(name)
• float balance account.balance()
• System.out.println ("The balance in " name
  "'s account is " balance)

10
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)

11
CORBA is Software Bus

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

12
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

13
CORBA Components

• The CORBA specification is comprised of several
  parts
• 1. An Object Request Broker (ORB)
• 2. Basic Object Adapter (BOA)
• 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

14
CORBA Architecture
15
CORBA Architecture

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

16
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.

17
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

18
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
• Visigenic's Caffeine demo version was
  demonstrated in Netscape's Developer Conference
  in Oct. 20, 1996.
• This tries IDL Independent programming
  environment. will be come out in quarter of next
  year.

19
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

20
Producing IDL file, Client, and Object
Implementation
21
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"

22
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

23
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

24
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.

25
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

26
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

27
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.

28
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

29
Initial OMG IDL Bank Specification

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

30
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)

31
Object Activation, invocation by the BOA
32
Implementing the Methods

• Using either the BOA Implementation or the TIE
  approach, a developer then writes Java
  definitions for the methods in class Account,
  AccountManager
• // Server.java
• import java.util.
• class Account extends Bank._sk_Account
• Account(float balance)
• _balance balance
• public float balance() throws CORBA.SystemExceptio
  n
• return _balance
• private float _balance
• class AccountManager extends Bank._sk_AccountManag
  er
• AccountManager(String name)
• super(name)

33
Implementing the Methods (Continued)

• public Bank.Account open(String name) throws
  CORBA.SystemException
• // Lookup the account in the account dictionary.
• Bank.Account account (Bank.Account)
  _accounts.get(name)
• if(account null)
• // Create a new account with between 0 and 1000
  dollars.
• float balance Math.abs(_random.nextInt())
  100000 / 100f
• account new Account(balance) // PAIK'S TRY
• System.out.println("Created " name "'s
  account " account)
• // Export the new object reference.
• _boa().obj_is_ready(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()

34
A Client Program

• // Client.java
• public class Client
• public static void main(String args)
• try
• // Initialize the ORB.
• CORBA.ORB orb CORBA.ORB.init()
• // Locate an account manager.
• Bank.AccountManager manager
• Bank.AccountManager_var.bind("Post-Modern
  Bank")
• // 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)
• catch(CORBA.SystemException e)
  System.err.println(e)

35
The Main Server Program

• // Server.java
• class Account extends Bank._sk_Account //
  Content of Account .
• class AccountManager extends Bank._sk_AccountManag
  er // Content of AccountManager .
• public class Server
• public static void main(String args)
• try
• // Initialize the ORB.
• CORBA.ORB orb CORBA.ORB.init()
• // Initialize the BOA.
• CORBA.BOA boa orb.BOA_init()
• // Create the account manager object.
• AccountManager manager new
  AccountManager("Post-Modern Bank")
• // Export the newly create object.
• boa.obj_is_ready(manager)
  System.out.println(manager " is ready.")
• // Wait for incoming requests
• boa.impl_is_ready()
• catch(CORBA.SystemException e)
  System.err.println(e)

36
Run Example

• Server Side
• ltpromptgt java Server
• AccountManagerServer,oidPersistentIdinterfaceNa
  meBankAccountManager,
• objectNamePost-Modern Bank is ready.
• Created JackB.Quick'saccountAccountServer,oidTr
  ansientId
• interfaceNameBankAccount,serverId3,creationTi
  me-1978991483
• Created Zhang's accountAccountServer,oidTransie
  ntIdinterfaceName
• BankAccount,serverId6,creationTime-1978964182
  

37
Run Example

• Client Side

38
Client-side Stubs

• The OMG IDL compiler automatically generates a
  client-side stub used to define "proxy objects"
  e.g.,
• The Bank Example (VisiBroker of Visigenic)
• Account.java interface for Account
• Account_var.java bind() operation definition
• _st_Account.java preparation for invocation of
  object
• AccountOperations.java interface for operation
  of IDL interface
• Server-side Skeleton
• _sk_Account.java method invocation and return
  results
• _tie_Account.java TIE Approach

39
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

40
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

41
WWW and Java ORB

• WWW, Java, CORBA are mainly complementary
  technologies creating a huge synergy effect.
• These technologies provide
• portable clients
• integration of information and computational
  services
• access to legacy and native servers
• openness through standard conformance
• object technology
• type-safe client server communication

42
WWW and Java ORB

• CORBA Key Features
• standardised and widely accepted distributed
  object-oriented technology
• programming-language independent interface
  specification OMG IDL
• vendor independent through a large number of
  competing ORB providers
• standardised set of common services
  CORBAservices and CORBAfacilities

43
WWW and Java ORB

• WWW Summary Assessment
• Strengths
• access and presentation of hypertext documents
  independent of their location
• integration of a number of application layer
  protocols(HTTP, FTP, NNTP, etc) under a common
  GUI
• Drawbacks(compared with middleware platforms)
• Type-safety and marshling
• Dumb clients and communication overhead

44
WWW and Java ORB

• Strength of Java
• Object-Oriented Programming Language
• Hardware platform/operating system/window system
  independent
• Embeddable into hypertext documents(HTML)
• Applets-applications down-loadable on demand
• Proper GUI implementation within WWW
  browsers(richer than with HTML and state
  preserving)
• Simple application installation and version
  control

45
WWW and Java ORB

• Integration CGI - Based

46
WWW and Java ORB

• Integration Java ORB

47
WWW and Java ORB

• Integration Java ORB
• invocations using IDL generated stubs
• invocations using the DII(Dynamic Invocation
  Interface)

48
Internet access and interoperability
49
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

50
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)

51
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

52
Interoperability via ORB-to-ORB
53
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.

54
Example of CORBA 2.0 Interoperability
55
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

56
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

57
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

58
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

59
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.

60
Trends in Internet

• 1993-1995 1995-199
  1997 -
• Language General Script Java, Java
  Frimarily Java
• Interaction CGI Based Script
  But Flexible
• Base Doc HTML, TEXT
  Objects (Include
• 
  HTML)
• Protocol HTTP, FTP, Gopher IIOP,
  LDAP
• Waves Explosion of Go Inside
  Web based E-Mail
• Web
  (Intranet) Groupware