The Stateful Proxy Model for Web Services Programming. Table of Contents 1. Introduction Current Programming Model for Web Services...

Transcription

1 The Stateful Model for s Programming Dhyanesh Narayanan dhyanesh@cs.stanford.edu Table of Contents 1. Introduction Current Programming Model for s The Stateful Model for s Motivation for the Stateful Model...2 a. The Andrew File System (AFS)... 2 b. The CODA File System The Stateful Model... 3 [Phase 1] Staging:... 3 [Phase 2] Mutation:... 3 [Phase 3] Entrustment: Example: Interaction using the Current Programming Model for s Interaction using the Stateful Model for s Sample Implementation: Conventionally-Bootstrapped Stateful Observations Conclusion... 9 References Introduction This document presents a (possibly new) model for programming s. We call this the Stateful Model. 2. Current Programming Model for s A currently used dominant programming model for s is the following: [Step 1] The client creates a proxy object (using service metadata), which serves as a skeletal representation of the in the client s execution context. [Step 2] The client makes calls on the proxy object which are routed to the actual endpoints and suitable results (if any) are returned to the client. [Step 3] The client consumes the results (if any) and disposes the proxy 1

2 3. The Stateful Model for s Before we describe the Stateful Model for s programming, we present the motivation for the same. 3.1 Motivation for the Stateful Model The motivation for the Stateful Model arises from the observation that solutions to the problem of architecting distributed applications (such as Web Services and clients) intersect well with those of building distributed services (such as network file systems). Specifically, we consider the distributed file systems Andrew (AFS) and CODA a brief description of these systems is included below: a. The Andrew File System (AFS) The Andrew File System [1,2] is a location-transparent distributed file system developed at Carnegie Mellon University. A key design choice in Andrew was the use of whole files as the basic unit of data movement and storage, rather than some smaller unit such as physical or logical records. Whole-file transfer and caching provides significant performance benefits in Andrew when compared to alternatives such as Sun s Network File System (NFS). Once a client workstation has a copy of a file, it can use it in a manner that is independent of the availability of the central file system on the server. This dramatically reduces network traffic and file server loads as compared to record-based distributed file systems. Furthermore, it is possible to cache and reuse files on the local disk, resulting in additional reductions in server loads and increase in workstation autonomy. b. The CODA File System The Coda File System [3] is a descendant of AFS that is expressly designed to support disconnected operation. Coda strives for constant data availability, allowing a user to continue working regardless of failures such as a network disconnection (due to say, the user being mobile). Coda uses server replication as one technique to enhance availability; storing copies of files at multiple servers would provide a higher availability than AFS. A client exploits server replication as long as it stays connected with at least one server. When no server can be contacted, the client resorts to a mode of execution referred to as disconnected operation in which the client relies solely on cached data. Coda uses an optimistic replication strategy for enhancing availability instead of the alternative of pessimistic replica control which aims at providing strict consistency. To effectively support disconnected operation, Coda provides a mechanism by which users can specify which files they would like cached for use during disconnected operation (referred to as hoard-profiles). In a phase called Hoarding, the Coda client actively caches files on the client based on a user s hoard-profile. When a client is disconnected from all Coda servers, it enters a phase called Emulation in which all file operations are absorbed locally and serviced from the cache. When connectivity is restored, a phase called Reintegration is used to commit local updates to the server and reconcile conflicts (if any). 2

3 3.2 The Stateful Model We define a Stateful as follows: A Stateful is a location-independent representation of server-side state on a client, which supports programmatic access and/or mutation of that state. Drawing upon the ideas from AFS/CODA, we define the Stateful Model for Web Services programming as consisting of three phases: [Phase 1] Staging: A client creates an application-relevant Stateful of the in the client s execution context. The client is said to stage the Stateful off the. [Phase 2] Mutation: The client uses programmatic mechanisms for local access and/or manipulation of relevant state in the Stateful. [Phase 3] Entrustment: The client commits any relevant state updates introduced during the Mutation phase to the as appropriate. Note that we have only specified/described the function of the Stateful [Model] here the form is intentionally left unspecified. As a corollary, one can have many different implementations of the Stateful [Model]. We shall revisit this aspect in Section Example: We provide an example to illustrate the use of the Stateful Model and contrast it with the currently dominant model for s programming. Consider an as shown below: A client wishes to use this for the following sequence of application-level operations: 1. Retrieve a customer s itinerary for review 2. Delete a leg of travel (from SFO->NY) from the itinerary 3. Add a leg of travel (from SFO->LA) to the itinerary 4.1 Interaction using the Current Programming Model for s Using the current s programming model from Section 2, the client would interact with the as described below. 3

4 [Step 1] creates a proxy using Service metadata. In the figure below, the actual service endpoints are grayed-out since they are not actively used in this step. Create [Step 2] makes calls on the local proxy for the application-level operations (which get routed to the ) Itinerary [Application-Level Operation: Retrieve a customer s itinerary for review] DeleteTravelLeg(SFO->NY) [Application-Level Operation: Delete a leg of travel (from SFO->NY) from the itinerary] AddTravelLeg(SFO->LA) [Application-Level Operation: Add a leg of travel (from SFO->LA) to the itinerary] 4

