Unit III R

8/8/2019 Unit III R

1/54

Component Based Technology Unit - III

UNIT - III

CORBA COMPONENT TECHNOLOGIES

Java and CORBA Interface Definition language Object Request Broker system object

model portable object adapter CORBA services CORBA component model containers

application server model driven architecture

3.1.JAVA and CORBA:

Java :

Pure object oriented language.

Non distributed.

Contribution to Distributed Computing

o Platform independent.

o Applets

o RMI-support of DC.

Editions

o J2SE - standard edition consisting of CORBA standard, IDL based communication.

o J2ME - Micro edition for Consumer devices (pager/smart cards)

o J2EE - Enterprise edition for EJB, Servlets.

Java RMI :

A network of heterogeneous machines is seen as a homogeneous network of Java virtual

machines.

Transparency of access to remote objects: remote method invocation looks like local

method invocation, modulo exception handling.

CORBA :

What Is CORBA?

The Common Object Request Broker Architecture (CORBA) is a unifying standard for

writing distributed object systems. The standard is completely neutral with respect to platform,language, and vendor. CORBA incorporates a host of technologies and is very broad in scope.

The Object Management Group (OMG), a consortium of companies that began in 1989,

invented CORBA.

The OMG has defined a protocol called Internet Inter-ORB Protocol (IIOP, pronounced

eye-op). IIOP is the standard Internet protocol for CORBA.

Why Should I Care about CORBA?

There are several reasons:

You can use CORBA for legacy integration.

Panimalar Engineering College , Chennai.

Sri - 1

8/8/2019 Unit III R

2/54


CORBA is a language-neutral standard and allows code written in several

languages to communicate. Thus, CORBA is an ideal platform for code written in different

languages to cooperate.

CORBA allows for advanced middleware development.

CORBA has a large installed basis of mission-critical systems.

Especially in the banking and telecommunications industries, you are likely to find

large installations of CORBA applications, some in highly critical, real-time operation scenarios.

CORBA and EJB have hooks connecting them.

Some EJB products will allow your enterprise beans to be called from two different

kinds of clients: clients written to use the J2EE suite of APIs and clients written to use CORBA

APIs. This means that code written in C11 or Smalltalk can call your enterprise beans.

CORBA:

It is a specification for DOM (Distributed Object Management).

Specification supported by more than 700 s/w, h/w manufacturers, Govt organizations,

user groups. (Object Management Group- OMG)

Defines a standard framework from which s/w developer can easily and quickly integrate

n/w resident s/w modules and applications to create a new, more powerful applications.

Problems solved by CORBA

o Client - Server Application difficulty.

o Rapid integrating legacy systems.

OMG ( Object Management Group) 1989.

Architecture formed by OMG is OMA highest level specification which addresses 4

architectural elements .

The role of the ORB is to route requests among the other architectural components.

CORBA services , CORBA facilities , CORBA domains are also defined as part of the

specifications.CORBA Concepts:

It is based on 3 important concepts

Object Oriented Model

Open Distributed Computing Environment

Component Integration and Reuse

1. Object Oriented Model:

CORBA is solidly grounded in fundamental object oriented concepts like Objects, classes,

encapsulation ,inheritance and Polymorphism.


Sri - 2

8/8/2019 Unit III R

3/54


CORBA object model is based on a complete object approach in which client sends a

message to an object. The message identifies an object , one or more parameters are included,

first parameter defines the operation to be performed.

CORBA Object Model Consists of

Object encapsulated entity provides services to a client

Request action created by a client directed to a target object

Object creation and destruction based on the state of requests, objects are

created/deleted

Types identifiable entity defined over values

Interfaces specification of operations requested by client

Operations an identifiable entity that defines what a client can request from an object

2. Open Distributed Computing Environment:

CORBA is based on a client-server model of Distributed Computing.

Client gives Request for service to another component on a n/w.

CORBA adds an additional dimension broker, between the client and server component.

Broker play 2 roles.

o Common Services like messaging and communication between client & server,

Directory service, Security Service and Location transparency.

o Insulates the application from system configuration such as h/w platform, operating

system, n/w protocol and implementation language.

Based on peer-to-peer communication model.

Supports Synchronous & limited version of Asynchronous communication.

Synchronous comm.- client will wait for the result from server

Asynchronous comm.- client sends the request to the server ,and

will not wait for the result

CORBA Architectural elements :


Sri - 3

8/8/2019 Unit III R

4/54


The four categories of the OMA(Object Management Architecture):

i. CORBA services Provides some basic system level services like Naming,

Persistence, and Event Notification.

ii. CORBA facilities Set of high level functions applicable in areas like user

Interface & Information Management.

iii. CORBA domains Specific to particular application domains

like finance, telecommunication and manufacturing.

Application objects Provides the new business capabilities that are

created by the system implementers. The key to integrating app

objects is the spec. of std interfaces using the Interface Definition

Language . Once interface is in IDL, communication is independent

of

1) Physical location

2) Platform type

3) N/w protocol

4) Programming language

CORBA Object Implementation Model :

Protocol GIOP (General Inter ORB Protocol)

Mapping of GIOP to TCP/IP => IIOP

IOR (Interoperable Object Reference)

Mechanism through which objects are accessed through the IIOP & between ORB


Sri - 4

Application

objects

CORBA

domains

CORBA

facilities

Object Request Broker

CORBAservices

8/8/2019 Unit III R

5/54


vendors. It includes ORBs internal object reference, Internet host address and port

number.

ORB Interface :

Request can be static or dynamic

Static invocations are defined at compile time & are made through an IDL

stub to skeleton

Dynamic invocations provide the ability to add new objects and interfaces

without requiring changes to the client code. DII and DSI are used

Object Adapter Component which activates/deactivates the servant object

3. Component Integration & Reuse:

Integration is the combination of 2 or more existing components. Without integration

tools and techniques , reuse is difficult and will probably leads to redundancy.

Case(i) custom interface must be defined for each interaction b/w components.

Case(ii) each interface is defined only once & subsequent interactions are handled by

the broker.

- allows rapid integration & reuse of components.

- Example for the above service

(i) CORBA interface repository allows clients to discover interface info.

(ii) CORBA implementation repository allows ORBs to locate & activate

implementations of objects.

Drawbacks of CORBA :

CORBA is slow-moving.

All standards committees are bureaucratic and slow to make decisions.

CORBA has a steep learning curve.

Products developed under CORBA may have incompatible features.

Its great that CORBA is a unifying standard.

JAVA & CORBA:

To enable the use of IIOP for communication with non-java sub systems.

RMI limits java-to java communication.

RMI over IIOP released in the year of 1999

enables the sending of objects by value, rather than sending a object reference.

follows CORBAs lifecycle mgmt approach rather than RMI distributed garbage

collection.


Sri - 5

8/8/2019 Unit III R

6/54


javas instanceof operator cant be used for discovering the interfaces, rather

service methods must be called.

Java RMI :

S.No. PROS CONS

1 Portable across many platform Tied only to platforms with java support

2 Can Introduce new code to foreign

JVMs

Security threats with remote code execution,

and limitations are enforced by security

restriction

3 Java developers may already have

experience with RMI

Learning curve for developers that have no

RMI experience is comparable with CORBA.

4 Existing system may already use RMI

the cost and time to convert to a new

technology may prohibitive.

Can Only operate with java systems . No

support legasy systems written in C+

+,Ada,Fortran,Cobol.

CORBA :

S.No. PROS CONS

1 Services can be written and executed with

different language with different platform through

IDL.

Describing services require the use

of an IDL which must be learned.

2 With IDL , the interface is clearly separated from

implementation

Some tools may not integrate new

changes with existing code.3 CORBA support primitive data types and wide

range of data structures.

CORBA does not support the

transfer of objects or code.

