p.11 OMA = Object Management Architecture (an OMG spec)
Object Model - how to describe distributed objects
Reference Model - characterizes interactions between objects
interface categories:
Object Services
Domain Interfaces
Application Interfaces
p.14 list of basic definitions
for one request a client can use a "static stub" or DII = Dynamic Invocation Interface
server "servant" can use IDL-generated skeleton or DSI = Dynamic Skeleton Interface
p.17 styles of request:
synchronous
deferred synchronous (DII only)
oneway
(future, maybe) asynchronous
p.18 Short IDL sample. Interface inheritance. There is a Corba-defined "Object" interface from which all interfaces implicitly inherit
p. 20 Operation invocation and dispatch
The local C++ client-side object that supports stub functions is called a proxy (but see p. 31).
The "interface repository" is a service that provides runtime access to idl definitions
p. 21 "Object adapters serve as the glue between servants and the ORB"
They create object references
They ensure that each target object is incarnated by a servant
They take requests dispatched by an ORB and direct them to a particular servant
C++ servants are classes derived from a skeleton
p.22 Problems with BOA. "BOA spec has been removed from CORBA"
p.23 GIOP and IIOP (GIOP over TCP/IP). IOR = "Interoperable Object Reference": hostname + port + object key (but see p. 29)
p.23 Request Invocation process. p. 24 Request Invocation characteristics:
location transparency
server transparency
language independence
implementation independence
architecture independence
OS independence
protocol independence
transport independence
p. 25 Object Reference Semantics: "An object reference is not the same as an object's identity". See sections 7.11.3 and 20.3.2.
p. 28 Reference Acquisition
P. 29 Object Reference = "Repository ID + endpoint info + object key. The first 2 are specified by Corba, the object key is vendor-specified. "multi-component profiles"
p. 31 References and Proxies
p. 33 General steps for building a C++ Corba application:
Define the IDL
Compile the IDL into stubs and skeletons
implement the server objects
write a server main (initialize the orb etc.)
build the server
write and build the client using the generated stubs
all pretty clear - but I don't see how the orb knows how to find the servant. Is there something in the servant's constructor that finds the orb when the servant is created?
Notes 8/26 ch. 4 - IDL
p.51 IDL as abstraction separating interface from implementation; a contract between clients and server
p. 52 purely declarative: object interfaces, operations, exceptions
p. 53 diagram showing the development architecture
p. 54 "federated servers"; OMG concurrency control service; load balancing is not standardized
p. 55 diagram showing development architecture if client and server use different ORBs
p.56 rules for naming & content of idl files; idl preprocessor identical to C++ preprocessor
p. 57 identifier must be declared before used; lexical rules are nearly identical to C++ except identifiers cannot contain a leading underscore and cannot contain non-English letters. Case insensitive, but each identifier must consistent capitalization.
p. 59 table of basic idl types including size constraints
p. 60 "all types except octet are subject to change in representation as they are transmitted between client and server."
p. 61 strings can be defined as bounded, as in "string <10>"
p. 63 typedefs, enums (values cannot be specified).
p. 64 struct, p. 65 unions are different than those in C++
p. 67 using union to implement optional values
p. 68 arrays; p. 69 anonymous types may be banned by a future release.
p. 70 choosing betwen sequences and arrays
p. 71 recursive types
p. 74 constants and literals are identical to C++
p. 78 intro / sample of defining an interface and operations
p. 79 interface syntax : what can be nested inside an interface: const type, exception, attributes, operations
p. 80 an iterface example; example of using qualified names
p. 81 semantics of object references
p. 82 dangers (or poor design) of using "hidden" communication between Corba implementation objects
p. 83 defining operations
p. 84 directional attributes on operation parameters and how they affect memory management
p. 353 generated header file names are not standardized
p. 355- the _this() call 1) creates a Corba object under RootPOA, 2) registers the object with the RootPOA as the implementer, 3) creates an object reference for the object, 4) returns the object reference
p. 356 important - releationship of POA_xx, xx_ptr: POA_xx::_this returns xx_ptr. See the discussion of transient objects here and see the sample main().
p. 362 See sec. 7.14.5 about array slice. MyArray_slice type, MyArray_alloc generated functions
p. 365 CORBA::string_dup() and CORBA::string_alloc and CORBA::string_free
p. 366 Null strings will not be passed to the servant and may not be returned or passed out by the servant.
Books RSS
