Effective Architectures for Distributed Object Computing

Effective Architectures for Distributed Object Computing

Michael Stal Siemens AG, Corporate Technology Dept. ZT SE 2 E-mail: [email protected]

Goals of this tutorial l Basic

architectural understanding of OO Middleware. l Better leveraging Component Platforms. l Demonstrating basic design pitfalls.

14:55

Michael Stal - Middleware Architecture

2

Content l l l l l l

Motivation Fundamental architectural principles Case Study: COM/COM+ Platform Comparison Design Issues Summary

14:55


3

Motivation l Driven

by the Internet as well as mobile and embedded devices distributed solutions are now considered common place. l However, building distributed applications is a non-trivial task. l Thus, the question is: how can we efficiently build and deploy such applications? 14:55


4

Motivation (cont’d)

The obvious architecture for such systems is a multi tier approach which provides a clear separation of concerns. 14:55


5

Services of the Middle Tier l The

services in the Middle Tier participate in different kinds of tasks: – They must participate in the workflow of integrated

„business“ processes. – They must connect to databases and other backend systems for data storage and service access.

14:55


6

Middle Tier Architecture l Problem:

Functionality in the middle tier is always subject to change and adaptation. It is used in unforeseen contexts (from different clients). l Solution: The middle tier should not be structured as a monolithic unit but rather be decomposed. 14:55


7

Component-based Software l Components

are the appropriate means for decomposition:

®

Presentation Tier components: ® ® ® ®

14:55

they typically represent sophisticated GUI elements. they share the same address space with their clients. their clients are containers that provide all the resources. they send events to their containers.

®

Middle Tier components: ® ® ®

they typically provide serverside functionality. they run in their own address space. they are integrated into a container that hides all system details.


8

Requirements for Distributed Componentbased Applications – Transparent, platform-neutral communication. – Activation strategies for remote components. – Non-functional properties such as performance, – – – – – 14:55

scalability, Quality of Service. Mechanism to find and create remote components. Keeping state persistent and consistent. Security issues. Data transformation. Deployment and configuration. Michael Stal - Middleware Architecture

9

Using Standard OO Middleware l l l l l

14:55

What about using plain CORBA or DCOM ? Yes, they provide an OO-RPC, But: developers must integrate services such as transactions or security themselves. Integration done by developers may require more than 50% of development time. Conclusion: An object-oriented RPC helps to connect different islands of code, but is not sufficient for building the middle tier.


10

Architecture for Middle Tier Components l Let

us introduce step by step some of the architectural elements required to build sophisticated middle tier component infrastructures.

14:55


11

Communication l

l

In Multi Tier systems we need to connect the tiers as well as the components within these tiers using communication mechanisms. There are four main styles of communication: – Collocated client/server (native procedure call) – Synchronous RPC – Asynchronous RPC – Message Queueing (Publish/Subscribe, Peer-to-Peer)

14:55


12

Handling Synchronous Communication

® Remote

components should appear same as local components from a communication perspective. ® Clients and servers should be oblivious to communication issues.

14:55


13

Proxy Pattern Solution Provide a placeholder for the object through which clients can access it

AbstractService Client service

A Service implements the object which is not directly accessible. Proxy

Service 1

service

1 service

A Proxy represents the Service and ensures the correct access to it. The Proxy offers the same interface as the Service. Clients use the Proxy to get access to the Service.

14:55


14

Dynamics Client

Proxy

Service

service pre-processing: marshaling service

post-processing: unmarshaling

14:55


15

Benefits and Liabilities Benefits

Liabilities

Access control to originals. Memory savings. Performance gaining (cache proxy). Separation of housekeeping and functionality.

14:55

Potential overkill, if proxies include overly sophisticated functionality. Level of indirection.


16

Proxy++ l However,

using proxies is not sufficient:

– How do we locate remote components? – How do we handle communication establishment

and exchange of network packets (the protocol)?

14:55


17

Object-Oriented Middleware l What

we need is an architecture that ...

– supports a remote method invocation paradigm – provides location transparency – allows to add, exchange, or remove services

dynamically – hides system details from the developer

14:55


18

Architectural Pattern: Broker Message exchange

Client-side Proxy

*

1

Message exchange

Broker

1

*

Server-side Proxy

marshal

main_loop

marshal

unmarhal

srv_registration

unmarshal

receive_result

srv_lookup

dispatch

service_p

transmit_message 1

receive_request

*

*

calls calls

1

Client

14:55

Bridge marshal

calls 1

Server

call_service_p

unmarshal

start_up

start_task

forward_message

main_loop

transmit_message

service_i


19

Broker Dynamics Client

Client Proxy

Broker

Server

Server Proxy register_service

method (proxy)

start_up assigned port

locate_server server port marshal receive_request

unmarshal dispatch method (impl.) result marshal receive_result unmarshal result

14:55


20

Benefits and Liabilities l Pros – Broker and Proxies hide – – – – –

14:55

communication Details of the OS are also hidden Interoperability with other brokers (bridges) Reusability of services Location Transparency Dynamic Reconfiguration

l

Cons – Restricted efficiency due

to indirection – Multiple points of failure – Testing and debugging harder as with all distributed systems


21

Generation of „Glue“ l Who

is in charge to implement all of these factories, proxies, etc.? l Generator tools provide the generation of necessary artifacts from high level language data definitions: Interface

Generator

Specif.

14:55

Proxy Code


22

Problem: Activation l It

is not feasible to have all server implementations running all the time. l Thus, there must be a way to activate servers on demand. l Which activation strategy should a broker follow?

