Limitations of Object-Based Middleware. Components in CORBA. The CORBA Component Model. CORBA Component

Transcription

1 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 73 74

2 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 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 77 78

3 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 tification 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 81 82

4 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 85 86

5 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 89 90

6 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 powerfull architecture to construct really distributed applications. But: there are lots of other, different middleware concepts, too. 91 Distributed Object Model (DCOM) Basic Technique in Microsoft's Windows: COM ( Object Model) Supports the development of components that can be dynamically activated and interact with each other Can be used in executables as well as in dynamic link libraries Was developed to support compound documents ActiveX: covers the tasks of OLE, together with new features like starting variants, scripting support, OLE: Object Linking and Embedding. Serves for gluing together different parts of compound documents COM: communication infrastructure between different objects located on the same computer DCOM: 'distributed version' of COM to support activation/interaction with components located on another machine. For a programmer, the distinction between COM and DCOM is hidden behind interfaces (access transparency) 92 Object Model Object Model Like CORBA, DCOM bases on the remote object model: objects can be placed in the same process as the client, in another process on the same machine, or in a process on a remote machine Basic concept: Distinction between interface and implementation The developer first specifies an object by its interface in an Interface Definition Language (Microsoft IDL = MIDL) An object simply is an implementation of an interface Interface means binary interface: a table of pointers to methods belonging to an interface. In this way, interfaces are language-independent Each interface is assigned with a globally unique Interface Identifier (IID) DCOM object: Instance of a class object, which represents an interface By calling a function CreateInstance on a class object (identified by a class ID, CLSID), a new object with this interface is build. All objects implement a standard interface: IUnknown A pointer to IUnknown is passed back when creating an object Important method in this interface: QueryInterface, which returns a pointer to another interface implemented by the object By this, a standard method to get access to each object's methods is given create Reference: IUnknown IUnknown QueryInterface(deposit) withdraw getbal. deposit setbal. Reference: deposit 93 94

7 Object Model Comparison to CORBA CORBA generates language-dependent stubs DCOM generates binary interfaces All objects in DCOM are transient Reference counting is part of IUnknown to see how many other objects are knowing about an object Having no more references, an object is destroyed An object can implement the IDispatch interface Dynamic invocation of objects An object does not have to know in advance all interfaces it will have to contact in its lifetime When an object implements this interface, calls to it can be constructed at runtime DCOM One specification of an interface Re-use of the specification A new specification for each mapping to a programming language Separate translation of the interface for each language CORBA Object Identifiaction and Activation Type library: storage for interface definitions [CORBA: Interface Repository] Associated with an application Used to figure out the signature of a method to be invoked dynamically Used as a type library for supporting program developers Registry (Windows registry) [CORBA: Implementation Repository] Used to provide a mapping from class identifiers to executable code. In case of a remote invocation, the Service Control Manager (SCM) on the target host is contacted by a client to access the remote registry 97 Communication in DCOM Client side: Client proxy: providing the object's interface and sending the request to the object Proxy marshaller: translating a request into a transport format before sending Server side: Object stub: receives a call from a client proxy and passes it on to the object Proxy marshaller: extracts a request from a receives message Communication at the beginning only was synchronous using RPC Alternatives: Callback interfaces The client provides an interface where the server can call back after working on a request Asynchronous communication For each method, two methods are implemented: A start method the client passes its request to A finish method the client calls to read the response of the server 98

8 Events Real asynchronous communication without the need for both, client and object, to be active: using events An event is modelled as a method call An event class groups events and can be instantiated to event objects which can send events of specific types To register an implementation for a method so that events can be sent to it, a pointer to the corresponding interface has to be sent to the event system The event system can store events to pass them on to the receiver later Passing Interface Pointers A client does not see distribution; the invocation of remote objects with DCOM is the same as an invocation of a local object with COM Difference: in COM an object is referenced by an interface pointer, in DCOM a remote object is referenced by implementing an interface as a proxy Passing on an object reference to another client is made by sending it the proxy which contains all connection information Supplier: someone who creates events Consumer: someone who receives events m_event: method of an object Naming in DCOM Only low-level naming Objects are only transient. To expand an object's lifetime, additionally a persistent object reference is stored to an object. This reference is called moniker. Monikers have all information available to reconstruct an object and reload its state Step Performer Client Moniker SCM Class object Moniker Description Calls BindMoniker at moniker Looks up associated CLSID and instructs SCM to create object Loads class object Creates object and returns interface pointer to moniker Instructs object to load previously stored state Types of Monikers Moniker type File moniker URL moniker Class moniker Composite moniker Item moniker Pointer moniker Description Reference to an object constructed from a file Reference to an object constructed from a URL Reference to a class object Reference to a composition of monikers Reference to a moniker in a composition Reference to an object in a remote process 6 7 Object Moniker Loads its state from file Returns interface pointer of object to client

