Application Hosting Services Requirements and Architecture

Application Hosting Services: Requirements and Architecture Ian Foster Computation Institute Argonne National Laboratory & University of Chicago Abstract The need to make application cod

Application Hosting Services:

Requirements and Architecture

Ian Foster Computation Institute Argonne National Laboratory & University of Chicago

Abstract

The need to make application code accessible as a Web Service arises frequently in scientific applications Depending on context, this apparently simple task can introduce a wide range of requirements, including interface generation, authorization of requests, generation of code to dispatch calls to application code, monitoring and management of tasks, data management, and dynamic mapping of application tasks to processors in respond to changing workloads The resulting “application hosting services” can vary greatly in their architecture and complexity, depending the requirements(s) to be addressed, the form of the application code(s), the type of task(s) to be executed, and the workload(s) to be supported Many groups are building relevant components and tools, but no one system meets all needs With the goal of encouraging

collaboration and communication, I review requirements for application hosting services, present

an application hosting service architecture, and identify interfaces that we may wish to define to enable interoperability of different tools and systems I also review existing approaches to building such services

Table of Contents

1 Introduction 1

2 Use Cases 2

3 Requirements 3

4 Architecture 3

5 Example Technologies 5

6 Security Considerations 5

7 Acknowledgements 5

8 References 5

1 Introduction

We use the term application hosting service to denote a component and/or tool in a

oriented architecture that enables network access to application logic that is not itself service-enabled This term can encompass a variety of capabilities and technologies, but the general concept is that the application hosting service addresses some of the programming and

administrative tasks inherent in providing a service interface to the desired application logic The service provider simply needs to “plug in” their application logic (in some more-or-less

automated manner) to create an application service

As an example, consider an “application” that takes the form of an executable program that takes

as input a set of command-line arguments and returns an integer value A simple application hosting service might address all service interface and task execution issues for such an

application, such as WSDL generation, request processing (including authorization) and dispatch, task monitoring and management, and response processing Thus, a service provider need supply only the executable and a specification of its arguments to create a new service

An application hosting service can also provide other functionality, such as dynamic allocation of the resources needed for task execution, remote management of policy, remote monitoring and management, persistence, and support for other “application” types such as procedures and workflows Different functionalities are required in different contexts, and so it is unlikely that

we will see a single application hosting service implementation Nevertheless, we find that different applications frequently require the same or similar functionality (e.g., authorization, WSDL generation), which suggests that we should be trying to exploit commonalities where these exist

These considerations motivate our development of this white paper, in which we:

 Present a set of use cases that are intended to define the scope of what we call an

“application hosting service”;

 Extract requirements from these use cases;

 Define an application hosting service architecture, in which we identify key components and the interfaces by which those components can interact; and

 Review existing application hosting tools and systems in the light of this architecture to see what capabilities they provide

2 Use Cases

We present a set of use cases intended to define the scope of what we want application hosting services to do

UC1: Make an executable program accessible as a service We want to make an executable

program accessible over the network via a Web Services interface, but we don’t want to have to

do any work! Thus, we want tools that can generate the WSDL, provide deserialization and dispatch code (including the code to call the application program), define and invoke appropriate authorization logic, and so on Depending on context, we may want the application WSDL to include operations for monitoring and controlling the application

UC2: Handle high and/or time-varying load Our application service becomes popular Thus,

we want our application hosting service to be able to handle multiple requests concurrently, perhaps by mapping them across multiple resources We may also want the service to acquire new resources dynamically in order to address time-varying load efficiently

UC3: Enable distributed monitoring and management We create multiple application

services, and want to be able to monitor and manage them remotely Thus, we want our

application hosting service to provide an administration interface that allows for remote

monitoring (e.g., current load, historical response times) and perhaps also management (e.g., change resource allocations, modify access policy)

UC4: Accounting We’re asked to justify the time and resources we spend on our application

hosting service Thus, we want the AHS to track usage and (per UC3) provide remote access to

that information (Something about finding user id info too, as per Stuart Martin’s document?)

UC4: Auditing Our computer security staff get nervous They ask how we’ll know who was

doing what if/when an intrusion occurs Thus we want our AHS to log significant events As per UC3, we may also want remote access to that information

UC5: Dynamic hosting Our application service gets yet more popular, and we find ourselves

wanting to create additional instances of the service Thus we want our AHS packaged so that we can deploy it on a remote resource via Web Service interface

UCn: Portal interfaces Despite our best efforts, our users (especially those who are infrequent

users) insist they don’t like Web Services: they want an interactive portal for submitting and managing requests Thus, we want tools for creating such portals automatically from application specifications

UCn: Workflow submission Is submission of (e.g.) BPEL workflows in scope?

Other issues we could work in here:

 Generating client code

 Registration of the service for discovery

 Persistence of information about jobs, and/or of the jobs themselves

 Access to data of various kinds

3 Requirements

We identify the following requirements:

 Automated wrapper generation: given a description of an application and its interface

(e.g., it might be an executable program that reads an input file and writes an output file), generate automatically (1) the WSDL required to (a) invoke that application and (b) monitor, manage, and request notifications of the status of individual invocations, and (2) the application-independent code that implements this interface

 AHS management Web Services-based interface for monitoring and managing the AHS

itself

 Dynamic AHS provisioning Dynamic provisioning of an AHS based on time-varying

workload This task might involve interfacing to a “provisioning agent” to manage the creation/destruction of “workers”, which then register with the AHS

 Dynamic AHS deployment The ability to deploy an AHS onto a service provider.

 Authorization Authorization based on standard (e.g., SAML-based) callouts.

 Persistence

 Policy management Remote management of authorization policy.

 Accounting.

 Web interfaces Automated construction of Web interfaces for various roles.

 Workflow? Submit requests to execute workflows.

 Data staging?

4 Architecture

Figure 1 shows some of the major components and interfaces that may be found in an application hosting service implementation This figure depicts, in particular, the hosting service into which

the application code is deployed with the help of application preparation tools, the policy decision point (PDP) that performs authorization decisions, the storage used for persistence, and the resource providers with which the application hosting service interacts to obtain needed

resources

Resource Provider

Appln Code

Appln Code

Appln Code

AHS Client Interface

AHS Mgmt Interface Hosting Service

Auth

interface

Resource Provider Provisioning interface

Application Prep Tool(s )

Persistence interface

Users

Admins

PDP

Policy Mgmt Interface

Application providers

Figure 1: Major components of an application hosting service

Q: Which part of this is the “application hosting service”? I’m not sure we are consistent.

Table 1 provides a complete list of the interfaces that may be used to interact with an AHS, or within an AHS implementation (Accounting/audit is not shown in Figure 1.)

Table 1: Interfaces used to interact with, or within, an AHS

resources

Medium

Other issues:

 Standard way of describing applications?

 Standard way of describing Web (portal) interfaces to AHSs?

 Submitting more complex requests: e.g., workflows

 Data staging? Data access in general

5 Example Technologies

Maybe a table?

Applications Wrapper Dispatch Policy Policy

Mgmt

Introduce

ActiveBPEL BPEL

workflow

Service call

machine AHE

Chinese?

Germans?

For now, a brief description:

 OPAL: Automatic generation of WSDL and interface code for executable programs Dispatch via GRAM to compute resources

 SoapLab: Automatic generation of WSDL and interface code for executable programs



6 Security Considerations

The AHS architecture addresses authorization, accounting, and audit issues

7 Acknowledgements

8 References