Chapter 17: CORBA case study
Download
Report
Transcript Chapter 17: CORBA case study
Chapter 17:
CORBA case study
By Carrie Mace and
William Coley
What is CORBA ?
CORBA is a middleware design
Allows application programs to communicate
without restriction to:
Programming languages
Hardware platforms
Software platforms
Networks they communicate over
Applications and CORBA
Applications are built from CORBA objects
Objects implement interfaces defined in CORBA’s
interface definition language(IDL)
Clients use remote method invocation to access
methods in the interface design language
The Object Request Broker is the middleware
component that supports remote method
invocation
Main Components of
CORBA’s RMI framework
CORBA IDL (Interface Definition Language)
CORBA architecture
GIOP (General Inter-ORB Protocol) defines external data representation
IIOP - defining a standard form for remote
object references
CORBA architecture
Implementation
repository
interface
repository
server
client
request
client
program
Proxy
for A
ORB
core
Or dynamic invocation
ORB
core
object
adapter
skeleton
reply
Or dynamic skeleton
Figure 17.6 from the textbook: The Main Components of the CORBA architecture
servant A
Object Request Broker
Core
Carries out the request-reply protocol
Provides an interface that includes:
Operations enabling start and stop
Operations to convert between remote
objects and strings
Operations to provide argument lists for
references using dynamic invocation
Object Adapter
Bridges the gap between CORBA objects
with IDL interfaces and the programming
language interfaces of the corresponding
servant.
Creates remote object interfaces
Dispatches each RMI to the appropriate
skeleton
Activates objects
Gives each object a unique object name
Skeletons
Classes generated in the language of the
server by an IDL compiler
Unmarshals arguments in requests
Marshals exceptions and replies in
responses
Client stubs/proxies
In the client’s language
Marshals the arguments in invocation
requests
Unmarshals the exceptions and results in
replies
Implementation Repository
Responsible for activating registered servers
on demand
Locates servers currently running
Uses the object adapter name to refer to
servers when registering or activating them
Implementation Repository entry:
Object adapter name
Pathname of object
implementation
Hostname and port number
of server
Interface Repository
Provides information about registered IDL
interfaces to clients and servers that
require it
Not required if static invocation is used for
client stubs and server skeletons
Not all Object Request Brokers provide an
interface repository
Dynamic Invocation
Interface
Used when not practical to use proxies
Client may not have the appropriate proxy
class to invoke a remote service
The client can obtain from the interface
repository the needed information to
construct an invocation
Dynamic Skeleton
Interface
Allows the CORBA object to accept
invocations when a skeleton doesn’t exist
Perhaps the interface was unknown at
compile time
Inspects the request for target object,
method to be invoked, and arguments
CORBA architecture
Implementation
repository
interface
repository
server
client
request
client
program
Proxy
for A
ORB
core
Or dynamic invocation
ORB
core
object
adapter
skeleton
reply
Or dynamic skeleton
Figure 17.6 from the textbook: The Main Components of the CORBA architecture
servant A
CORBA: Interface
Definition Language
Defines modules, interfaces, types,
attributes and method signatures
Same lexical rules as C++
Has additional keywords to support
distribution (i.e. interface, any, attribute,
in, out, inout, readonly, raises)
IDL Modules
Allows interfaces and IDL type definitions
to be organized into logical units
Defines a naming scope
Prevents names defined within a module
from clashing with names defined outside
of it
IDL Interfaces
Describes the methods that are available
in CORBA objects that implement that
interface
Defines a set of operations and attributes
Generally depends on a set of types
defined within it
IDL Methods
General form of a method signature:
[oneway]<return_type><method_name>
(parameter1,…,parameterL)[raises(except1,
…,exceptN)][context(name1,…,nameM)]
IDL Methods Continued
Parameters labeled as in are passed to
the invoked object
Parameters labeled as out are to be
returned to the client
Parameters labeled as inout are seldom
used
IDL Methods Continued
Return type may be void if no value is to be
returned
The expression oneway is optional. Made
with maybe semantics
Indicates client is not blocked
The expression raises is optional
Indicates user-defined exceptions
The expression context is also optional
Supplies mappings from string names to string values
IDL Types
Supports 15 primitive types
Constants can be declared
Special type called Object
values are remote object references
6 constructed types, all passed by value
arrays and sequences used as arguments
must be defined in typedefs
No data type can contain references
Attributes of IDL
interfaces
Attributes are private to CORBA objects
Each attribute declared results in the IDL
compiler generating methods to retrieve and
set the attribute
Attributes can be readonly
Only the retrieve method is generated by the
IDL compiler
IDL interfaces: Inheritance
Extended interfaces can redefine types,
constants, and exceptions
Not allowed to redefine methods
Can extend more than one interface
An interface may not inherit methods or
attributes with common names from two
different interfaces
How Legacy Code is
Handled
Legacy code is existing code designed
without distributed objects in mind
Legacy code can become a CORBA object
by
Defining an IDL interface for the code
Providing implementation of the object
adaptor and skeletons
CORBA Remote
Object References
IOR: Interoperable Object References
Defined in CORBA 2.0
Format:
IDL interface type
Interface repository
identifier
protocol and address details Object Key
adapter
object
IIOP host domain port
name
name
name
number
Transient IORs last as long as the hosting
process.
Persistent IORs last between activations of the
CORBA objects.
CORBA Services
Provide generic facilities that may be
used by a wide variety of applications
Naming Service
Event and Notification Service
Security Service
Transaction and Concurrency Services
Trading Services
Persistent Object Service
Naming Service
Allows names to be bound to the remote
object references
A naming context is the scope within which a
set of names applies
CORBA objects are given hierarchical names,
which cannot be used as pathnames
Allows for the Federation of Naming
Services.
Each server provides a subset of the naming graph
CORBA
Event Service
Defines interfaces allowing objects of
interest to communicate notifications to
subscribers
Event channels: allow multiple suppliers
to communicate with multiple consumers
in an asynchronous manner
CORBA
Notification Service
Extends the CORBA Event Service
Notifications may be data structures
Consumers may use filters
Suppliers may discover what events
consumers are interested in
Possible to configure the properties of a
channel, a proxy, or an event
CORBA
Security Service
Authentication of users and servers
Access controls can be applied to CORBA
objects
Auditing by servers of remote method
invocations
Facilities of non-repudiation
Verifies an invocation was carried out
Trading Services
Allows CORBA objects to be located by
attributes
Database contains mapping from service types
and their attributes to the remote object
reference of CORBA objects
Can form federations that
Use their own database
Can perform queries on behalf of other clients
Concurrency and
Transaction Services
Allows distributed CORBA objects to participate
in flat and nested transactions
RMI calls are introduced with begin, commit or
rollback
Clients can suspend or resume transactions
Concurrency control services use locks to control
access to CORBA object
Can be used within transactions
Can be used independent of transactions
Persistent Object Service
Suitable for use as a persistent object store for
CORBA objects
Can be implemented using
Files
A Relational Database System
An Object-Oriented Database System
The data store request to the POS can be
implemented by the client or by the CORBA
object
More Information
http://htm4.ee.queensu.ca:8000/ling/corb
a.html
http://www.omg.org/gettingstarted/corba
faq.htm
http://www.cs.indiana.edu/hyplan/kksiaze
k/tuto.html
http://www.cs.wustl.edu/~schmidt/corba.
html