9 Active Directory Windows 2000 contains a directory service called Active Directory which can be used by DCOM A distributed system based on Windows 2000 is partitioned into domains consisting of a number of resources and users Each domain has a domain controller which is a local directory server A domain controller is implemented as a LDAP directory server LDAP servers are registered in DNS Problem: a client has to know the target domain for its request GLOBE GLobal Object-Based Environment Experimental distributed system developed by Vrije Universiteit Amsterdam Design goal: support huge number of objects and users spread across the Internet, scalability is central role Fundamental concept: how are objects viewed? Objects don't only encapsulate state and operations, but additionally they encapsulate the implementation of policies that prescribe the distribution of an object's state across multiple machines Each object determines how its state is migrated, replicated or distributed over its replicas Globe Object Model t uses the remote object model Objects, i.e. their states can be physically distributed (and replicated). They are called distributed shared objects Each process running a 'part' of an object has a local implementation of the object's interface implementation (local representative, local object) Each local object offers an interface SOInf (similar to IUnknown in DCOM) Local objects implement binary interfaces, interfaces are described using an IDL 105 Composed Objects Two kinds of local objects Primitive local object Composite local object: composed of several primitive or composed local objects Composition is used to construct a usable local object Semantics subobject implements the functionality Communication subobject provides a standard interface to the underlying network; it offers message-passing primitives for communication Replication subobject implements the object's distribution strategy Control subobject is intermediate between user interface and all object functions 106

10 Process-to-Object Binding concepts like type library and registry for getting interface descriptions and activating objects. Used in Globe: Communication Only synchronous communication Some local objects (here in process A) can be seen as proxies only forwarding requests If an object's state is replicated, the replication subobject forwards the request to all replicas and merges the results Globe Client and Server Client: Server Additionally: Method Bind AddBinding CreateLR RemoveLR UnbindDSO ListAll ListDSO StatLR Process bound to a distributed shared object, invoking this object by making calls at the control subobject (process A on the last slide) Process that can handle only invocations coming in through the network (processes B and C on the last slide) object servers for supporting distributed shared objects/hosting local objects. Interface for such object servers: Description Lets the server bind to a given object, unless it is already bound Lets the server bind to an object, even if it is already bound Lets the server create a local object for a new distributed object Lets the server remove a local object of a given object Lets the server remove all local objects of a given object Returns a list of all local objects Returns a list of all local objects for a given objects Get the status of a specific local object Naming Globe distinguishes between naming and locating objects Each distributed shared object is assigned a globally unique object identifier (OID) An object handle contains the OID Location service is organised hierarchically The address given back by the location service can be a Stacked address: Field Protocol identifier Protocol address Implementation handle Instance address: Field Implementation handle Initialization string Description A constant representing a (known) protocol A protocol-specific address Reference to a file in a class repository (URL) Description Reference to a file in a class repository String that is used to initialize an implementation

11 Globe Naming Service Simple naming service with human-friendly names: Based on DNS Names are represented by a Uniform Resource Identifier (URI) Comparison of CORBA, DCOM and Globe Issue Design goals Object model Services Interfaces Synchronous communication Asynchronous communication Callbacks Events Messaging Object server Directory service Trading service CORBA Interoperability Remote objects Many of its own Language-dependent Flexible (POA) DCOM Functionality Remote objects From environment Binary Hard-coded Globe Scalability Distributed objects Few Binary Object dependent Comparison of CORBA, DCOM and Globe Issue Naming service Location service Object reference Synchronisation Replication support Transactions Fault tolerance Recovery support Security CORBA Object's location Transactions Separate server By replication Various mechanisms DCOM Interface pointer Transactions ne By transactions By transactions Various mechanisms Globe True identifier Only intra-object Separate subobject By replication More work needed 113