CORBAservices. Naming. Part of the CORBA Naming Service Interface in IDL. CORBA Naming Service

Transcription

1 CORBAservices CORBAservices are general purpose and application independent services. They resemble and enhance services commonly provided by an operating system: Service Collection Query Concurrency Transaction Event Notification Externalization LifeCycle Licensing Naming Property Trading Persistence Relationship Security Description Facilities for grouping objects into lists, queue, sets, etc. Facilities for querying collections of objects in a declarative manner Facilities to allow concurrent access to shared objects (locking) Flat and nested transactions on method calls over multiple objects Facilities for asynchronous communication through events Advanced facilities for event-based asynchronous communication Facilities for marshaling and unmarshaling of objects Facilities for creation, deletion, copying, and moving of objects Facilities for attaching a license to an object Facilities for system-wide name of objects Facilities for associating (attribute, value) pairs with objects Facilities to publish and find the services on object has to offer Facilities for persistently storing objects Facilities for expressing relationships between objects Mechanisms for secure channels, authorisation, and auditing Time Provides the current time within specified error margins 52 Naming CORBA supports different types of names Most basic types, object references and character-based names, are supported by the CORBA naming service There are a number of advance naming facilities whereby objects can found based on associated properties Independently from logical object names, CORBA objects can be addressed by URLs: iioploc://appserver.klick-and-bau.com:4711/object-24 references the CORBA object which can be connected to on host 'appserver.klick-and-bau.com' using port 4711 and object identifier 'object-24' iiopname://appserver.klick-andbau.com/buchhaltung/stammdaten/artikelhome references the CORBA object which the naming service on host 'appserver.klick-and-bau.com' knows by the name 'Buchhaltung/Stammdaten/ArtikelHome' In both cases, IIOP is used as communication protocol 53 CORBA Naming Service Used to look up object references using a character based name Names in CORBA are sequences of name components each taking the form of a (id,kind)-pair, where id and kind are both strings: id is used to name an object, kind is a simple indication of the name object (e.g. 'dir' for a directory object) There are no restrictions with respect to the structure of a naming graph Each node in a naming graph is treated as an object Naming context: an object that stores a table mapping name components to object references (like directory node) Naming graph does not have a root context, however each ORB is required to provide an initial naming context which effectively operates as the root in a naming graph Names are always resolved with respect to a given naming context A client resolves a name by invoking the resolve method on a specific naming context If name resolution succeeds, it always returns either a reference to a naming context or a reference to a named object Name resolution proceeds as in DNS 54 Part of the CORBA Naming Service Interface in IDL struct Name string id; string kind; typedef sequence <Name> Name; interface NamingContext void bind (in Name n, in Object obj); binds the given name and remote object reference in my context void unbind (in Name n); removes an existing binding with the given name void bind_new_context(in Name n); creates a new naming context and binds it to a given name in my context Object resolve (in Name n); looks up the name in my context and returns its remote object reference void list (in unsigned long how_many, out BindingList bl, out BindingIterator bi); returns the names in the bindings in my context 55

2 How to Find the First Naming Context? Trading Service The CORBA name service allows you to search a name context and to navigate through several name contexts. This works as in other name services. But how to find the root context, i.e. the naming service itself? The naming service is identified by an object reference To solve the problem, the ORB itself is responsible to provide facilities to get initial object references. A reference to the root context can be got by calling the function resolve_initial_reference("name Service") provided by the ORB: interface ORB... Object resolve_initial_references (in String name);... } CORBA defines some more names the ORB has to resolve, e.g. "RootPOA" and "InterfaceRepository". Further names can be configured by the administrator. Naming Service = White pages But sometimes, no concrete name but only a description of the needed service is known Trading Service (= Yellow pages) An object is not denoted by a logical name, but by a description of its capabilities: Service Type (description of object functionality, determines interface) Service Properties (non-functional description of a service) Roles: Trader: stores and searches service descriptions Importer: a client searching for an object s service Exporter: an object offering a service The Trading Process matches both descriptions sorts all services with matching type and properties by a client s constraint gives back the reference to the best matching service A service is described by Service Type Service Properties Example: Searching a Print Service Exporter: specifies its offer, i.e. type and properties, e.g. format=a3, A4, A5} cost_per_page=10 pages_per_sec=5 3. Selected service Trader Service Directory 1. Service Export n... Type T4 T5 T2 Reference... Properties... Importer: specifies type and constraints, e.g. format=a4 AND cost_per_page<15 minimize cost_per_page Only service offers fulfilling those restrictions are further considered 2. Service Import T2 T2 1 4 static vs. dynamic properties Thematchingservicesare sorted by this criterion Importer The client specifies its demands to a service 4. Service usage Exporter Exporter Exporter A server specifies its functionality and its capabilities 58 Note: properties can be static or dynamic (value is changing over time). Considering dynamic properties is seldom realised. 59

