Network Computing (EE906) Part 4: Distributed Object Technology

Transcription

1 Network Computing (EE906) Part 4: Distributed Object Technology EE906-DOT Objectives Learn and Understand about Basic principles of socket and its programming Java RMI and its programming CORBA architecture and its programming EE906-DOT- 2

2 An Brief Overview of Network-based Middleware Socket is a low level interface to network and inter-process communication (IPC) Remote Procedure Call (RPC) builds on sockets to define functions that can be called remotely, HTTP/CGI can be classed as a form of RPC Distributed Component Object Model (DCOM) is Microsoft s proprietary distributed object computing model (Java) Remote Method Invocation (RMI) is Java s distributed object model with similarities to CORBA, but a single language system. Common Object Request Broker Architecture (CORBA) is a vendor and language neutral standard for a distributed object computing model Mobile Agent Technology (MAT) supports code migration. In this part we will be studying Socket, RMI, and CORBA. EE906-DOT- 3 Sockets EE906-DOT- 4

3 Sockets Mechanism Overview Sockets programming is the most common mechanism for communication over TCP/IP networks and inter-process communication (IPC) on UNIX platforms. Socket APIs exist for almost all platforms and provide vendor interoperability. Three types of sockets: stream use Transfer Control Protocol (TCP) to provide reliable connection oriented data transfer. datagram use User Datagram Protocol (UDP) for unreliable nonconnection oriented data transfer. raw for interface to lower layer protocols such as IP network layer of Internet Control Message Protocol (ICMP). EE906-DOT- 5 What s Socket? A socket is one endpoint of a two-way communication link between two programs running on the network. A socket is bound to a port number so that the layer 4 can identify the application that data is destined to be sent. server port client server port port client The client and server can then communicate by writing to or reading from their sockets. port connection EE906-DOT- 6

4 Socket: High-level Addressing Applications sending datagrams or segments to a host need to identify a target that is more specific than the IP address, since packets are normally directed to certain processes and not to the system as a whole. TCP and UDP provide this by using ports. Client User Application TCP IP Data Link Physical Process TCP IP Data Link Physical Server Process Transport Service Access Point (TSAP) (TCP/UDP ports) Network Service Access Point (NSAP) (IP addresses) Other clients Common applications use well-known port numbers: eg. FTP = 20, telnet = 23, http = 80, POP3 = 110, SMTP = 25 EE906-DOT- 7 Socket: IP address + port number Client process 1 IP address a port u a d u z data c d w x data Server process/ Thread 1 port x d b y v data Client process 1 IP address b port v d b y v data Server process/ Thread 2 port y Client process 1 IP address c port w c d w x data a d u z data Server process/ Thread 3 port z src IP, dst IP, src port, dst port EE906-DOT- 8

5 Lifecycle of a Basic TCP C/S Transaction Socket() bind() Socket() connect() Signals start of session listen() accept() (blocks waiting for connection) write() message read() (blocks waiting for data) (blocks waiting for data) read() response write() close() close() Client process Server process See TCPClient.java and EchoServer.java for example. EE906-DOT- 9 Java Implementation of Sockets Socket support is part of the Java language There are Socket, ServerSocket and DatagramSocket classes. Note that the bind() and listen() calls of Berkeley sockets are incorporated in the ServerSocket() and accept() Java calls. Java attaches streams to a stream (TCP) socket. Java requires the DatagramPacket class to build/receive a packet using a datagram (UDP) socket. Example Analysis (refer to supplement) Open a socket. Open an input stream and output stream to the socket. Read from and write to the stream according to the server's protocol. Close the streams. Close the socket. EE906-DOT- 10

6 Lifecycle of a Multi-session Server Transaction Socket() bind() Socket() listen() connect() Signals start of session accept() write() message accept() read() read() response write() close() close() Client process Server process See TCPClient.java and ThreadedEchoServer.java for example. EE906-DOT- 11 Sun Java RMI (Remote Method Invocation) EE906-DOT- 12

