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 Introduction Use Cases Requirements .3 Architecture .3 Example Technologies .5 Security Considerations .5 Acknowledgements References Introduction We use the term application hosting service to denote a component and/or tool in a serviceoriented architecture that enables network access to application logic that is not itself serviceenabled 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 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 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 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 Appln Code Application providers Application Prep Tool(s ) Provisioning interface AHS Client Interface Users Appln Appln Code Code AHS Mgmt Interface Admins Resource Resource Provider Provider Hosting Service Auth interface Policy Mgmt Interface Persistence interface PDP 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 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 Client access to application code High Monitoring and management of AHS Medium 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 Provide access to accounting and audit data Low AHS client AHS management Persistence Accounting/audit 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 OPAL GRAM SoapLab Fork pyglobus Fork Policy Policy Mgmt 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 ... 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... 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... 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