Chapter 17: CORBA case study

1
Chapter 17 CORBA case study

• By Carrie Mace and
• William Coley

2
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

3
Applications and CORBA

• Applications are built from CORBA objects
• Objects implement interfaces defined in CORBAs
  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

4
Main Components of CORBAs 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

5
CORBA architecture
Implementation repository
interface repository
server
client
ORB core
object adapter
request
servant A
skeleton
ORB core
client program
Proxy for A
reply
Or dynamic skeleton
Or dynamic invocation
Figure 17.6 from the textbook The Main
Components of the CORBA architecture
6
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

7
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

8
Skeletons

• Classes generated in the language of the server
  by an IDL compiler
• Unmarshals arguments in requests
• Marshals exceptions and replies in responses

9
Client stubs/proxies

• In the clients language
• Marshals the arguments in invocation requests
• Unmarshals the exceptions and results in replies

10
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
Pathname of object implementation
Hostname and port number of server
Object adapter name
11
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

12
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

13
Dynamic Skeleton Interface

• Allows the CORBA object to accept invocations
  when a skeleton doesnt exist
• Perhaps the interface was unknown at compile time
• Inspects the request for target object, method to
  be invoked, and arguments

14
CORBA architecture
Implementation repository
interface repository
server
client
ORB core
object adapter
request
servant A
skeleton
ORB core
client program
Proxy for A
reply
Or dynamic skeleton
Or dynamic invocation
Figure 17.6 from the textbook The Main
Components of the CORBA architecture
15
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)

16
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

17
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

18
IDL Methods

• General form of a method signature
• onewayltreturn_typegtltmethod_namegt
• (parameter1,,parameterL)raises(except1,,exceptN
  )context(name1,,nameM)

19
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

20
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

21
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

22
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

23
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

24
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

25
CORBA Remote Object References

• IOR Interoperable Object References
• Defined in CORBA 2.0
• Format

protocol and address details
IDL interface type
Object Key
Interface repository identifier
adapter name
object name
host domain name
port number
IIOP

• Transient IORs last as long as the hosting
  process.
• Persistent IORs last between activations of the
• CORBA objects.

26
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

27
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

28
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

29
CORBANotification 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

30
CORBASecurity 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

31
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

32
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

33
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

34
More Information

• http//htm4.ee.queensu.ca8000/ling/corba.html
• http//www.omg.org/gettingstarted/corbafaq.htm
• http//www.cs.indiana.edu/hyplan/kksiazek/tuto.htm
  l
• http//www.cs.wustl.edu/schmidt/corba.html