Hosting and Accessing Objects via Persistent Web Services

Hosting and Accessing Objects via Persistent Web Services Daniel J Grose Centre for E-Science Lancaster University

Overview ● Brief introduction to GROWL and SABRE ● SABRE user requirements ● Taxonomy of GRID users ● Hosting Legacy Interfaces – the need for a client programmers API ● Client/Server Architecture ● Conclusions

SABRE Software for the Analysis of Binary Recurrent Events SABRE is designed to model recurrent events for a collection of individuals or cases and many other types of repeated measures data with binary, ordinal or count responses. It fits both standard models and various mixture models which allow for residual heterogeneity. It can be used to fit the following univariate statistical models : • binary data with logit, probit or complementary log-log link • ordinal response data using a probit link • count response data using a log-linear Poisson model • continuous response using identity link SABRE employs reweighted least squares (standard homogenous models) and Newton-Raphson maximum likelihood (random effects binary models) algorithms.

SABRE Development History ● ● ● Single threaded application with simple shell based user interface. C++ wrapper to SABRE. Single threaded extension to R (one model per session) employing C++ wrapper. ● Multi-threaded extension to R (>= one model per session) ● Parallel implementation using (MPI) running in batch mode ● How to provide R interface to parallel implementation in employed remotely on HPC ?

>library(sabre. R) # load the sabre. R library > sabre 0<-sabre. session(); # create a new sabre model > trade. union<-read. table(``. /Trade. Union. table'') # read the data into a data frame > names(trade. union) # show the variates [1] "CASE" "YEAR" "AGE" "EVNO" "SUPR" "HRS" "NOEM" "SEX 1" "TU" "PROM" [11] "SC 80" > sabre. data(sabre 0, trade. union) > sabre. display. variates() Name Levels Type ________________ cons 1 X case 1 X year 1 X age 1 X evno 1 X supr 1 X hrs 1 X noem 1 X sex 1 1 X tu 1 YVAR prom 1 X sc 80 1 X fnoem 5 X fsc 80 6 X > plot(trade. union) # plot the data

> sabre. fit(sabre 0, ''year'', ''age'', ''fnoem'', ''fsc 80'') > # NB returns control to user immediatley even though analysis is still running > sabre. display. estimates(sabre 0) *** Sabre analysis still in progress *** > #. . . some time later. . . > sabre. display. iterations(sabre 0) Initial Homogeneous Fit: Iteration Log. lik. Difference _____________________ 1 -1131. 9093 2 -1073. 2798 58. 63 3 -1073. 0111. 2687 4 -1073. 0110 0. 1204 E-03 5 -1073. 0110 0. 4700 E-09 Iteration Log. lik. Step End-points Orthogonality length 0 1 criterion ____________________________________ 1 -917. 86146 1. 0000 fixed 6. 5174 2 -878. 33512 1. 0000 fixed 19. 983 3 -868. 98256 1. 0000 fixed 4. 6722 4 -867. 52529 1. 0000 fixed 5. 2621 5 -867. 20337 1. 0000 fixed 11. 115 > #. . . user can be doing other things within R whilst sabre analysis takes place. . . > sabre. display. estimates(sabre 0)

What Extra is Required to Run a GRID SABRE Session ? > nwg<-grid. resource(``~/smith. pem'', ''~/ca. pem'', + ''growl. lancs. ac. uk: 50000'', ''~/smith. passwd'') > sabre 0<-sabre. session(nwg) # this time create a sabre session with a grid resource. . . exactly the same session as before !!. . .

The Problem – A Missing Layer * Adapted from Foster and Kesselman

The Problem – A Missing Layer

$Example. Local Interface and Implementation #ifndef ___ACCUMULATOR_H___ #define ___ACCUMULATOR_H___ class Accumulator { private: unsigned$

Example. Local Interface and Implementation #ifndef ___ACCUMULATOR_H___ #define ___ACCUMULATOR_H___ class Accumulator { private: unsigned int m_n. Value; public: Accumulator(); unsigned int Next. Value(); }; include "Accumulator. h" Accumulator: : Accumulator() : m_n. Value(0) {} unsigned int Accumulator: : Next. Value() { return m_n. Value++; }

Client Invoking Local Service #include <iostream> #include "Accumlulator. h" int main() { Accumaulator Acc; std: : cout << Acc. Next. Value() << std: : endl; return 0; }

“IDL” + *. h *. f *. jav + Source Session Manager WSDL + *. cpp *. f *. jav MAKE Client Library Server Library Agent Library

$Client Invoking Remote Service #include <iostream> #include "GROWL_Accumlulator. h" int main() { GROWL_Accumaulator Acc;$

Client Invoking Remote Service #include <iostream> #include "GROWL_Accumlulator. h" int main() { GROWL_Accumaulator Acc; // additional code required for invoking remote instance Acc. Set. Client. Params("~/smith. pem", "~/ca. pem", "growl. lancs. ac. uk: 50000", "~/smith. passwd"); std: : cout << Acc. Next. Value() << std: : endl; return 0; }

Configuration Certificate XML Client LIB Application Session Manager Agent Factory LIB g. SOAP server libraries

Configuration Certificate DN Service Grid Resource Certificate XML Library Client LIB Application Session Manager Agent LIB Agent ID Socket Numbers Agent Factory LIB g. SOAP server libraries

Configuration Certificate DN Agent ID Certificate XML Client LIB Application Socket Number Session Manager Agent LIB Globus Condor Other Agent Factory LIB g. SOAP server libraries Certificate

Configuration Certificate XML Client LIB Application Session Manager Agent Factory LIB g. SOAP server libraries LIB

Agent Architecture

Conclusions ● ● ● ● Existing GRID users (the early adopters) are predominantly GRID middleware users. However, the large majority of potential grid users are not. To capture the latter, client side developers require simple API's to program against legacy interfaces that can be integrated easily into existing client environments (ostensibly as if they were local services). The API's must offer multiple language mappings. A potential risk is that development effort is too focused on creating user interfaces for interacting with middleware rather than developing the client programmers API. The lifetime of the service does not usually correspond to the lifetime of the client. These requirements imply extensible secure severs that can host multiple implementations via a common interface. . . and all of the implementation state must be on the server side. What the client gets is what they have subscribed to !! The service provider is responsible for deciding how this is done. Importantly, the client side interface does not change when the user decides to change service provider !!