[Lecturer: H. Muccini] [Link]
edu/~muccini/ics123
ICS 123 (Fall 2002)
Software Architectures, Distributed
Systems, and Interoperability CORBA
Lecture 13: CORBA
- CORBA Object Model
- CORBA Architecture
- CORBA vs. COM vs. Java/RMI
4/35
Object-Oriented Middleware Who is the OMG?
IDL Non-profit organization
They are more powerful Founded April 1989
They handle failure Java/RMI: 1997
They support inheritance Com/DCOM: 1993-1996
CORBA: 1995
Presentation Layer
More than 800 members
Common data representation
Marshalling and Unmarshalling Dedicated to creating and popularizing object-oriented
industry standards for application integration, e.g.
Session Layer CORBA
Object activation UML
Object Binding …
2/35 5/35
Client Server Goals of CORBA
Support distributed and heterogeneous object
Stub Registry Stub request in a way transparent to users and
Middleware application programmers
The Client side: Facilitate the integration of new components
• Requires the service identifying the object it needs through an object
reference with legacy components
• The Client Object is connected to (and depends on) its Client Stub
• The Client Stub has the ability to locate the referenced object in the network
Open standard that can be used free of charge
Based on wide industry consensus
The Server side:
• The server object needs to be registered using the Registry Languages supported:
• Receives the request from the Client Stub
• The Server Stub maps the object reference to the active object, checks if the C, C++, Smalltalk, Ada-95, Java and OO-Cobol
object is active. If it is not, it starts up the object. Then, it forwards the request
to the object implementing the service. 3/35 6/35
1
Object Management Architecture (OMA) Object Model and Interface Definition
Application Interfaces Domain Interfaces Common Facilities Objects
Types
Modules
Attributes
Object Request Broker (ORB)
Operations
Requests
Exceptions
Subtypes
CORBAServices
CORBAServices: Object location, object creation and mobility, concurrent access control,
7/35 10/35
distributed transaction controller, …
Roadmap on this lecture (1/2) Inheritance
Objects in CORBA
The CORBA Object Model Interface Server
Server
Each object has one identifier that is unique
within an ORB
Client - How the Client can require the operation it needs Different from COM
Client - Parameter passing
In order to make an object request, the client
needs to have a reference to a server obj.
Failure handling References support location transparency
Server
Server
…
… Object references are persistent
Client
Client
…
… Server
Server
8/35 11/35
Roadmap on this lecture (2/2) Types in CORBA (in CORBA IDL)
The CORBA Architecture The object model is statically typed
Client Stub Type safety is guaranteed
Server Skeleton Atomic types
Object Adapter Boolean, char, short, long, float and string
Dynamic Invocation New types can be built using the typedef
construct combined with the keywords
sequence, struct, array and union
CORBA Vs. COM Vs. Java/RMI
9/35 12/35
2
CORBA Object Model: Types Operations (in CORBA IDL)
Syntax:
<return type><operation name>(<parameter>, <>, …)
typedef struct _Address { <parameter> = <parameter kind><parameter type><parameter name>
string street; CORBA does not support OVERLOADING
Constructed string postcode;
types Atomic Parameter kind
string city; types
interface Team { Parameter list
} Address; Return types
...
typedef sequence <Address>AddressList;
void bookGoalies(in Date d);
interface Team { ... };
string print();
Parameter type
};
Operation name Parameter name
13/35 16/35
used in requests
Module (in CORBA IDL) Exceptions (in CORBA IDL)
≈ 25 system
module Soccer {
A module is used typedef struct _Address { Exceptions (e.g. network down,
to restrict the scope string street;
string postcode; invalid object reference, out of memory)
In this way, we can string city;
have different elements } Address; Soccer::Address Type-specific Exceptions
(types, interfaces) with };
the same name module People { Exception name Exception data
typedef struct _Address {
A module can contain string flat_number; exception PlayerBooked{sequence<Date> free;};
type definition (as in string street;
the example), interface string postcode;
definitions, constants string city; interface Team {
and exceptions ...
string country;
} Address; People::Address void bookGoalies(in Date d) raises(PlayerBooked);
Two interfaces can have
}; };
the same name
Operations declare
14/35 17/35
exceptions they raise
Attributes (in CORBA IDL) Subtypes and Inheritance
Syntax: Attribute <static type> <name> •CORBA supports multiple inheritance
All attributes declared in the interface are accessible to clients •Inheritance is public
CORBA IDL supports the concept of constants (const) •The inheritance hierarchy has a single root, that is, the Object interface
interface Player; Implicit supertype: Object
typedef sequence<Player> PlayerList; Operation Inherited by Club
interface Trainer;
interface Organization {
Clients cannot typedef sequence<Trainer> TrainerList; readonly attribute string name;
change value };
Supertype
interface Club : Organization {
interface Team {
exception NotInClub{};
readonly attribute string name; readonly attribute short noOfMembers;
attribute TrainerList coached_by; readonly attribute Address location;
attribute Club belongs_to; attribute TeamList teams;
attribute PlayerList players; attribute TrainerList trainers;
...}; void transfer(in Player p) raises(NotInClub);
15/35 }; 18/35
changeable Attribute type Attribute name
3
Summarizing: IDL CORBA: Normal and Exception Behavior
Client NORMAL EXCEPTION
module Bank {
Modules interface Account {
Interfaces float balance(); Client requests ORB forwards
ORB propagates
Attributes };
an operation on result to
exception to
an object
client
Types interface AccountManager {
client
Constants
exception CantOpen {};
ORB
Operations
Account open(in string name)
Exceptions
raises (CantOpen); ORB locates
Object
Object raises
produces
exception
}; object and operation
forwards request result
};
Object
19/35 22/35
Architecture The CORBA Object Model
Client Object Implementation
IDL Interface
Conceptual
level Client Operation on object Object
Dynamic Client ORB
Implementation Object requested by client
Skeletons Adapter
Invocation Stubs Interface
Compilation according to
ORB Core language-specific
mapping
Implementation
Client Stub, implementation skeleton and Dynamic level
Invocation interface are responsible for marshalling Client Object Implementation
and unmarshalling Stub Skeleton
ORB
Stub and skeleton are generated from the IDL using
an IDL compiler Client Implementation facilitatedrequest
Client
by ORB Object Implementation
Presentation Layer
-Common data representation
20/35 23/35
-Marshalling and Unmarshalling
Session Layer
Architecture
-Object activation
-Object Binding
Client Object Implementation
CORBA vs. COM vs. Java/RMI
Dynamic Implementation Object
Client ORB
Skeletons Adapter
Invocation Stubs Interface
ORB Core
The Object Adapter handles:
The server obj. registration, activation and deactivation, references
There are many Object Adapter:
Basic Object Adapter (BOA)…
Replaced by the Portable Object Adapter (POA)… it also supports
persistent objects
The object interface is used to initialize clients and servers 21/35 24/35
4
Comparison Roadmap
Object Model: Architecture: F ea t ur e C O M /D C O M C O R B A /II O P
Objects Stub Security Shipping : NTLM
NT5: MIT Kerberos,
Shipping: none
Beta: Multiple SSL variations
Types Skeleton SSL/Public Key
Operations Proxy Languages Visual C++, Visual J++, C, C++, ADA-95
Requests SCM Visual Basic, Cobol JAVA, Smalltalk,
OO-Cobol
Exceptions …
No Visual Basic
Multiple Transports TCP IP, IP, IPX, SPX, HTTP, TCP only
many others
25/35 28/35
CORBA and COM: The Object Model Java RMI and CORBA - COM
RMI:
Differences:
Differences: Requires objects to be programmed in Java
INTERFACES: The inheritance root in CORBA is the interface “Object”
. COM has “IUnknown” as root interface. Objects are platform independent
TYPES: CORBA supports more type’s construction mechanisms: The IDL is in Java
COM: records and arrays
CORBA: sequence, struct, array and union extend the [Link] class
REQUESTS:
REQUESTS: COM operations return a 32-bit integer, while CORBA can any method that can be remotely invoked in Java/RMI may
return different types. COM requests can be local to the same process, throw a [Link]
local to the same machine, remote (using RPC)
IDL: CORBA uses CORBA IDL while COM uses MIDL Java needs to call a Security Manager
INHERITANCE: COM does not support multiple inheritance (p. 105), Many object services are being defined within Enterprise
while CORBA does JavaBeans
Multiple interfaces in COM provide similar expressiveness as multiple
inheritance in CORBA CORBA provided these services since the OMA architecture
FAILURE HANDLING: COM uses the HRESULT. CORBA uses system COM provides services through COM+
and type-specific exceptions. COM failure handling is less powerfull
than CORBA’s (p. 104) It can be used in any hw platform with a JVM
ID: COM uses unique UUID and CLSID CORBA may be run on different O.S.
COM mainly under Windows
26/35 29/35
CORBA and COM: The Object Model Java RMI and CORBA, COM
Similarites:
Similarites
OPERATION VISIBILITY: Like COM, CORBA does not have
any primitives to define the visibility of operations Object Reference
OPERATIONS TYPE: CORBA and COM operations type are CORBA identifies objects through object references
very similar, since both present input, output and input/output COM objects are identified by interface pointers
parameters Java/RMI objects are identified by references
Inheritance root
Notes:
CORBA Object
RPC: Microsoft did not invent the distribution mechanisms by
COM
IUnknown
scratch but extended OSF/DCE’s RPC
COM is for reuse and evolvability, using binary encapsulation Java/RMI
Remote
and binary compatibility Inheritance and Failure Handling
STUBS: COM proxies are equivalent to CORBA client stub Both CORBA and Java/RMI support multiple inheritance at the
MODULE: COM has not the concept of “module” owned by IDL or interface level
CORBA: CORBA and Java/RMI IDLs can specify exceptions in the
CORBA modules are for scoping purpose IDLs while DCOM does not
COM does not need, since it uses UUIDs and CLSIDs
Corba ORB is not portable to other ORB products
27/35 30/35
5
The CORBA Architecture
Java/RMI - Interface
DCOM - IDL CORBA - IDL
definition
…
library SimpleStocks Client Object Implementation
{
importlib("[Link]
package SimpleStocks;
");
module SimpleStocks import [Link].*;
[
{ import [Link].*; Implementation
uuid(BC4C0AB0-5A45- Dynamic Client ORB Object
interface StockMarket Skeletons
11d2-99C5- Invocation Interface Adapter
{ public interface Stubs
00A02414C655),
exception Remote(); StockMarket extends
dual
float get_price(in [Link]
]
string symbol) raises { ORB Core
interface IStockMarket
Remote(); float get_price(String
: IDispatch
{
};
};
symbol ) throws
RemoteException;
Marshalling and unmarshalling
HRESULT get_price([in]
BSTR p1, [out, retval]
float * rtn);
}
Activation and Deactivation
}
…
File : File :
File : [Link]
[Link] [Link]
31/35 34/35
The RMI Architecture To conclude
Client Server
CORBA, COM and RMI
Stub Registry Skeleton Activation CORBA: for mission-critical and high-availability
Interfaces Interfaces applications. Unix and mainframes
COM: distributed systems for Windows operating
RMI Runtime (rmid,rmiregistry)
systems
Stub and Skeleton are responsible for marshalling and
Java/RMI: Internet and e-commerce, portable
unmarshalling. They are automatically generated using the rmic applications
command
The Registry is used to register and access the Server object
(rebind, lookup)
The Activation Interfaces are used to activate components on
demand
32/35 35/35
The COM Architecture Server
Client COM Class
Application
Implementation Layer
Object Interface COM Object Interface COM Presentation
Proxy stub stub Library
proxy Library Layer
SCM SCM Session
Registry Registry Layer
OXID
Microsoft RPCs Object
OXID OXID
Resolver Resolver
The “Presentation” layer is responsible for marshalling and
unmarshalling and create or locate an interface pointer to clients
The Service Control Manager (SCM) is responsible for activation
The OXID is the protocol representing the how to
communication information
33/35