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

2. 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

3. 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.

4. 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 ?

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

6. > sabre.fit(sabre0,''year'',''age'',''fnoem'',''fsc80'')
> # NB returns control to user immediatley even though analysis is still running
> sabre.display.estimates(sabre0)
*** Sabre analysis still in progress ***
> # ... some time later ...
> sabre.display.iterations(sabre0)
Initial Homogeneous Fit:
Iteration Log. lik Difference
__________________________________________
E-03
E-09
Iteration Log. lik Step End-points Orthogonality
length criterion
________________________________________________________________________
fixed fixed
fixed fixed
fixed fixed
fixed fixed
fixed fixed
> # ... user can be doing other things within R whilst sabre analysis takes place ...

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

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

9. The Problem – A Missing Layer

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

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

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

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

14. Session Manager Agent Factory Client Application LIB Configuration
Certificate
Certificate
XML
Session
Manager
Client
Application
LIB
Agent
Factory
LIB
LIB
gSOAP server
libraries

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

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

17. Session Manager Agent Agent Factory Client Application LIB LIB
Configuration
Certificate
Certificate
XML
XML
Session
Manager
Client
Application
LIB
Agent
LIB
Agent
Factory
LIB
LIB
gSOAP server
libraries

18. Agent Architecture

19. 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 !!