3 Event Service Asynchronous communication can by realised with one-way calls, but One-way calls are best effort Overhead when simply a signalling information should be transmitted Communication by events CORBA's Event Service In this model, each event is associated with a single data item, generally represented by means of an object reference or an application-specific value An event is produced by a supplier and received by a consumer The event service offers an event channel which is logically placed between suppliers and consumers and suits for delivering events 60 Push and Pull Model Push model: Whenever en event occurs, the supplier produces the event and pushes it through the event channel Event channel passes the event on to its consumers In this model consumers passively wait for event propagation and expect to be interrupted when an event happens Pull model: Consumers poll the the event channel to check whether an event has happened The event channel in turn polls the various suppliers Note: the models can be combined How does it work? For both, consumers and suppliers, proxies (for push and pull operations) are implemented in the event channel. Consumer and producer use synchronous communication with these proxies for the time delivering or getting events 61 Event Channel Notification Service PushSupplier 1 PushSupplier n PullSupplier 1 PullSupplier m.. ProxyPushConsumer ProxyPullConsumer Event Channel ProxyPushSupplier ProxyPullSupplier.. PushConsumer 1 PushConsumer r PullConsumer 1 PullConsumer s Notice: kind of multicast: all events are passed from a Supplier Proxy to all Consumer Proxies Event services drawbacks: CORBA's event service does not support persistence of events. If a consumer connects to the event channel too late, events get lost Consumers have no chance to filter events. Each event is passed to every consumer. If different event types need to be distinguished it is necessary to set on a separate event channel for each event type Event propagation is unreliable. No guarantees need to be given concerning the delivery of events Notification service Event typing Filtering capabilities have been added Offers facilities to prevent event propagation when no consumers are interested in a specific event 62 63

4 Synchronisation and Transactions Replication and Fault Tolerance Two important services that do synchronisation in CORBA are the Concurrency Control service and the Transaction service The two services collaborate to implement distributed and nested transactions using two phase locking with a central lock manager A transaction is initiated by a client and consists of a series of invocations on objects. When an object is invoked for the first time it automatically becomes part of the transaction. This information is passed to the server when invoking the object Two types of objects can be part of a transaction: Recoverable object: is executed by an object server capable of participating in two phase commit protocol Transactional objects: executed by server that do not participate in a transaction's two phase commit protocol (typically read-only objects) CORBA transactions are similar to distributed transactions as presented before The service distinguishes read from write locks and is also capable of supporting locks at different granularities (e.g. whole tables vs. single records) CORBA offers no support for generic caching and replication Application developers have to resort to an ad-hoc approach when replication is needed (such approaches are often based on using interceptors) Only the replication of objects for fault tolerance is included in the current CORBA version 3 Fault Tolerance Dealing with failures: replicate objects into object groups, consisting of identical copies of an object referenced as if it would be a single object. A group offers the same interface as the objects it contains Uses a special kind of an IOR, the Interoperable Object Group Reference (IOGR) Fault Tolerance Fault Tolerance Supported strategies: passive replication, active replication, quorum-based replication When a client passes an IOGR to the ORB, the ORB attempts to bind to one of the replicas. The components field could refer to the primary or a copy of the object's replicas If binding fails, the ORB can try another copy Replication manager: creating and managing object groups, replacing replicas in case of a failure Interceptors are used to pass invocations to a separate replication component maintaining consistency and realising recoverability 66 67

5 Limitations of Object-Based Middleware Object-Oriented programming is a standardised technique, but Lack of defined interfaces between objects It is hard to specify dependencies between objects Internal configuration of objects Long time to install new applications s s are functional entities they must define what they offer and what they need Application construction: composition of objects with defined interfaces Semi-automatic deployment of the application: Run-time environment configuration s in CORBA CORBA Model (CCM) Distributed, component-oriented model s are binary code fragments for functional entities, maybe implemented in different languages Application deployment by definition of functional entities and interactions between entities Standardised environment for management: creation, activation, deactivation, CORBAservices for components (Security, Persistence, Event, Transactions) Interoperability with Enterprise Java Beans (EJB) CORBA Model is a specification for creating server-side scalable, language-neutral, transactional, multi-user and secure enterprise-level applications The CORBA Model CORBA State/Country Chicago San Jose Point-of-Sale Data IT Department Processing Center Centers Market Analysis Central Team Data Store Client Middleware Bus Repository Compose Deploy Online Ordering Assembly Server System Development Deployment & Configuration Metadata Order Deployment Processing ASP & Configuration Mechanism Containers Containers Middleware Framework Application Server Extends the CORBA Object Model Provides standard run-time environment for components application servers containers : reusable physical entity Container: standardised execution environment for components Application server: generic server process Adoption of POA Uses CORBAservices: Transactions, Security, Event, is a new CORBA meta-type. Extension of type Object (with constraints) Has an interface, and an object reference Also, a stylized use of CORBA interfaces/objects Provides component features (also named Ports) Could support multiple interfaces Each component instance is created and managed by a unique component home A component describes: What functionality a component offers to other components What functionality a component needs from other components What kind of interaction are used between components: synchronous or asynchronous Which component properties can be configured Which manager is responsible for managing component instances 70 71