14:55


23

Solution Integrate activation code for automatically starting up server implementations. Provide necessary information in tables:

Client useService Activation Table Get Service

insertEntry removeEntry lookupEntry changeEntry

The Activation Table stores associations between services and their physical location.

Activator

(de)activate getService register unregister onShutdown

14:55

Upon incoming requests the Activator looks up whether a target object is already active. If the object is not running it activates the implementation.

Service

service shutdown

The Client uses the Activator to get service access. A Service implements a specific type of functionality that it provides to clients.


24

Dynamics: Sample Scenario Activ. Table

Activator

Client getService

lookupEntry [not active] activate

Implementation changeEntry result

object

port service

onShutdown

changeEntry

14:55


25

Asynchronous and TimeIndependent Communication l Using

conventional semantics brokers support only blocking communication: – Clients must wait until their invocation returns.

Even if they use multi-threading the underlying brokers will block. – A receiver must be online. However, this can not always be guaranteed. 14:55


26

Sender

Solution Message API

Solution

Queue

Introduce intermediary queues between senders and receivers : Queues are used to store messages persistently. They cooperate with other queues for message routing.

store forward remove Message

Queue

Receiver

14:55

A sender sends messages, while a receiver receives them.

store forward remove

Messages are objects send from a sender to a receiver.

Message API

A Message API is provided for senders and receivers to send/recv messages.


27

Dynamics Sender create send

Message API

Queue

Queue

Message API

Message Message Message store

Message forward

Receiver receive

create

receive Message Message read

14:55


28

Developer‘s View l OO

developers prefer request/response semantics: – Two message types are used: l Requests contain in/in-out arguments l Results carry out/inout arguments and results – Callback object or Poller object to retrieve result. – Player/Recorder strategy: Recorder enqueues

request-part of invocation, Player dispatches to actual implementation and enqueues result-part. 14:55


29

Publish/Subscribe l l

Usually, a specific client calls a specific remote server and blocks until the result returns. Sometimes, this strategy is not sufficient. Consider a server that reports share values. l A polling strategy leads to performance bottlenecks. l The share values could be spread across different servers. l More than one client is interested in the information.

l

How can we decouple clients and servers?

14:55


30

Solution Decouple suppliers (publishers) and consumers (subscribers) of events:

Event Queue Publisher produce

attachPublisher detachPublisher attachSubscriber detachSubscriber

creates

*

Subscriber consume

Publishers create events and store them in an event queue with which they have previously registered. Consumers register with event queues from which they retrieve events.

receives

Event

Filter filter

An Event Queue is storing events.

Events are objects used to transmit state change information from publishers to consumers. For event transmission push-models and pullmodels are possible. Filters could be used to filter events on behalf of subscribers.

14:55


31

Dynamics Publisher

Event Queue

Subscriber

attachSubscriber produce

Event

pushEvent event pushEvent event consume

detachSubscriber

14:55


32


Liabilities

Decouples consumers and producers of events. n:m communication models are supported.

14:55

Must be careful with potential update cascades.


33

How to provide and evolve component functionality l Every

Component Model defines how components should import and export functionality. l Components should be able to evolve over time without impact on clients.

14:55


34

Multiple Interfaces l Most

objects have only one interface. l Thus, if we want the banana, we get the whole gorilla. l How can we make this more flexible?

14:55


35

Extension Interface Pattern Ask for a reference to an interface

Client

Root QueryInterface

Call_service

Call a service on an interface

*

CreateInstance *

Factory Create_Component

1

*

new

Component Create_Component

1+

implements

Extension Interface i QueryInterface service_i

Server Initialize unititialize

14:55


36

Dynamics Client

Factory

Start_client CreateInstance(Ext.Intf. 1)

Component new

Extension 1

Extension 2

create create

Ref. To Extension1 service1

QueryInterface(Extension Interface 2) Ref. To Extension2 service2

14:55


37

Benefits and Liabilities Benefits Exchangeability of components Extensibility through interfaces Prevention of interface bloating No subclassing required Separation of concerns

14:55

Liabilities Restricted efficiency due to indirection Complexity and cost for development and deployment


38

Client/Component View l As

we saw so far, clients access component functionality using synchronous RPCs or other communiation styles. l The next question is how to create new components or find existing ones. Client

14:55

? Michael Stal - Middleware Architecture

39

Solution: Factory/Finder Pattern AbstractComp

Separate the management of components from their use:

InstanceA AbstractHome findA findB

ConcreteComp

◆

An Abstract Home declares an interface for operations that find or create abstract instances of components.

◆

Concrete Homes implements the abstract Home interface for finding specific instances or creating new ones.

◆

Abstract Comp. declares interface for a specific type of component class.

◆

Concrete Comp. define instances.

◆

A Primary Key is associated with an a component.

InstanceA

ConcreteHome find create

Primary Key

14:55


40

Dynamics Component

Home

Client create

Primary Key Primary Key

find („Tom“);

lookup

Component method

14:55


41

Finding the Homes Client

l Homes

allow to create and find components, but how do we locate the homes? l Anwer: Use a global directory service

14:55

Node getName

*

Binding getObject


Directory

resolve listNodes navigate newBinding newSubDir remove

42

Component/Container View l l

In order to shield components from the underlying infrastructure specifics, containers are introduced. Containers are responsible to: – Manage the lifecycle of components and notify components

about lifecycle events such as activation, passivation, transaction progress. – Provide components uniform access to services such as transactions, security, persistence. – Register and deploy components. Component 14:55

