Unit - Iii Corba Component Technologies

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
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
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
The four categories of the OMA(Object Management Architecture):
Application CORBA CORBA

objects domains facilities
Object Request Broker
CORBAservices
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
vendors. It includes ORB’s 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.
It’s 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 CORBA’s lifecycle mgmt approach rather than RMI distributed garbage
collection.

Sri - 5
 java’s instanceof operator can’t 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 Security threats with remote code execution,
JVMs and limitations are enforced by security
restriction
3 Java developers may already have Learning curve for developers that have no
experience with RMI RMI experience is comparable with CORBA.
4 Existing system may already use RMI Can Only operate with java systems . No
the cost and time to convert to a new support legasy systems written in C+
technology may prohibitive. +,Ada,Fortran,Cobol.
CORBA :
S.No. PROS CONS
1 Services can be written and executed with Describing services require the use
different language with different platform through of an IDL which must be learned.
IDL.
2 With IDL , the interface is clearly separated from Some tools may not integrate new
implementation changes with existing code.
3 CORBA support primitive data types and wide CORBA does not support the
range of data structures. transfer of objects or code.
4 CORBA is an easy way to link objects and CORBA specifications is still in a
systems together. 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
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
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 of every 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
// 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
// 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
}
catch (Exception e)
{
System.err.println("ERROR: " + e);
e.printStackTrace(System.out);
}
}
}
//CounterClient.java
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
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
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-neutral interface 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 it’s all written in
one language.
IDL Defines protocol to access objects , Like a contract , Well-specified and Language-
independent