6 A CORBA offered operation interfaces interface required operation interfaces Building CCM Applications is Assembling Instances OFFERED Facets Event sinks Receptacles Event sources REQUIRED consume events Attributes produced events configurable properties Facets Receptacles Multiple named interfaces that provide the component s application functionality to clients - one of these must be the same as the supported interface Each facet embodies a view of the component, corresponds to a role in which a client may act relatively to the component A facet represents the component itself, not a separate thing contained by the component Facets have independent object references Connection points between components, where one uses an interface of another No inherent life cycle dependencies or ownership relationship implied - no operations are inherently transitive across receptacle connection Plug in to the receptacle one or more references to instances of the required component type Explicit client relationship Ability to specialize by delegation, compose functions IDL compiler generates operations to connect to and disconnect from the receptacle 74 75

7 Events Attributes Decoupled communication between components Receptacle supports direct communication between components In contrast, events are indirect: Event channel contacts set of consumers for each event Simple event model based on channels Subset of CORBA Notification Service ( push model) s can declare that they Produce a kind of event (event source) Emit (1:1) Publish (1:N) Accept a kind of event (event sinks) Named configurable properties Allow component configuration on an instance basis Determine behavior (within range of possible behaviors) for particular component instance Configurator objects can configure components by establishing attribute values Attributes exposed through accessors and mutators Signal when completed and then validity checked Can be configured By visual property sheet mechanisms in assembly or deployment environments By homes or during implementation initialization Potentially readonly thereafter Homes A CORBA Home A home manages a specified component type Home definition is distinct from component definition More than one home type can manage the same component type (but any given component instance has only one home) Allows life cycle characteristics or key type to vary/evolve without changing component definition Instantiated at deployment time Home interface c 1 MyHome c N 78 79

8 HomeFinder Dining s Example A HomeFinder is used to find out the reference for the home interface belonging to a component type All homes can be registered here (is not done automatically) A brokerage of homes to clients Home implementations register with home finder Clients request homes from home finder Home finder makes determination of what is the best home to service a client, based on the client s request and any available environmental or configuration data resolve_initial_reference( HomeFinder ) gives back reference to HomeFinder Thinking Hungry Starving Eating Dead Kant Aristotle Descartes Thinking Hungry Starving Eating Dead Thinking Hungry Starving Eating Dead IDL Example component attribute string name; // The left fork receptacle. uses left; // The right fork receptacle. uses right; // The status info event source. publishes StatusInfo info; Home left right info Dining s as CORBA s name = Kant name = Descartes Base ref. Facet Receptacle Event Sink Event Source home Home manages factory new(in string name); name name = Aristotle Observer 82 83

9 State Types enum State EATING, THINKING, HUNGRY, STARVING, DEAD eventtype StatusInfo public string name; public State state; public unsigned long ticks_since_last_meal; public boolean has_left_fork; public boolean has_right_fork; name component attribute string name; // The left fork receptacle. uses left; // The right fork receptacle. uses right; // The status info event source. publishes StatusInfo info; home Home manages factory new(in string name); Home name Observer exception InUse interface void get() raises (InUse); void release(); // The fork component. component Manager // The fork facet used by philosophers. provides the_fork; // Home for instantiating Manager components. home Home manages Manager Home Manager component Observer // The status info sink port. consumes StatusInfo info; // Home for instantiating observers. home ObserverHome manages Observer Observer Home Observer 86 87

10 Client Programming Model -aware and -unaware clients Clients see two design patterns Factory client finds a home and uses it to create a new component instance Finder client searches an existing component instance through Name Service, Trader Service, or home finder operations Invokes operations on component instances CCM by this offers a powerful architecture to construct really distributed applications More information as additional information on the web page 88