Limitations of Object-Based Middleware Components

Transcrição

Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Limitations of Object-Based
Middleware
Components in CORBA
Object-Oriented programming is a standardised technique, but…
CORBA Component Model (CCM)
• Lack of defined interfaces between objects
• Distributed, component-oriented model
• It is hard to specify dependencies between objects
• Components are binary code fragments for functional entities, maybe
implemented in different languages
• Internal configuration of objects
• Application deployment by definition of functional entities and interactions
between entities
• Long time to install new applications
• Standardised environment for
• Component management: creation, activation, deactivation, …
• CORBAservices for components (Security, Persistence, Event,
Transactions)
Components
• Components 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
„CORBA Component Model is a specification for creating server-side scalable,
language-neutral, transactional, multi-user and secure enterprise-level
applications“
71
Chapter 2: Middleware
San Jose
IT Department
Chicago
Data
Center
Central
Data
Store
Market
Analysis
Team
Client
Component
Repository
Middleware Bus
Compose
Deploy
Component
Assembly
Online
Ordering
Server
System Development
Deployment
&
Configuration
Metadata
Deployment
&
Configuration
Mechanism
Order
Processing
Component
Containers
ASP
Component
Containers
Middleware Framework
Application Server
•
•
72
The CORBA Component Model
State/Country
Point-of-Sale
Processing
Centers
• Interoperability with Enterprise Java Beans (EJB)
CORBA Component
Extends the CORBA Object Model
Provides standard run-time environment
for components
– application servers
– containers
• Component: reusable physical entity
• Container: standardised execution
environment for components
• Application server: generic server
process
• Adoption of POA
• Uses CORBAservices:
Transactions, Security, Event, …
73
• Component 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
74
Building CCM Applications is
Assembling Component Instances
A CORBA Component
Component interface
offered operation
interfaces
required operation
interfaces
Receptacles
Component
Event
sinks
REQUIRED
OFFERED
Facets
Event
sources
produced events
consume events
Attributes
configurable properties
75
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
76
•
•
77
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
78
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)
Components 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
79
80
Homes
A CORBA Component 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
MyComponentHome
c1
…
cN
81
82
HomeFinder
Dining Philosophers 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(”ComponentHomeFinder”) gives
back reference to HomeFinder
Thinking
Hungry
Starving
Eating
Dead
Thinking
Hungry
Starving
Eating
Dead
Fork
Descartes
Kant
Fork
Fork
83
home PhilosopherHome manages
Philosopher {
factory new(in string name);
};
84
Dining Philosophers as
CORBA Components
IDL Example
component Philosopher
{
attribute string name;
// The left fork receptacle.
uses Fork left;
// The right fork receptacle.
uses Fork right;
// The status info event source.
publishes StatusInfo info;
};
Aristotle
Thinking
Hungry
Starving
Eating
Dead
Component
Base ref.
Philosopher
PhilosopherHome
Facet
Fork
Receptacle
name = Kant
Event Sink
Fork
left
Philosopher
right
Event Source
Philosopher
Fork
info
name = Descartes
name
Philosopher
name = Aristotle
85
Observer
86
Philosopher State Types
enum PhilosopherState
{
EATING, THINKING, HUNGRY,
STARVING, DEAD
};
Philosopher Component
component Philosopher
{
attribute string name;
// The left fork receptacle.
uses Fork left;
// The right fork receptacle.
uses Fork right;
// The status info event source.
publishes StatusInfo info;};
Philosopher
name
eventtype
{
public
public
public
public
public
};
StatusInfo
string name;
PhilosopherState state;
unsigned long ticks_since_last_meal;
boolean has_left_fork;
boolean has_right_fork;
87
name
88
Fork Component
Observer Component
Observer Home
ForkHome
Philosopher
home PhilosopherHome manages Philosopher {
factory new(in string name);
};
exception InUse {};
interface Fork
{
void get() raises (InUse);
void release();
};
// The fork component.
component ForkManager
{
// The fork facet used by philosophers.
provides Fork the_fork;
};
// Home for instantiating ForkManager components.
home ForkHome manages ForkManager {};
PhilosopherHome
Observer
Fork
Manager
component Observer
{
// The status info sink port.
consumes StatusInfo info;
};
// Home for instantiating observers.
home ObserverHome manages Observer {};
89
90
Distributed Component Object Model
(DCOM)
Client Programming Model
•
Component-aware and -unaware clients
•
Clients see two design patterns
Basic Technique in Microsoft's Windows: COM (Component 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
– Factory – Client finds a home and uses it to create a new component
instance
ActiveX:
• covers the tasks of OLE, together
with new features like starting
variants, scripting support, …
– Finder - Client searches an existing component instance through Name
Service, Trader Service, or home finder operations
•
Invokes operations on component instances
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
CCM by this offers a powerfull architecture to construct really distributed
applications.
But: there are lots of other, different middleware concepts, too.
91
• 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
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
• 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
create
Reference: IUnknown
• Each interface is assigned with a globally unique Interface Identifier (IID)
IUnknown
• 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.
93
QueryInterface(deposit)
withdraw getBal.
setBal.
deposit
Reference: deposit
94
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
• One specification of an interface
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
• Re-use of the specification
DCOM
• A new specification for
each mapping to a
programming language
• Separate translation of
the interface for each
language
CORBA
95
96
Object Identifiaction and Activation
Communication in DCOM
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
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
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
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
97
• 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
Events
Passing Interface Pointers
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
• 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
99
100
Naming in DCOM
Types of Monikers
• 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
Moniker type
Description
File moniker
Reference to an object constructed from a file
Step
Performer
Description
URL moniker
Reference to an object constructed from a URL
1
Client
Calls BindMoniker at moniker
Class moniker
Reference to a class object
2
Moniker
Looks up associated CLSID and instructs SCM to
create object
Composite moniker
Reference to a composition of monikers
3
SCM
Loads class object
Item moniker
Reference to a moniker in a composition
4
Class object
Creates object and returns interface pointer to
moniker
Pointer moniker
Reference to an object in a remote process
5
Moniker
Instructs object to load previously stored state
6
Object
Loads its state from file
7
Moniker
Returns interface pointer of object to client
101
102
Active Directory
GLOBE
• 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
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
103
104
Globe Object Model
Composed Objects
• Not 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
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
105
• Control subobject is intermediate
between user interface and all
object functions
106
Process-to-Object Binding
Communication
• No concepts like type library and registry for getting interface descriptions and
activating objects.
• Used in Globe:
• 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
107
Globe Client and Server
Naming
Client:
Process bound to a distributed shared object, invoking this object by
making calls at the control subobject (process A on the last slide)
Server
Process that can handle only invocations coming in through the
network (processes B and C on the last slide)
Additionally:
object servers for supporting distributed shared objects/hosting local
objects. Interface for such object servers:
Method
Description
Bind
Lets the server bind to a given object, unless it is already bound
AddBinding
Lets the server bind to an object, even if it is already bound
CreateLR
Lets the server create a local object for a new distributed object
RemoveLR
Lets the server remove a local object of a given object
UnbindDSO
Lets the server remove all local objects of a given object
ListAll
Returns a list of all local objects
ListDSO
Returns a list of all local objects for a given objects
StatLR
Get the status of a specific local object
108
•
•
•
•
•
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
Description
Protocol identifier
A constant representing a (known) protocol
Protocol address
A protocol-specific address
Implementation handle
Reference to a file in a class repository (URL)
Instance address:
109
Field
Description
Implementation handle
Reference to a file in a class repository
Initialization string
String that is used to initialize an implementation
110
Comparison of CORBA, DCOM and
Globe
Globe Naming Service
Simple naming service with human-friendly names:
• Based on DNS
• Names are represented by a Uniform Resource Identifier (URI)
111
Comparison of CORBA, DCOM and
Globe
Issue
CORBA
DCOM
Globe
Naming service
Yes
Yes
Yes
Location service
No
No
Yes
Object reference
Object's location
Interface pointer
True identifier
Synchronisation
Transactions
Transactions
Only intra-object
Replication
support
Separate server
None
Separate
subobject
Transactions
Yes
Yes
No
Fault tolerance
By replication
By transactions
By replication
Recovery support
Yes
By transactions
No
Security
Various
mechanisms
Various
mechanisms
More work needed
113
Issue
CORBA
DCOM
Globe
Design goals
Interoperability
Functionality
Scalability
Object model
Remote objects
Remote objects
Distributed objects
Services
Many of its own
From environment
Few
Interfaces
Language-dependent Binary
Binary
Synchronous
communication
Yes
Yes
Yes
Asynchronous
communication
Yes
Yes
No
Callbacks
Yes
Yes
No
Events
Yes
Yes
No
Messaging
Yes
Yes
No
Object server
Flexible (POA)
Hard-coded
Object dependent
Directory service
Yes
Yes
No
Trading service
Yes
No
No
112

Limitations of Object-Based Middleware Components

Transcrição

Documentos relacionados

Security in Communication Networks

Naming vs. Locating Entities Simple Solution for a

Layer 1 – Physical Layer Transmission Media Twisted Pair

Application Example: WWW Communication in the WWW WWW

Wireless Broadband Networks 802.16

Mobile Communications

Mobile Communications

Chapter 2 - Informatik 4

History of Optical Disks Basic Technology Basic

On the Way to Today`s Internet ARPANET ARPANET

Metropolitan Area Networks Resilient Packet Ring

Mobile Communications Structure of the Lecture

Data Encryption Standard (DES) General Structure of

das institut für südasien-, tibet- und

Transfer and Control Protocols Standards of ITU H.261

Name of Module: Biometric Identification Credit Points (ECTS):3

Wireless Ethernet Wireless LANs: Design Goals

Mangamarkt Anmeldung

Naming - Informatik 4

An die Bundeskanzlerin Angela Merkel Bundeskanzleramt Willy

Network Categories Network Types for the Local

Video Signal Representation Visual Representation