5 [Step 3] consumes results and disposes proxy Dispose 4.2 Interaction using the Stateful Model for s Using the Stateful Model for s programming proposed in Section 3, the client would interact with the as described below. Note that the service endpoints in the figures below are replaced by a single dotted endpoint. This is to depict the fact that the actual endpoints exposed by a that supports interaction through the Stateful Model, would depend on the implementation of the Stateful Model being used (this aspect is described further in Section 5). [Phase 1] Staging: The client stages a Stateful for s off the s (for the customer in question). This operation is denoted by. Stateful [Phase 2] Mutation: performs the application-level actions using programmatic mechanisms of the staged Stateful, accessing and updating the state as required. In the figures below, the mutated Stateful is shown in red to indicate that updates have been made to the associated state. Note that during the entire duration of application-level operation of the client, there is no communication required with the. Itinerary [Application-Level Operation: Retrieve the customer s itinerary for review] 5

6 DeleteTravelLeg(SFO->NY) [Application-Level Operation: Delete a leg of travel (from SFO->NY) from the itinerary] AddTravelLeg(SFO->LA) [Application-Level Operation: Add a leg of travel (from SFO->LA) to the itinerary] [Phase 3] Entrustment: commits the state updates (introduced in the Mutation phase) to the. This operation is denoted by. Entrust _SP() 5. Sample Implementation: Conventionally-Bootstrapped Stateful As noted in Section 3, the definition of the Stateful [Model] is non-normative with regard to form and allows for many possible implementations. This section presents one such implementation which we call the Conventionally-Bootstrapped Stateful. We reuse the scenario to illustrate this implementation. The Conventionally-Bootstrapped Stateful is simply a typed object (with fields capturing state and methods capturing behavior), which can be loaded and used within the client execution context. It is suitably set-up to encapsulate server-side state and behavior that are relevant to a given set of application-level operations. Given this form for the Stateful, the could be structured as shown below: 6

7 Notice that the operations and which are artifacts of the Stateful Model are simply mapped to conventional endpoint operations of the. A client that wishes to interact with this Web Service using the Stateful Model would proceed as follows: [Step 1] Create a conventional proxy object Create [Step 2] Use the conventional proxy to stage a Stateful off the from the endpoint (hence the name Conventionally-Bootstrapped Stateful ). This step implements the Staging phase of the Stateful Model. Stateful [Step 3] Perform the application-level operations on the Stateful using fields/methods exposed by the [typed object form of the] Stateful. This step implements the Mutation phase of the Stateful Model. Again, as noted in Section 4.2, there is no communication required with the during the entire duration of this step. Also note that the conventional proxy remains unused during this step. Itinerary [Application-Level Operation: Retrieve the customer s itinerary for review] DeleteTravelLeg(SFO->NY) [Application-Level Operation: Delete a leg of travel (from SFO->NY) from the itinerary] 7

8 AddTravelLeg(SFO->LA) [Application-Level Operation: Add a leg of travel (from SFO->LA) to the itinerary] [Step 4] Use the conventional proxy to commit updates made [to the Stateful ] in Step 3, to the using the endpoint. This step implements the Entrustment phase of the Stateful Model. [Step 5] Dispose the conventional proxy Dispose 6. Observations The following observations and caveats are in order: All through the presentation of the Stateful Model in this document, we have not suggested that it is better in one or more respects when compared to the currently used model of s programming. There do exist some advantages, such as the ability to execute application-level operations without requiring any communication with the, but this comes with making certain assumptions and certain trade-offs. Hence, at this point, the Stateful Model is purely being proposed as an interesting alternative to explore in the context of programming s. As we refine this proposal further, it is expected that we would likely enable certain interesting/new scenarios with the Stateful Model. By definition, the Stateful may entail support for executing code on the client. This raises the whole host of issues conventionally associated with mobile code (such as applets). Some immediate ones are: What is the form in which this 8

9 code is delivered? How is it guaranteed to execute on the client platform? What about security issues? The form of the Stateful provides for very interesting investigation in itself. The Sample Implementation proposed in Section 5 provides just one possible (and arguably simple-minded) form. Richer forms could support wider and more efficient functionality. For example, one simple optimization could be to enable the Stateful to be smart and selectively package only the mutating updates made to state, and ship them to the service during the Entrustment phase. The interaction between the client and the server could also be refined as a result of improving the form of the Stateful. For example, we could consider relaxing the restriction that the Stateful should be set-up in such a way that it can handle all relevant application operations locally. Then, we might be able to stage a lighter proxy off the that can absorb most application operations/state-mutations locally but may require communication with the for staging more state/behavior on an as-needed basis to support additional operations. 7. Conclusion We have proposed a (possibly new) model for programming s, which we call the Stateful Model. An operational description of the Stateful Model has been provided by means of an example. The proposed model has also been contrasted (in terms of operational specifics) with the currently used dominant programming model for s. A sample implementation of the Stateful [Model] has also been presented, viz. the Conventionally-Bootstrapped Stateful, and has been described with an example. Finally, we have made some critical observations about the current proposal. Active feedback is sought on this proposal. We look forward to refining the definition of the Stateful Model and taking it forward as an interesting alternative for programming s, potentially enabling new scenarios. References [1] Scale and performance in a distributed file system, JH Howard et al, ACM Transactions on Computer Systems, 1988 [2] An overview of the Andrew file system, JH Howard, USENIX Winter, 1988 [3] Coda: A Highly Available File System for a Distributed Workstation Environment, M. Satyanarayanan et al, IEEE Transactions on Computers,