7 RMI Overview The Java RMI system allows an object running in one Java Virtual Machine (JVM) to invoke methods on an object running in another JVM (possibly on another machine across the network). Java RMI provides support for remote communication between programs written in the Java programming language. RMI applications are usually comprised of two separate parts: a server and a client. A typical server application creates some remote objects, makes the references to them accessible, and waits for clients to invoke methods on these remote objects. A typical client application gets the remote reference and then invokes methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. So it is a kind of middleware. EE906-DOT- 13 RMI from Developer s Viewpoint Let s see what functionalities are needed for a typical distributed object application and how they are provided by Java RMI. First, locate remote objects: a simple naming facility, rmiregistry which enables the server application to register its remote objects and the client application to retrieve the remote objects. Then, communicate with remote objects: Details of communication between remote objects are handled by RMI; to the programmer, remote communication looks like a standard Java method invocation. Sometimes, load class bytecodes for objects that are passed: in the case of a caller passing objects to remote objects, RMI provides the necessary mechanisms for loading an object's code, as well as for transmitting its data. EE906-DOT- 14

8 A Simple View of RMI Architecture client RMI registry RMI RMI server EE906-DOT- 15 RMI Structure (using Web server as Deployment Mechanism for example) client RMI registry RMI RMI Web server URL Protocol server URL Protocol URL Protocol Web server EE906-DOT- 16

9 A Closer Look at the RMI Architecture Client Object Server Object Stub Proxy layer Skeleton Remote Reference Manager Remote Reference Layer Remote Reference Manager RMI Transport Layer EE906-DOT- 17 Object in RMI In a distributed application some of the implementations are assumed to reside in different virtual machines. Java RMI is object-oriented and one of the central and unique features of RMI is its ability to download the bytecodes of an object's class if the class is not defined in the receiver's virtual machine. The types and the behaviour of an object, previously available only in a single virtual machine, can be transmitted to another, possibly remote, virtual machine. RMI passes objects by their true type, so the behaviour of those objects is not changed when they are sent to another virtual machine. This allows new types to be introduced into a remote virtual machine, thus extending the behaviour of an application dynamically. Objects that have methods that can be called across virtual machines are remote objects. (see later for how to make an object become remote) EE906-DOT- 18

10 Stub When a remote object is passed from one virtual machine to another, RMI passes a remote stub for a remote object. The stub acts as the proxy for the remote object and is, to the caller, the remote reference. A stub for a remote object implements the same set of remote interfaces that the remote object implements. The caller invokes a method on the local stub, which is responsible for carrying out the method call on the remote object. EE906-DOT- 19 Steps to Develop Distributed Application Using RMI 1. Design and implement the components of distributed application Determine which components are local objects and which are remote ones Define remote interfaces (client s view of the remote object) Implement remote interfaces in server classes Write a server program to create server objects Write the client program 2. Compile sources and generate stubs Compile the remote interfaces, server classes, server and client programs (using javac) Run the stub compiler (rmic) to create client stubs and server skeletons EE906-DOT- 20

11 Steps to Develop Distributed Application Using RMI continue 3. Make classes network accessible In this step, make these classes network accessible: the class files associated with the remote interfaces, stubs, and other classes that need to be downloaded to clients. E.g., using web server 4. Run the application Start the RMI registry on the server (rmiregistry) Run the server program on the server to create and register remote objects Run the client program that calls remote methods of the remote objects EE906-DOT- 21 Java RMI Example Please refer to supplement for source codes. CountRMI.java is a Java interface that defines an object that will be called remotely but does not actually implement the object. Noted that (how an object becomes remote): A remote interface extends the interface java.rmi.remote. Each method of the interface declares java.rmi.remoteexception in its throws clause, in addition to any application-specific exceptions. CountRMIImpl.java is the actual implementation of the remote object. Declares the remote interfaces being implemented Defines the constructor for the remote object Provides an implementation for each remote method in the remote interfaces EE906-DOT- 22

12 Java RMI Example cont. CountRMIServer.java is the main server class that controls the server life-cycle. Create and install a security manager Create one or more instances of a remote object Register remote objects with the RMI remote object registry CountRMIClient.java is an example client implementation. [Source code analysis and live demo] Naming class in JDK API doc. EE906-DOT- 23 A Note about Security In JDK1.2 and above, downloaded code is generally regarded as unsafe and therefore governed by the rules of the installed security manager. JDK 1.2 and above contains enhancements for finer-grained security and requires code to be granted specific permissions to be allowed to perform certain operations. For simplicity, in this example we allow all permissions. grant { permission java.security.allpermission; }; java -Djava.security.policy=<policy file> <app-name> EE906-DOT- 24

