1 / 10

CORBA Common Object Request Broker Architecture OMG - “Object Management Group”

CORBA Common Object Request Broker Architecture OMG - “Object Management Group” OMG, a group of about 500 organisations (see www.omg.org) promotes standards for inter-operation of object-oriented systems, across boundaries of Operating Systems, Networks, Programming languages.

casper
Download Presentation

CORBA Common Object Request Broker Architecture OMG - “Object Management Group”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CORBA Common Object Request Broker Architecture OMG - “Object Management Group” OMG, a group of about 500 organisations (see www.omg.org) promotes standards for inter-operation of object-oriented systems, across boundaries of • Operating Systems, • Networks, • Programming languages. http://csiweb.ucd.ie/staff/acater/comp30150.html

  2. RPC - Remote Procedure Call RMI - Remote Method Invocation ORB - Object Request Broker OQL - Object Query Language ODMG - Object Data Management Group ODMG-93 = -1.0; ODMG-2.0 standards OMA - Object Management Architecture ODL - Object Definition Language IDL - Interface Definition Language GIOP - General Inter- ORB Protocol IIOP - Internet Inter- ORB Protocol DII - Dynamic Invocation Interface DSI - Dynamic Skeleton Interface BOA - Basic Object Adapter http://csiweb.ucd.ie/staff/acater/comp30150.html

  3. RMI is an OO extension of RPC, that provides a generic communication mechanism allowing objects on different computers to interact transparently. • Client objects use server object stubs; • Server objects and their stubs each depend on local RMI runtime support for the underlying message passing. http://csiweb.ucd.ie/staff/acater/comp30150.html

  4. RMI is an OO extension of RPC, that provides a generic communication mechanism allowing objects on different computers to interact transparently. • Client objects use server object stubs; • Server objects and their stubs each depend on local RMI runtime support for the underlying message passing. http://csiweb.ucd.ie/staff/acater/comp30150.html

  5. Manually creating stubs is pointless, direct message-passing is just as easily programmed. But automated stub generation, from object interface definitions, does simplify programming. It can be done • by extending an existing HLL, or • by using a platform-independent language-independent IDL, with compilers producing stubs for all languages and all platforms. OMG promotes CORBA, which defines • a particular IDL, • ORB - the RMI runtime support, • Inter-ORB communication protocols. http://csiweb.ucd.ie/staff/acater/comp30150.html

  6. An ORB is basically a process running on a computer, which provides services to other processes on the same machine and to other ORBs on different machines. The CORBA IDL has elements • Operations: essentially method declarations. • Their parameters have {in, out, inout} modes, • An operation may or may not be "oneway", - returning no result, having no out or inout parameters • Exceptions • Standardised data types • basic types (long, float, char etc) • constructed types (string, array, seq etc) • Attributes (may be read-only) • Modules (for namespaces) http://csiweb.ucd.ie/staff/acater/comp30150.html

  7. An IDL compiler generates, for a particular HLL-OS-Platform combination: • a header file, for use by implementations of client & server objects • a stub, for use by client object • an object-definition skeleton, needing to be turned into an object implementation by further programmer effort. Stubs provide static methods that can be invoked by a client object, these methods will communicate transparently with the local ORB. That local ORB will if necessary find a remote server ORB (possible because objects "register" their identity and their interface with an ORB, using its Interface Repository). The server ORB invokes the methods of the server object, and provides other services to it (eg registering, timeouts) via an "object adapter". http://csiweb.ucd.ie/staff/acater/comp30150.html

  8. CORBA demands that ORBs implement a standard BOA; an OO Database Adapter standard is also proposed. Interface Repository API provides DII (Dynamic Invocation Interface) ability - with which a client object may dynamically discover objects & their methods, and invoke those methods, using metadata. Server ORB uses DSI (Dynamic Skeleton Interface) ability for dynamic objects with no static skeleton. http://csiweb.ucd.ie/staff/acater/comp30150.html

  9. The OMA (Object Management Architecture) is a collection of standard but optional object interfaces, built on top of a CORBA core, providing • CORBAservices - system-level services for standardising the lifecycle of objects: such as object naming, object creation, object relocation, controlling access to objects • CORBAfacilities - higher-level services - categorised as • "horizontal" generic facilities useful across many domains - eg printing • "vertical" facilities useful in one particular application domain, eg telecom. Some CORBAservices - eg concurrency control, query services - overlap with desired features of a DBMS. http://csiweb.ucd.ie/staff/acater/comp30150.html

  10. "The OMG has not yet standardised the use of a ODBMS within CORBA. The ODMG has addressed this issue in a position statement, indicating that the integration of an ODBMS in an OMA ORB must respect the goals of distribution and heterogeneity while allowing the ODBMS to be responsible for its multiple objects. The relationship between the ORB and the ODBMS should be reciprocal; the ORB should be able to use the ODBMS as a repository and the ODBMS should be able to use the services provided by the ORB." There would be prohibitive overhead if each ODBMS object were individually registered with ORB, hence the desirability of a specialised alternative to BOA, the Object Database Adapter, for flexibility and performance. ORB may handle access to unregistered objects maintained within ODBMS by invoking methods of the ODBMS. http://csiweb.ucd.ie/staff/acater/comp30150.html

More Related