4 CORBA is an easy way to link objects and

systems together.

CORBA specifications is still in a

state of flux.

5 CORBA system may offer greater performance Speed may be traded off against ease

of use for pure java systems.

Understanding of how CORBA Work :

Object Request Brokers : (ORB)

An Object Request Broker(ORB) facilitates network communication. ORBs enable

disparate applications to communicate without being aware of the underlying communications

mechanism. They are responsible for finding objects to service method calls, handling parameter

passing, and returning results.

Numerous commercial and Open Source CORBA ORBs for different platforms and

programming languages are available on the market. Some examples are Iona Orbix, Borland

VisiBroker, and the Open Source ORBs TAO and JacORB.


Sri - 6

8/8/2019 Unit III R

7/54


The ORB , which is the heart of CORBA , is responsible for all the mechanisms required

to perform the following ORB functions :

intercepts calls

finds object

invokes method

passes parameters

returns results or error messages

Figure The ORB facilitates your networking needs

Figure shows Parts of ORB


Sri - 7

8/8/2019 Unit III R

8/54


Using the DII, a client can invoke an operation on a new type of object that it's just

discovered and there is only one DII, serving every instance ofevery object type.

Dynamic invocation interface :

Invoking operations can be done through either static or dynamic interfaces. Static

invocation interfaces are determined at compile time, and they are presented to the client using

stubs. The DII , on the other hand, allows client applications to use server objects without

knowing the type of those objects at compile time.

DII uses the interface repository to validate and retrieve the signature of the operation on

which a request is made. CORBA supports both the dynamic and the static invocation interfaces.

Dynamic skeleton interface :

It allows servers to be written without having skeletons, or compile-time knowledge, for

the objects being implemented.

Its main purpose is to support the implementation of gateways between ORBs which

utilize different communication protocols.

IDL generates stubs and skeleton programs for each interface .

Stub acts like a local function call, providing interface to ORB ,

Skeleton is server side implementation of IDL interface.

For example program in DII and DSI in CORBA :

DII and DSI in CORBA

(Increment operation)

//Example.idl

module Example

{

interface Counter

{

long increment (in long arg);

};

};

//CounterServer.java

import Example.*;

import java.util.*;

import org.omg.CosNaming.*;

import org.omg.CosNaming.NamingContextPackage.*;

import java.io.*;import org.omg.CORBA.*;


Sri - 8

8/8/2019 Unit III R

9/54


// servant must extend DynamicImplementation

class HelloServant extends DynamicImplementation

{

// store the repository ID for the implemented interface

static String[] myIDs = {"IDL:Example/Counter:1.0"};

ORB orb;

// create a reference to the ORB

HelloServant(ORB orb) { this.orb = orb; }

// must implement invoke() for handling requests

public void invoke(ServerRequest request)

{

try {

I nt res=0,s=0;

System.out.println("DSI: invoke called, op = "+request.op_name());

// create an NVList to hold the parameters

NVList nvlist = orb.create_list(0);

// need an if statement like this for each method name

if (request.op_name().equals("increment") == true)

{

// need an Any for each argument

Any any1 = orb.create_any();

any1.insert_long(1);

nvlist.add_value("arg1", any1, ARG_IN.value);

// pass the NVList to the request to get values

request.params(nvlist);

s=nvlist.item(0).value().extract_long();

System.err.println("Argument 1: " + s);

s=s+1;

TypeCode result_tc = orb.get_primitive_tc(TCKind.tk_short);

Any result1 = orb.create_any();

result1.type(result_tc);

result1.insert_long(s);

NamedValue resultVal = orb.create_named_value ("result1", result1,

org.omg.CORBA.ARG_OUT.value);System.err.println("Result is " +s);


Sri - 9

8/8/2019 Unit III R

10/54


// Set result and return

request.set_result(result1);

}

}

catch (Exception ex)

{

ex.printStackTrace();

System.out.println("DSIExample: Exception thrown: " + ex);

}

}

// implement an _ids method to return repository ID of interface

public String[] _ids() { return myIDs; }

}

// HelloServer implemented in the usual fashion

public class CounterServer

{

public static void main(String args[])

{

try{

// create and initialize the ORB

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

// create servant and register it with the ORB

HelloServant helloRef = new HelloServant(orb);

orb.connect(helloRef);

// Get the root naming context

org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");

NamingContext ncRef = NamingContextHelper.narrow(objRef);

// Bind the object reference in naming

NameComponent nc = new NameComponent("Counter", "");

NameComponent path[] = {nc};

ncRef.rebind(path, helloRef);

System.out.println("The Counter Server is up and ready...");

// Wait forever for current thread to die

Thread.currentThread().join();


Sri - 10

8/8/2019 Unit III R

11/54


}

catch (Exception e)

{

System.err.println("ERROR: " + e);

e.printStackTrace(System.out);

}

}

}

//CounterClient.java


import org.omg.CORBA.*;

import java.lang.*;

import Example.*;

public class CounterClient

{


{

try

{



// get the root naming context

org.omg.CORBA.Object Ref =orb.resolve_initial_references("NameService");

NamingContext ncRef = NamingContextHelper.narrow(Ref);

// resolve the Object Reference in Naming

NameComponent nc = new NameComponent("Counter", "");


//Counter counterRef = CounterHelper.narrow(ncRef.resolve(path));

org.omg.CORBA.Object objRef=ncRef.resolve(path);

NVList argList = orb.create_list (1);

Any argument = orb.create_any ();

argument.insert_long(Integer.parseInt(args[0]));

NamedValue nvArg = argList.add_value ("arg", argument, org.omg.CORBA.ARG_IN.value);

//hold the request


Sri - 11

8/8/2019 Unit III R

12/54


Any result = orb.create_any ();

result.insert_long(1);

NamedValue resultVal = orb.create_named_value ("result", result,

org.omg.CORBA.ARG_OUT.value);

//create request

Request thisReq = objRef._create_request (null, "increment", argList, resultVal);

thisReq.invoke ();

result = thisReq.result().value ();

System.out.println ("increment () returned: " + result.extract_long ());

}

catch (Exception e)

{

System.out.println("CounterClient : Exception: " + e) ;


}

}

}

Sample Input and Output:

Z:\>set path=C:\Program Files\Java\jdk1.5.0\bin

Z:\>idlj fall Example.idl

Z:\>javac Example\*.java

Z:\>javac CounterServer.java

Note: CounterServer.java uses or overrides a deprecated API.

Note: Recompile with -deprecation for details.

Z:\>javac CounterClient.java

Z:\>start orbd CounterServer -ORBInitialPort 1060

--

Z:\>start java CounterServer -ORBInitialPort 1060

Z:\>java CounterClient 10 -ORBInitialPort 1060

increment () returned: 11

3.2. INTERFACE DEFINITION LANGUAGE [ IDL ]:

The cornerstone of CORBA is the OMG interface definition language(OMG IDL). OMG

IDL is a language that CORBA uses to define the interfaces between clients and the objects they

call.


Sri - 12

8/8/2019 Unit III R

13/54


It is a specification that enables interoperability by separating interface from

implementation.

It is not a programming language has no constructs.

When you write a CORBA object implementation, that object implementation must have a

corresponding IDL that defines the interface for that object implementation.

By programming with OMG IDL,you force a clear distinction between interface and

implementation; you can vary your implementation without changing the interface your clients

use.

The IDL concept is shown in Figure.

Another great benefit to OMG IDL is that it is a language-neutralinterface for object

implementations. You can write your IDL once and then define your object implementations in

any language that CORBA supports, such as C++ or Smalltalk. And because IDL is language-

neutral, client code that calls your object implementations can be written in any language that

CORBA supports as well. Thus, IDL enables you to have a deployment mixing heterogeneous

languages.

