Best viewed with the Flash browser: click here!
All + All -CORBA
- + -C++ Language Mapping
- + - client side
- + - interface
- interface maps to abstract classes
- actual proxy classes are subclasses
- + - interface inheritance
- object references can be widened and narrowed
- + - widening
- no type conversion
- no duplication
- + - narrowing
- requires explicit operation that may create a new stub object
- always triggers duplication
- potential remote communication to validate target type
- returns _nil on failure
- + - object references
- local reference counting
- xxx_ptr for pointer-like types
- + - xxx_var for auto-managed references
- constructor invokes duplicate
- destructor invokes release
- can be used like pointers (typically overload operator->)
- CORBA::release(obj)
- xxx::_duplicate to create new object
- implemented by the interface class
- + - lifecycle
- a client never creates object references
- + - a client can get an object reference
- as result/out parameter of operation
- initial reference
- narrowing
- nil reference
- a client keeps references and may duplicate it
- eventually the client releases the references
- + - ORB
- + - ORB_init
- may get cmd line parameters
- + - operations to create stringified object references
- IOR
- corbaloc
- corbaname
- + - ORB_init
- + - operations
- map to member functions with same name
- + - parameter passing
- must consider memory mgmt
- must differ between fixed- and variable-sized types
- must consider parameter directionality
- + - out parameters in general
- _out suffix
- fixed size -> &
- variable size -> T_out performs memory mgmt
- + - passing of simple types
- + - in
- pass by value
- + - out
- passed as _out type
- + - inout
- passed by reference
- + - result
- passed as return value
- + - in
- + - passing of fixed-size types
- goal: avoid copy
- + - in
- pass as const &
- + - out
- as _out type (can also pass _var)
- + - inout
- reference
- + - passing of variable-length string types
- + - in
- const char *
- + - out
- CORBA::String_out
- + - inout
- char *
- + - in
- + - passing of variable-length complex types
- + - in
- const & (to avoid copying)
- + - out
- as _out type
- caller must explicitly deallocate using delete
- + - inout
- references
- + - in
- + - passing of object reference
- + - in
- as _ptr type
- + - out
- as _ptr reference or _var type
- + - inout
- as _ptr reference
- + - in
- + - passing _var types
- + - in
- const _var &
- + - out
- _var type
- + - inout
- _var reference
- + - in
- + - attributes
- map to pair of get/set methods overloaded on attribute name
- + - exception
- mapped to own classes
- + - interface
- + - server side
- the server side mapping is a generalization of the client side mapping
- + - skeleton class for each interface
- class with prefix POA_
- servant classes inherit from skeleton class
- + - ORB initialization steps
- + - 1.Initialize ORB
- CORBA::ORB_init();
- + - 2. get RootPOA
- orb->resolve_initial_references("RootPOA");
- 3. Narrow RootPOA to PortableServer::POA
- + - 4. Obtain servant manager
- poa->the_POAManager();
- + - 5. Activate servant manager
- poa->activate();
- 6. Create servant instance
- + - 7. Activate servant
- servant->_this();
- + - 8. Start ORB mainloop
- orb->run()
- + - 1.Initialize ORB
- + - parameter passing to servants
- + - simple types
- pass by value of reference (depending on direction)
- + - fixed-length complex types
- (const) reference
- _out type for output parameters
- + - strings
- pass as char * or references
- String_out for output
- + - complex types & any
- + - in
- pass by const reference
- + - out
- pass by reference
- use _out type
- + - result
- return pointer
- + - in
- + - object references
- pass _ptr value or reference
- + - simple types
- + - raising exceptions
- throw by value
- catch by reference
- ORB deallocates all in and inout parameters
- + - types
- here you find a node for each IDL construct and a child node for the C++ mapping
- + - module
- namespace
- + - enum
- enum
- dummy values allowed to enforces 32bit enum values
- + - const
- static const (in classes)
- const (outside classes)
- + - primitive types
- + - boolean
- CORBA::Boolean
- + - strings
- + - char
- CORBA::Char
- + - wchar
- CORBA:WChar
- helper functions for allocation, duplication and freeing
- terminated with \0
- + - char
- + - short
- CORBA:Short
- + - float
- CORBA:float
- ...
- + - boolean
- + - variable length types
- + - memory mgmt convention
- producer allocates
- consumer deallocates
- example: results on client side: ORB allocates, caller deallocates
- + - _var types are generated
- wrappers for lower-level mapped types
- manages storage for lower-level type
- generated for both fixed-size and variable-sized types
- example string -> CORBA::String_var
- + - memory mgmt convention
- + - struct
- fixed-length fields are mapped like primitive types
- variable-length fields are mapped to memory-managed classes
- + - sequence
- maps to vector-like type
- + - union
- does not map to C++ unions because they have no discriminator
- union discriminator is set by using one of the access methods
- rw access methods provided for all possible types
- for default case there is a _default() method
- + - client side
- + -CCM
- CORBA Component Model, introduced with CORBA 3
- includes IDL extension (CIDL)
- implementation framework
- container framework
- simplifies state mgmt and persistance
- packaging + deployment specification
- about this mindmap
Creator: Lars Windolf
~ heavily base on a CCM lecture by Martin Löwis (HPI, Uni Potsdam)
last modified: 29.09.2004
- + -IDL
- + - Interface
+ - defines object services
- horizontal services
+ - defines domain interfaces
- vertical services
defines application interfaces
no private/protected possible
smallest unit of distribution
can have exceptions
is a type (can be passed with operations, but passing is always done per reference, valuetypes can used for per value passing)
+ - interfaces can be derived from other interfaces
- but still no function overloading allowed
multiple inheritance allowed
- + - IDL user roles
- IDL developer
- write IDL specification
- server developer
- provides server implementation
- application developer
- implements client application
- IDL developer
- + - Exceptions
- IDL developer can defines new ones
- + - CORBA provides system exceptions
- need not to be defined to be thrown
- can have members like structures
- defines an interface contract between client and server
- compiled by IDL compiler provided with language mapping
- purely declarative
- Java/C++ syntax
- only IDL types can be used for client/server communication
- + - Types
there are a lot of standard types
a struct statement can only define a type and no data, the defined type has to be used anywhere to make any effect
recursive type definitions can only be created by using sequences
- + - Valuetype
creates an interfaces that when used is passed by value and not by reference
to prevent one communcation round-trip per object data access
+ - use cases
- extensible structures
- recursive and cyclic structures
- allows complete implementation of Java RMI with CORBA
needs a factory to create an instance in the receiving ORB, application must register the value factory
receiving ORB must know complete structure
method definitions require local implementations
can be truncatable (receiving ORB omits unknown fields)
can be recursive
can have private fields
value boxes: can be used to create valuetypes from standard types, this is useful for building recursive valuetypes containing standard type fields
- + - Operations
- have a name
- have a return type
- + - can have parameters
- + - parameters have directionality
- in
- out
- inout
- + - parameters have directionality
- can throw exceptions
- can be oneway
- + - can have context clauses
- a feature to pass something similar to Unix environment vars
- no function overloading
- + - Attributes
- cause the generation of set/get operations
- can be read-only (no get operation)
- + - Modules
- to define namespaces
- can be extended
- + - Interface
- + -architecture
- OO RPC's
- + - Object Services
- + - what are object services?
- Object Services are infrastructure services, independent from specific applications.
- Are defined in IDL
- can be implemented independently from a specific CORBA implementation (cf. ORB services)
- + - Naming Service
associates names with object references
can be used instead of IORs to find the "initial" application object
ORB provides standard interface to locate name service : orb->resolve_initial_references("NameService");
+ - binding
- inserting a name
+ - unbinding
- deleting a name
+ - names
- have an id
- have a kind
- a name defines a path relative to the naming context
+ - URLs
- + - corbaloc
- syntax: host,port,object key
- + - corbaname
- string version of name service entry
- syntax: host, default object key, #, path
there where propietary approaches...
+ - and there is INS
- Interoparable Naming Service
- std cmd line -ORBInitRef NameService=...
- shorter URLs
- Trading Services
- Property Service
- + - Event Service
- alternative for call-based client-server architecture
- simple decoupled communication
- 1:n communication possible
- n:n medium may be used
- source of messages does not know consumers
- emitting messages is typically non-blocking
- + - OMG standardized interfaces
- for event consumers and suppliers
- for push and pull communication
- for typed and untyped communication
- also available: event channel interfaces
- + - Notification Service
- extension of Event Service
- (Transactions)
- (Persistency)
- + - what are object services?
- + - interoperability protocols
- CDR (Common Data Representation)
- GIOP (General Inter-ORB Protocol)
- IIOP (Internet Inter-ORB Protocol)
- + - alternative protocols
- + - ESIOP: environment specific
- e.g. DCE-CIOP
- SCCP (Signal Control Part) IOP
- pluggable protocols
- + - ESIOP: environment specific
- + - standard control flow
- + - 1. client sends request
- client ORB analyses object reference
- connects to server if necessary
- sends request
- + - 2. ORB receives request
- activates server
- activates target servant
- invokes method
- sends back reply
- + - 1. client sends request
- + -ORB
- + - POA
- replaces BOA (CORBA 2.1)
- POA interfaces are local
- + - details object activation
- POA has an active object map
- on creation each POA is assigned to a POA manager
- a POA defines a namespace for servants
- + - servant
- implementation object, determines run-time semantics of one or more CORBA objects
- has an ObjectID (unique within a POA)
- can be active or inactive
- + - default servant
- servant associated with all ObjectIDs
- + - etherealization
- the action of detaching a servant from an ObjectID
- + - incarnation
- the action of creating or specifying a servant for a given ObjectID
- object reference needs to be given
- + - activation
- creates object reference
- servant must be given
- + - POA manager
- controls flow of requests for one or multiple POAs
- + - has an activity state
- + - active
- requests are processed
- + - holding
- requests are saved
- + - discarding
- requests are refused with TRANSIENT exception
- + - inactive
- requests rejected
- connections are shut down
- + - active
- + - responsibilities
- assigns object references to servants
- transparently activates servants
- + - assigns policy to servants
- all servants within a POA have the same implementation characteristics (policies)
- the root POA has a standardized set of policies
- determines relevant servant for incoming requests and invokes the requested operation at the servant
- + - object references
- + - consists of
- repository id
- transport address
- + - object key
- POA Name
- ObjectID
- the object key is a specific format for each ORB
- + - consists of
- + - BOA
- deprecated
- + - POA
- + -open, standardized and portable middleware platform
- no more socket programming!
- programming conventions and design patterns
- + - advantages
- vendor independent
- platform independent
- solves repetive tasks for developers of distributed systems
- there are a lot of language mappings
- + - disadvantages
- no reference implementation
- consensus/compromise architecture
- not perfect
- can be overkill
- + -CORBA objects
- have interfaces defined in IDL
- implemented in programming language mapping
- + - objects are accessed through object references
- + - reference
- identifies exactly one object
- more than one reference my refer one object
- is strongly type
- + - references are opaque
- IOR (interoperable object ref) needed to use between incompatible ORBs
- can be "nil" (does not yet refer to an object)
- can dangle (object doesn't exist anymore)
- allows late banding
- maybe persistent
- + - reference
- + -is transparent in terms of
- language
- location
- service
- implementation
- architecture
- operation system
- (protocol)
- (transport)
- + -CORBA 2 vs. 3
- + - in v2 objects are restricted to single interface
- separate service and mgmt interface
- async communication hard to implement
- handling a large number of objects requires significant book-keeping in application
- deployment of applications is difficult
- + - in v2 objects are restricted to single interface