The Future of Internet - PowerPoint PPT Presentation

1 / 60
About This Presentation
Title:

The Future of Internet

Description:

e.g., Windows OLE and the OMG Common Object Service Specification(COSS) ... Widows OLE/COM. Traditionally limited to desktop application. CORBA Components ... – PowerPoint PPT presentation

Number of Views:49
Avg rating:3.0/5.0
Slides: 61
Provided by: ebizUa
Category:
Tags: future | internet | ole

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com