1 / 22

Lecture 5

Lecture 5. Advanced CORBA Topics. Object Adapters, Revisited. In the 2.x specification, client side CORBA code was highly portable Server Side: Basic Object Adapter interfaces the world of “objects” to that of “servants” Underspecified and non portable server side code

dolf
Download Presentation

Lecture 5

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. Lecture 5 Advanced CORBA Topics

  2. Object Adapters, Revisited • In the 2.x specification, client side CORBA code was highly portable • Server Side: Basic Object Adapter • interfaces the world of “objects” to that of “servants” • Underspecified and non portable server side code • ORB vendors had to implement vendor-specific methods and naming • skeleton base class naming convention • object registration with the ORB (_obj_is_ready, obj_is_ready, etc.) • activation policies • What’s a CORBA object again? • A CORBA object is an abstract entity with an: • identity • interface • implementation • Portable Object Adapter • Accepted by the OMG in 1997 as part of CORBA 2.2

  3. The Portable Object Adapter • Specified to fix a number of the problems with the BOA • Like the BOA, mainly concerned with interactions of objects and servers • Each ORB is associated with a root POA • A POA is a composite object which can create and contain other POAs • The Object key (of the IOR) contains: • the name of the managing POA • Object ID: identifies a specific object implementation relative to the POA in the Object Key • The BOA supported only early binding, when an IOR was created, the object’s servant was instantiated • The POA supports late binding--the separation of the IOR from the servant instantiation process • The binding between a servant and a CORBA object can be per request (via a Servant Locator) or not per request, which uses a Servant Activator.

  4. POA continued • Defined new category object called servant managers • new focus on objects rather than server processes • manages object implementations, incarnates and etherealizes associations between objects and servants on demand • CORBA objects are activated and deactivated • Servants are incarnated and etherealized • supports persistent objects • supports ForwardRequest exception for indirection • supports single thread model as well as POA-managed multithreading • supports transient objects • supports multiple instances of the POA • each POA manages a group of object implementations

  5. General Inter-ORB Protocol (GIOP) • A transport-independent communication protocol • GIOP Goals and Motivations: • Two ORBs must be able to communicate without any knowledge of the other’s internal mechanisms • The transport protocol must provide support for all CORBA functionality • The transport protocol must support the ORB-specific integrity of content and semantics of one ORB in the communication with another ORB • GIOP has three core elements: • Common Data Representation (CDR) • Message Formats • Transport Assumptions

  6. Common Data Representation • GIOP specifies that Network Byte Order will default to that of the sender, and it is the responsibility of the receiver to make any modifications that are necessary • In contrast to XDR, which forces a big endian ordering • GIOP tags a message with the network byte ordering of the sender (0 = BE, 1 = LE) • NBO is encoded in a byte in a GIOP 1.0 header, in a bit in a byte in GIOP 1.1 • GIOP specifies that all data is aligned on the sender’s natural boundaries. • 1: char, octet, boolean • 2: short, unsigned short • 4: long, unsigned long, float, enumerated types • 8: long long, unsigned long long, double, long double • Data is padded with spaces (0x20) as neccesary • Complex types are aligned according to their members (modulus alignment): • struct s { char c; double d; }; • c is in byte 1 • followed by 7 spaces (0x20) • followed by the double d • Strings are encoded with a 4-byte unsigned long which indicates the length of the string plus the terminating null, followed by the chars in the string, followed by a NUL byte (0x0). • CDR encodings are NOT self-describing, but IDL-described

  7. GIOP Message Formats • There are 8 message formats defined: • Message Fragmentation was introduced in GIOP 1.1 and allows for more efficient marshaling by allowing the sender to send data in a single request and have that fragmented into several packets without forcing the sender to buffer and marshall the data in advance

  8. GIOP Transport Assumptions • The transport is connection-oriented • Connections are full-duplex • allows receiver to reply to sender over the same connection without having to know the socket address of the sender • Connections support symmetric closure (GIOP 1.2) • either end can close the connection • The Transport is reliable (basic TCP assumptions) • messages will never be delivered more than once • message will be delivered in order • The Transport supports an unmarshaled byte-stream delivery • receiver sees data as a continuous byte stream rather than some structured data element • The transport supports orderly error reporting on connection loss • both parties receive error notifications in the case of failure

  9. Internet Inter-ORB Protocol • GIOP, while it has assumptions, is independent of any particular transport protocol • The Internet Inter-ORB Protocol specifies a TCP transport for GIOP • IIOP supplies the notion of an IOR • The Repository ID (most derived-type of Object implementation) • The endpoint information (socket for server or OAD) • The Object Key (the POA as well as the object servant ID) • IIOP defines how this information is encoded into an IOR • IIOP 1.1 adds support for tagged components, which allow specification in transports (codeset support, ORB-specific info, security info, etc.)

  10. CORBA Services • Naming Service (Object Location by Name - “White Pages”) • Trader Service (Object Location by service category - “Yellow Pages”) • Event Service (Distributed Messaging) • Transaction Service, OTS (Distributed Transactions) • Concurrency Service (provides controls for concurrent access of objects and transactions by concurrent threads) • Security Service (provides user authentication and object access control) • Life Cycle Service (Factory for creating, deleting, copying, and relocating objects) • Licensing Service (Provides access control services for licensing objects) • Time Service (service for getting the time, and manipulating time values - span(), etc.) • Query Service (service for querying collections of objects) • Persistence Service (Service for persisting the state of objects, interfaces with Object Adapters for instantiation) • Relationship Service (allows for CORBA objects to be related by design - role, cardinality, etc., as in UML) • Property Service (allows property sets to be associated with objects)

  11. Naming Service • Service provides a client with the ability to locate an object implementation’s IOR by well known name (WKN) • The Naming Service maintains a database of bindings between WKNs and IORs. • The Naming Service is often thought of as a kind of UNIX directory structure • root • EasternUS • Massachusetts • Boston NorthEnd Hanover Street La Piccola Venezia • Each branch in the tree is called a NamingContext • Each name in the naming service is a NameComponent • Getting the root naming service: • Object nameRef = orb.resolve_initial_references(“NameService”); • NamingContext nc = NamingContextHelper.narrow(nameRef);

  12. The Naming Context • The NamingContext is an IDL interface that supports the following methods:

  13. The NameComponent • Each Name in a NamingContext is a sequence of NameComponent objects:struct NameComponent { Istring id; //the name of the component Istring kind; //a user-defined description }; • A NameComponent is a single entry in a pathname, it might represent the “local” in /usr/local/bin.

  14. Binding an Object • To bind an object, you do the following: • get the initial NamingContext via resolve_initial_references() • narrow the Object result to the more derived NamingContext type using narrow() • Create a starting NamingContext:NameComponent nc1 = new NameComponent(“EasternUS”, “the good side”);NameComponent nc2 = new NameComponent(“Massachusetts”, “ok state”);NameComponent nc3 = new NameComponent(“Boston”, “now we’re talkin”);NameComponent nc4 = new NameComponent(“NorthEnd”, “only place to go”);NameComponent nc5 = new NameComponent(“HanoverStreet”, “oh yes”);NameComponent nc6 = new NameComponent(“LaPiccolaVenezia”, “aaaahhhh”);NameComponent [] name = { nc1, nc2, nc3, nc4, nc5, nc6 };NamingContext italian = rootContext.bind_new_context(name);ItalianEateryImpl piccolaVenezia = new ItalianEateryImpl(MODERATE_PRICE);italian.rebind(name, piccolaVenezia);

  15. Resolving an Object • To locate an object, you do the following: • get the initial NamingContext via resolve_initial_references() • narrow the Object result to the more derived NamingContext type using narrow() • Create a starting NamingContext:NameComponent nc1 = new NameComponent(“EasternUS”, “”);NameComponent nc2 = new NameComponent(“Massachusetts”, “”);NameComponent nc3 = new NameComponent(“Boston”, “”);NameComponent nc4 = new NameComponent(“NorthEnd”, “”);NameComponent nc5 = new NameComponent(“HanoverStreet”, “”);NameComponent nc6 = new NameComponent(“LaPiccolaVenezia”, “”);NameComponent [] name = { nc1, nc2, nc3, nc4, nc5, nc6 };orb.omg.CORBA.Object ior = rootContext.resolve(name);ItalianEatery piccolaVenezia = ItalianEateryHelper.narrow(ior);piccolaVenizia.eat(ItalianEatery.VEAL_EGGPLANT_PARMESAN);

  16. ToolTalk and RPC • ToolTalk is a messaging service from SunSoft allowing peers to communicate via ToolTalk without having to connect directly or know about one another • A message is not sent from a peer to another connected peer process, but a client dispatches a message of a specific type to the ToolTalk service • Servers register with the ToolTalk service, and specify what types of messages they are interested in receiving • The ToolTalk service then dispatchs messages from clients to these registered listening servers according to their type. • All this is a lot like System V IPC Message Queues; however ToolTalk ran over RPC and thus provided one of the first distributed messaging services. • ToolTalk is still used today in Sun’s openwin X server communication (view on any Solaris box): • /usr/openwin/share/include/desktop/tt_c.h • “ToolTalk is perhaps too high level a service to replace RPC as a general-purpose distributed programming mechanism. Also, its complexity presents a significant learning hurdle. Nonetheless, it is an interesting new paradigm and one which we can expect to see more of in the future.” --Chris Brown, UNIX Distributed Programming, 1994

  17. The CORBA Event Service • The COS Event Service allows for decoupled asynchronous message transfer between CORBA objects • The Event Service acts as a well-known intermediary between objects that wish to communicate, but do not wish to be tightly coupled • Senders of events are called suppliers, and receivers of events are called consumers. • The COS Event Service implements the Mediator and Proxy Patterns (GoF) • The COS Event Service offers what is commonly referred to as the Producer-Consumer model • Messages can be accessed by either a pull or Pull metaphor • Message passing takes place asynchronously (non-blocking model) • The COS Event Service delivery can be set up to be typed or untyped • The COS Event Service will automatically buffer received events, offering semi-persisted messaging • Communication can follow either a pull or Pull model • Consumers can either synchronously (Pull) or asynchronously (pull) obtain messages from the Event Services, or have the Event Service deliver events to them (pull model) • A 1-1 correspondence between Producers and Consumers is not necessary

  18. The Connection Process • Regardless of the model, the following steps must be taken to connect to an event channel: • The client must bind to the Event Channel, which must already have been created by someone, perhaps the client • The client must get and Admin object from the Event Channel • The client must obtain a proxy object from the Admin object (a Consumer Proxy for a Supplier client and a Supplier Proxy for a Consumer client) • Add the Supplier or Consumer client to the event channel via a connect() call • Transfer data between the client and the Event Channel via a push(), pull(), or try_pull() call

  19. The COS Event Service Design • Suppliers and Consumers each connect to the event service, via a particular channel. • Each channel can have multiple consumers and suppliers, and all events delivered by a supplier are made available to all consumers • An event channel can be thought of as a repository of common interest, the Usenet model is available as a metaphor • Suppliers and consumers connect to an event channel, and begin communication through the channel • The Event Channel supports two models of interaction: pull and Pull • Push Model: The sender initiates the delivery of the message to the recipient • Pull Model: The recipient initiates the delivery of the message from the sender by request • The Event Channel plays roles on behalf of suppliers and consumers • For consumers, it plays the role of a supplier • For suppliers, it plays the role of a consumer • Through this role playing, the Event Channel can decouple the communication between the two interested parties

  20. The Pull Model • In the Pull Model, the consumer initiates the flow of events from the supplier • When a Pull supplier wants to connect to the event channel, the event channel will “pretend” it is a Pull consumer, by creating a consumer proxy for the supplier to talk to • The supplier is none the wiser, and simply delivers messages on request to its “consumer”, which is a proxy object within the event channel • When a Pull consumer wants to connect to the event channel, the event channel will “pretend” it is a supplier, by creating a supplier proxy for the consumer to talk to. • In the Pull Consumer scenario, the Pull Consumer pulls (or tries to pull) events from the Proxy Pull Supplier • In the Pull Supplier scenario, the Proxy Pull Consumer pulls events from the Pull Supplier.

  21. The Push Model • In the Push Model, the supplier initiates the flow of events to the consumer • When a Push Supplier wants to connect to the event channel, the event channel will “pretend” it is a consumer, by creating a consumer proxy for the supplier to talk to • The supplier is none the wiser, and simply delivers messages to its “consumer”, which is a proxy object within the event channel • When a Push Consumer wants to connect to the event channel, the event channel will “pretend” it is a supplier, by creating a supplier proxy for the consumer to talk to. • In the Push Consumer scenario, the event channel pushes events out to the consumer via the push supplier proxy • In the Push Supplier scenario, the supplier pushes events out to the event channel via its push consumer proxy.

  22. The Hybrid Model • Push Supplier/Push Consumer: Push suppliers push events onto the channel, which in turn pushes them out to consumers • Push Supplier/Pull Consumer: Push suppliers push events onto the channel, and pull consumers pull events (or try to pull) from the channel when they need one • Pull Supplier/Push Consumer: The event channel pulls events from the Pull Supplier, and then it pushes these events out to the Push Consumers • Pull Supplier/Pull Consumer: The Pull Consumers pull events from the event channel, which in turn pulls them from the Pull Suppliers.

More Related