?


Container 43

Container An container is a runtime environment for components that might be based upon - a Web Server or - a Database Server or - a CORBA Server or - a TP-Monitor or - an Operating System, ...

14:55

Client

Client

Container

Imperative Programming

Server Component

Server Component

Declarative Programming

Transaction Security Resources ...

Transaction Security Resources ...


...

44

Interception l l

l

l

A component developer does not know a priori in which environment his component will execute. Components should specify declaratively in configuration files which execution contexts they require. The container then should provide the right execution environment, e.g., by creating a new transaction when required. But how can we make this strategy work?

14:55


45

Solution Context

provide Runtime runEventLoop attachInterceptor manage interceptors

Abstract Interceptor

callback attach * handleEvent

Runtime represents the framework to which we like to attach interceptors. It is responsible for managing and calling interceptors. Concrete Interceptors implement the event handler for the system specific events they have subscribed for.

handleEvent

Concrete Interceptor

Introduce interceptors that can be attached to a system for handling particular events. Whenever an event occurs, the associated interceptors get automatically called:

Container

Context contains information about the event and allows to modify the system behavior after interceptor completion. The container is responsible for registering its interceptors with the runtime.

14:55


46

Dynamics Runtime

Application

runEventLoop

create

Interceptor

attach Interceptor Place interceptor in internal interceptor map event Look for registered interceptors create

Context

handleEvent Context

14:55


47

Container Interception l l

l

The container intercepts all incoming requests from clients. It reads the component‘s requirements from a XML configuration file and does some pre-processing before actually delegating the request to the component. Interception also enables performance strategies such as Just-in-Time Activation, Object Pooling, and Caching.

14:55


48

Container/Component Interfaces lA

component provides event interfaces the container automatically invokes when particular events occur (such as activation or passivation). l The container provides generic interfaces to the component that it can use to access container functionality such as transaction control.

14:55


49

Component Lifecycle l Who

is in charge to activate and passivate a component? – Container is responsible to activate a component. – Component can be passivated by itself, the

container, after each method call, after each transaction.

14:55


50

Persistence Strategies l l

l l

Components might directly access their persistent data (Component-managed Persistence). Containers might automatically generate persistence code upon deployment (Container-managed persistence). Persistence Providers might be accessed directly (lowlevel Persistence). An Adapter layer might hide the component from persistence provider specifics (Persistence service).

14:55


51

Service Access and Integration l Within

their configuration files component providers might specify: – Role-based Security: Who is allowed to call which

component methods, etc. – Transaction Attributes: How the component uses transactions. – Persistence Issues. – Concurrency and Synchronization Requirements. 14:55


52

Transactions

Applications that leverage distributed objects also have distributed state. How can we keep this state consistent and persistent in a distributed environment? 14:55


53

2PC Transaction Pattern Transaction Proxy commit rollback begin getCoordinator getTXInfo

A Client is responsible for defining transaction boundaries as well as for starting and stopping transaction.

Client initiateTX controlTX

call

Introduce a transaction-based paradigm for distributed objects:

Coordinators coordinate the cooperation of distributed objects within a transaction.

Coordinator prepare commit rollback register

A Resource changes its internal state during a transaction. It registers with the coordinator. register

Transactional Object Transactional Object service service

14:55

Resource Resource prepare commit rollback service

A Transactional Object participates in a transaction but its state remains unaffected by the transaction. A Transaction Proxy allows clients and objects to retrieve information and control transactions.


54

Dynamics Client

Account 1

Account 2

Coordinator

Context begin

withdrawMoney get_itf enlisten account1

depositMoney get_itf

enlisten account2

commit commit prepare prepare commit commit

14:55


55


Liabilities

ACID properties are guaranteed. Transaction-based handling of distributed objects. Clients largely unaffected.

14:55

Resources must implement specific protocol to participate in transactions.


56

Component Types l We

14:55

can identify different component types:

Coupling to Container

„History aware“

Primary Key

Component Categories

transient

No

No

Service

transient

Yes

No

Session

persistent

Yes

No

Process

persistent

Yes

Yes

Entity


57

Component Packaging l Basically,

a ready-to-run component consists of:

– Resources – Binaries – Configuration Information

lA

component infrastructure must also define how these artifacts are combined and wrapped.

14:55


58

Roles

Persistence Provider Provides storage facilities

Component Provider A Application Assembler takes components and plugs them together

Deployer Deploys acomponents and applications

Container Provider

Server Provider

provides containers where the components live

provides the operating environment aka Application Server, may be a OS vendor, ORB vendor, Database vendor, ...

Component Provider B System Administrator responsible for configuration and adminitration of enterprise environment

14:55


59

Container Interface

Scenario

6‘‘. New

10. Intercept 13. Delegate

4. Create Component

Factory Proxy Comp. Proxy

Client

3. New

6‘‘‘. Set Interface 1. Deploy

Container

7. New

5. Intercept and delegate

9. Call method 11. Query Config. 8. Return Ref

Component Configuration Factory/Finder

2. Enter info

Configuration Database

12. Create Transaction

Transaction Service 14:55


60

Now, just select the right standard J l COM+,

Windows DNA 2000, Microsoft.NET or l CCM, CORBA 3 or l EJB, J2EE Andrew Tanenbaum: „The best thing about standards is that there are so many to choose from“ 14:55


61

Ingredients of EJB JNDI

Naming Service 1) lookup home

Deployment Descriptor

2) create bean 2”) find bean

EJB Context

EJB Home

EJB Jar

