Chapter 6 lập trình mạng corbra

• CORBA là một sản phẩm của OMG (Nhóm Quản lý Đối tượng), một tập đoàn của hơn 800 công ty trải dài hầu hết các ngành công nghiệp CNTT • Để phù hợp với các đặc tính của OMG, CORBA không phải là một triển khai, nhưng một đặc điểm kỹ thuật để tạo và sử dụng các đối tượng • Việc triển khai riêng lẻ đặc điểm kỹ thuật này tạo thành ORB (Nhà môi giới yêu cầu đối tượng)

Trang 1

Chapter 6

CORBA

Contents

•Background and basics

•The structure of a Java IDL specification

•The Java IDL process

•Using factory objects

•Objects persistence

•RMI-IIOP

6.1 Background and basics

•CORBA is a product of the OMG (Object Management Group), a

consortium of over 800 companies spanning most of the I.T industry

•In keeping with the ethos of the OMG, CORBA is not a specific

implementation, but a specification for creating and using distributed

objects

•An individual implementation of this specification constitutes an ORB

(Object Request Broker)

•Java IDL (Interface Definition Language) is the ORB that constitutes

one of the core packages of the Java SE and is the ORB that will be

Trang 2

6.1 Background and basics (RMI vs CORBA)

•Whereas RMI ORBs use a protocol called JRMP (Java Remote Method

Protocol), CORBA ORBs (e.g java IDL) use IIOP (Internet Inter-Orb

Protocol), which is based on TCP/IP It is IIOP that provides

interoperability between ORBs from different vendors

•Another fundamental difference between RMI and CORBA is that,

whereas RMI uses Java to define the interfaces for its objects, CORBA

uses a special language called Interface Definition Language (IDL) to

define those interfaces

6.1 Background and basics

•In order for any ORB to provide access to software objects in a

particular programming language, the ORB has to provide a mapping

from the IDL to the target language

•Mappings currently specified include ones for Java, C++, C, Smalltalk,

COBOL and Ada

•At the client end of a CORBA interaction, there is a code stub for each

method that is to be called remotely This stub acts as a proxy (a

‘stand-in’) for the remote method

•At the server end, there is skeleton code that also acts as a proxy for

the required method and is used to translate the incoming method

call and any parameters into their implementation-specific format,

which is then used to invoke the method implementation on the

associated object

Trang 3

6.1 Background and basics (how it works)

•Method invocation passes through the stub on the client side, then

through the ORB and finally through the skeleton on the server side,

where it is executed on the object

•For a client and server using the same ORB, Figure below shows the

process

•Remote invocation when

client and server are using

different ORBs

6.2 The structure of a Java IDL specification

•Java IDL includes an OMG-compliant version of the IDL and the

corresponding mapping from this IDL into Java

•IDL supports a class hierarchy, at the root of which is class Object

This is not the same as the Java language’s Object class and is

identified as org.omg.CORBA.Object (a subclass of java.lang.Object )

in Java

•Some CORBA operations (such as name lookup) return an object of

class org.omg.CORBA.Object , which must then be ‘narrowed’

explicitly (effectively, typecast into a more specific class)

•This is achieved by using a ‘helper’ class that is generated by the idlj

Trang 4

•An IDL specification is contained within a file with the suffix idl

•The surrounding structure within this file is normally a module

(though it may be an interface ), which corresponds to a package in

Java (and will cause a Java package statement to be generated when

the IDL is compiled)

•The module declaration commences with the keyword module ,

followed by the name of the specific module (beginning with a

capital letter, even though the Java convention is for a package name

to begin with a lower-case letter)

•The body of the module declaration is enclosed by curly brackets

and, like C++ (but unlike Java), is terminated with a semi-colon

•For a module called Sales , then, the top level structure would look

Note the mandatory semi-colon following the closing bracket!

•Within the body of the module, there will be one or more interface

declarations, each corresponding to an application class on the server

and each commencing with the keyword interface , followed by the

name of the interface (When the IDL is compiled, each statement will

generate a Java interface statement.)

•The body of each interface declaration is enclosed by curly brackets

and specifies the data properties and the signatures of the

operations (in CORBA terminology) that are to be made accessible to

clients

Trang 5

•Each data property is declared with the following syntax:

attribute <type> <name>;

•For example: attribute long total;

•By default, this attribute will be a ‘read-and-write’ attribute and will

automatically be mapped to a pair of Java accessor and mutator

methods (‘get’ and ‘set’) methods when the IDL file is compiled