13 RMI s advantages RMI can pass objects as parameters or return values because the client and server speak the same language (Java bytecode). Another advantage Java RMI has is that it runs on a virtual machine (VM), which means: bytecode is independent of the processor details; and the VM can use bytecode validation, as well as a security manager thread to check the VM stack behaviour. The normal method of starting RMI is by stub and skeleton proxy objects, as for RPC. However, RMI can additionally send stubs dynamically. CORBA (later in these notes) does not send stub code because the compilation to object code might have been for a different processor. EE906-DOT- 25 RMI Summary (with comparison to CORBA) It shares many similarities with CORBA. RMI doesn t use IDL, instead it uses utility (rmic) to convert server object Java file into stub and skeleton class files. (The stub and skeleton are equivalent to those generated by CORBA IDL compiler) It uses the RMI registry for providing references to objects (similar to CORBA Name service) Like CORBA, it supports both static (compile time) object definition and dynamic (run time) object discovery/definition RMI includes the use of a Security Manager Java RMI allows Java bytecode to be sent over ORB as well as data. Clients can load client stubs at run time after discovering the server. EE906-DOT- 26

14 Microsoft COM/DCOM EE906-DOT- 27 Microsoft COM/DCOM COM (Common Object Model) refers to both a specification and implementation developed by Microsoft COM provides a framework for integrating components, which supports interoperability and reusability of distributed objects. COM processes can run on the same machine but in different address spaces. Distributed COM is an extension to COM that allows network-based component interaction. With DCOM, components operating on a variety of platforms can interact, as long as DCOM is available within the environment. EE906-DOT- 28

15 More on DCOM An ActiveX component is a DCOM object. Natively uses C/C++ (Win32/MFC) Microsoft Visual J++ includes Java bindings for DCOM Incompatible with CORBA. Heavily used by Microsoft. Currently only seriously supported on Windows operating systems. Requires Microsoft Transaction Server (MTS). Likely to be replace by.net... EE906-DOT- 29 CORBA (Common Object Request Broker Architecture) CORBA Introduction IDL CORBA Application Example CORBA Naming Service and Example EE906-DOT- 30

16 CORBA Introduction EE906-DOT- 31 CORBA Overview From Object Management Group (OMG) OMG is a non-profit consortium dedicated to promoting the theory and practice of distributed object technology CORBA is OMG's open, vendor independent specification for an architecture that computer applications use to work together over networks. A complete distributed object platform. Mechanisms by which objects transparently make requests and receive responses CORBA is a standard and NOT a product. EE906-DOT- 32

17 Main CORBA Features Interoperability: provides object independence from network types, languages, component boundaries and operating systems. Transparency: Location transparency thanks to ORB Programming Language transparency thanks to IDL Platform/vendor transparency thanks to GIOP/CDR (Common Data Representation) Network HW/SW transparency thanks to GIOP/CDR CORBA and Java are a formidable partnership, Java brings object portability across platforms. EE906-DOT- 33 CORBA History 1989: OMG founded by 8 members. CORBA 1.0 defined 1991: CORBA 1.1 Includes IDL and basic functionality definitions No real specifications for interoperability 1994: CORBA 2.0 Interoperability (GIOP) and the BOA defined Currently: CORBA 3.x EE906-DOT- 34

18 OMA (OMG Management Architecture) OMA is OMG s vision of distributed object technology and is the framework which all OMG adopted technologies fit. OMA defines the interfaces for the objects and leave the implementation to software vendors. The OMA reference model is an architectural framework for the standardization of interfaces to infrastructure and services used by applications. Emphasis is given to the reusability, the core of OOP. Application Objects Domain Facilities Common Facilities Object Request Broker Naming, Trading, Security, Object Services EE906-DOT- 35 Components of OMA Reference Model Object Request Broker (ORB): at the conceptual centre of RM, acting as a message bus between different objects. Defined in CORBA Spec. Object Services (or CORBA services in OMA brand name): fundamental services that application developer may need in order to find and manage their objects and data. Basic building blocks. Common Facilities (or Horizontal Facilities): end-user-oriented interfaces that provide facilities across application domains. E.g., Internationalization and Time Facilities, Data Interchange and Mobile Agent Facilities, etc. Domain Facilities (or Vertical Facilities): focusing on particular application domains such as telecom, Internet, business object, health care etc and carried out by SIG (Special Interest Group) and task forces. Application Objects: whose interfaces are usually defined by the applications rather than OMG. EE906-DOT- 36