Sri - 13
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 a sample snippet of 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
. 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 short and float ) and
constructed types (such as struct 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
- 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
- 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 String type in OMG IDL maps to the java.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
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:
Scalars—contain single values
Arrays—contain multiple values arranged in an n-dimensional “grid.”
Structures—are 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
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{

Sri - 19
// 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
{
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
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 don’t exist already, housekeeping of threads, and more. Modern
ORB implementations have object adapters coded to the CORBA Portable Object Adapter (POA)
specification.
The Figure shows CORBA invocation( Calling Method ) process .

Sri - 22
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
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
– 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
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
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 object is an identifiable, encapsulated entity that provides one or more services that can
be requested by a client.

Sri - 27
3.5.PORTABLE OBJECT ADAPTER (POA) :
An object adapter is 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 vendor’s 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
• Implementer’s perspective:

Sri - 28
o informs the ORB of available objects and processes that are
ready to receive requests
• Client’s 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
POA’s 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
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 B’s 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
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. CORBA’S 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
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:
RoleA Figure
Relationship
B
Document
RoleC AA
Relationship
A
RoleE
Icon
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
 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
Persistent Persistent
client object
ID
Connect,
dis
OMG IDL
connect,
Persisten Persistent
store,
ce object restore,
protocol mgr delete
Persistent OMG IDL

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

Sri - 33
- Created by database vendors.(IBM,Sybase,ODMG)
- PP is used to store object’s 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()
1-
restore Persistent 2-
Client restore
object
4- Persistent
data
object mgr
3-
restore
Persistent data
service
- 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 object
Task 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
- 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 called Event 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; the push model and the pull model.
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 of Procurer will then
pull the event from the passive supplier and issues it to the consumer.

Sri - 35
The Mixed Mode Communication :

The suppliers use the push model and consumers use the Pull model, this is commonly
known as the Push/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
– 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
In a typical development and deployment scenario ,there will be an application server

provider who creates and sells an Application server along with CCM containers that will run
on these servers.
Application Servers
These provide the system services like a raw execution environment ,multiprocessing
,load-balancing, device access, provide naming and transaction services and make
containers visible.
CCM Containers:
These act as the interface between a CORBA component and the outside world. A CCM
client never accesses a CORBA component directly. Any component access is done
through container –generated methods which in turn invoke the components’ methods.
There are basically two basic types of containers.
They are,
1.Transient containers
2.Persistent containers
Transient containers:
It may contain transient ,non-persistent components whose states are not saved at all.
Persistent containers:
It contains persistent components whose states are saved between invocations . Depending
upon the types of components that they can execute ,CCM Containers may be divided
into :
1. Service containers
2. Session containers

Sri - 38
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
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
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
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 Interface’s)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
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 Client’s 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
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
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:
as specified in IDL home definition identifies the component type managed by

Component the home as the composition's component type
home
Abstract identifies abstract storage type that will incarnate the component.
Sri - 45
storage
binding
(optional)
Component may specify a number of executor segments, which are physical partitioning of
Executor component that encapsulates independent state and may be activated
independently.
Delegation allows mapping of operations defined on home to operations on either
specification component or abstract storage home. This feature is optional for basic
(optional) component.
3.9. APPLCIATION SERVERS :

Most service implementations are bundled with ORBs and not sold as separate products.
The ORBs aren’t sold as individual product but are bundled with large application products such
as:
 IBM’s WebSphere
 BEA’s Weblogic Enterprise
 IONA’s Orbix E2A Application Server platform
 Borland’s Enterprise server
All these combine J2EE application server with CORBA ORB and service functionality.
IONA’s Orbix is an ORB that is available for a large number of platforms.It supports C+
+,Smalltalk,java and object COBOL binding.
BEA’S WEBLOGIC:
It’s 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 – it’s a combination of WebLogic products and Tuxedo product.
WebLogic Server – integrates BEA’s 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
• 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.
IBM’S WEBSPHERE:
It’s 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 XML
Advanced edition – adds J2EE application server capabilities by supporting EJB
Enterprise edition – incorporates a CORBA 2-complaint ORB
WebSphere’s Advanced edition’s 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 programmer’s control over performance characteristics
by manifesting either too many entity instances or too few.
WebSphere’s Enterprise edition builds on ComponentBroker
ComponentBroker:
It’s 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
• 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.
IONA’S ORBIX E2A APPLICATION SERVER PLATFORM:
It’s 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 IONA’s 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.
BORLAND’S ENTERPRISE SERVER:
• Visibroker originally developed by Visigenic is Borland’s 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
• 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- Doesn’t 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 Borland’s 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
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 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
• 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 model is 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
 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
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
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

Sri - 54

Unit - Iii Corba Component Technologies

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Unit - Iii Corba Component Technologies

Transféré par

Droits d'auteur :

Formats disponibles

Component Based Technology Unit - III

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Application CORBA CORBA

Object Request Broker

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Figure The ORB facilitates your networking needs

Figure shows Parts of ORB

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

The IDL concept is shown in Figure.

Panimalar Engineering College , Chennai.

IDL has following features,

Panimalar Engineering College , Chennai.

IDL For Bank Account,

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

OMG IDL Maps to Concrete Languages :

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

class HelloServant extends _HelloImplBase

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

The Figure shows CORBA invocation( Calling Method ) process .

Panimalar Engineering College , Chennai.

The figure show simple “helloworld” application Model

Panimalar Engineering College , Chennai.

Fig. shows CORBA Reference Model architecture

Panimalar Engineering College , Chennai.

Fig. shows CORBA communication paradigm

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Figure shows Request dispatching based on POA

Panimalar Engineering College , Chennai.

Persistent OMG IDL

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

Panimalar Engineering College , Chennai.

- application object defines persistent state through DDL.

Panimalar Engineering College , Chennai.

Methods of Event Communication:

The Pull Model:

Panimalar Engineering College , Chennai.

The Mixed Mode Communication :

Panimalar Engineering College , Chennai.

In a typical development and deployment scenario ,there will be an application server

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Figure : CCM Components

Panimalar Engineering College , Chennai.

Panimalar Engineering College , Chennai.

Figure shows Container Architecture

Panimalar Engineering College , Chennai.