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