•For some strange reason, these methods do not contain the words

‘get’ and ‘set’ or any equivalent verbs, but have the same names as

their (noun) attributes.

•The accessor and mutator methods for a given attribute have exactly the

same name, then, but are distinguished from each other by having

different signatures

•The ‘get’ method takes no arguments and simply returns the value of the

attribute, while the ‘set’ method takes an argument of the corresponding

Java type and has a return type of void (though only the different argument

lists are signifi cant for the compiler, of course)

•For the example above, the accessor and mutator methods have the

following signatures:

int total(); //Accessor

void total(int i); //Mutator

•If we wish to make an attribute read-only (i.e., non-modifiable), then

we can do this by using the modifier readonly For example:

readonly attribute long total;

•This time, only the accessor method will be created when the file is

compiled

Trang 6

•The full set of basic types that may be used in attribute declarations is

shown in Table below, , with the corresponding Java types alongside

•Within each operation signature, the basic types available for the

return type are as above (slide trước), but with the addition of void

•Types short, long and long long may also be preceded by

the qualifier unsigned , but this will not affect the targets of their

mappings

•The qualifier const may also be used (though this generates an

initialized variable in Java, rather than a constant indicated by the Java

qualifier final)

•Parameters may have any of the basic types that data properties

have, of course

•In addition to this, each parameter declaration commences with in

(for an input parameter), out (for an output parameter) or inout

(for an update parameter)

Trang 7