IDL is also inherently platform-neutral, allowing clients and object implementations to

be deployed in different platforms. For example, your clients can exist on a Windows box and talk

to business objects deployed on a Sun Solaris box.

IDL allows you to write a distributed application with the illusion that its all written in

one language.

IDL Defines protocol to access objects , Like a contract , Well-specified and Language-independent


Sri - 13

8/8/2019 Unit III R

14/54


IDL has following features,

part of the CORBA standard.

Universal notation for s/w interfaces.

Defines an opaque boundary b/w client code and object implementation

It is language independent, supports multiple lang. bindings. From a single IDL

specification, std bindings include C,C++, smalltalk & others.

Enable platform independent.

It is pure specification, not implementation

Syntax :

module identifier

{type,constant & exception declarations

interface identifier : base

{

attribute declarations

type identifier(parameters) raises exception;

type identifier(parameters) raises exception;

}

}

For example ,

Here is asample snippetof IDL:

module examples

{

interface HelloWorld

{

string sayHello(in string myName);

}

}

Parameter passing in IDL :

Parameters to a method can be declared of three different types:

in - Used for input only(i.e.parameters are copied from client to server )

out - parameters are copied from server to client .(i.e. Allow the modification )


Sri - 14

8/8/2019 Unit III R

15/54


. inout - May be used for input and may also be modified.( i.e.,parameters are used both

for incoming and outgoing information and are copied both ways. )

IDL For Bank Account,

module Bank

{

interface bank_account

{

exception overdrawn_exception {};

void deposit(in float amount);

void withdraw(in float amount) raises (overdrawn_exception);

float balance();

}

};

For example 2,

module MyAnimals

{

interface Dog:Pet,Animal

{

attribute integer age;

exception NotInterested(string explanation);

void Bark(in short how_long) raises(NotInterested);

void Sit(in string where)raises(NotInterested);

}

interface Cat:Animal

{

void Eat();

}

}

There are many different types in IDL, including basic types (such as shortandfloat) and

constructed types (such asstruct and enumeration ).

IDL modules:

- Separate namespace for IDL definitions.This prevents potential name conflicts among

identifiers used in different domains.- Donot inherit from other modules.


Sri - 15

8/8/2019 Unit III R

16/54


- Modules can be nested.

IDL Interfaces:

- specifies s/w boundary between a service implementation and its clients.

- Defines the details of distributed objects, contains operation signature.

-

IDL Forward:

used to declare as an interface name before its complete definition appears in the IDL file

used to define recursive definition

IDL Constants:

IDL allows the definition of constant values.

char, Boolean, Float, String

The constant definitions can include some arithmetic expressions.

Ex:

Const Char separator=/;

Const Boolean ON=TRUE;

Const Float pi=3.14;

Const Float days_month=364.5/12;

IDL Type Declaration:

Renaming of intrinsic types & creation of user defined types that can be either

enumeration, strucuter, arrays, sequences or unions.

to enable strong type checking of operator signature

Ex:

typedef unsigned long PhoneNumber;

typedef String GuestName,Address;

enum ChargeCard{MasterCard, Visa, Americanexpress};

IDL Sequences:

unique in IDL,used to create variable length arrays

Mapping to C++, encapsulated behind a C++ class definition

Mapping to C, converted as structure with maximum,(Size)

-length,-buffer Member

IDL Attributes:

- IDL definitions includes public attributes and operations.

- Data members are declared using the attribute keyword. The declaration must include a

name and a type. Attributes are readable and writable by default.


Sri - 16

8/8/2019 Unit III R

17/54


- By default, all IDL definition known by the ORB are public.

- Attributes may be read only or read-write.

Interface CensusData

{

attribute unsigned short age;

readonly attribute String birth_date;

};

attribute declarations map to accessor functions.

For read-write attribute get_set functions

read only attribute get functions

For example,

module Example

{

interface ufo

{

readonly attribute String Name;

readonly attribute String FirstContact;

}

};

OMG IDL Maps to Concrete Languages :

IDL is only a descriptive language in that it describes the interfaces to your objects. You

cannot execute IDL.

The OMG IDL maps to specific languages, such as Java or C++.

With the IDL-to-Java mapping, the Stringtype in OMG IDL maps to thejava.lang.String

object in Java.

It is important to realize that, although IDL is a language, it is more of an abstraction

because you never write client code or object implementations that use IDL files. Rather, you use

IDL to define the interfaces to your objects and then map that IDL into your particular language

using an IDL compiler.

IDL Language Elements :

These elements include dynamic data types, array operations, positional parameters

(arguments), keywords, and automatic compilation.

Variables and Data Types :


Sri - 17

8/8/2019 Unit III R

18/54


IDL is different from other languages that require programmers to specifically designate a

particular data type for each variable. IDL interprets variable types by their usage. This loose or

dynamic data typing gives IDL flexibility and the ability to redefine variable data types at the

command line or within programs.

Notice that since the variable value is within single quotes, IDL interprets it as a string.

IDL does not hold the previous value of the variable in memory, so it can be changed at any time.

The three valid IDL variable organizations are scalars, arrays, and structures:

Scalarscontain single values

Arrayscontain multiple values arranged in an n-dimensional grid.

Structuresare collections of scalars, arrays, or other structures.

Java Data types Mapping to IDL Datatypes :

Java Data Types IDL Data types

Void - void

Boolean - boolean

Char - wchar

Byte - octet

Short - short

Int - long

Long - long long

Float - float

Double - double

java.lang.String -string / wstring

IDL Variable Types :

Undefined - Structure

Unsigned byte - Double precision complex

16-bit integer - Pointer heap variable

32-bit integer - Object reference heap variable

Single precision - floating Unsigned 16-bit integer

Double precision - floating Unsigned 32-bit integer

Single precision - complex 64-bit integer

String - Unsigned 64-bit integer

For example ,

1. Define the remote interface ( i.e. Hello.idl)

2. Compile the remote interface.(i.e. Using idlj compiler)3. Implement the server.(i.e. HelloServer.java)


Sri - 18

8/8/2019 Unit III R

19/54


4. Implement the client.(i.e.HelloClient.java)

5. Start the applications.

Interface Definition (Hello.idl) :

module HelloApp

{

interface HelloCallback

{

void callback(in string message);

};

interface Hello

{

string sayHello(in HelloCallback objRef, in string message);

};

};

Implementing the Server (HelloServer.java) :

import HelloApp.*;


import org.omg.CosNaming.NamingContextPackage.*;


class HelloServant extends _HelloImplBase

{

public String sayHello(HelloCallback callobj, String msg)

{

callobj.callback(msg);

return "\nHello world !!\n";

}

}

public class HelloServer

{


{

try{

// create and initialize the ORBORB orb = ORB.init(args, null);


Sri - 19

8/8/2019 Unit III R

20/54


// create servant and register it with the ORB

HelloServant helloRef = new HelloServant();

orb.connect(helloRef);




// bind the Object Reference in Naming

NameComponent nc = new NameComponent("Hello", "");


ncRef.rebind(path, helloRef);

// wait for invocations from clients

java.lang.Object sync = new java.lang.Object();

synchronized (sync)

{

sync.wait();

}

} catch (Exception e) {

System.err.println("ERROR: " + e);


}

}

}

Implementing the Client (HelloClient.java) :

import HelloApp.*;



class HelloCallbackServant extends _HelloCallbackImplBase

{

public void callback(String notification)

{

System.out.println(notification);

}

}

public class HelloClient{


Sri - 20

8/8/2019 Unit III R

21/54



{

try{






// resolve the Object Reference in Naming

NameComponent nc = new NameComponent("Hello", "");


Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));

HelloCallbackServant helloCallbackRef = new HelloCallbackServant();

orb.connect(helloCallbackRef);

// call the Hello server object and print results

String hello = helloRef.sayHello(helloCallbackRef,"\ntest..\n");

System.out.println(hello);

} catch (Exception e) {

System.out.println("ERROR : " + e) ;


}

}

}

