1 / 32

CORBA Architecture

CORBA Architecture. Nitin Prabhu. Outline. CORBA Object Model CORBA Architecture Static Invocation Dynamic Invocation CORBA Communication Model. CORBA Object Model. Client. Encapsulation. Request. Object Implementation. CORBA Object implementations Request CORBA Types Interfaces

amaya-goodwin
Download Presentation

CORBA Architecture

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 Architecture Nitin Prabhu

  2. Outline • CORBA Object Model • CORBA Architecture • Static Invocation • Dynamic Invocation • CORBA Communication Model

  3. CORBA Object Model Client Encapsulation Request Object Implementation • CORBA Object implementations • Request • CORBA Types • Interfaces • Operations • Exceptions Exception value

  4. CORBA Object • Object is a encapsulated entity that performs services • Object is referred to by an unique object reference • Client software invokes object services by generating request • Object returns some results or returns exception

  5. CORBA Request • A request is a message sent from a client to an object. • It consists of • an operation. • a target object. • zero or more parameters. • an optional request context.

  6. CORBA Types • An identifiable entity defined over values. Value Object Reference Basic Value Constructed Value Short long Ushort Ulong Float Double Char String Boolean Octet Struct Sequence Union Array

  7. CORBA Interface • An Interface comprises a set of operations and attributes that a client may utilize to request services of an object. • All interface information is public. • Interfaces are defined in IDL.

  8. CORBA Operations • An operation is an identifiable entity, that denotes a service which can be requested. • Operation Signature consists of • Operation name • Parameters required • Return Value • Exceptions thrown • Contextual Information • Execution Semantics • Synchronous • Asynchronous

  9. CORBA Exceptions • An exception is an indication that an operation request was not performed successfully. • Two types • Standard Exceptions • User defined Exceptions • CORBA guarantees that the client will not hang. Either it returns successfully or with an exception.

  10. OMA • Object Management Architecture COMMON FACILITIES • Horizontal • User Interface • Mail • Printing • Vertical • Telecom • Finance • Health Care APPLICATION OBJECTS OBJECT REQUEST BROKER naming trading security persistence COMMON OBJECT SERVICES

  11. Interface Repository Implementation Repository CORBA Architecture Per-Object Type Generated Interface ORB Dependent Interface Standard Interface Client Object Implementation Object Static IDLSkeleton Dynamic Skeleton IDLStubs ORBInterface Dynamic Invocation Adapter ORB core

  12. ORB • Object Request Broker. • Gives the communication infrastructure that is capable of relaying object requests across distributed platforms. • Client calls the Object implementation through interfaces provided by ORB. • Advantages: • Separates Client and Server implementation • Separates both client and Server from underlying communication infrastructure and protocol stack and so replaceable while migration from one implementation to other

  13. Interoperable Object Reference(IOR) • An ORB must create an IOR whenever an object reference is passed across ORB’s • Includes ORB’s internal object reference and addressing information

  14. Client Stubs • Client side proxy for server. • Joins to the client at one end and to the ORB core at the other end. • Client-to-stub interface is decided by the standard OMG language mapping for the chosen programming language. • Clients actually invoke methods on stub objects.

  15. Server Skeletons • Acts as client proxy for server implementation. • Connects • to the server object via the mapping defined for its programming language on . • To the Object Adapter via a proprietary interface. • Invocation pass through Object Adapter to skeletons, which in turn actually invoke methods on server object.

  16. Object Adapter • Different kind of object implementations - • objects residing in their own process and requiring activation. • others not requiring activation. • or some residing in same process as ORB. • OA helps the ORB to operate with different type of objects. • Most widely used OA - BOA (Basic OA) • Recently standardized - POA (Portable OA)

  17. Object Adapter Contd... • Services provided by ORB via OA - • Registering implementations. • Generation and interpretation of object references. • Mapping object references to their corresponding implementation. • Activating and deactivating object implementation. • Invocation of methods via a skeleton.

  18. Interface Repository • Contains information regarding the interfaces to ORB objects. • Can be used by the ORB in 2 ways - • To provide type-checking of request signatures, whether a request was issued through DII or stub. • To check correctness of inheritance graph. • Client objects can use it - • To manage installation and distribution of interface definitions around your network. • Language compilers may use them to generate stubs and skeletons. • Can be shared by more than one ORB or one ORB may refer to more than one interface repository.

  19. Implementation Repository • Contains all the information regarding object implementation. • Provides a persistent record of how to activate and invoke operations on object implementations. • CORBA gives vendors free-hand in handling implementations.

  20. Marshaling • Refers to the process of translating input parameters to a format in which it can be transmitted over the network. • Unmarshaling is the reverse of marshaling. • Stubs and skeletons contain code for marshaling and unmarshaling.

  21. Development Steps IDL CORBA Compile Stubs Skels Client Server Compile Link Compile Link Client Server

  22. Object Adapter(BOA/POA) Static Invocation Server Servant Client IOR Server IDL Skeleton Client IDL Stub Server ORB Client ORB IIOP

  23. Client Invocation Process Scenario Client Program 1. Object string valued 2. Obtain object Handle 4. Check exceptions object reference 3. Invoke request 5. Utilize results 6. ORBFree( ) String_to_object( ) user_fun( ) Results & exceptions File ORB Interfaces Interface Stub ORB CORE

  24. Object Implementation Invocation Scenario Object Implementation Methods 3. Activate object 5. Access BOA service 2. Registration of implementation 4. Invoke method 1. Activate Implementation Basic Object Adapter Skeleton Object Request Broker Core

  25. Dynamic Invocation Interface • Generic interface for making remote invocations. • Uses interface repository at run-time to discover interfaces. • No need of pre-compiled stubs. • Steps - • Obtain IOR. • Ask IOR of the interface name and get a reference to an object in the interface repository. • Obtain the method description. • Create the request to be passed. • Invoke the operation/method.

  26. Dynamic Skeleton Interface • Allows the ORB and OA to deliver requests to an object without the need of pre-compiled skeletons. • Implemented via a DIR (Dynamic Invocation Routine). • ORB invokes DIR for every DSI request it makes.

  27. Dynamic Skeleton Interface Contd... • Steps - • OA up-calls the DIR servant and provides the request information (targeted object and operation name etc.). • DIR asks IOR for the interface name of the targeted object and gets the meta-data information about it from interface repository. • Creates the request to targeted object, using other parameters from the received request. • Locates the Servant and send the request to it. • Takes the return parameteres and give them back to OA.

  28. Differences between Dynamic invocation and static invocation • Use • SI used for general purpose • DI used for special purpose where extra flexibility is needed • In SI interfaces should be known at compile time,In DI interfaces are discovered during run time using data in interface repository • Static Interface are easier to use and code

  29. CORBA Communication model • It is independent of underlying protocol suite and assumes an underlying connection-oriented protocol at transport layer. • Two protocols are defined in the communication mode. • GIOP-General Inter ORB Protocol • IIOP- Internet Inter ORB Protocol

  30. GIOP-General Inter ORB Protocol. • IT is a high level standard protocol for communication between ORB implementations. It is designed to directly work over any connection- oriented transport protocol • GIOP defines a transfer syntax known as CDR (Common Data Representation) and seven messages that cover ORB request reply semantics. • No format negotiations are needed.In most cases,clients send a request to objects immediately after they open the connection. • CDR maps data types defined in IDL in to flat, networked message representation. CDR also takes care of the inter-platform issue. •  GIOP also defines a format for Interoperable Object References(IOR).

  31. IIOP- Internet Inter ORB Protocol • It is a specialized form of GIOP for TCP/IP networks. • IIOP specifies how GIOP messages will be exchanged over TCP/IP network • An ORB must support IIOP in order to be considered compliant with CORBA 2.0. • It consists primarily of the specification for the IIOP IOR, which contains the host name and the port number.

More Related