19 CORBA/ORB Architecture EE906-DOT- 37 CORBA Architecture client Client program Proxy for A ORB core ORB Implementation Repository IIOP Interface Repository ORB core Object Adaptor skeleton server Servant A The communication protocol used by CORBA is based on the GIOP (General Inter-ORB Protocol) specification IIOP (Internet Inter-ORB Protocol) denotes the implementation of GIOP over TCP/IP EE906-DOT- 38

20 ORB Components Architecture Clients Server Objects Dynamic Invocation Interface IDL Stubs ORB Interface IDL Skeletons Dynamic Skeleton Interface Object Adapters Object Request Broker IIOP Interface Repository Implementation Repository EE906-DOT- 39 ORB Uses Object Reference to identify and locate objects Object Reference: A handle to an object that a client must hold in order to access the object. Interoperable Object Reference (IOR): object referencing across heterogeneous ORBs. Delivers request to objects; Returns output values back to client The ORB components can be broken up into four groups The ORB Core which uses the Internet Inter-ORB Protocol to communicate between ORBs over TCP/IP. Components responsible for finding and implementing dynamic objects (objects found and linked to implementations at run-time): Interface/Implementation Repositories, Dynamic Invocation and Dynamic Skeleton Invocation. Components responsible for static object interfaces (objects defined at compile time): Client IDL stubs and Static Skeletons. Ancillary components providing support/interface services: ORB Interface and Object Adaptor. See org.omg.corba.orb in JDK1.4 API document EE906-DOT- 40

21 Stubs and Skeletons client stubs and server skeletons A client stub is a small piece of code that allows a client component to access a server component. This piece of code is compiled along with the client portion of the application. Similarly, server skeletons are pieces of code that you "fill in" when you implement a server. The client stubs and server skeletons are generated when you compile IDL interface definitions. EE906-DOT- 41 Dynamic Invocation Interface (DII) & Dynamic Skeleton Interface (DSI) Dynamic Invocation Interface (DII) Let the client discover methods at run time. Allows dynamic construction of object invocations Application can thus make calls on objects without compile time knowledge More flexible than static approach ; but more complicated and less typesafe. Dynamic skeleton interface (DSI) Server counterpart to the client dynamic invocation interface. Produces run-time binding of services that are dynamically found by a client. These interfaces may be used by a developer directly, but most commonly they are used by the ORB internally and are not seen by the general programmer. EE906-DOT- 42

22 Static & Dynamic Skeletons Static Skeletons Server counterpart to the client IDL stubs. Produced by the IDL compiler. Provide static interfaces to the server services. Dynamic skeleton interface Server counterpart to the client dynamic invocation interface. Produces run-time binding of services that are dynamically found by a client. EE906-DOT- 43 Interface Repository (IFR) & Implementation Repository Interface Repository (IFR) Provides type information necessary to issue requests using the DII A store of all the registered component interfaces. Can be dynamically updated as new object interfaces are found. Also stores additional information like debugging info, libraries of stubs or skeletons etc Implementation Repository Run-time store of information about classes that the server supports, instantiated objects and their ID s. Store for ancillary information such as security and administrative information. EE906-DOT- 44

23 ORB Core and ORB Interface Object request broker core Provides the core components to allow inter-orb communication. Is a common bus upon which object methods can be requested. Uses General Inter-ORB protocol (GIOP) which specifies message formats and common data representations. The Internet Inter-ORB Protocol (IIOP) specifies how GIOP messages are transmitted over TCP/IP networks. ORB Interface APIs to local services for the application. E.g., utility services like type conversion for object references. EE906-DOT- 45 Object Adaptor (OA) An Object Adaptor defines how an object is activated transparently. Provides a consistent interface to varied implementations, and controls lifecycle operations on objects. Allowing varied methods of implementation facilitates integration of legacy applications. Implementations must be registered with the OA. Accepts requests for server objects. When a client requests a service from an object, the OA maps the request to the appropriate implementation. Responsible for object instantiation. Assigns a unique object ID (object reference) to each instantiated object. CORBA 2.0 defines the Basic Object Adapter (BOA), CORBA 3.0 defines the Portable Object Adapter (POA). EE906-DOT- 46

