Download - Corba 1
-
8/8/2019 Corba 1
1/96
-
8/8/2019 Corba 1
2/96
2
Early Distributed Computing
Language specific remote procedure calls
- Tightly coupled to protocol
- Tightly coupled to language semantics
- Often highly proprietary Homogenous environment
Typically one to one cardinality
- Not highly scalable
-
8/8/2019 Corba 1
3/96
3
What is CORBA?
Architecture for interoperable distributed computing
- Based on the OMGs Object Management Architecture
Internet Interoperability Protocol (IIOP)
Language mappings (OMG IDL)
Integrated and reusable services
-
8/8/2019 Corba 1
4/96
4
Distributed Object-based Systems
Goal: transparently access remote objects in a distributedsystem
Challenges:
- Ensure semantics of invoking a local object
- Accommodate heterogeneity, e.g., multiple languages, OSes,
Middleware
Object
Client Server
Object
-
8/8/2019 Corba 1
5/96
5
Two Examples
Common Object Request Broker Architecture (CORBA)
- International standard: multiple languages, OSes, vendors
Distributed Common Object Model (DCOM)- MS standard: only MS OSes
-
8/8/2019 Corba 1
6/96
6
CORBA
CORBA is similar in high level concepts to RMI
RMI is basically a simplified form ofCORBA
It Adds:
Cross-platform
Multiple language interfaces
Widely used standard
Allows programs written in various languages to communicate
with each other as would two processes in the same address space.
Features leveraged by clients:
- Invocation transparency- Implementation transparency
- Location transparency
-
8/8/2019 Corba 1
7/96
7
CORBA Architecture
ORB
C++ Object
Client Server
Java Object
IIOPORB
Stub ObjectAdapter
Skeleton
Remote-object: object implementation resides in serversaddress space
-
8/8/2019 Corba 1
8/96
8
Stub
Provides interface between client object and ORB
Marshalling: client invocation
Unmarshalling: server response
ORB
C++ Object
Client Server
Java Object
IIOPORB
Stub ObjectAdapter
Skeleton
-
8/8/2019 Corba 1
9/96
9
Skeleton
Provides iterface between server object and ORB
Unmarshaling: client invocation
Marshaling: server response
ORB
C++ Object
Client Server
Java Object
IIOPORB
Stub ObjectAdapter
Skeleton
-
8/8/2019 Corba 1
10/96
10
Object Adapters
-
8/8/2019 Corba 1
11/96
11
Object Adapters
Generate and interpret object references
Activate and deactivate object implementations
Handle method invocations via skeletons
Basic Object Adapter (BOA)
Portable ObjectAdapter (POA)
-
8/8/2019 Corba 1
12/96
12
Object Adapters
-
8/8/2019 Corba 1
13/96
13
Defines how objects are activated/deactivated
- Initializing server objects:
BOA.obj_is_ready( /* the object ref */ );
Registers the object with the ORB
BOA.impl_is_ready();
Tells the BOA/ORB to begin listening for requests
Basic Object Adapter (BOA)
-
8/8/2019 Corba 1
14/96
14
Portable Object Adapter (POA)
Replaces BOA
- Most commercial implementations still use BOA
Expanded scope of OA to include
- Activation policies
- Threading models
- Object life cycle (transient/persistent)
- Pre/post invocation capabilities
-
8/8/2019 Corba 1
15/96
15
(Portable) Object Adapter(POA)
Register class implementations
Creates and destroys objects
Handles method invocation
Handles client authentication and access control
ORB
C++ Object
Client Server
Java Object
IIOPORB
Stub ObjectAdapter
Skeleton
-
8/8/2019 Corba 1
16/96
16
What is an ORB?
A distributed object bus
Hides transport mechanisms
- Location
- Method invocation- Marshalling
OMG Interface Definition Language
(IDL) provides the language
independent semantics
ORB
-
8/8/2019 Corba 1
17/96
17
Object Request Broker (ORB)
Enables object to transparently make and receive requests andresponses
...like a telephone exchange, providing the basic
mechanism for making and receiving calls
ORB
-
8/8/2019 Corba 1
18/96
18
Object Request Broker (ORB)
Abstracts remote request and response mechanisms
Transport fordistributingmethod invocations
ORB
Object ImplementationClient
RequestRequest
-
8/8/2019 Corba 1
19/96
19
ORB Usage
ORB is a singleton
ORB initialization
- Single static call to init() an ORB
- After initialization, you register objectswith the ORB using an Object Adapter
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();
-
8/8/2019 Corba 1
20/96
20
Proxy-based Invocation
ORB
SkeletonStub
RequestRequest
Client Object Implementation
RequestRequest
-
8/8/2019 Corba 1
21/96
21
ORBAbstraction
How is this possible in a heterogeneous environment?
ORB
Object ImplementationClient ??JavaJava C++C++
IDLIDL
JavaJava C++C++
IDLIDL
-
8/8/2019 Corba 1
22/96
22
Object Request Broker ...
Communication infrastructure sending messages betweenobjects
Communication type:
- GIOP (General Inter-ORB Protocol)
- IIOP (Internet Inter-ORB Protocol) (GIOP on TCP/IP)
ORB
C++ Object
Client Server
Java Object
IIOPORB
Stub ObjectAdapter
Skeleton
-
8/8/2019 Corba 1
23/96
23
ORB and IIOP
The IIOP is a protocol by which ORBs communicate
-
8/8/2019 Corba 1
24/96
24
Internet Inter ORBProtocol (IIOP)
Transport protocol
- Defines inter ORB communication
- Runs on top of TCP/IP
- Defines CORBA messages
IIOP is a specification
- Vendors must implement to be CORBA-compliant
- Allows for multi-vendor interoperability
-
8/8/2019 Corba 1
25/96
25
CORBA Object
Server
Interface
IDL
C++/Java
Implementation
Interoperable Object ReferenceCORBA
Object
Servant
-
8/8/2019 Corba 1
26/96
26
Interoperable Object Reference (IOR)
Uniquely identifies an object (see object references)
Server
InterfaceIDL
C++/JavaImplementation
Interoperable Object ReferenceCORBA
Object
Servant
-
8/8/2019 Corba 1
27/96
27
Interface Definition Language (IDL)
Describes interface
Language independent
Client and server platform independent
Server
Interface
IDL
C++/Java
Implementation
Interoperable Object ReferenceCORBA
Object
Servant
-
8/8/2019 Corba 1
28/96
28
IDL (cont)
In RMI we had an RMI compiler run on the .class file wewanted to be remote. Its more complex underCORBA
The interface is written in Interface Definition Language,IDL. IDL is language-neutral (by being a different languagethan anything else) though highly reminiscent of C++(multiple inheritance, similar syntax, etc.)
IDL has a set of primitive data types similar to mostlanguagesinteger, float, string, byte, etc.
-
8/8/2019 Corba 1
29/96
29
Overall CORBA Architecture
ORB
Client Server
IIOPORB
Stub ObjectAdapter
Skeleton
C++ Object IDL Java Object
Implementation
repository
Interface
repository
Implementation repository
activates registered servers on demand and locates running servers
uses the object adapter name to register and activate servers
Interface repositoryinterface repository provides information about registered IDL interfaces to clientsand servers that require it.
-
8/8/2019 Corba 1
30/96
-
8/8/2019 Corba 1
31/96
31
Development Steps
1 write the IDL file
2 compile with idltojava (stubs/skeleton generated automatically)
3 write object implementation (servant)
4 write client application
steps:
1
Stub Skeleton
Client Application Object Implementation
ORB ORB
request
response
IDL
idltojava
2
3
2
4
-
8/8/2019 Corba 1
32/96
32
Example ofCORBA Services
Naming: Keeps track of association between objectnames and their reference. Allows ORB to locatereferenced objects
Life Cycle: Handles the creation, copying, moving,and deletion of objects
Trader:A yellow pages for objects. Lets you findthem by the services they provide
Event: Facilitates asynchronous communicationsthrough events
Concurrency: Manages locks so objects can s
hareresources
Query: Locates objects by specified search criteria
-
8/8/2019 Corba 1
33/96
33
CORBAservices are the baseline services available to allobjects sitting on the ORB communication bus.
1. Naming Service
2. Event Management Service
3. Life Cycle Service
4. Persistent State Service
5. Transaction Service
6. Concurrency Service
7. Relationship Service
8. Externalization Service
9. Query Service
10. Licensing Service
11. Property Service
12. Time Service
13. Security Service
14. Notification Service
15. Trader Service
16. Collections Service
-
8/8/2019 Corba 1
34/96
34
Corba Services
Service Description
Collection Facilities for grouping objects into lists, queue, sets, etc.
Query Facilities for querying collections of objects in a declarative manner
Concurrency Facilities to allow concurrent access to shared objects
Transaction Flat and nested transactions on method calls over multiple objects
Event Facilities for asynchronous communication through events
Notification Advanced facilities for event-based asynchronous communication
Externalization Facilities for marshaling and unmarshaling of objects
Life cycle Facilities for creation, deletion, copying, and moving of objects
Licensing Facilities for attaching a license to an object
Naming Facilities for systemwide name of objects
Property Facilities for associating (attribute, value) pairs with objects
Trading Facilities to publish and find the services on object has to offer
Persistence Facilities for persistently storing objects
Relationship Facilities for expressing relationships between objects
Security Mechanisms for secure channels, authorization, and auditing
Time Provides the current time within specified error margins
-
8/8/2019 Corba 1
35/96
35
CORBA vs. RMI
CORBA RMIPlatform independent JVM specific
Protocol independent
(IIOP)
Proprietary protocol
(JRMP)
Language
independent (IDL)
Java specific
Objects by value
(3.0)
Objects by value
(serialization)
-
8/8/2019 Corba 1
36/96
36
RMI Deployment
Object Implementation
Stubs Skeletons
Interface
DefinitionImplementation
Installation
Client
-
8/8/2019 Corba 1
37/96
-
8/8/2019 Corba 1
38/96
38
CORBA Features
Language independence
Location transparency
Reuse of facilities & services
OMG IDL defined interfaces
Stub & Skeleton generation
Server activation
-
8/8/2019 Corba 1
39/96
39
CORBAResources
Object Management Group (OMG)- www.omg.org
- www.corba.org
Discussion groups- comp.object.corba
- comp.lang.java.corba
Implementers- Inprise: www.inprise.com
- Iona: www.iona.com
- Sun: java.sun.com/products/jdk/1.2/
-
8/8/2019 Corba 1
40/96
40
Creating a CORBAObject
Initialize ORB and BOA
Instantiate the object
Export the object
- BOA.obj_is_ready()
Optionally register the object
- NamingContext.rebind()
Tell the ORB to begin receiving requests
- BOA.impl_is_ready()
bli t ti id i (St i [] ) {
-
8/8/2019 Corba 1
41/96
41
Activating the QuoteServerpublic static void main(String[] args) {
try {// Initialize object request brokerORB orb = ORB.init(args, null);
// Initialize basic object adapterBOA boa = orb.BOA_init();
// Create a new QuoteServer ...QuoteServer quoteServer = new QuoteServer();
// ... and export the objectboa.obj_is_ready(quoteServer);
// Object Request Broker InitializedSystem.out.println (QuoteServer ORB
initialized");
// Wait for incoming requestsboa.impl_is_ready();
} catch (SystemExcpetion e) {
-
8/8/2019 Corba 1
42/96
42
Accessing a CORBAObject
ORB uses Interoperable Object References (IORs)
Object might be local, client usesproxy
Client must acquire first object reference- Naming/Trading service
- Proprietary bind
- Proprietary URL service
- Some other proprietary means
-
8/8/2019 Corba 1
43/96
-
8/8/2019 Corba 1
44/96
44
Using a CORBAObject
Initialize the ORB on the client
Get a reference to the remote object
- IOR
-A
ctual reference (e.g. from bind()) Invoke methods
-
8/8/2019 Corba 1
45/96
45
Accessing the QuoteServer
// Create an object request brokerORB orb = ORB.init(args, null);// Obtain object reference for name service ...org.omg.CORBA.Object object =
orb.resolve_initial_references("NameService");// ... and narrow it to a NameContextNamingContext namingContext = NamingContextHelper.narrow(object);// Create a name component array
NameComponent name[] = { new NameComponent(QuoteServer","") };// Get a QuoteServer object reference ...org.omg.CORBA.Object objectReference = namingContext.resolve(name);// ... and narrow it to get a QuoteServerQuoteServer quoteServer = QuoteServerHelper.narrow(objectReference);// invoke methods on referenceQuote noveraQuote = quoteServer.getQuote(MCTR);
-
8/8/2019 Corba 1
46/96
46
Technical/Architectural Overview
CORBA facilities come in two groups:
1. horizontal facilities
target client-side functionality
2. vertical facilities
target domain-specific functionality
T h i l/A hit t l O i
-
8/8/2019 Corba 1
47/96
47
Technical/Architectural Overview(cont.)
Horizontal facilities specifications:
1. Mobile Agents Facility
2. Printing Facility
3. Internationalization Facility
Vertical facilities domain-specific services are beingdeveloped for various business areas:
1. Common Enterprise Models
2. Finance/Insurance
3. Electronic Commerce4. Manufacturing
5. Healthcare
6. Telecommunications
T h i l/A hit t l O i
-
8/8/2019 Corba 1
48/96
48
Technical/Architectural Overview(cont.)
7. Transportation
8. Life Science Research
9. Utilities
10. C4I (Command, Control, Communications, Computers, and
Intelligence)
11. Space
T h i l/A hit t l O i
-
8/8/2019 Corba 1
49/96
49
Technical/Architectural Overview(cont.)
CORBAfacilities
Obj
Obj
i
li
i
i
CORBAfacilitiesC
!
ili
i
N
#
#
i$
#
i
i
i
li
i
#
i
i
i
i
%
i$
l
ili
&
i
'
l
i
i
Object Management Architecture reference
model.
-
8/8/2019 Corba 1
50/96
50
CORBA Basics
I( )
J0
1
0
m o d u l e p a c k a g e
in te r a ce in te r a ce
s t ruc t c l ass
cons t pub l i c s t a t ic i na l
boolean boolean
c h a r c h a r
c h a r c h a r
oc t e t oc t e t
s tr in g a v a .l an g . t ri n gs tr in g a v a .l an g . t ri n g
sh o r t sh o r t
u n s i g n e d sh o r t sh o r t
l o n g i n t
u n s i g n e d l o n g i n t
l o n g l o n g l o n g
u n s i g n e d l o n g l o n g l o n g
loat loat
d o u b l e d o u b l eixed ( o t s p p orte i i d l j ) j a v a . m a t h . B i g D e c i m a l
se q u e n c e [] (array )
[ ] (array ) [] (array )
Fi . 6 .9 I2 3
k4 5
6
7
r8
s, t5 9 4
s@ A 8
t h4
irB @ 9 9
iA C
s t7
J@
D
@
k4 5
6
7
r8
s.
-
8/8/2019 Corba 1
51/96
51
CORBA Basics (cont.)
Method call types:
- synchronous
client makes call on remote blocking method
standard method call on remote service
client makes call on remote non-blocking method
remote method qualified withoneway modifier in IDL file
remote method receives only in arguments
- asynchronous
client makes synchronous call on remote method, remoteservice responds at a later time by calling method on client
must be qualified withoneway to prevent deadlock
-
8/8/2019 Corba 1
52/96
52
CORBA Basics (cont.)
E
liF G
tH
F
rI F
r
P . registerClient( this )
2. clent.endMessage()Q
liR S
tT S
U
sR
rV R
rT
rR
S W X
U
R T
U
lW
ckR
U
.
Deadlock caused by client calling a server that calls the client.
-
8/8/2019 Corba 1
53/96
53
Distributed Exceptions
CORBA specifies two exception types:
1. System Exceptions
defined for use by CORBA infrastructure
2. User Exceptions
defined using IDL by developers
Standard CORBA exceptions map to Java exceptions asfinal classes.
-
8/8/2019 Corba 1
54/96
54
Case Study: Chat
Chat is a basic network application using a centralbroadcasting point where a collection of clients pushes inmessages and the middleware pushes out messages.
Following use cases:
1. Connect: A client finds and connects to a chat server.
2. Disconnect: A client completes a chat session bydisconnecting from the chat server.
3. Send message: A connected client creates a chat messageand gives the message to the chat server.
4. Receive message: A connected client receives messagesdelivered by the chat server.
-
8/8/2019 Corba 1
55/96
55
Static Invocation Interface (SII), Dynamic InvocationInterface (DII) and Dynamic Skeleton Interface (DSI)
Two ways to invoke a request:
1. statically using Static Invocation Interface (SII)
relies on creating a request through invoking a static method ina stub
stub generated from compile-time definition of an object type(IDL interface) and object operations (methods within IDLinterface)
2. dynamically using Dynamic Invocation Interface (DII)
programmatically creates and send invocation request directlyto ORB without assistance of stub
developers responsible for guaranteeing sending proper typeand number of arguments to invocation
Server unaware of process that created the request.
Static Invocation Interface (SII) Dynamic Invocation
-
8/8/2019 Corba 1
56/96
56
Static Invocation Interface (SII), Dynamic InvocationInterface (DII) and Dynamic Skeleton Interface (DSI)
(cont.)
Interface Repository (IR)
- contains descriptive information about distributed objects:
modules available
interfaces defined
names of operations defined within interfaces argument types
return types
exceptions raised
Steps needed to make DII call:
1. Obtain object reference to server object2. Look up desired method in Interface Repository
3. Build argument list using IRs OperationDef
4. Create and initialize Request object
5. Invoke Request and wait for call to unblock (return)
6. Get results
-
8/8/2019 Corba 1
57/96
57
BOAs, POAs and TIEs
Object adapter- stands between a distributed object and its ORB
- enables clients to access ORB services:
IOR generation
security activation/deactivation
OMG specified two adapter types: Object Management Group The OMG was formed in 1989 by a group of
vendors with the aim of creating a standard architecture for distributed objectsin networks.
- Basic Object Adapter (BOA)
vague definition of an adapter which led to inconsistenciesbetween different vendors implementations
- Portable Object Adapter (POA)
more widely used, even though more complex than BOAs
-
8/8/2019 Corba 1
58/96
58
BOAs, POAs and TIEs (cont.)
POA connects an object reference to developer-writtencode using code found in IDL generated skeleton.
- allow fine-grained control
Distributed objects inherit from a POA base definitiongenerated by IDL compiler
- enables distributed object to be usable by a POA,
- enables POA to control all access to servant through policies
-
8/8/2019 Corba 1
59/96
59
BOAs, POAs and TIEs (cont.)
POA policies:
- ImplicitObjectActivation ,
tells POA outside object created servant and activated it
- IDAssignmentPolicy, and
determines who is responsible for assigning a unique ID to agiven servant
- RequestProcessingPolicy.
uses object id either to find matching servant or invoke defaultservice that uses object id to perform lookup in database
Policy combinations provide POAs with fine-grained controlover one or many servants.
-
8/8/2019 Corba 1
60/96
60
BOAs, POAs and TIEs (cont.)
Another way for developer to us a POA is to wrap theirservants in a TIE.
- enables interaction with a POA without having servants objectimplementation inherit structure from POAImpl.
- servant can inherit from other base classes freely
-
8/8/2019 Corba 1
61/96
61
CORBA services
CORBAservices define base services and a supportstructure useful to a wide range of applications.
Five most commonly used services:
1. Naming Service
2. Security Service
3. Object Transaction Service
4. Persistent State Service
5. Event and Notification Services
-
8/8/2019 Corba 1
62/96
62
Naming Service
Associates name objects with arbitrary value (known asname bindings).
A path to a name binding consists of zero or more namingcontexts (a collection of unique name bindings).
Resolvinga name binding returns object associated withname.
Bindinga name creates association between a name andan object.
Multiple name bindings can point to a single object.
-
8/8/2019 Corba 1
63/96
63
Security Service
Consists of two levels
- Level 1
provides basic security for
1. user authentication,
2. invocation security, and
3. availability of authentication principals to security-awareapplications
allows applications to ignore system-security requirements
requires support forno delegation and single delegation
models
-
8/8/2019 Corba 1
64/96
-
8/8/2019 Corba 1
65/96
65
Object Transaction Service
Enables CORBA objects to execute as parts of distributedtransactions.
- a transaction describes a collection of interactions where multipleusers may access and/or modify data.
acronym ACID describes four standard requirements forreliable transactions:
1. Atomic completion of numerous steps must be conductedas one, otherwise each step must be undone.
2. Consistent effects of transaction are repeatable andpredictable.
3. Isolated transaction not interrupted from outside and givesno indication if execution is proceeding serially orconcurrently.
4. Durable transaction results are persistent.
-
8/8/2019 Corba 1
66/96
66
Object Transaction Service (cont.)
- transactions complete in one of two ways:
1. committed
changes are made to persist
2. rolled back
changes made to data are discarded
- POAs dictate transaction types supported by servants
shared transactions
unshared transactions
shared and unshared transactions
-
8/8/2019 Corba 1
67/96
67
Object Transaction Service (cont.)
Concepts of transactional clients, transactional objects andrecoverable objects define the OTS.
- transactional clients interact with OTS to create and commit orrollback a transaction
- transaction objects behaviors vary when invoked within atransaction (objects data not recoverable)
- recoverable object is a transactional object in which data isrecoverable (maintain their data and capable of restoring their loststate)
Java Transaction Service (JTS) is Java implementation ofdistributed transaction service
- uses CORBA OTS specification to define protocol
-
8/8/2019 Corba 1
68/96
68
Persistent State Service
PersistentState Service (PSS) stores and retrievesobjects.
Abstracts interaction between objects and datastores.
PersistentState Definition Language (PSDL) defines adistributed object schema in a portable fashion.
- PSDL is a superset of IDL
defines two new constructs
storagetype
storagehome
-
8/8/2019 Corba 1
69/96
69
Persistent State Service (cont.)
- contains two definition types:
abstract definition
define portable definition of the persistable state of a CORBAobject
concrete definition
-
8/8/2019 Corba 1
70/96
70
Event and Notification Services
EventService defines mechanism that decouples deliveryof events (messages) from source of events.
- no predefined event types in specification
- keeps track of action events and event listeners
Suppliercreates events that are processed by a consumer.
Inpush model, supplier sends event messagesasynchronously to all consumers registered to receivemessages.
Inpull model, consumer polls supplier for events.
Event and Notification Services
-
8/8/2019 Corba 1
71/96
71
Event and Notification Services(cont.)
Notification Service is a direct extension of the EventService.
- objects can create and destroy event channels arbitrarily, and canfilter output using Filter Objects and Object Constraint Language
Event and Notification Services
-
8/8/2019 Corba 1
72/96
72
Event and Notification Services(cont.)
Standard flow of a StructuredEvent:
1. finding object reference to Notificaion Service (instance ofEventChannelFactory)
2. EventChannelFactory creates an EventChannel
3. supplier asks EventChannel to return SupplierAdminobject
4. SupplierAdmin returns a Consumer proxy (such asStructuredProxyPushConsumer) to an event channel
5. access to distributed events (through push or pull models) is
accessible throug
hproxy
Event and Notification Services
-
8/8/2019 Corba 1
73/96
73
Event and Notification Services(cont.)
ProxySupplier
Co nsum er
EventChannel
ProxyConsumer
Supp lier
Co nsum erSupp lier
Co nsum er
Supp lier
EventChannel
Even t
Eve nt
Even t
Even t
Event
Event
Even t
C onc ep tually, a Sup plie r send s a n Event to a C onsume r.
An EventChannel dec o up les the Supp lier from the Consum er.
Adding a ProxyConsumera nd ProxySupplier ena bles further dec ouplinga nd m akes it p ossible to sup po rt bo th the push and pull models.
Supplier-to-consumer flow using the Event/Notification Service.
-
8/8/2019 Corba 1
74/96
74
EJBs and CORBA components
CORBA Component Model (CCM) Request for Proposal(RFP) recommends the JavaBeans component model asbasis of a server-side framework.
CORBAcomponents based on Component Implementation
Framework (CIF) architecture.
CIF defines superset ofPersistent State DefinitionLanguage called Component IDL (CIDL)
CIDL is component model forCORBA objects and a
container-programming model where CORBA componentsexist at runtime
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
75/96
75
EJBs and CORBAcomponents(cont.)
ID L key w ords to sup p or t t h e C O RBA
C o m p o n e n t M o d e l ( C C M )
component home provides
consumes import setRaises
emits local supports
finder mu ltiple typeId
getRaises primaryKey typePrefix
Fig. 27.4 IDL keyw ords to sup p ort th e C O RBA C o m p o n e n t M o d e l.
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
76/96
76
EJBs and CORBAcomponents(cont.)
Component Interface Definition Language (CIDL) is asuperset ofPersistent State Definition Language.
- defines
components in a way that enables automatic generation of
components persistence code. component implementation
state management
- compiled with a CIDL compiler
Developers organize components as an assembly with adescriptor.
- describes how components are deployed
- extension ofOpen Software Description (OSD) Format
-
8/8/2019 Corba 1
77/96
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
78/96
78
p(cont.)
Four areas make up CCM container programming model:
1. External types
interfaces seen by client wanting to communicate withcomponent
2. Container types API component uses to communicate with runtime container
3. Container Implementation types
different containers have different relationships with surroundingsystem. Three types: stateless, conversational, and durable.Each type defines its system support
4. Component Category
where a component fits in overall framework
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
79/96
79
p(cont.)
Using a containers internal interfaces, a component hasfull access to services a container supports
- Container defines APIs for:
component security
persistence
transactions
events
lifecycle
- Component implements call-back interfaces to allow container-to-component communication.
-
8/8/2019 Corba 1
80/96
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
81/96
81
p(cont.)
Y
a b
c
d
c t Te
b
d
fd
sc r i b t i
c
S e r v i c e g
o e s n o t m a i n t a in s t a t e i nh
o r m a t io n ( c o m p l e t e l y s t a t e le s s )
g
o e s n o t h a v e a u n i q u e i d ( p r i m a r y k e y )
I m p l e m e n t s n e e d e d b e h a v io r
( e . g . , c a l c u l a t e I n t e r e s t ,
a d d I t e m T o S h o p p in g C a r t , e t c . )
i
a n u s e t r a n s a c t i o n s , i s n o t i n c l u d e d i n t h e c u r r e n tt r a n s a c t i o n
S e s s i o n p
a i n t a i n s i n t e r n a l - s t a t e inh
o r m a t i o n
q
a s a u n i q u e i d t h a t i s u s a b l e o n l y b y i ts c o n t a i n e r
I m p l e m e n t s n e e d e d b e h a v i o r
i
a n u s e t r a n s a c t i o n s , b u t i s n o t i n c l u d e d i n t h e c u r r e n t t r a n s a c t io n
p
a p s t o S e s s io n E Jr
s
E n t i t y i
o n t a i n e r - o r c o m p o n e n t - m a n a g e d p e r s i s t e n t s t a t e
q
a s a u n i q u e i d ( p r im a r y k e y )
I m p l e m e n t s n e e d e d b e h a v i o r t h a t i s o p t i o n a l l y t r a n s a c t i o n a l
p
a p s t o E n t i t y E Jr
s
s
r o c e s s i
o n t a i n e r - m a n a g e d o r c o m p o n e n t - m a n a g e d p e r s i s t e n t s ta t e th a t is i n a c c e s s i b l e t o
c l i e n t s
i
o n t a in e r - m a n a g e d o r c o m p o n e n t - m a n a g e d p e r s is t e n c e oh
t h e c o m p o n e n t s
p r i m a r y k e y ( i d e n t i t y) t i t h v i s i b i l i t y o h t h e p r im a r y k e y t h r o u g h u s e r - d e h i n e dm e t h o d s
I m p l e m e n t s n e e d e d b e h a v i o r a n d t h e b e h a v i o r i s o p t i o n a l l y t r a n s a c t io n a l
Fi . .5 C O R B A c u v w u x y x t t w y s x
y
s c r iw
t iu x
s.
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
82/96
82
p(cont.)
Activation andpassivation are actions around invocationboundaries of an object operation.
- activation lifecycle
1. request arrives to ORB to invoke operation on object
2. ORB sends request to POA3. POA sends request to container managing component
4. container activates object
- passivation policies defined by components deploymentinformation
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
83/96
83
p(cont.)
In distributed systems, clients dont create remote objects.Clients discoverremote objects.
- discovery through file containing objects IOR
- discovery throughNaming Service
Factories (ComponentHome instances) of remote systemscreate objects for their corresponding systems.
- component definition must define component factory
- if component persistent, must define findmethod usingcomponents primary key
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
84/96
84
p(cont.)
CORBAcomponents use subset ofCORBAservices forComponentImplementation Framework.
- Security Service
every component may have own security requirement
defined in components deployment descriptor
container must keep track of active policies and apply them
- Object Transaction Service (lite version)
container can control transaction boundaries
component can control transaction boundaries
- Persistent State Service
container-managed persistence, PSS transparent to component
not ideal for all situations
component-managed persistence, should still use PSS to save state
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
85/96
85
(cont.)
- Notification Service
accessed indirectly
container mediates use of event service by component
container does not preclude direct use ofNotification Service
component developers are encouraged to define events in IDL asway of keeping components functional description in one location
keywords:
publishes
any number of consumers can subscribe to an event
methods declared with publishes expected to be part ofshared interface of component
emits
only one consumer can subscribe to an event
expected to be private channel used internally by system
EJBs and CORBAcomponents
-
8/8/2019 Corba 1
86/96
86
(cont.)
CCM and EJB models are similar.
CCM specification defines two component levels
- basic
mirrors EJB model almost exactly
single threaded
uses security, transaction and persistence services only
exposes only single interface
- extended
can expose multiple interfaces advanced store types allows components to be properly
persisted
supports use of Event Services
Sun and OMG worked closely to ensure EJB model is
CCM architecture subset.
-
8/8/2019 Corba 1
87/96
87
CORBA vs. RMI
CORBA is comprehensive view of distributed systemsarchitecture.
RMI describes only communication proxies and protocolsbetween client object and server object.
-
8/8/2019 Corba 1
88/96
88
When to Use RMI
RMI suitable for smaller distributed applications in whichscalability, architecture, heterogeneity, and extensibility arenot major concerns.
Mapping of RMI and RMI capabilities to OMA
encompasses only Applications Objects and the ORB. RMI does not define Quality of Service or asynchronous
invocations.
RMI does not offerPOA or range of control offered byP
OA. RMI has dynamic class loading. CORBA places
implementation burden on clients.
-
8/8/2019 Corba 1
89/96
89
When to Use RMI (cont.)
RMI allows objects to participate in distributed systemsconsistently and predictably.
RMI is a natural choice for distributed systems built inJava.
A pure Java-distributed system needs to be consideredfrom an architectural perspective where distributed issuescan be discovered and resolved before the implementationissues are decided.
-
8/8/2019 Corba 1
90/96
90
When to Use CORBA
CORBA defines and provides implementations to manycommon requirements for most complex distributedsystems:
- architecture
- Quality of Service (QoS)- Scalability
- Heterogeneity
- Extensibility
-
8/8/2019 Corba 1
91/96
RMI IIOP ( )
-
8/8/2019 Corba 1
92/96
92
RMI-IIOP(cont.)
- runtime limitations:
sending a tree graph from ORB to ORB may be problematic ifmultiple nodes point to one object
CORBA does not define distributed garbage collection
Casting stubs may not work properly, so using the static methodnarrow of class java.rmi.PortableRemoteObject isencouraged.
RMI downloads the stubs needed by client, CORBA does not.
RMI IIOP ( t )
-
8/8/2019 Corba 1
93/96
93
RMI-IIOP(cont.)
- steps involved in writing distributed application using RMI-IIOP:
use javax.rmi.PortableRemoteObject instead of usingjava.rmi.UnicastRemoteObject
use JNDI (Java Naming andDirectory Interface) instead of RMIRegistry
do not downcast remote objects to subclass types; use methodnarrow of class PortableRemoteObject to cast distributedobjects as subclass types
RMIMessengerCase Study Portedt RMI IIOP
-
8/8/2019 Corba 1
94/96
94
to RMI-IIOP
Porting RMI messenger example (Chapter 13) to RMI-IIOP is easier than porting application to CORBA.
- remote interfaces remain same
- support classes remain same
- new implementations for
ChatServer remote interface (ChatServerImpl),
ChatServerAdministrator
MessageManager interface (RMIIIOPMessageManager)
DeitelMessenger
ChatServer RMI-IIOPI l t ti
-
8/8/2019 Corba 1
95/96
95
Implementation
ChatServerImpl
- implements ChatServer remote interface
subclass of class javax.rmi.PortableRemoteObject
- does not implement method register
- handles registration with name services
F t Di ti
-
8/8/2019 Corba 1
96/96
Future Directions
OMA guiding document forCORBA systems
- falls short in average-size systems
CORBA Component Model
- abstracts system issues through programming constructs:
containers
subsystems
CORBA working on architectural process
- Model Driven Architecture (MDA)
Expansion of OMGs architecture- maintains compatibility with previous embodiments
- gives new vitality to OMG