Remote Bean Home Interface

new 4

Client

EnterpriseBean

EJB Object

4) remove 3) Use bean

Remote Bean Interface

ejbCreate ejb...

Bean Instance

bean-methods

Application Server (Container) 14:55


62

Flavors of Enterprise Beans l There

are three flavors of enterprise Beans:

– A session bean type (mandatory for EJB 1.0 and EJB 1.1

compliant containers) – An entity bean type (mandatory in EJB 1.1 compliant containers) – A message bean type (mandatory in EJB 2.0 compliant containers, but not covered here)

14:55


63

CORBA Components = EJB2 BEA Systems DSTC Expersoft Genesis IBM Inprise Iona Oracle Rogue Wave Unisys 14:55

PLUS • Sun Microsystems • Hewlett Packard • UBS, AG • Fujitsu Limited Michael Stal - Middleware Architecture

64

CORBA Containers Home

XML Configuration

Client Component

POA

Container Containers shield clients and components from the details of the underlying ORB, services, network + operating system specifics.

Transactions

Security

Persistence

CORBA ORB Operating System

14:55


65

Case Study: COM+ ® Microsoft‘s

14:55

Vision: COM+ everywhere


66

COM+ Interfaces l An

interface in COM is a grouping of semantically related functionality: interface IBank { HRESULT deposit ([in] long amount); HRESULT withdraw ([in] long amount); HRESULT getAmount ([out, retval] long *amount); }

l Each

interface defines a contract between the user and the interface implementor.

14:55


67

COM Interfaces (cont‘d) COM+ implements the Extension Interface Design Pattern: l Each COM interface is derived from the base interface IUnknown: – HRESULT QueryInterface (REFIID, void **p); – long AddRef(); – long Release();

l

If you have one interface of a COM Object, you can get any other interface by using QueryInterface.

14:55


68

COM Interfaces (cont‘d) l But

how do you get your first interface? l Anwer: By using the COM API! Get Interface Ptr

Which Component

HRESULT hr = CoCreateInstance(CLSID_COMponent, NULL, CLSCTX_INPROC_SERVER, IID_IUnknown, (void**) myIUnkPtr); Preferred Location

Which Interface

Return value

if (SUCCEEDED(hr)) { myIUnkPtr->QueryInterface(IID_MyInterface, &myIPtr); myIPtr->service1(...); }

14:55


69

COM‘s Binary Standard lA

COM Interface is accessed through a virtual table pointer: vptr

&QueryInterface

Implementation of QueryInterface

&AddRef

Implementation of AddRef

&Release

Implementation of Release

&Service1

Implementation of Service

