Invocation Patterns

Apart from synchronoussynchronous, sequentialsequential mode of method invocation our architecture supports: AsynchronismAsynchronism – each method invocation returns

immediately and a separate thread is expected to block on a complementary call waiting for the output data to become available

ConcurrencyConcurrency – by default, slave processes handle each client request in a separate thread

TransactionsTransactions– the most general model of concurrent nested transactions is assumed

Bartosz Baliś1,2 Marian Bubak1,2 Michał Węgiel11Institute of Computer Science AGH, Mickiewicza 30, 30-059 Kraków, Poland

2Academic Computer Centre CYFRONET, Nawojki 11, 30-950 Kraków, Poland{balis,bubak}@uci.agh.edu.pl, mwegiel@acm.org

Legacy System

Master

Slave

Monitor

singletonsingletonresponsible for host responsible for host

registration and registration and creation of monitor creation of monitor and slave processesand slave processes

permanent process

transient processes

one per clientone per clientresponsible for responsible for reporting about reporting about

and controlling the and controlling the associated slave associated slave

processprocess

one per clientone per clientprovides means of provides means of

interfaceinterface--based based statestatefulful conversation conversation with legacy softwarewith legacy software

Hosting Environment

Registry

Factory

Proxy Factory

Instance

Proxy Instance

permanent services

transient services

singletonsingletonkeeps track of keeps track of legacy systems legacy systems

which registered which registered to participate in to participate in

processingprocessing

singletonssingletonsresponsible for responsible for creation of the creation of the corresponding corresponding

instancesinstances

one per clientone per clientdirectly called by directly called by

the client, provides the client, provides externally visible externally visible

functionalityfunctionalityone per clientone per client

responsible for responsible for mediation between mediation between legacy systems and legacy systems and service requestorsservice requestors

Registry Master

Assign

Monitor

Slave

[success]

Assign

[timeout]

Create

Proxy Instance

Create

Heartbeat

[continue]

Heartbeat

[migration]

Assign

[timeout]

Destroy

Request

Response

Request

Response

Legacy System Side

Factory

Proxy Instance

Instance

Proxy Factory Registry

Create

NewCreate

NewAssign

InvokeInvoke

DestroyDestroy

Service Requestor Side

Legacy System

Master

Slave

Monitor

Legacy System

Master

Monitor

Slave

Provides for loadload--balancingbalancing & faultfault-- tolerancetolerance

High-level approach (migration awareness)

State extraction & restoration: checkpointingcheckpointingcombined with repetition of short-term history history of method invocations Committed

Aborted

Committed

Aborted

Committed

Aborted

Unfinished

Checkpoint Failure

Transaction omitted

Transaction repeated

Time

Selection of optimal state reconstruction scenario isbased on transaction flowtransaction flowand checkpoint sequencecheckpoint sequence(multiple state snapshots are recorded and the one enabling for fastest recovery procedure is chosen)

Hosting Environment

Registry

Factory

Proxy Factory

Legacy System

Master

Service Requestor

Service Process

Instance

Proxy Instance

Slave

Monitor

SOAP

SOAP

Target Grid Service

Legacy Code

Architecture

Scenarios

Process Migration

Essential aspect: process creation / termination CoarseCoarse-- grainedgrained resources: mastermasterprocesses FineFine-- grainedgrained resources: monitormonitor / slaveslaveprocesses

Registry

Master

Monitor/ Slave

Information Services

Data Management

Job Submission

Resource BrokerCoarse-Grained Allocation (c)

Fine-Grained Allocation (f)

c.1

c.2

c.3

c.4

c.5

f.1f.2

Resource Management

Operation

Performance Evaluation

Benchmark: two functionally equivalentfunctionally equivalentgrid services; one of them employed LGF

Measurements performed on client sideclient side

Instance construction•• ThroughputThroughput reduced 3.1 times

Method invocation•• BandwidthBandwidth reduced 2.5 times

•• LatencyLatency increased 2.5 times

Instance destruction •• ThroughputThroughput reduced 2.1 times

References

Baliś, B., Bubak, M., Węgiel, M.: A Framework for A Framework for Migration from Legacy Software to Grid ServicesMigration from Legacy Software to Grid Services. In Proc. 3rd CracowGrid Workshop, Krakow, Poland,2003, pp. 254-265.

Baliś, B., Bubak, M., Węgiel, M.: Adaptation of Adaptation of Legacy Software to Grid ServicesLegacy Software to Grid Services. In Proc. ICCS 2004, Krakow, Poland, LNCS 3038, vol. 3, pp. 26-33, Springer.

Baliś, B., Bubak, M., Węgiel, M.: A Solution for A Solution for Adapting Legacy Code as Web ServicesAdapting Legacy Code as Web Services. In Proc. Workshop on Component Models and Systems for Grid Applications, Saint-Malo, France, 2004, Kluwer.

LM

SM

Node

LM

Node

Site

Slave

Proxy Instance

Instance

SOAP

SOAP

MCI

MCIMCI

OCM-G LGF

Grid application monitoring system composed of twocomponents compliant to OMISinterface: ServiceService ManagerManager (SM) and Local MonitorLocal Monitor (LM)

Case Study: OCM-G

Implementation

Acknowledgements: research partially funded by the Crossgrid project

SOASOA: environment wherein loosely-coupled grid services interact by exchanging messages (high level of interoperability and abstraction). Legacy softwareLegacy software: traditional libraries and applications executed as regular programs (system/language dependent).

Legacy sideLegacy side: client assignment, system monitoring, request processing. Requestor sideRequestor side: instance construction, method call, instance destruction.