24 Common Object Services Specification (COSS) A set of services provided by the ORB to facilitate the development of applications Naming Service (maps object names to object references) Event Service (interfaces to send and receive events) Lifecycle Service (defines conventions for creating / deleting/ copying/moving objects) Persistent Object Service (common interfaces to mechanisms used for retaining/managing persistent state of objects) Transactions Service (supports various transaction models e.g. flat & nested) Query Service (allows queries on collections of objects) Concurrency Control Service (allows multiple clients to coordinate access to shared resources) Relationship Service (defines object relationship graphs) Externalization Service Externalizing: transforming object into a stream of data Internalizing: transforming data stream into new object Licensing service (mechanism of controlling use of objects - to protect intellectual property) EE906-DOT- 47 IDL (Interface Definition Language) EE906-DOT- 48

25 Interface Definition Language (IDL) Separates object implementation from interface A declarative language (like C++) defining types of objects by separating interfaces, operations and parameters Provides a declaration only, the implementation is up to the programmer of the server and is accessed by the client via the CORBA ORB. Used to declare an objects: attributes, parent classes, exceptions, type of events and methods (input/output parameters and types). It is the essential standardised component that allows CORBA to work across multi-vendor, multi-platform/language systems. EE906-DOT- 49 IDL Constructs Constants: to assist with type declarations Data type declarations: to use for parameter typing Attributes: used to get and set a value of a particular type Operations: to take parameters and return values Interfaces: to group data type, attribute, and operation declarations Valuetypes: to group data type, state, and operation declarations Modules: for name space separation All the declarations made in IDL can be made available through the Interface Repository (IR). EE906-DOT- 50

26 Lexical Analysis Identifiers: must start with a letter and may be followed by zero or more letters, numbers, and underscores. Case-sensitive. Keywords: all in lowercase Comments: both styles of C++ comments are used in IDL. /* comments go here, cannot be nested */ // indicating the rest of a line is a comment Punctuation: curly braces, semicolon, comma See the example of IDL file in the supplement. EE906-DOT- 51 Modules and Interfaces To avoid name clashes when using several IDL declarations together the module is used as a naming scope. Module can contain any well-defined IDL, including nested modules. Interfaces also open a new naming scope and contain constants, data type declarations, attributes, and operations. // FlightBooking.idl module FlightBooking { interface Flight {}; }; Any interface name in the same scope can be used as a type name, and interfaces in other name scopes can be referred to by giving a scoped name that is separated by double colons (::). E.g., FlighBooking::Flight ::FlighBooking::Flight - explicitly showing that it is relative to the global scope. EE906-DOT- 52