This fact is often hidden by the underlying programming environment (e.g., Visual Basic, Delphi, Visual J++, C#).

14:55


70

Microsoft IDL l Interfaces,

Classes, .. are defined using

IDL: [uuid(12345678-1234-1234-1234-123456789ABC), object] interface ISearch : IUnknown { import “unknwn.idl"; HRESULT enterKey([in] BSTR key, [in] Variant entry); HRESULT searchKey([in] BSTR key, [out, retval] IIterator **retval); HRESULT removeKey([in] BSTR key); HRESULT removeEntry([in] BSTR key, [in] Variant entry); } 14:55


71

Type Libraries l The

MIDL-Compiler can also generate type libraries used for dynamic wiring (necessary for Scripting and Browser environments). l ProxyStub Implementations as well as Type Libraries are also registered in the Registry, so that COM can find them.

14:55


72

Application-driven Dispatch l The

dispatch of incoming request for a COM Interface is done by the stub. l If you want to dispatch yourself, use IDispatch: interface HRESULT HRESULT HRESULT HRESULT }

IDispatch : IUnknown { Invoke(/* dispatching requests to internal methods */); GetIDsOfNames(/* Convert user-readable name to index*/ ); GetTypeInfoCount(/* Is type info available? */); GetTypeInfo(/* return type info */);

l Benefit:

Only need to handle one COM interface l Liability: Yet another indirection layer! 14:55


73

Implementations l Where

COM-objects can live:

– In a DLL that is attached to the client (INPROC) – In a local EXE-server (LOCAL) – In a remote server on another machine (REMOTE)

l For

14:55

the client this remains transparent.


74

COM-style new-operator l To

instantiate several objects of a COM class, factories are provided (one per class implementation): new

Factory

COM Class

CreateInstance() LockServer()

When a client requests a COM object, the COM API activates the implementation and calls the factory. 14:55


75

Instantiating an Object Client

COM Runtime

Registry

CoCreateInstance CLSID_BankAccount, NULL, CLSCTX_INPROC, IID_IBankAccount, ppBankAccount

[not loaded] result C:\MyDLLServers\bank.dll

loadLibrary

DLL

C:\MyDLLServers\bank.dll

Factory

GetProcAddress „DllGetClassObject“

result &ProcAddress

DLLGetClassObject CLSID_BankAccount IClassFactory &pFactory

CreateInstance

NULL, IID_IBankAccount ppBankAccount

MyBank QueryInterface

result IBankAccount

result IBankAccount

14:55


76

DCOM l (D)COM

provides a Broker Architecture l It simply is COM with a longer wire. l Object-oriented RPC based upon DCE RPC. l Additional methods in the COM API. l Delta Pinging for garbage collection. l DCOMCNFG for setting security and other issues. l Apartment models for threading. 14:55


77

DCOM (cont‘d) Client

Server

Proxy

Stub

DCE RPC

COM Infrastructure 14:55


Stub 78

Concurrency Issues l

l

l

In a MTA (Multi Threaded Apartment) objects may be executed by different threads (no thread affinity). Synchronization done by the developer. In a STA (Single Threaded Apartment) all requests are synchronized using a Windows queue. Objects in STA are executed by their creator‘s thread. If client‘s and component‘s apartment types are not compatible the runtime creates a proxy.

14:55


79

Microsoft Transaction Server l l

l l

While COM separates interface from implementation, MTS separates behavior from state. MTS defines a framework (a set of COM interfaces and a runtime) in which databases (resource managers) can enlisten. In-process COM objects can participate in transactions. A distributed two-phase commit protocol is supported using the Distributed Transaction Coordinator.

14:55


80

MTS Containers

l

MTS is a container: When a client calls CoGetClassObject for a registered COM object, a reference to an internal object is returned so that MTS can intercept all incoming requests. l Objects within a MTS surrogate process might be temporarily deactivated and activated on demand (Just-in-Time Activation). Thus, resources can be shared actively and efficiently. l Applications that want to execute code before the object is deactivated and before it is activated can implement IObjectControl. interface IObjectControl: IUnknown { HRESULT Activate(void); // called after activation void Deactivate(void); // called before deactivation BOOL CanBePooled(void); // recycle the object? }

14:55


81

Container Interface l

Each object running in the MTS environment is shadowed by a context object that maintains information about the object. Context object auomatically created by MTS: interface IObjectContext: IUnknown { HRESULT CreateInstance([in] REFCLSID rclsid, [in] REFIID riid,[out, retval, is_iid(riid)] void **ppv); HRESULT SetComplete(void); HRESULT SetAbort(void); HRESULT EnableCommit(void); HRESULT DisableCommit(void); BOOL IsInTransaction(void); BOOL IsSecurityEnabled(void; HRESULT IsCallerInRole([in] BSTR bstrRole, [out, retval] BOOL* pfIsInRole); }; 14:55


82

Transactional Behavior l

Each MTS object must be associated with a transaction mode: – TRANSACTION_REQUIRED: Methods of the object must

execute within the scope of a transaction. When the client does not run within a transaction, a new transaction is automatically created by MTS. – TRANSACTION_REQUIRES_NEW: Methods of the object

must execute within their own transaction. Thus, a new transaction is automatically created by MTS. – TRANSACTION_NOT_SUPPORTED: The component does not

support transactions. – TRANSACTION_SUPPORTED:

Component

inherits

transaction status from client. 14:55


83

What is COM+ l l l l

First of all: COM+ = COM + Services COM+ is MTS 3.0 It is integrated to Windows 2000 It contains a lot of services such as – – – – – –

14:55

Transaction Serrvices (MTS) Security Services Synchronization Services Queued Components Event Service COM+ Catalog = RegDB + Registry Michael Stal - Middleware Architecture

84

COM+ Application Server l Surrogate

DLLHOST.exe (container) hosts COM+ components. l Interception used to intercept incoming requests. COM+ Object Context Wrapper

Client

DLLHOST.EXE IObjectContext

COM+ Catalog 14:55

Transactions

COM+ Events


Security

85

COM+ Applications l l l l l

A COM+ application is a package that consists of a collection of in-process middle-tier components. Administration/Configuration done on a per-application basis. MMC (Microsoft Management Console) for adding/removing apps. Server Application runs as a separate process. Library Application runs in client address space and cannot leverage most services such as object pooling, ...

14:55


86

Queued Components l

l

Queued Components use MSMQ instead of COM. Every interface can be marked as queued if its methods have no out, in-out, retval arguments. Queue Moniker responsible on the client side to start a recorder: GetObject(“queue:/new:MyBank.Bank”) QC.ListenerHelper to be activated on server site.

l

Queue operations may participate in transactions.

l l

Client

Server Recorder

14:55

Queue


Player 87

Neutral Apartments and Synchronization l Neutral

apartment introduced for efficiency reasons. l NA object is always instantiated in NA apartment. Creator receives lightweight proxy. l Synchronization service with activities (set of objects) use casuality IDs for locking sychronization. 14:55


88

Advanced Topics

14:55


89

Dynamic Environments l Until

now, clients can only access services that are available at compile-time. l Typically, in distributed environments services must be dynamically added, exchanged, or removed. l How can we access objects that are not known at deployment-time? 14:55


90

Simplified Reflection Pattern accesses

Client

Solution

Reflection API

Provide type information through meta objects and allow clients to find and use this meta information:

access and use meta information

Meta Object Information dynamicServvice

use services

1

Abstract BaseObject

Meta Objects provide information and functionality about existing base objects. The Reflection API is responsible for creating and retrieving Reflection Objects. Base Objects implement the application functionality.

getInformation

Clients access Meta Objects to dynamically invoke base functionality. 1

Concrete BaseObject service

14:55


91

Dynamics Meta Object

Client

Reflection API

Object

Object getMetaObject MetaObject metaInformation

analyze meta info and invoke meta services Invocation dynamicService

service service execution

Result

14:55


92


Liabilities

Support for change. Clients may dynamically invoke objects without compile-time knowledge. Support for visual builder tools and for scripting environments. Base Objects may be added at run-time.

14:55

Possible performance problems. Implementation harder to maintain and understand.


93

Fault Tolerance ® To

enhance fault tolerance, more than one server should provide the same service. ® It should be transparent to the client that replicated servers are used. ® How can we introduce this kind of transparency?

14:55


94

Object Group Pattern Object Group dispatchRequest enterGroup leaveGroup selectCoordinator

Decouple suppliers (publishers) and consumers (subscribers) of events: An Object Group represents a group of objects that all provide the same service. Object provides a specific service to clients.

*

The coordinator is selected by the Object Group to dispatch requests.

Object service

Worker service

14:55

1

Coordinator

State

Workers receive requests from their coordinator and return results. Each member of the object group maintains its own state.

service


95

Dynamics New Worker

Object Group

Coordinator

Worker

enterGroup newWorker Object N

freezeState

synchronizeState event request dispatchRequest service service returnResult result

14:55


96


Liabilities

Resilience to failures in distributed object implementations. Clients unaffected by object group internals. State remains consistent.

14:55

Overhead due to several indirection layers.


97

Concurrency and Scalability Issues l Typically,

multiple clients share the same server

objects. l If everything gets serialized, Quality of Service will not be very good. l Is an optimization possible?

14:55


98

Coordinator-Worker Pattern Servant

Problem Object

Client 3

Client 2

If multiple clients share servant, we must coordinate access to it: Methods invoked on the object should not block the entire process thus downgrading the QoS of other objects. Synchronized access to the object should be simple. Clients should be unaware of the parallelism.

Client 1 Client 14:55


99

Solution: Coordinator-Worker

Client

Coordinator

Decouple method invocation from method execution:

methodA methodB

Request

Queue

A request is created for every method invoked.

enqueue dequeue

Concrete MethodRequest1


A coordinator retrieves requests and creates requests it places into the queue.

A worker dequeues the requests from the queue and dispatches them to the actual method implementation. It returns the result to the client. An queue retains all pending requests.

Worker Worker Worker

14:55

A client invokes methods.

dispatchRequest dispatchRequest dispatchRequest


100

Dynamics Client

Coord.

Queue

Worker

method

Request

enqueue

Request

dequeue getInfo dispatch

result

14:55

A client invokes a method on the coord.. The coordinator creates a request and places the request to the queue. The worker is ready for new work and dequeues he request. It reads all information relevant with the request and dispatches the request to the actual implementation. The worker sends the result back to the client.


101


Liabilities

Enhances concurrency. Transparent leveraging of available parallelism. Separates receiving of requests from their execution.

Method execution order can differ from method invocation order. Performance overhead. Complicated debugging.

14:55


102

Asynchronous Cooperation l Using

synchronous RPCs, clients must block until servers return. l Sometimes, clients are interested to continue their work and retrieve the result at a later time. l How can we accomplish this kind of decoupling?

14:55


103

Solution Decouple method invocation from method execution: Proxy method_1 method_N

Activation Queue

Scheduler enqueue dispatch

creates

creates

Future

enqueue dequeue

maintains

* MethodRequest

guard call

Servant method_1 method_N

A proxy provides an interface that allows clients to access methods of an object. A concrete method request is created for every method invoked on the proxy. A scheduler receives the method requests and dispatches them on the servant when they become runnable. An activation queue maintains pending method requests.



A servant implements the methods. A future allows clients to access the results of a method call on the proxy.

14:55


104

Dynamics Client

Proxy

Servant

Scheduler

method

Future Method Request enqueue

dispatch write

read

14:55

call

method

A client invokes a method on the proxy. The proxy returns a future to the client, and creates a method request which it passes to the scheduler. The scheduler enqueues the method request into the activation queue (not shown here). When the method request becomes runnable, the scheduler dequeues it from the activation queue (not shown here) and executes it. The method request executes the method on the servant and writes results, if any, to the future. Clients obtain the method’s results via the future.


105


Liabilities

Enhances concurrency. Simplifies synchronized access to a shared object that resides in its own thread of control. Transparent leveraging of available parallelism.

14:55

Method execution order can differ from method invocation order. Performance overhead. Complicated debugging.


106

Deployment l Up

to now, every component must be manually placed on a network node and registered. l In a real world system, this would lead to severe administration problems. l We prefer the infrastructure to install components automatically from a central location. 14:55


107

Deployer Pattern Problem It may be necessary to re-configure a system with new components or remove old components. However, The re-configuration must happen at run-time; and Everything must be done from a central location.

14:55


108

Deployer Solution-Structure Deployer

Administration

deploy remove

Centralize the system’s configuration in a separate component. Configuration

Concrete Configuration 1

*

Concrete Configuration 2

A configration consists of a code artifact and configuration data. A deployer takes a configuration and forwards it to an remote installer.

Installer

An installer takes the configuration package and installs it locally on its node.

install uninstall

14:55


109

Dynamics Deployer Deployer

Administrator create deploy

Installer

Config Configuration getTargetNode

getConfigData

Configuration install create

Service

delete

X

changeConfig remove

Configuration getTargetNode Configuration uninstall

14:55


110


Liabilities

Centralized administration. Increased configuration dynamism.

14:55

Lack of determinism, since configuration is done at run-time. Increased overhead compared to statically configured systems.


111

Locating services l In

a network services are dynamically added and removed. l Services might even be migrated to different locations. l How can we cope with dynamic reconfiguration?

14:55


112

Location Pattern Where is X?

Problem In distributed systems services are dynamically added and exchanged: Clients should be able to locate services without previous location knowledge; Services should be able to register themselves dynamically with the network;

X

14:55

Even the Location service itself should not be known in advance.


113

Solution Service

Location

provideSvc

Services provide application functionality.

Locator 0..1

findLocSvc

Locator

useSvc

14:55

LocationSvc

locateSvc registerSvc

findLocSvc

Client

Introduce a central component for retaining service information. Locate this component using multicast communication:

A client uses services. A location service retains information on services. It helps to locate and register these services. Locators are local objects used to locate the location service. A location is a newtwork node. It might provide at most one location service.


114

Dynamics Location 1

Locator API

Service

Location 2

Location Svc

Locator API

Client

findLocSvc query [not found] query Location Svc Location Svc

self

registerSvc

query

findLocSvc

Location Svc Location Svc lookupSvc

invoke

14:55


Service

115


Liabilities

Services can be dynamically registered with network. Clients can locate services without previous knowledge of location. Enhanced fault-tolerance through replicated location services. Leasing models possible.

14:55

Additional network roundtrips. Programming is (slightly) more difficult. If location service fails the whole system will fail (if you do not take care using replication).


116

Some Design Issues and Pitfalls

14:55


117

Think 3 Tier! Server Components are elements of the middle tier: Thin Client Presentation Tier

Client

Client

COM+ Application COM+

Business Objects Middle Tier

COM+ Server

Persistent Data Database Tier 14:55

DB Server Michael Stal - Middleware Architecture

DB Server 118

Modeling When to use session or service components

Every time, when you need to design processes, activities, that do not need recoverable state Every time, when the server must have memory (conversational state), use session components. Otherwise service comps.! to migrate logic to the middle tier

14:55


119

Modeling (cont‘d) When to use process or entity components To design persistent business processes and objects When you want to access data base tables OO-style but not to keep session specific data on the server. Process components help to model persistent workflows, entity components help to model database state. Entity components should not be used by the client directly: it is better if entity comps are only accessed by session comps.

14:55


120

Rule 1: Minimize communication overhead Do not define access methods (“setter/getter”) for single values, but introduce methods, that read or write multiple values at the same time. Use valuetypes when possible! Reason: You never get communication for free! - Every remote method invocation leads to network communication

In general, minimize number of invocations! - Transfer multiple data with each call! 14:55


121

The wrong way public interface Account … { … void setLastName(String n); String getLastName(); void setFirstName(String n); String getFirstName(); }

Client-Code

account ccm = …;

Application

ccm.setLastName(”Maier”);

COM+ COM+

ccm.setFirstName(”Hugo”);

server

…= ccm.getLastName(); 14:55


122

The right way public interface Account … { … void setPerson(Person p); Person getPerson(); }

public class Person implements Serializable { … void setLastName(String n); String getLastName(); void setFirstName(String n); String getFirstName(); }

Client-Code Account ccm = …; Person pers = new Person(); pers.setLastName(”Maier”); pers.setFirstName(”Hugo”);

Local Person

ccm.setPerson(pers);

14:55


Application COM+ COM+

server

123

Rule 2: Never transfer mass data Avoid methods that provide mass data. Better define a kind of iterator to get data in smaller portions. Keep the state of the iterator either in the server or in the server. BookStore store = …; String[] isbn; public interface BookStore … { … String last = null; String[] listISBN(String last); do { isbn = store. listISBN(last); } if (isbn != null) { // Computation …. last = isbn[isbn.length-1]; } } while (last != null); 14:55


124

Rule 3: Clients should not access entity components Entity Components should only be used by Session Components, or by Service Components, but not by clients directly. Reason: Otherwise, applications tend to be developed in Client/Server style.

Client

Session COM+

Entity COM+ Entity COM+

14:55


125

The Future l Web

Integration has become the most important issue nowadays. l ASP, JSP, Servlets enable gateways to middle tier functionality. l XML even enables data interchange and data transfer.

14:55


126

Broker @ Web • Firewalls are open for specific ports only such as port 80h • However, COM+ assigns ports dynamically.

Client

Server

call_service_p start_task

start_up http Port 80h

main_loop service_i

Idea: Leverage HTTP as underlying transport protocol 14:55


127

Broker @ Web (cont‘d) lA

protocol defines syntax, semantics and order of messages exchanged between peers. l Hence, we must also introduce a data representation. l If different brokers interoperate, data must be self-describing. l Idea: Define data representation with XML 14:55


128

XML + HTTP = SOAP l The

Simple Object Access Protocol defines an XML-based RPC protocol: POST /Server/Object HTTP/1.1

SOAP:Header Header 1

SOAP:Body

HTTP Transport 14:55


129

SOAP Messages l SOAP

defines two kinds of on-the-wire messages: requests and responses. l Requests denote the target to be called, as well as the in and in/out-parameters. l Reponses contain an error code or the result, as well as in/out- and out-parameters. l Messages are sent via M-POST or POST. 14:55


130

General Message Structure l

Here is a fully-featured SOAP Message:

SOAP messages are bracketed by envelopes headers are optional 12345678 this feature must be supported by the receiver Bill Gates message body 14:55


131

Example: Request Server

Client POST /magrathea/Shares HTTP/1.1 Host: 139.111.11.13 Content-Type: text/xml Content-Length: nnn SOAPAction: urn:magrathea.com:Shares:#getValue MSFT

14:55


132

Example: Response (on success) Server

Client

200 ok Content-Type: text/xml Content-Length: mmm 69

14:55


133

Example: Response (on app. error) Server

Client 200 ok Content-Type: text/xml Content-Length: mmm 200 header not supported No

14:55


134

XML is the Future l l l l l

SOAP defines a transport protocol based upon XML and HTTP. Leveraging HTTP helps clients and servers to circumvent firewalls. Using SOAP, web servers can be extended to full blown Broker architectures. Microsoft and CORBA vendors have already signaled their support for SOAP. Competitors: none

14:55


135

Case Study: Microsoft.NET l l l l l l l l 14:55

.NET Framework includes core services. Common Language Runtime that makes languages interoperable. Reflection Mechanisms included. C# as a new programming language. SOAP for communication (incl. SCL, DISCO). ASP+ for making components accessible as web services. .NET tries to present a uniform platform for componentbased software development. WinForms and WebForms for user experience. ADO+ for data access using XML. Michael Stal - Middleware Architecture

136

Platform Comparison

14:55


137

Platform Comparison CCM

EJB

COM+

Owner

OMG

Sun

Microsoft

Language Support

Many

Java

Many

Operating Systems

Many

VM

Windows 2000

Implementations

Many to arrive

Many

One

COTS Components

-

-

-

3rd Party Support

(++)

++

++

Developer Tool Support

(+)

(+)

(+)

14:55


138

Platform Comparison (cont‘d) CCM

EJB

COM+

Architectural Concept

Container & Interception



Patterns

Finder & Factory

Finder & Factory

Factory

Role Model

Multiple Interfaces

Single Interface

Multiple Interfaces

Activation

Container & POA

Container

Container & Runtime

Component Categories

14:55

Session, Session, Entity „Stateless“ Service, Session Process, Entity Michael Stal - Middleware Architecture 139


EJB

COM+

Communication

IIOP

IIOP/RMI

DCE/SOAP

Persistence

PSS

Serializat.

Databases

Events

Notification Service

Not yet supported

COM+ Events

Transactions

OTS

JTS/OTS

„MTS“

Security

CORBA Sec.

Security Package

COM+ Security

Asynchronous Com.

AMI/TII

JMS

Queued C.

Directory Service

CosNaming

JNDI

ADSI

14:55


140


EJB

COM+

Scalability

++

+

+

Communication Bridges

RMI-IIOP, COM, SOAP

RMI-IIOP, SOAP

IIOP, SOAP

Component Integration

EJB

CCM

n.a.

Installation and Configuration

Installation Deployment process

Depending on Container vendor

COM+ Explorer + Registry

Configuration Data

XML

XML

Proprietary

Administration support

n.a.

n.a.

n.a.

Dynamic Networks

n.a.

Jini

UPnP

14:55


141

Conclusions l Last

words r Middle Tie ts Compontiemne a

a Once upon ompany software c develop a decided to logy. Their o n h c te w e n defeat a goal was to dragon dangerous .... that used to

14:55


142

l l l l l

Conclusions

Building distributed systems is complex, but middle tier components help to master the complexity. Component/container infrastructures are required to seamlessly integrate core services and enable declarative programming. There are many similarities as we well as differences between COM+, EJB, and CCM. There are still some problems: QoS, debugging and testing, administration, and deployment. In the future, the Web and XML will significantly affect and change middle tier technologies. 14:55


143

Any Questions ?

14:55


144

Thanks a lot for attending this tutorial!!

14:55


145

Suggested Reading l l l l l l l l

Henning, Vinoski: Advanced CORBA Programming with C++, Addison-Wesley, 1999. Donald Box: Essential COM, Addison Wesley, 1998. Chappel, Understanding Windows 2000 Distributed Services, Microsoft Press, 2000. Rofail, Shohoud, COM and COM+, Sybex, 2000. All books by Eddon/Eddon and Richard Grimes. Buschmann, Meunier, Rohnert, Sommerlad, Stal: Pattern-Oriented Software Architecture - A System of Patterns, Wiley, 1996. Schmidt, Stal, Rohnert, Buschmann: Pattern-Oriented Software Architecture 2 – Patterns for Concurrent and Networked Objects, Wiley, 2000. Gamma, Helm, Johnson, Vlissides: Design Patterns - Elements of Reusable ObjectOriented Software, Addison Wesley, 1995.

14:55


146

Internet References l

The Patterns Home Page http://www.hillside.net/patterns/

14:55


147

Effective Architectures for Distributed Object Computing

Effective Architectures for Distributed Object Computing

Suggest Documents

Middleware for Distributed Systems - Distributed Object Computing ...

aItPm - Distributed Object Computing

Distributed Computing Architectures for Digital ...

Optimizing QoSin Distributed Systems/Cloud Computing Architectures

Model- Driven Engineering - Distributed Object Computing (DOC ...

Possible Paper Layout - Distributed Object Computing - Vanderbilt ...

Tonatiuh: An Object Oriented, Distributed Computing ...

Visual OS - Distributed Object Computing - Vanderbilt University

Activator - Distributed Object Computing (DOC) group - Vanderbilt ...

Event Tool Framework - Distributed Object Computing

Activator - Distributed Object Computing - Vanderbilt University

NetQoPE - Distributed Object Computing - Vanderbilt University

C++ Idioms - Distributed Object Computing (DOC) group

iOverbook - Distributed Object Computing - Vanderbilt University

The ADAPTIVE Service Executive - Distributed Object Computing

MoPED - Distributed Object Computing - Vanderbilt University

Location Management in Object-based Distributed Computing

2 On Distributed Systems - Distributed Object Computing (DOC ...

DISTRIBUTED REFLECTIVE ARCHITECTURES FOR ANOMALY ...

Architectures for Distributed Systems: Open

Architectures for Distributed Systems: Open

Frameworks - Distributed Object Computing (DOC) Group for DRE ...

DAnCE - Distributed Object Computing (DOC) Group for DRE Systems

Effective Use of Resources Distributed Cloud Computing Platform for ...