module Sales {

interface StockItem{

readonly attribute string code;

attribute long currentLevel;

long addStock(in long incNumber);

long removeStock(in long decNumber);

•If only one interface is required, then some programmers may choose

to omit the module level in the idl file.

•In addition to the basic types, there are six structured types that may

be specified in IDL: enum , struct , union , exception , sequence and

array

•The first four of these are mapped to classes in Java, while the last

two are mapped to arrays

•The difference between a sequence and an array in IDL is that a sequence

does not have a fixed size

•Since enum , struct and union are used only infrequently, they will not

be given further coverage here

Trang 8

•IDL exceptions are of two types: system exceptions and user-defined

exceptions

•The former inherit (indirectly) from java.lang.RuntimeException and

are unchecked exceptions (i.e., can be ignored, if we wish)

•The latter inherit (indirectly) from java.lang.Exception via

org.omg.CORBA.UserException and are checked exceptions (i.e.,

must be either caught and handled or be thrown for the runtime

environment to handle).

•To specify that a method may cause an exception to be generated, the

keyword raises is used For example:

void myMethod(in dummy) raises (MyException);

•(Note that brackets are required around the exception type.)

•Obviously, raises maps to throws in Java.

•One final IDL keyword worth mentioning is typedef This allows us to create

new types from existing ones For example:

typedef sequence<long> IntSeq;

This creates a new type called IntSeq, which is equivalent to a sequence/array of

integers

•This new type can then be used in data property declarations For example:

attribute IntSeq numSeq;

•Note: If a structured type (array, sequence, etc.) is required as a data attribute or

parameter, then we cannot declare it directly as a structured type, but must use

typedef to create the new type and then use that new type Thus, a

declaration such as

attribute sequence<long> numSeq;

would be rejected

Trang 9

6.3 The Java IDL process

•At the heart of Java IDL is a compiler that translates the programmer’s IDL

into Java constructs, according to the IDL-to-Java mapping

•As of J2SE 1.3, the compiler is called idlj and is part of the core Java

download

•The stub and skeleton files (and a number of other fi les) are generated by

the idlj compiler for each object type that is specified in the idl file

•Once these files have been generated, the Java implementation files may

be written, compiled and linked with the idlj -generated files and the ORB

library to create an object server, after which client program(s) may be

written to access the service provided

•Steps required to set up a CORBA client/server application:

1 Use the idlj compiler to compile the above file, generating up to six

files for each interface defined

2 Implement each interface as a ‘servant’

3 Create the server (incorporating servants)

4 Compile the server and the idlj -generated files.

5 Create a client

6 Compile the client

7 Run the application

•This first example application simply displays a greeting to any client

that uses the appropriate interface registered with the Java IDL ORB

to invoke the associated method implementation on the server

Trang 10

0 Create the IDL file.

•The file will be called Hello.idl and will hold a module called

Simple-CORBAExample

•This module will contain a single interface called Hello that holds the

signature for operation getGreeting

1 Compile the IDL file.

•The idlj compiler defaults to generating only the client-side bindings

•To vary this default behaviour, the –f option may be used This is

followed by one of three possible specifiers: client , server and all

•If client and server are to be run on the same machine, then all is

appropriate and the following command lineshould be entered:

idlj –fall Hello.idl

•This causes a sub-directory with the same name as the module (i.e.,

Simple-CORBAExample ) to be created, holding the six files listed

below

•Hello.java

Contains the Java version of our IDL interface It extends interface HelloOperations

[See below], as well as org omg.CORBA.Object (providing standard CORBA object

functionality) and org.omg.CORBA.portable.IDLEntity

•HelloHelper.java

Provides auxiliary functionality, notably the narrow method required to cast CORBA

object references into Hello references.

• HelloHolder.java

Holds a public instance member of type Hello If there were any out or inout

arguments (which CORBA allows, but which do not map easily onto Java), this file

would also provide operations for them.

Trang 11

•HelloOperations.java

Contains the Java method signatures for all operations in our IDL file In this

application, it contains the single method getGreeting.

•_HelloImplBase.java

An abstract class comprising the server skeleton It provides basic CORBA functionality

for the server and implements the Hello interface Each servant (interface

implementation) that we create for this service must extend HelloImplBase

•_HelloStub.java

This is the client stub, providing CORBA functionality for the client Like

HelloImplBase.java , it implements the Hello interface.

2 Implement the interface.

•Here, we specify the Java implementation of our IDL interface

•The implementation of an interface is called a ‘servant’, so we shall name

our implementation class HelloServant

•This class must extend HelloImplBase Here is the code:

class HelloServant extends _HelloImplBase {

public String getGreeting(){

return ("Hello there!");

}

•This class will be placed inside the same file as our server code

3 Create the server.

•Our server program will be called HelloServer.java and will subsume

the servant created in the last step

•It will reside in the directory immediately above directory

SimpleCORBAExample and will import package SimpleCORBAExample

and the following three standard CORBA packages:

•org.omg.CosNaming (for the naming service);

•org.omg.CosNaming.NamingContextPackage (for special exceptions thrown

by the naming service);

Trang 12

3 Create the server

(i) Create and initialise the ORB

•This is effected by calling static method init of class ORB (from

package org.omg.CORBA )

•This method takes two arguments: a String array and a Properties

object

•The first of these is usually set to the argument list received by main ,

while the second is almost invariably set to null :

ORB orb = ORB.init(args,null);

(ii) Create a servant

•Easy enough:

HelloServant servant = new HelloServant();

(iii) Register the servant with the ORB

•This allows the ORB to pass invocations to the servant and is achieved

by means of the ORB class’s connect method:

orb.connect(servant);

Trang 13

(iv) Get a reference to the root naming context

•Method resolve_initial_references of class ORB is called

with the String argument “NameService” (defined for all CORBA

ORBs) and returns a CORBA Object reference that points to the naming

context:

org.omg.CORBA.Object objectRef =

orb.resolve_initial_references("NameService");

(v) ‘Narrow’ the context reference

•In order for the generic Object reference from the previous step to be

usable, it must be ‘narrowed’ (i.e., typecast ‘down’ into its

appropriate type)

•This is achieved by the use of method narrow of class

NamingContextHelper (from package org.omg.CosNaming ):

NamingContext namingContext =

NamingContextHelper.narrow(objectRef);

(vi) Create a NameComponent object for our interface

•The NameComponent constructor takes two String arguments, the

first of which supplies a name for our service The second argument

can be used to specify a category (usually referred to as a ‘kind’) for

the first argument, but is typically left as an empty string

•In our example, the service will be called ‘Hello’:

NameComponent nameComp = new

Trang 14

(vii) Specify the path to the interface

•This is effected by creating an array of NameComponent objects, each

of which is a component of the path (in ‘descending’ order), with the

last component specifying the name of the NameComponent

reference that points to the service

•For a service in the same directory, the array will contain a single

element, as shown below

NameComponent[] path = {nameComp};

(viii) Bind the servant to the interface path.

•The rebind method of the NamingContext object created earlier is

called with arguments that specify the path and service respectively:

namingContext.rebind(path,servant);

(ix) Wait for client calls.

•Unlike our previous server programs, this is not achieved via an explicitly

‘infinite’ loop A call is made to method wait of (Java class) Object This call

is isolated within a code block that is declared synchronized , as shown

Định dạng
Số trang	29
Dung lượng	334,55 KB