Application Hosting Services



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

Introduction

We use the term application hosting service to denote a component and/or tool in a service-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.

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.

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?

• Others?

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.

[pic]

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

|Name |Description |Priority |

|AHS client |Client access to application code |High |

|AHS management |Monitoring and management of AHS |Medium |

|Persistence |Store AHS state on stable storage |Medium |

|Provisioning |Negotiate with resource providers for resources |Medium |

|Authorization |SAML-based callout to policy decision point | Done |

|Policy management |Enable remote modification of access policies |Done |

|Accounting/audit |Provide access to accounting and audit data |Low |

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

Example Technologies

Maybe a table?

|Applications |Wrapper |Dispatch |Policy |Policy

Mgmt | | | | | |OPAL | | |GRAM | | | | | | | |SoapLab | | |Fork | | | | | | | |pyglobus | | |Fork | | | | | | | |Introduce | | | | | | | | | | |ActiveBPEL |BPEL workflow | |Service call | | | | | | | |GT4 GRAM |Executable | |Scheduler | | | | | | | |GT4 WMS |Virtual 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.

• pyGlobus:

•

Security Considerations

The AHS architecture addresses authorization, accounting, and audit issues.

Acknowledgements

References

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download