Internet Protocols and Applications I - PowerPoint PPT Presentation

1 / 72
About This Presentation
Title:

Internet Protocols and Applications I

Description:

Extended CGI. ASP (Active Server Page) of Microsoft ... The ORB passes the receiver's implementation a pointer to a proxy in its own address space ... – PowerPoint PPT presentation

Number of Views:103
Avg rating:3.0/5.0
Slides: 73
Provided by: philipp76
Category:

less

Transcript and Presenter's Notes

Title: Internet Protocols and Applications I


1
Internet Protocols and Applications I
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
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)

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

11
Life-Cycle
  • Instanciation
  • Init()
  • Service()
  • Done()

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

13
Example
  • Refer Apache Tomcat

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

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

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

17
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

18
Introduction toCommon Object Request Broker
Architecture(CORBA)
19
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

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

21
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

22
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

23
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

24
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

25
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

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

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

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

29
CORBA is Software Bus
  • CORBA provides a communication infrastructure for
    a heterogeneous, distributed collection of
    collaborating objects.

30
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

31
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

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

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

35
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

36
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

37
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

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

40
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

41
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

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

43
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

44
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

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

46
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

47
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

48
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

49
Initial OMG IDL Bank Specification
  • // Bank.idl
  • module Bank
  • interface Account
  • float balance()
  • interface AccountManager
  • Account open(in string name)

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

51
Object Activation, invocation by the BOA
52
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)

53
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()

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

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

56
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()

57
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

58
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

59
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

60
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

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

62
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

63
Interoperability via ORB-to-ORB
64
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.

65
Example of CORBA 2.0 Interoperability
66
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

67
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

68
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

69
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

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

71
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

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