Building and Running Hello World :

The following instructions assume you can use port 1050 for the Java IDL name server.

Substitute a different port if necessary. Note that for ports below 1024, you need root access on

UNIX machines, and administrator privileges on Windows95 and NT.

* Create the source code files as shown above.

* Run idlj on the IDL file to create stubs and skeletons:

idlj -fall Hello.idl

* Compile the .java files, including the stubs and skeletons:

javac *.java HelloApp/*.java

* Make sure the name server is running:

tnameserv -ORBInitialPort 1050&* Start the Hello server:


Sri - 21

8/8/2019 Unit III R

22/54


java HelloServer -ORBInitialPort 1050

* Run the Hello application client from a different shell than the server:

java HelloClient -ORBInitialPort 1050

CORBA Static Invocations :

The conventional way to perform distributed computing in CORBA is to have the client

invoke locally on a pregenerated stub . The stub is a proxy for the real object implementation,

which exists elsewhere on the network. The stub is responsible for going through the client-side

ORB runtime, which channels the request over the network via IIOP.

The receiving server-side ORB runtime receives the IIOP request, then calls a skeleton to

handle the request. The server-side skeleton is a pregenerated file, just like the stub. The skeleton

is responsible for delegating the invocation to the actual server-side CORBA object

implementation (also called a servant )that will service the request. The skeleton is also

responsible for coordinating with an object adapter .

This object adapter performs many tasks, such as mapping object references to servants,

activating servants in case they dont exist already, housekeeping of threads, and more. Modern

ORB implementations have object adapters coded to the CORBAPortable Object Adapter (POA)

specification.

The Figure shows CORBA invocation( Calling Method ) process .


Sri - 22

8/8/2019 Unit III R

23/54


The figure show simple helloworld application Model

3.3.OBJECT REQUEST BROKER ( ORB ):

An Object Request Broker (ORB) facilitates network communication. ORBs enable

disparate applications to communicate without being aware of the underlying communications

mechanism. They are responsible for finding objects to service method calls, handling parameter

passing, and returning results.

The (ORB) is the middleware that establishes the client-server relationships between

objects. Using an ORB, client can transparently invoke a method on a server object, which can be

on the same machine or across a network.

The ORB is an abstract entity that acts as the middleman in all remote method invocations.

The ORB finds a server that can handle a method invocation, passes the request to the

server, receives the response and forwards it to the client.

The functions handled by an ORB are actually implemented in both client and server.


Sri - 23

8/8/2019 Unit III R

24/54


Fig. shows CORBA Reference Model architecture

An ORB must provide:

Access to common services

Standard communication using common protocol (GIOP)

Location transparency in server activation and deactivation

Insulation from system and platform dependencies like one interface, multiple

implementations

There are two important things to note about the CORBA architecture and its computing model:

Both the client and the object implementation are isolated from the ORB by an IDL

interface. All requests are managed by the ORB . This means that every invocation (whether

it is local or remote) of a CORBA object is passed to an ORB . In the case of a

remote invocation, however, the invocation passed from the ORB of the client to

the ORB of the object implementation.

Expected benefits of the ORB approach :

Provides universal notation for interfaces: IDL;

Simplifies distributed computing

remote and local object invocation are indistiguishable (?)


Sri - 24

8/8/2019 Unit III R

25/54


location transparency

standard services (registration, )

standard protocol over several transport layers

Promotes component-based development

components are reusable

components are designed for integration

Enables large-scale use of design patterns

Provides a path for legacy system integration through wrapping

Fig. shows CORBA communication paradigm

3.4. SYSTEM OBJECT MODEL :

IBM's System Object Model was deprecated in 1998.

SOM was originally developed independently from CORBA as part of OS

workplace shell. In fact distributed computing is supported by distributed

SOM(DSOM) libraries ,which build on SOM.

SOM implemented a superset of the CORBA 2 standard and supported meta

services that are still not on the CORBA map.

SOM defined a binary standard.

IBM's system object Model (SOM) provides a powerful toolset for building object-

oriented applications in multiple languages on multiple platforms. It is fully

compliant with the Object Management Group's (OMG) Common Request Broker

Architecture (CORBA).

The System Object Model is an object-oriented shared library system developed

by IBM. A distributed version based on CORBA, DSOM allowed objects on

different computers to communicate.

SOM (System Object Model) is a library packaging technology that enables languages to

share class libraries regardless of the language they were written in. This ability to share class


Sri - 25

8/8/2019 Unit III R

26/54


libraries between various object oriented languages solves many interoperability and re-use

problems between object oriented and non object oriented languages as well.

Two Features of SOM stand Out,

Its supports for meta programming and support or binary compatibility across

binary releases.

Meta Programming :

SOM implemented a support of the CORBA 2 standard and supported meta services that

are still not on the CORBA.

In Meta programming model largely follows the smalltalk example.

Meta class :

So every class is itself an object and as such an instance of a metaclass. All Metaclasses

are instances of a single class, Metaclass, which is its own metaclass.

SOM Goes beyond the reflective capabilities of CORBA as SOM allows classes to be

constructed or modified dynamically .

SOM guarantees binary compatibility across a large number of base class changes,

including refactoring of class hierarchies, as long as the required methods remain available and of

compatible signature .

Binary Compatibility :

Versioning and binary compatibility are supported by the notion of a release order.

As a special case , SOM guarantees that , if no interface changes took place, then building

the next clients compiled against the previous release. The Syntactic Fragile Base Class (FBC)

problems is solved by this(i.e. Recompile and redistribute within any reasonable time for each

changes in component)

Key characteristics of SOM in support of these key commercial requirements include:

the ability to create portable shrink wrapped binaries

the ability to create class libraries in one language that can be accessed and used by other

languages

the ability to subclass from binaries even if they were written in a different language

the ability to add new methods and relocate existing methods without re-compilation of the

application

the ability to insert new classes into the inheritance hierarchy without recompiling the

application.

3.4.1.Objects:


Sri - 26

8/8/2019 Unit III R

27/54


SOM objects are derived from a root object which defines the essential behavior common

to all SOM objects. Factory methods are used to create SOM objects at run time. These factory

methods are invoked on a class object, in the SOM run-time.

3.4.1.1 Operations

The interface to a SOM object is defined by permitting the specification of operation

signatures which consist of an operation name and the argument and result types. Operations are

performed on methods which implement an objects behavior.

3.4.1.2 Requests

Client requests are invoked on objects by specifying the name of an object and the name of

the operation along with parameters to invoke on it. An object can support multiple operations.

3.4.1.3 Messages

Messages are not explicitly identified in SOM.

3.4.1.4 Specification of behavioural semantics

SOM defines object behavior by permitting the specification of operation signatures which

consist of an operation name, and the argument and result types. The semantics of the operations

on an object are defined by the methods that implement these operations.

3.4.1.5 Methods

Methods are invoked on SOM objects. Methods can be relocated upward in the class

hierarchy without requiring the client to be re-compiled. SOM supports three different method

dispatching mechanisms; offset, name resolution, and dispatch function resolution.

3.4.1.6 State

The state of SOM objects is accessed through published interfaces to an object. Invoking

operations on objects may cause state changes.

3.4.1.7 Communication model

Since SOM is a basic mechanism, its run-time model is one where an operation occurs on

a single thread within a single process.

The object model provides an organized presentation of object concepts and terminology.

The object model first describes concepts that are meaningful to clients, including such

concepts as object creation and identity, requests and operations, types and signatures. It then

describes concepts related to object implementations, including such concepts as methods,

execution engines, and activation.

An objectis an identifiable, encapsulated entity that provides one or more services that can

be requested by a client.


Sri - 27

8/8/2019 Unit III R

28/54


3.5.PORTABLE OBJECT ADAPTER (POA) :

An object adapteris the mechanism that connects a request using an object reference with the

proper code to service that request. The Portable Object Adapter, or POA, is a particular type of

object adapter that is defined by the CORBA specification.

The first object adapter to be specified for CORBA was the Basic Object adapter(BOA).

The BOA has been implemented in various CORBA products. But the specification of a BOA

was not complete.

The POA is the portable mechanism used to determine which servant should be invoked

as a result of a client request.

The intents of the POA ,as its name suggests is to provide an object adapter that can be used

with multiple ORB implementation with different vendors implementations.

The POA is designed to meet the following goals:

Allow programmers to construct object implementations that are portable between

different ORB products.

Provide support for objects with persistent identities.

Provide support for transparent activation of objects.

Allow a single servant to support multiple object identities simultaneously.

One POA (called the root POA) is supplied by each ORB; additional child POAs

can be created and configure them with different behaviors

the rootPOA, by default, provides a TRANSIENT lifespan policy for objects each

POA has a name relative to the POA in which it was created

CORBA object Adapter is to mediate between an ORB & the actual implementation of an

object receiving incoming calls and returning results

POAs create servants following number of different possible policies.

It produces load balancing ,which requires an inactive object.

POAs keep pointers to skelton.

POA defines standard interfaces to do the following

o Map object reference to a servant

o Allows transparent activation of object

o Associate policy information with objects

Object adapters types

1) Basic Object Adapter

The BOA is a logical component of the ORB

Implementers perspective:


Sri - 28

8/8/2019 Unit III R

29/54


o informs the ORB of available objects and processes that are

ready to receive requests

Clients perspective:

o ensures that an invocation to an object reference reaches a

running process containing an object that can respond to it

BOA functions:

o launch processes

o dispatch requests to processes

must have access to the Implementation Repository

BOA Other Functions are ,

Generation of object references.

Authentication and access control

Persistence

2) Portable Object Adapter

Drawback in BOA-porting CORBA object implementation from one ORB to another so

replaced by POA

Need For POA :

Portability - The POA allows programmer to construct servants that are portable

between different ORB implementations.

Persistent Identities It support objects with persistent identities. The POA is designed

to support servants that can provide consistent service for objects whose lifetime span multiple

server process lifetimes.

Automation It support transparent activation of objects and implicit activation of

servants. This makes the POA easier and simpler to use

Behavior governed by policies POA provides extensible mechanism for associating

polices with the servants in a POA.POA Architecture

The ORB is an abstraction visible to both the client and server. The POA is an

ORB Component visible only to the server i.e clients are not directly aware of the

POAs existence .

Each POA has a name relative to the POA in which it was created

POA have Manager objects that activate them/change their Processing state.

Key Terms:

o Servants: Implementation object


Sri - 29

8/8/2019 Unit III R

30/54


o Object id: to identify CORBA object

o Active object Map: Mapping table contains object id & servant

o Incarnate: Action of running servant to serve requests associated with a

particular object

o Etherealize: destroy the relation between servant and object id

o Default servant: object to which requests are dispatched when no object id

in AOM

The application developer can register servants with the root POA if the policies

of the root POA specified in the POA specification are suitable for the application.

A server program may want to create multiple POAs to support different kinds of

CORBA objects and / or different kinds of servant styles.

The server application in the diagram contains 3 other nested POAs : A , B, & C ,POA A and B are children of the Root POA; POA C is Bs child. Each POA has an

Active Object Map Table that maps Object IDs to servants

POA policies:

1) ID Uniqueness: Determines whether more than one object id may refer to the same

servant object Policy Name: UNIQUE ID/MULTIPLE ID

2) ID Assignment: Determines whether the POA /programmer assigns Object id

Policy Name: USER_ID, SYSTEM_ID

3) Life Cycle: determines whether objects are transient/persistent P.N: TRANSIENT,

PERSISTENT

4) Servant Retention: Determines where to keep the mapping table

POA Manager

It encapsulates the processing state of one or more POAs. Application can use POA

manager to activate/deactivate POAs.

Figure shows Request dispatching based on POA

Basic steps in setting up a POA


Sri - 30

8/8/2019 Unit III R

31/54


1) Obtaining a reference to the root POA

2) Defining the POA policies

3) Creating a POA as a child of the root POA

4) Creating a servant & activating it

5) Activating the POA through its Manager

3.6. CORBAS SERVICES :

In addition to enabling objects to communicate over the network, the OMG has published

a set of CORBA Object Services (known as CORBA Services [COS]) that give your networked

objects additional capabilities. These services are optionally provided by CORBA vendors. Most

serious CORBA products give you one or more services to aid development. These include:

The CORBA Naming Service (COS Naming) is a CORBA service that enables you

to look up CORBA objects by name, a technology similar to the Java Naming and

Directory Interface (JNDI).

The CORBA Notification Service allows for asynchronous communications

between CORBA objects.

The CORBA Object Transaction Service (OTS) enables CORBA objects to

perform transactions.

The Concurrency Control Service allows for multiple clients to concurrently

interact with a resource.

The CORBA Security Service adds secure functionality to your CORBA system.

The CORBA services are the set of fundamental enabling interfaces for globally applicable

services capabilities. To success with CORBA a good familiarity with each of the CORBA

services is essential.

The CORBA services architecture:

It provides an organization for the services and infrastructure elements. It compromises

four categories of service elements.

1. Infrastructure services: It includes service elements that are tightly coupled to the ORB

mechanism such as messaging and interoperability.

1.security and time 2.Messaging 3.CORBA core 4.Interoperability

5.Language 6.Call by value 7.Mappings

2. Task management services: It includes enabling services for managing distributed object

events, transactions and concurrency.

1.Events 2.Concurrency 3.Transaction

3. Information management services: It includes basic services for manipulation and

retrieval of data such as properties ,relationship and collections.


Sri - 31

8/8/2019 Unit III R

32/54


1.Properties 2.Relationships 3.Multithread 4.Query

5.Externalization 6.Persistent object 7.Collection

4. System management services: It includes basic services for enabling the management of

meta-data (data about data),naming and object lifecycle.

1.Naming 2.Lifecycle 3.Licensing 4.Trader 5.Interface

Repository

Information Management Services:

1)Properties Services:

Properties are dynamic set of attributes, can be attached to application object. It is a name,

value pair, name is string and value is CORBA type any.

Access to properties can be restricted ie read only properties.

Ex:- desktop mgr, debugging tools, browser

2)Relationship Service:

General purpose service for establishing linkage & relationship among objects and it

defines relationships & cardinality.

It can have any no of roles whose cardinality can be specified.

Ex:

3)Query Service:

- allows application to perform queries on CORBA objects.

- General purpose set of software interface for query objects.

- Query objects are used to parse queries and execute and return query result.

- Used in database products supports both relational & object database model.

- Supports (1) static query (2) dynamic query.Static query :


Sri - 32

Document

RoleC AA

RoleA Figure

RoleE

Icon

Relationship

B

Relationship

A

8/8/2019 Unit III R

33/54


queries that are extension to programming language syntax.

known at compile time, so query optimization improves the performance.

Dynamic query :

generated at runtime, taken as string input passed to query objects.

Query service interface supports 2 evaluation of dynamic queries

synchronous execution client thread would block until query is completed.

(4)Externalization Service:(Serialization)

- converting data structures & other object states to form that can be stored/transmitted,

removes pointers, converting binary data into flat representation.

- Part of marshalling.

- Internalization externalized data can be reconstructed to original data structure

form.

- can be used to relocate the objects, but same software must be

available in the remote machine

Uses:

- email, persistant storage, pass by value mechanism in CORBA.

- Supports compound externalization process of externalizing multiple object that are

configured as graph of objects using relationship service.

(5)Persistant object service:

- Major components

- provides set of interfaces(persistant protocol-PP) for managing the persistence of object.


Sri - 33

clientPersistent

objectPersistent

ID

Persistentdata

service

Data

store

Persistent

object

mgr

Persisten

ce

protocol

OMG IDL

OMG IDL

Connect,

dis

connect,

store,

restore,

delete

8/8/2019 Unit III R

34/54


- Created by database vendors.(IBM,Sybase,ODMG)

- PP is used to store objects persistent state has 3 protocols.

1) ODMG 93

2) Direct access protocol defines persistent state through DDL

3) Dynamic data object protocol persistent state is stored similar to properties

service i.e. a pair name, value name-string, value-any

Scenario: Restore()

- application object defines persistent state through DDL.

- Returns persistent state to persistent object as set of attribute indicated in DDL

(6)Collection service:

- set of interfaces for common grouping of objects.

- Various ways (1) sequential list of object

(2) stack of object

(3) queue of object

(4) bag of objectTask Management CORBA Services:

1)The Event service:

- defines a communication model , defines generic interfaces for passing event information

among multiple sources and multiple event consumer.

- The CORBA Event Service defines a communication model that allows an application to

send messages to objects, without even knowing that the target object that will receive the

message exists


Sri - 34

ClientPersistent

object

Persistentobject mgr

Persistent data

service

1 -

restore 2 -

restore

4 -

data

3 -

restore

8/8/2019 Unit III R

35/54


- The Event service decouples the communication between objects. In order to support this

type of operation, the CORBA Event Service has introduced a new CORBA architectural

element calledEvent Channel

Advantage:

- sources(supplier) & consumer need not know each other.

- Decouples generator(supplier) and receiver of events

- event service allows object to dynamically register or unregister their interest of specific

events

- 2 roles of object

(1) supplier object that generates event

(2) consumer object that receives event

Methods of Event Communication:

The CORBA Event Service specifies two basic models for allowing suppliers and

Consumers to communicate event data; thepush model and thepullmodel.

The PUSH Model :

The Pull Model:

The pull model (in the Figure) is the reverse to the push. An active consumer makes a pull

request to the Event Channel to get event data, the channel playing the role ofProcurerwill then

pull the event from the passive supplier and issues it to the consumer.


Sri - 35

8/8/2019 Unit III R

36/54


The Mixed Mode Communication :

The suppliers use the push model and consumers use the Pull model, this is commonly

known as thePush/Pull model. In this case both, suppliers and consumers could initiate the event

transfer. Suppliers invoke an operation on an object in the Event Channel to transfer event data.

Consumers would invoke another operation on the object in the Event Channel to obtain event

data.

2) Concurrency Service :

Framework for managing concurrent object access

Analogous to multithreading support in C++/Java

Facilities for interfacing with transaction service

Concurrency Service assumes usage of locks

Read, write-locks, multi-possession, two-phase locks

Conflicts with existing locks are resolved by a first-come first-served

queuing model

Interfaces to represent resources:

LockSet, TransactionalLockSet

LockSetFactory interface for object creation

3) Transaction Service (contd.)

Transaction can involve a series of remote method calls

Whole transaction is rolled back when a significant error is encountered

Transaction contexts are propagated along the way

Service provides framework for notification and management of transaction boundaries


Sri - 36

8/8/2019 Unit III R

37/54


Little help with implementation of rollback operations

Interfaces:

Current interface: start and end of transactions

Control interface: manipulation of ongoing transactions

Terminator, Coordinator, Resource objects

Depends on Concurrency and Persistent Object Services

3.7.CORBA COMPONENT MODEL(CCM):

Introduction:

The CORBA Component Model (CCM) is a specification for creating server-side scalable

,language-neutral, transactional, multi-user and secure enterprise-level applications.

CCM component model is an extension of EJB.

CCM Compliant products would go beyond the current tendency of J2EE application

servers that largely use CORBA only as an interoperable connectivity standard via

IIOP.

CCM components itself consists of multiple segments.

Goals:

Separating configuration concerns into aspects:

Server configuration

Object/service configuration

Application configuration

Object/service deployment

CCM Architecture:

A typical CCM architecture consists of

1. CCM Containers

2. CORBA components that run in these containers

3. The portable Object Adapter (POA)

4. The Object Request Broker(ORB)

5. Other CORBA objects services like CORBA Transactions, CORBA Security,

CORBA Persistence ,CORBA Events ,etc;


Sri - 37

8/8/2019 Unit III R

38/54

8/8/2019 Unit III R

39/54


3. Entity containers

4.Other containers

CCM Clients:

These make use of the CCm components for their operation. They then make use of the CCM

Container to invoke the component methods.

CCM Component Overview:

CCM components can expose multiple interfaces. while defining the IDL for each

component, the interfaces that it provides and the interfaces that it uses have to be specified.

Event generation and publication declarations are used to define an event source. event

consumption declarations are used to describe event skins

There are four types of CCM components:

1.Service Components

2.Session Components

3.Process Components

4.entity components

1. Service components:

Each service component is usually associated with one CCM client and its lifetime is restricted

to that of one single operation request (or a single method call).Each service components is

created and destroyed by the particular CCM client that it is associated with service components

do not survive a system shutdown.

2.Session components:

Each session components is usually associated with one CCM client. Each session component

is created and destroyed by the particular CCM client that it is associated with. A session

component can either have states or they can be stateless .However session do not survive a

system shutdown. A session component is very similar to a session EJB.

There are two types of session components. they are

stateless session components

stateful session components

a.Stateless session components:

These types of components have no internal state. since they do not have any states, they

need not be passivated. because of the fact that they are stateless, they can be pooled in to service

multiple clients(remember MTS components and stateless session EJBs)

b.Stateful session components:


Sri - 39

8/8/2019 Unit III R

40/54


These types of components posses internal states. Hence they need to handle persistence.

These types of components can be saved and restored across client sessions(remember stateful

session EJBs)

3.Process components:

The process components always have states. Each process component may however be

shared by multiple CCM clients. their states can be persisted and stored across multiple

invocations. Hence they can survive system shutdowns.

4.Entity components:

The Entity components always have states. Each Entity component may however be

shared by multiple CCM Clients. their states can be persisted and stored across multiple

invocations. Hence they van survive system shutdowns.

Each Entity Component can be uniquely identified by its primary key. An entity

component is very similar to an entity EJB

Difference b/w Process Entity Components:

One of the major differences between process and entity components are that while the entity

component has a primary key to uniquely be identified by the client, a process component does

not

Passivation is the process by which the state of a component is saved to persistent

storage and then is swapped out.

Activation is the process by which the state of a component is restored by swapping it in

from persistent storage.

CORBA object reference:

A CORBA object reference is an abstract handle referring to an instance of a CORBA objects.

A object reference hides the location where the actual object resides and contains protocol

information defined by the CORBA application.

General Notation Example : Stock exchange


Sri - 40

8/8/2019 Unit III R

41/54


FEATURES OF CCM COMPONENTS :

Figure : CCM Components

Ports :

There are four types of ports defined in CCM which are explained below:

# Ports Definition Symbol

1. Facets Facets are distinct named interfaces provided

by the component for client interaction. i.e.,

Components exposes named interface as

surface feature using which other client

applications can interact by explicit

connection. Using facets a component can

give multiple object references.

2. Receptacles Receptacles are named connection points

that describe the component's ability to use a

reference supplied by some external agent.

Receptacles make use of the reference

provided by the Facets.

3. Event Source Event Source are named connection points

that emit events of a specified type to one or

more interested event consumers, or to an

event channel.

4. Event Sink Event sink are named connection points into


Sri - 41

8/8/2019 Unit III R

42/54


which events of a specified type may be

pushed.

Note :

The facets and receptacles can be connected together to provide synchronous connections.

The emitters (events source) and consumers (event sink) also can be connected together to provide

asynchronous connections between two components.

5.Attributes:

Attributes can bed used by configuration tools to preset configuration values of a

component.

CCM allows operations that access and modify attribute value to raise exceptions.

Component developers must decide whether an attribute implementation is part of the

transient persistent state of the component.

CCM features :

Fully written in java.

Portability , maintenance and support

An open compilation and generation tool chain.

An OMG IDL 3 compiler is used.

A flexible distributed deployment and execution middleware infrastructure.

3.8.CONTAINER:

CORBA 3 defines a component implementation framework(CIF) which includes

generators that accept CIDL(Component Implementation Description Language) input and

generate implementation code that completes explicitly provided component code.

The container manages component instance depending component category. It offers all its

services through simplified APIs(Application Programming Interfaces)the component manages a

component, it creates and uses a POA with request for specific Component and home interfaces to

manage life cycle of a component.

Every component instance is placed inside a CCM Container.

Component interact with POA as well as transaction ,Security , Persistence and

notification service via interfaces on their container.


Sri - 42

8/8/2019 Unit III R

43/54


Figure shows Container Architecture

The container manages a component. It creates and uses a POA with requested features for

specific component category. Client can use external interfaces of a component to interact with

component and home interfaces to manage life cycle of a component.

a. External API types:

The external API types of a component are the contract between the component developer

and the component client. It consists of two types of interfaces mainly home interface and

application interface. Home interface allows client to obtain reference to one of the application

interfaces the component implements. From Clients prospective two design patterns are

supported namely factory patterns for creating new components and finder patterns for existing

components.

b. The container API type:

The container API defines a API framework, i.e. contract between specific component and

container. It defines two types of container APIs namely session APIs and entity APIs depending

on component category.

CORBA Usage Model:

A CORBA Usage specifies the required interaction pattern between the container, the POA and

the CORBA services.

Stateless: which uses transient object reference in conjunction with a POA servant which

can support any objected

Conversational: which uses transient references with a POA servant that is dedicated to

specific objected

Durable: Which uses persistentence references with POA servant that is dedicated to a

specific obectid

Servant Programming Environment:


Sri - 43

8/8/2019 Unit III R

44/54


In addition to object services the component can specify servant lifetime policy to optimize

memory usage.

1.Servance Lifetime Management

2.Transaction

3.Security

4.Events

5.Persistence

1.Servant lifetime Management:

Servants are programming language objects which the POA uses to dispatch operation

requests based on object identification. The server programming model for CORBA components

include facilities to efficiently manage the memory associated with these programming objects.

The servant lifetime policies are defined as follows:

Method: This policy causes the container to activate the component on every operation

request and to passivate when that operation is completed.

Transaction: This policy causes the container to activate the components on the first operation

of request within transaction and leave it until transaction completes.

Component: This policy causes the container to activate the component on the first operation

and remains active until component implementation requests to passivate.

Container : This policy cause the container to activate component on the first

operation request and leave it active until container decides to

passivate it.

2.TRANSACTION:

CORBA component supports both self-managed transaction through containers APIs Or

container managed transaction by using set of defined policies.

NOT_SUPPORTED The component does not support transactions. If client sends transaction

to the component, it remains suspended until component completes the

operation.

REQUIRED The component requires a current transaction to execute successfully. If

the operation is invoked without a transaction context, the container starts

new transaction and commits or rollback once operation is completed by

component.

SUPPORTS This component will support transaction if one is available.

REQUIRES_NEW The component requires its own transaction to execute successfully. If

client sends transaction context it'll remain suspended until the new

transaction is completed.


Sri - 44

8/8/2019 Unit III R

45/54


MANDATORY The component requires the client be in a current transaction before this

operation is invoked.

NEVER The component required that client not be in current transaction

before this operation is invoked.

3. Security

The security policy is applied consistently to all categories of components. Access

permissions are defined by the deployment descriptors associated with the component

4. Event

CORBA components use a simple subset of the CORBA notification service to emit and

consume events

5.Persistence

To make component state durable , entity container API make use of persistence

mechanism .It support 2 types of persistent support.

1) Container Managed Persistence 2) Self Managed Persistence

1) Container Managed Persistence - The component developer simply

defines the state that is to be persisted and container automatically saves and restores the

state as required . A special lang called PSDL (Persistent state definition Lang) is used to

store / restore the component state.

2) Self Managed Persistence - the component developer assumes the responsibility of

managing persistent state of the component

Component Implementation Framework :

The Component Implementation Framework (CIF) is set of classes and tools that

help in implementation of components. The idea of component is binary unit is clear in

CCM, which is known as executor that defines name of artifacts that can be generated by

CIF. CCM includes a declarative language (CIDL) for describing implementations of

component, as well as their abstract states using Persistence State Description Language

(PSDL). CIDL is superset of PSDL. The most important keyword in CIDL is

"composition" that specifies how the implementation of component can be split into

different executors and how the state elements are associated with each other. A

composition comprises the following elements:

Component

home

as specified in IDL home definition identifies the component type managed by

the home as the composition's component type

Abstract identifies abstract storage type that will incarnate the component.


Sri - 45

8/8/2019 Unit III R

46/54


storage

binding

(optional)

Component

Executor

may specify a number of executor segments, which are physical partitioning of

component that encapsulates independent state and may be activatedindependently.

Delegation

specification

(optional)

allows mapping of operations defined on home to operations on either

component or abstract storage home. This feature is optional for basic

component.

3.9. A3.9. APPLCIATIONPPLCIATION SSERVERSERVERS ::

Most service implementations are bundled with ORBs and not sold as separate products.

The ORBs arent sold as individual product but are bundled with large application products such

as:

IBMs WebSphere

BEAs Weblogic Enterprise

IONAs Orbix E2A Application Server platform

Borlands Enterprise server

All these combine J2EE application server with CORBA ORB and service functionality.

IONAs Orbix is an ORB that is available for a large number of platforms.It supports C++,Smalltalk,java and object COBOL binding.

BEABEASS WWEBEBLLOGICOGIC::

Its a family of products:

J2EE application server (WebLogic server)

Integration Server (WebLogic integration)

Web server (WebLogic Portal)

WebLogic Workshop dedicated integrated development environment that enables the creation,testing and deployment of applications and web services built using the WebLogic products.

WebLogic Enterprise platform its a combination of WebLogic products and Tuxedo product.

WebLogic Server integrates BEAs transaction processing monitor via the WebLogic Tuxedo

Connector at levels of IIOP connection pooling, transactions and security.

Tuxedo includes a

CORBA 2-complaint ORB for C++ and Java including implementations of object

o

lifecycle, naming, notification, security and Transaction services. An interface repository is also present.


Sri - 46

8/8/2019 Unit III R

47/54


It supports load balancing of objects and requests across replicated server processes and

server groups.

Routing requests can be

Data-driven 2) Factory-based

Multiple incoming incoming client connections can be multiplexed Multithreaded servers can be constructed

Has a security framework that can be customized to integrate with external security

systems.

IBMIBMSS WWEBEBSSPHEREPHERE::

Its a family of products that includes:

1) Standard edition 2) Advanced edition 3) Enterprise edition

Standard edition a web server supporting Java servlets, Java server pages and XMLAdvanced edition adds J2EE application server capabilities by supporting EJB

Enterprise edition incorporates a CORBA 2-complaint ORB

WebSpheres Advanced editions J2EE implementation stood out for its support of EJB

container-managed persistence and relationships in a way that integrates tightly with the DB2

caching system. It reduces an application programmers control over performance characteristics

by manifesting either too many entity instances or too few.

WebSpheres Enterprise edition builds on ComponentBroker

ComponentBroker:

Its a way of packaging existing software into components and supports simple set-up of

connections between such components.

Supports CORBA and Java to enable connectivity

Provides management facility to control aspects such as

Security

Adequate resourcing to satisfy demands

Proximity of location

It has the

o CBToolkit (facilitates development of components)

o CBConnector (enables connection and management of components)

It separates business objects from client views. Business objects encapsulate functionality

according to business functions.

Object builder generates source code skeletons for business objects based on OMG IDL

and further specifications for C++/Java


Sri - 47

8/8/2019 Unit III R

48/54


CBConnector managed object framework is provided so that new classes can inherit all

standard management interfaces and functionality

Services provided are:

Lifecycle ,Externalization,Naming,Security,Event,Persistence

Concurrency,Transaction services,Identity service

Drawback it is difficult to use in combination with other CORBA-complaint products.

IONAIONASS OORBIXRBIX E2A AE2A APPLICATIONPPLICATION SSERVERERVERPLATFORMPLATFORM::

Its an ORB that is available for large number of platforms, supporting Smalltalk,

C++, Java, and Object COBOL buildings,

Orbix is implemented as a pair of dynamic link libraries for the client and server interface.

One for client,One for the server interface

A daemon process is used to handle activation on demand for incoming requests

It integrates Orbix 2000 and IONAs iPortal application server supporting J2EE and

development of web services.

It is CORBA 2.4-complaint and supports C++ and Java.

Application server is available in

Standard,Enterprise,Mainframe,J2EE technology edition

COMet runs under Windows and implements CORBA/COM interworking via local

COM interfaces.

ORBacus

o its CORBA 2.4-complaint ORB distributed as source code that is available in C++

and Java

o it supports several services such as:

Names,Events,Properties,Times,Trader,Notify

Orbix/E 2.1

o lightweight ORB for embedded applications in C/C++ or Java that compiles with

minimum memory needs,

o Implements a basic POA and includes embedded Naming and Event services.

o Fault tolerance achieved via multiple profiles each designated to different protocol

or server.

BBORLANDORLANDSS EENTERPRISENTERPRISE SSERVERERVER:

Visibroker originally developed by Visigenic is Borlands ORB implementation.

Visibroker for Java is CORBA 2-complaint ORB implementation written entirely in Java

Visibroker for C++ is CORBA 2-complaint ORB implementation written entirely in C++


Sri - 48

8/8/2019 Unit III R

49/54


It uses IIOP for all requests

It supports multiple object replicas. Client requests are forwarded to one of these replicas

to balance load and survive server crashes.

Provides an integrated transaction service (ITS)

With CORBA transaction services

Implements logging and recovery

Connectivity with database and legacy systems

Administrative facilities,Security,Firewall,Naming event

Enterprise servers comes in three variant

o Web Edition- Doesnt include VisiBroker and focuses on delivering web pages

o VisiBroker Edition

Has automatic fail-over,Visibroker ORB

Visual administration tool ,Naming service

o AppServer Edition

It is J2EE 1.3 certified ,Support EJB 2.0

Integrated with Borlands JBuilder development environment ,

SonicMQ ,Application partitioning

For Example ,

// Calc.idl

module Calc

{

interface Adder

{

long add(in long x, in long y);

}

}

To do ,

..bin> idltojava Calc.idl

This create the following files in the folder named as calc.

Adder.java (a Java interface that maps the IDL interface)

_AdderStub.java (a client stub)

_AdderImplBase.java (a server skeleton)

AdderHelper.java (a helper class)

AdderHolder.java (a holder class)


Sri - 49

8/8/2019 Unit III R

50/54


Steps to Implementing a server,

o Extend base class

Implement all methods declared in IDL

o Provide a main method

Create an ORB instance

Create a server instance

Inform the ORB about the instance

Acquire a Naming Context

Register the instance in that Naming Context under some name

//AdderServer.java

class AdderServer extends _AdderImplBase

{

public int add( int x, int y )

{

System.out.println(x + " + " + y + " = " + (x+y));

return x + y;

}


{// create and initialize the ORB


// create server and register it with the ORB

AdderServer adderRef = new AdderServer();

orb.connect(adderRef);


org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");


// bind the Object Reference in Naming

NameComponent nc = new NameComponent("Adder", "");


ncRef.rebind(path, adderRef);

}

Steps to Implementing a client :


Sri - 50

8/8/2019 Unit III R

51/54


Create an ORB

Get a reference to the Naming Context

Look up the correct name in that Naming Context

Receive an object reference to that object

o Actually, to its Stub

Invoke methods on the reference

3.10. MODEL DRIVEN ARCHITECTURE :

In an attempt to build on several OMG specifications including UML, XML and CORBA

the OMG architecture board introduced a new approach called Model Driven Architecture(MDA)

in july 2001.

MDA is the base architecture for all forethcoming OMG Specifications.

Goals of MDA is to embrace CORBA,J2EE,XML,.net and other technologies. An approach to IT system specification that separates the specification of system

functionality from the specification of the implementation of that functionality on a

particular technology platform

Design once, build it on any platform

A modelis a formal specification of the function, structure and/or behaviour of a system

Examples:

Source code is a model

An UML-based specification is a model

Models of different systems are structured explicitly into:

Platform Independent Models (PIM)

Platform Specific Models (PSM)

A complete MDA specification consists of a definitive platform-independent base UML

model, plus one or more platform-specific models and interface definition sets, each describing

how the base model is implemented on a different middleware platform.

Software design launched by OMG

Defines the functionality & behavior of a distributed system

Support model driven engineering of s/w system

Provides set of guidelines for structuring specifications expressed as models

Defines system functionality using a platform independent model

Plat form specific model CORBA ,.NET etc

This includes UML notations and Meta model facility


Sri - 51

8/8/2019 Unit III R

52/54


Specification to be writtenin 2 levels 1) PIM 2) PSM

The principles of MDA :

Four principles underlie the OMG's view of MDA:

1. Models expressed in a well-defined notation

2. The building of systems can be organized around a set of models by imposing a series of

transformations between models, organized into an architectural framework of layers and

transformations.

3. Describing models in a set of metamodels facilitates

4. Acceptance and broad adoption of this model-based approach requires industry standards

to provide openness to consumers, and foster competition among vendors.

To support these principles, the OMG has defined a specific set of layers and

transformations that provide a conceptual framework and vocabulary for MDA.

OMG identifies four types of models:

1) Computation Independent Model (CIM)

2) Platform Independent Model (PIM)

3) Platform Specific Model (PSM) described by a Platform Model (PM)

4) an Implementation Specific Model (ISM).

Platform Independent Model (PIM) :

A formal specification of the structure and function of a system that abstracts away

technical detail

Expressed using UML

For example ,


Sri - 52

8/8/2019 Unit III R

53/54


Platform Specific Model (PSM) :

Specifies how the functionality specified in a PIM is realized on a particular platform

Expressed using UML extended with platform specific UML profiles

Meta Models :

This is the way to describe the semantics of the models.


Sri - 53

8/8/2019 Unit III R

54/54


The UML meta model describes in precise detail the meaning of a class, an attribute, and

the relationships between these two concepts.

The OMG recognizes the importance of meta models and formal semantics for modeling,

and it has defined a set of meta modeling levels as well as a standard language for expressing

meta models: the Meta Object Facility (MOF). A meta model uses MOF to formally define the

abstract syntax of a set of modeling constructs.

Figure shows an example of PIM to PSM transformations

Date post:	10-Apr-2018
Category:	Documents
Upload:	yashwant-gopal
View:	227 times
Download:	0 times

Unit III R

Documents