27 Inheritance An interface can be extended or reused via inheritance. Inheritance is declared by using a colon after the new interface name, followed by a base interface name. module InheritanceExample { interface A { typedef unsigned short ushort; ushort op1(); }; interface B:A { boolean op2(in ushort num); }; }; Multiple inheritance is allowed. E.g. interface C : A, B, X::interfaceY { }; EE906-DOT- 53 Types and Constants The interface name declared in IDL becomes an object type name. The basic types are rich enough to represent numeric, strings, characters, and Booleans. The structured types available in IDL are structure, discriminated union, array, and sequence. Exception can be considered to be a special case of structures that are used only in raises clauses of operations. The keyword typedef allows aliases to be created for any legal type declaration. interface StringProcessor { typedef string <8> octstring; typedef string <100> centastring; // } Constants: const short max_bandwidth = 10; EE906-DOT- 54

28 Operations and Attributes Operation declarations are similar to C++/Java function prototypes, which contain an operation name, a return type (or void to indicate that no value is expected), and a list of parameters (may be empty). Each parameter must have a directional indicator to show in which direction the data travel. in: client to object out: return parameter inout: client value modified by object and returned. Attributes: e.g., typedef float AccountBalance; readonly attribute AccountBalance min_bal, max_bal; attribute string balance_of_the_day; EE906-DOT- 55 Example IDL file module Counter { interface Count { attribute long sum; long increment(); }; }; This defines a simple class with a public data member and function member. The module can be compared to a Java package. The interface is similar to a Java interface or C++ abstract class. The attribute is comparable to a public data member. The method notation is similar to Java or C++. Each language (C++, Java, etc...) requires its own IDL mappings. EE906-DOT- 56

29 IDL to Java Mapping CORBA module method in parameters out and inout parameters typecast attribute char octet string short, long, float, double interface sequence or array Java Package normal Java parameters Java Holder classes (created by IDL then instantiated at the client side) Java Helper classes Java overloaded accessor and modifier methods with the same name as the attribute char byte java.lang.string short, long, float, double interface array EE906-DOT- 57 IDL Compilation IDL compilation produces stubs/skeletons stub - local function call for the client skeleton - server side of the object implementation Client-Server communication is facilitated by stubs & skeletons IDL Definitions Implementation Installation Interface Repository Stubs skeletons Implementation Repository client Object Implementation EE906-DOT- 58

30 CORBA Examples EE906-DOT- 59 Java IDL Development Process Define the Remote Interface Using IDL instead of Java language Using IDL makes it possible for developers to implement clients and servers in any other CORBA-compliant language. Compile the remote interface idlj/idltojava compiler generates the Java version of the interface, as well as the class code files for the stubs and skeletons. Implement the server Implement the client use the stubs as the basis of your client application. The client code builds on the stubs to start its ORB, look up the server using the name service provided with Java IDL, obtain a reference for the remote object, and call its method. Start the applications start the name service, then start the server, then run the client. EE906-DOT- 60

31 IDL code The code examples in the supplement document show an example of a CORBA application. The example client calls a remote object to repeatedly increment a remote variable and times the whole operation. Class design defined: Class CounterClient will instantiate a Count object, call the Count.increment() method a set number of times and time the operation. The corresponding IDL code is: module Counter { interface Count { attribute long sum; long increment(); }; }; EE906-DOT- 61 Code Generated by IDL Compiler The previous IDL code is compiled using an appropriate IDL-to-Java compiler as we wish to show a Java example. The example will demonstrate static method invocation. The compiler produces six Java source files under the package named Counter: Counter/Count.java Counter/_CountStub.java Counter/CountHelper.java Counter/_CountImplBase.java Counter/CountHolder.java Counter/CountOperations.java EE906-DOT- 62

32 Code Generated by IDL Compiler - explanation Counter/_CountStub.java is the client IDL stub that marshals requests onto the ORB bus. Counter/_CountImplBase.java is the implementation of the server static skeleton that unmarshals the requests from the client stub. It combines the functionality of Java and CORBA through the implementation of the org.omg.corba.object interface. Counter/CountHelper.java provides useful helper methods such as a method called narrow() that can cast a CORBA object to a Count object. Counter/CountHolder.java holds a public instance member of type Count and allows the object to be passed as a method parameter across the ORB bus. Counter/Count.java is a Java interface that maps the IDL class definition into Java. It is the interface that is actually used in the client code to invoke the server object. (Note that it actually extends Counter/CountOperations.java) EE906-DOT- 63 Server Side Implementation The IDL compiler has generated quite a lot of code for our simple single method object, however, it has not actually generated the implementation of the method, a client application or a server application. That is left for the programmer to do. Example server code is shown in CountServer.java. The server generates the implementation by extending the Counter._CountImplBase class (as shown in the CountServant class). It starts the ORB, instantiates the Count implementation object (the CountServant count object) and registers it with the ORB. One important feature of this server is that it saves Inter-operable Object Reference (IOR) to disk (the Counter_Count.ref file). An IOR is a standardised object ID that defines where to find the object implementation. EE906-DOT- 64

33 Client Side Implementation The client side uses the Count interface to actually call the remote Count implementation that resides on the server ORB. An example is shown in CountClient.java The client must start the ORB and then find the object that it wishes to use. This simple client uses the stringified IOR that was saved to disk to find the object. Note that instead of instantiating a local Count object the ORB is used to obtain a Count object using the orb.string_to_object() method. This returns an object of type org.omg.corba.object. The narrow() helper function is then used to cast this object to type Count. From thereon the Count object can be used as though it is a local object however in reality its methods are implemented in the server process. EE906-DOT- 65 Discussion of this Simple Example CORBA does all the messy inter-process communication - no need to define socket level application dependent protocols. This simple example has a few shortcomings, the most important of which is that the client can only find the server object through the reference file (Counter_Count.ref). The next example circumvents the object location problem EE906-DOT- 66

34 Client 2 Example The second example uses exactly the same server code as the previous example but implements the client as an applet (CountClientApplet.java used in count.html ) Other than some GUI and applet specific code the client is very similar to the last example. The only significant difference is the technique that the client uses to obtain the server object. How does the client find the server object? EE906-DOT- 67 CORBA Naming Service EE906-DOT- 68

35 CORBA Services There are number of ancillary services that CORBA provides in addition to an ORB. Four of the services (there are many) are: Life Cycle Service - defines operation for creating, copying, moving and deleting components on the bus. Persistence Service - provides a single interface for storing components persistently on storage servers (e.g. DBMS). Event Service - allows components on the bus to dynamically register interest in specific events that signalled on a well-known event channel object. Naming Service - a well known object (i.e it is itself a CORBA object) that allows a client to locate an object by name on another ORB, possibly through an existing network directory service. This service gives another method for our example application to find a server object. EE906-DOT- 69 Dynamic Invocation The examples given in the lecture all use static object invocation. That is the objects are defined at compile time using IDL. CORBA allows a client to search for suitable objects. The server advertises a server object using meta-data. The client can use the metadata to further interrogate the server to find out exactly what the methods for a particular object do. Thus, it is conceivable that a user could discover the required functionality during run-time. Although dynamic invocation requires greater complexity (code is required to interrogate the server) it allows for greater flexibility than static invocation. EE906-DOT- 70

36 Example of CORBA Service: Naming Service Here we will consider the Naming Service as an example CORBA service and use it to show how clients can find objects. Previous examples showed accessing objects using: Object reference stored as a string ( stringified IOR ) on a shared disk resource. (Only works if both client and server have direct access to the disk.) Object reference stored on disk but accessed through a web server. (Requires a web server and the server to be able to write in the web servers file space.) A more flexible (but more complex) approach is to use the CORBA naming service which is itself a CORBA server object! EE906-DOT- 71 CORBA Naming Service The CORBA naming service is encapsulated in a class called org.omg.cosnaming.namingcontext and has the usual associated helper and holder classes associated with it. The code for this CORBA object is usually packaged with the ORB. A server creates a server CORBA object and registers it with the Name server. A client connects to a Name Server and requests a reference to the CORBA object that it requires by its class name. Hierarchical namespaces can be formed. The programs CountClientName.java and CountServerName.java show the use of the name service by extending the earlier Count example (note that the IDL and subsequently produced stub, skeleton, helper and holder are identical). EE906-DOT- 72

37 Creating a CORBA Namespace Application ORB Root Context resolve_initial_references() bind_new_context() Context1 bind_new_context() Context2 bind() object Server Application Name Server EE906-DOT- 73 Finding CORBA Object client ORB Root Context Server Object resolve_initial_references() Create name Resolve reference Object reference invoke methods client Name Server Server EE906-DOT- 74

38 Conclusion of Part 4 Sockets are the lowest level (practical) network communication API CORBA provides vendor/language/operating system independent client/server middleware. CORBA allows a client application to call a remote object as though it is a local object. CORBA allows object interfaces to be defined either at compile time, using IDL, or at run time using CORBA services for finding the objects and performing dynamic invocation. The CORBA naming service provides a framework for finding object references. CORBA, RMI and DCOM provide similar features for implementing remote object servers but in different implementation environments. The choice client/server technique used for an application depends upon many design parameters. EE906-DOT- 75 Main References Sun, The Java Tutorial: Custom Networking ( R. Orfali and D. Harkey. Client/server programming with Java and CORBA. Wiley, 2nd edition, End of Part 4 EE906-DOT- 76