Last time, we studied how to build a service using SOAP:

Transcription

1 Services Monday, November 26, :54 AM Last time, we studied how to build a service using SOAP: Services Page 1

2 The dream of service architecture Monday, November 26, :03 AM The dream of service architecture You create a subroutine in Java. You ask politely that it be presented as a service. The service is written for you. Your service's nature is advertised on the web. Your service becomes discoverable in searches. Clients are automatically written to call the service -- in any language. Services Page 2

3 Services Page 3 Science fiction? Monday, November 26, :08 AM This is not science fiction, but I am glossing over some really important details: You must comply with a service pattern in order for your subroutine to be wrappable. This pattern includes requirements on how you store and retrieve local persistent data. The paradigm has limits: notably, that the service input and output schemas only represent the limits of the language's type system. You must learn a new programming paradigm: generate and modify.

4 Services Page 4 Details of a cloud-based service Monday, November 26, :23 PM Details of a cloud-based service Part I: Code generation strategies. What happens "outside the code"? Part II: Persistence strategies. What has to happen "inside the code"?

5 Services Page 5 Part I: code generation Monday, November 26, :24 PM Part I: code generation How can we avoid the tedium of XML/XSchemas in writing web services? What will we give up as a result?

6 Services Page 6 Developing SOAP the old way Wednesday, March 10, :01 AM Developing SOAP the old way: "top-down" Define input schema. Define output schema. Define request handler for the schema, that generates appropriate output for each input. Define client that calls the request handler and encodes data according to the schema. Zzzz...

7 Services Page 7 Bottom-up service development Wednesday, March 10, :05 AM The new world order: bottom-up service development Start by defining Plain Old Java Objects (POJOs) that you want to turn into web services, e.g., that read NoSQL data. Generate XML Schemas, service stubs, etc using a service deployment framework, e.g., Apache Axis 2. Don't even learn XML or Schemas! The framework handles all of that!

8 Services Page 8 Service deployment frameworks Wednesday, March 10, :31 PM Service deployment frameworks Manage "deployment" of a service. Require only minimal input from you. Java Code to deploy. Some configuration options. Result: a running service. Two main ones: Apache Axis (LAMP) Microsoft Visual Studio Services (IIS)

9 Services Page 9 Apache Axis 2 Wednesday, March 10, :12 AM Apache Axis 2 Built on top of the Apache Tomcat Java Servlet Engine. Supported in native Eclipse J2EE edition (without plugins, but you do have to download local copies of Apache Tomcat and Axis and get them running and bound into Eclipse). Takes plain old java objects (POJOs) as input. Generates service and client code that treats POJOs as services!

10 Services Page 10 Requirements Monday, November 26, :40 PM Requirements The POJO must be "serializable": it must be possible to make a portable copy of the object. The service calls must be methods in the object.

11 Services Page 11 Using Axis Wednesday, March 10, :18 AM Using Axis Define a simple service as a java class. Tell Axis it should become a service. "Package" the service. "Deploy" the service. Reference:

12 Services Page 12 Defining a service Wednesday, March 10, :19 AM /** * The service implementation class */ public class SimpleService { public String echo(string value) { return value; } } Pasted from <

13 Informing Axis of the service Wednesday, March 10, :19 AM Informing Axis of the service: services.xml <service> <parameter name="serviceclass" locked="false">simpleservice</parameter> <operation name="echo"> <messagereceiver class="org.apache.axis2.rpc.receivers.rpcmessagereceiver"/> </operation> </service> Pasted from < Services Page 13

14 Services Page 14 Packaging the service Wednesday, March 10, :21 AM Packaging the service Axis expects service files to be found in a specific directory hierarchy. Creating the hierarchy: mkdir temp javac SimpleService.java -d temp/ mkdir temp/meta.inf cp services.xml temp/meta.inf/ cd temp jar -cvf SimpleService.aar *

15 Services Page 15 Deploying the service Wednesday, March 10, :30 AM Deploying the service Choose a web server platform (e.g., Apache Tomcat+Axis2 or SimpleHTTPserver + Axis2) (Instructions differ.) Simplest deployment: SimpleHTTPserver included with Axis2.

16 Services Page 16 Using SimpleHTTPServer Wednesday, March 10, :32 AM Using SimpleHTTPServer Create a "repository" axis2-repo containing conf subdirectory containing axis2.xml empty modules subdirectory (contains jars that your code might need). services directory containing SimpleService.aar Run the SimpleHTTPserver: sh http-server.sh /path/to/axis2-repo

17 Services Page 17 Now things get interesting Wednesday, March 10, :45 AM Now things get interesting Axis2 Services are reflective, i.e., they are self-describing on the web. If one runs the SimpleHTTPserver and browses to one gets a description of the service and even how to use it. Weird: one has to have the service running before one can build a client to it.

18 Creating a client Wednesday, March 10, :49 AM Creating a client Client code is generated by querying the reflection interface for a running service! (It doesn't matter how you wrote the service) sh WSDL2Java.sh -uri \\ \\ -o /path/to/my/client/code/ This generates code in the Axis2 hierarchy that calls the service. It can be run on a different host than the host on which the service was developed! It can be written in a different language. Services Page 18

19 Querying via generated code Wednesday, March 10, :51 AM // SimpleServer.echo corresponds to // SimpleServiceStub.EchoResponse // in generated code. package org.apache.axis2; import org.apache.axis2.simpleservicestub.echoresponse; public class Client { public static void main(string[] args) throws Exception { SimpleServiceStub stub = new SimpleServiceStub(); //Create the request SimpleServiceStub.Echo request = new SimpleServiceStub.Echo(); request.setparam0("hello world"); } } //Invoke the service EchoResponse response = stub.echo(request); System.out.println("Response : " + response.get_return()); Pasted from < Services Page 19

20 Services Page 20 What did we give up? Monday, November 26, :25 PM What did we give up? XSchemas are generated by the language type system. They do not fully enforce preconditions. In Axis, it isn't possible to do so. Reason: just-in-time compilation. XML is slow to encode/decode. This is a performance issue. So we don't use this for non-public interfaces.

21 Services Page 21 A tale of two service generators Monday, November 26, :46 PM Apache Axis Just-in-time compilation XSchema preconditions are based upon language type system Microsoft Visual Studio Web Services Generate and modify Can modify XSchemas to assert more than language-based preconditions

22 Services Page 22 Part II: Persistence Monday, November 26, :09 AM Your java subroutine must be written to be: horizontally scalable: it is possible to deploy more service instances without problems. stateless: any instance of the service can handle any request. consistency aware: it is not possible for multiple instances to get confused about persistent service state.

23 Services Page 23 Relationship between Parts I and II Monday, November 26, :26 PM Relationship between Parts I and II Part I: how to generate a service from a java class. Part II: how to make that class intelligently use persistent data.

24 Services Page 24 A simple example of persistent state Monday, November 26, :43 AM A simple example of persistent state An "availability" service: remembers whether you're busy now or available to chat. Key: your user identifier (e.g., Windows LiveID or Google ID) Value: boolean: TRUE if you're available. Two service calls: put(id,avail): set the availability for a user ID to a specific state avail = get(id): get the availability for a user ID.

25 A cloud model of a service Monday, November 26, :25 AM Services Page 25

26 Services Page 26 Why we are going to this trouble Monday, November 26, :59 PM We want horizontal scalability of the front end: we should be able to add front-ends without modifying behavior. We want vertical scalability of the datastore: we should be able to add storage resources without changing behavior.

27 Distributable programs Wednesday, January 27, :06 AM "Distributable" applications Are regular serial application programs. Can have many concurrent instances running in different locations. All instances do the same thing. All instances have the same view of the world. Services Page 27

28 Distributed objects Wednesday, January 27, :08 AM Distributed objects Give all instances of an application "the same view" of the world. Are opaque to the application. Are distributed in ways that the application cannot detect. Services Page 28

29 Services Page 29 Classes and instances Monday, January 24, :58 PM Best to think about cloud clients and services in terms of classes and instances: For a client: The class determines the kind of application. An instance is one copy of a program that satisfies class requirements There can be many concurrent instances of a client (e.g., 1000 cellphone users) For a service: The class is the kind of service An instance is one copy of a program that provides the service. There can be many instances of the same service (e.g., geographically distributed)

30 Binding Monday, January 24, :01 PM The concept of binding You run an app on your cellphone. It connects to a service. It does something (e.g., recording your Lat/Long location) It logs out. What can you assume about this transaction? You cannot assume that you'll ever get the same server again. or that the server you get will have the same view of the cloud. unless you know something more about the cloud! When you write a service All data must be stored in the cloud. There is no useful concept of local data. There is no concept of server-to-server communication except through the datastore. Services Page 30

31 A model of cloud execution Monday, January 24, :54 PM Services Page 31

32 Services Page 32 ACID Wednesday, January 27, :09 AM Datastores should exhibit what is commonly called ACID: Atomicity: requested operations either occur or not, and there is nothing in between "occurring" and "not occurring". Consistency: what you wrote is what you read. Isolation: no other factors other than your actions affect data. Durability: what you wrote remains what you read, even after system failures.

33 Services Page 33 Consistency and concurrency Wednesday, January 27, :19 AM Consistency and concurrency Two visible properties of a distributed object: consistency and concurrency Consistency: the extent to which "what you write" is "what you read" back, afterward. Concurrency: what happens when two instances of your application try to do conflicting things at the same exact time?

34 Consistency Wednesday, January 27, :20 AM Consistency The extent to which "what you write" into a distributed object is "what you read" later. Two kinds: Strong consistency: if you write something into a distributed object, you always read what you wrote, even immediately after the write. Weak (eventual) consistency: if you write something into a distributed object, then eventually -- after some time passes -- you will be able to read it back. Immediate queries may return stale data. Services Page 34

35 Services Page 35 A file analogy Wednesday, January 27, :36 AM A file analogy Strong consistency is like writing to a regular file or database: what you write is always what you get back. Eventual consistency is like writing something on pieces of paper and mailing them to many other people. What you get back depends upon which person you talk to and when you ask. Eventually, they'll all know about the change.

36 Services Page 36 Concurrency Wednesday, January 27, :23 AM Concurrency How conflicting concurrent operations are handled. Two kinds: Strong concurrency: if two or more conflicting operations are requested at the same time, they are serialized and done in arrival order, and both are treated as succeeding. Thus the last request determines the outcome. Weak ("opportunistic") concurrency: if two conflicting operations are requested at the same time, the first succeeds and the second fails. Thus the first request determines the outcome.

37 Services Page 37 A file analogy Wednesday, January 27, :41 AM A file analogy On linux, file writes exhibit strong concurrency, in the sense that conflicting writes all occur and the last one wins. Likewise, in a database, a stream of conflicting operations are serialized and all occur -- the last one determines the outcome. Opportunistic concurrency only occurs when there is some form of data locking, e.g., in a transaction block.

38 Services Page 38 Strong consistency and concurrency Wednesday, January 27, :54 AM Consistency/Concurrency tradeoffs Obviously, we want both strong consistency and strong concurrency But we can't have both at the same time!

39 Services Page 39 Strong consistency requirements Wednesday, January 27, :01 AM Strong consistency requires Some form of write blocking until a consistent state, Which implies a (relatively) slow write time before unblocking. Which means we can't afford to "wait" for the write to end in order to sequence writes. Which means we can't have strong concurrency!

40 Services Page 40 Strong concurrency requirements Wednesday, January 27, :01 AM Strong concurrency requires Some form of write sequencing. A (relatively) fast write time, with little blocking. Which means writes need time to propagate. Which means we can't have strong consistency!

41 Services Page 41 Two approaches to Consistency and Concurrency Wednesday, January 27, :03 AM Google's "appengine" Provides strong consistency At the expense of opportunistic concurrency. Amazon's "dynamo" Provides strong concurrency. At the expense of exhibiting eventual consistency.

42 Services Page 42 AppEngine Wednesday, January 27, :18 AM AppEngine properties Strong consistency: what you write is always what you read, even if you read at a (geographically) different place! Opportunistic concurrency: updates can fail; application is responsible for repeating failed update operations. Updates should be contained in "try" blocks!

43 Services Page 43 Modifying distributed objects in AppEngine Wednesday, January 27, :23 AM Modifying distributed objects in AppEngine A distributed object is controlled by a persistence manager. A distributed object retrieved from the persistence manager remains "attached" to the cloud. If you "set" something in a persistent object, this implicitly modifies the cloud version and every copy in other concurrently running application instances! This is what strong consistency means! So if some concurrent application instance sets something else in an object instance you fetched, your object will reflect that change (via strong consistency). So mostly, you observe what appears to be strong concurrency.

44 Services Page 44 The illusion of strong consistency Monday, January 24, :09 PM The illusion of strong consistency How is this actually done? It's actually smoke and mirrors! Creating strong consistency Every object is "dirty" if changed, and "clean" if not. Very fast mechanisms for propogating "dirty" information (e.g., a bit array). A class of objects is dirty if any instance is. An instance is dirty if its data isn't completely propogated. Relatively slow mechanisms for changing something from "dirty" to "clean". Actually propogate the data, then relabel the thing as clean. Applications get "dirty" info immediately, and then wait until the data is clean before proceeding!

45 An example object Wednesday, January 27, :28 AM import com.google.appengine.api.datastore.key; import java.util.date; import javax.jdo.annotations.idgeneratorstrategy; import javax.jdo.annotations.identitytype; import javax.jdo.annotations.persistencecapable; import javax.jdo.annotations.persistent; import = IdentityType.APPLICATION) public class = IdGeneratorStrategy.IDENTITY) private Key private String private String private Date hiredate; public Employee(String firstname, String lastname, Date hiredate) { this.firstname = firstname; this.lastname = lastname; this.hiredate = hiredate; } // Accessors for the fields. JDO doesn't use these, but your application does. public Key getkey() { return key; } public String getfirstname() { Services Page 45

46 public String getfirstname() { return firstname; } public void setfirstname(string firstname) { this.firstname = firstname; } public String getlastname() { return lastname; } public void setlastname(string lastname) { this.lastname = lastname; } } public Date gethiredate() { return hiredate; } public void sethiredate(date hiredate) { this.hiredate = hiredate; } Pasted from < ses.html> Services Page 46

47 Services Page 47 Entity identity and keys Wednesday, January 27, :36 PM Entity identity and keys An object of type Key helps one locate persistent objects in the cloud By default, the system assigns it. You can also make one that is easier to remember.

48 Services Page 48 Creating an object with a settable key Wednesday, January 27, :45 PM import javax.jdo.annotations.idgeneratorstrategy; import javax.jdo.annotations.persistent; import javax.jdo.annotations.primarykey; import = IdGeneratorStrategy.IDENTITY) private Key key; public void setkey(key key) { this.key = key; } Pasted from < ddeletingdata.html>

49 Making an object with a known key Wednesday, January 27, :46 PM import com.google.appengine.api.datastore.key; import com.google.appengine.api.datastore.keyfactory; //... Key key = KeyFactory.createKey(Employee.class.getSimpleName(), "Alfred.Smith@example.com"); Employee e = new Employee(); e.setkey(key); pm.makepersistent(e); Pasted from < ddeletingdata.html> Services Page 49

50 Services Page 50 Retrieving an object via a known key Wednesday, January 27, :47 PM Key k = KeyFactory.createKey(Employee.class.getSimpleName(), "Alfred.Smith@example.com"); Employee e = pm.getobjectbyid(employee.class, k); Pasted from < ddeletingdata.html>

51 Services Page 51 Changing persistent objects Wednesday, January 27, :52 PM Key k = KeyFactory.createKey(Employee.class.getSimpleName(), "Alfred.Smith@example.com"); Employee e = pm.getobjectbyid(employee.class, k); e.setfirstname("alfred"); // happens in distributed space, immediately!

52 Services Page 52 A hard thing to understand Wednesday, January 27, :57 PM

53 Services Page 53 Persistent object caveats Wednesday, January 27, :38 PM Persistent object caveats Changes to a persistent object occur when requested. Access functions must be used; persistent data must be private; the PM factory adds management code to make this happen! Changes are reflected everywhere the object is being referenced!

54 Services Page 54 What does strong consistency mean? Wednesday, January 27, :02 PM What does strong consistency mean? When you change something in an instance of a persistent object, it is changed in every other image of that instance, including inside other instances of your application! But this is a polite illusion; in reality, other instances of your application wait for data they need to arrive! If -- on average -- there is one app looking at the object, then -- on average -- no one waits!

55 Services Page 55 Updating an entity from its own values Wednesday, January 27, :08 PM Consider the code: Key k = KeyFactory.createKey(Employee.class.getSimpleName(), "Alfred.Smith@example.com"); // assume existence of persistent getsalary and setsalary methods Employee e = pm.getobjectbyid(employee.class, k); e.setsalary(e.getsalary()+100); // Give Alfred a raise! Consider what happens when two application instances invoke this code at nearly the same time.

56 Services Page 56 The problem of concurrent updates Wednesday, January 27, :11 PM The code e.setsalary(e.getsalary()+100) is the same thing as (and is implemented as!) tmp = e.getsalary() tmp = tmp e.setsalary(tmp)

57 Services Page 57 So, we can execute this as: Wednesday, January 27, :13 PM So, we can execute this twice according to the following schedule: Instance 1 Instance 2 e.getsalary e.getsalary e.setsalary e.setsalary And Alfred gets a $100 raise rather than a $200 raise :(

58 Services Page 58 Transactions Wednesday, January 27, :16 PM Transactions allow us to avoid that problem: Identify operations that should be done without interruption. Keep other concurrent things from interfering between begin() and commit(). E.g.: Key k = KeyFactory.createKey(Employee.class.getSimpleName(), "Alfred.Smith@example.com"); pm.currenttransaction().begin(); Employee e = pm.getobjectbyid(employee.class, k); e.setsalary(e.getsalary()+100); // Give Alfred a raise! try { pm.currenttransaction().commit(); } catch (JDOCanRetryException ex) { // ouch: something prevented the transaction! throw ex; // share the pain! }

59 Services Page 59 How this works Wednesday, January 27, :32 PM How this works The transaction block (from begin() to commit()) attempts to execute before any other changes can be made to e. If no other changes have been made to e between begin() and commit(), the transaction succeeds. If some change in e has been made meanwhile, the transaction fails, e gets the changed values, the whole transaction is cancelled, and the application has to recover somehow (if it can).

60 Services Page 60 How this behaves Wednesday, January 27, :34 PM How this behaves If two applications try to do this, then the object will only change due to a commit. If two commits interleave, an exception is thrown. So we know we've goofed! It is the use of transactions that "creates" weak concurrency, but without them, we have chaos!

61 Services Page 61 Optimistic concurrency Wednesday, January 27, :23 PM Optimistic concurrency Transaction blocks delimit things that should be done together. If something changes about the object between begin() and commit(), the transaction throws an exception. So, the application knows that its request failed.

62 Services Page 62 Coping with optimistic concurrency via retries Wednesday, January 27, :25 PM for (int i = 0; i < NUM_RETRIES; i++) { pm.currenttransaction().begin(); Employee e = pm.getobjectbyid(employee.class, k); e.setsalary(e.getsalary()+100); // Give Alfred a raise! try { pm.currenttransaction().commit(); break; // from retry loop! } catch (JDOCanRetryException ex) { if (i == (NUM_RETRIES - 1)) { throw ex; } } }

63 Services Page 63 Global picture Monday, November 26, :47 PM

64 Services Page 64 End of Lecture on 11/26/2012 Monday, November 26, :33 PM

65 Services Page 65 When is strong concurrency a good choice? Wednesday, January 27, :34 AM When is strong concurrency a good choice? So far, we see that the outcome of concurrency is weak (transaction) consistency. Why does strong concurrency work well in Amazon dynamo? This is really subtle. Dynamo is intended as a data warehouse. Thus it is not a database itself, but rather, a historical record of a database. Thus it is never necessary to invoke a transaction on it!

66 Services Page 66 The NoSQL controversy Wednesday, March 09, :10 PM The NoSQL controversy NoSQL = "Not only Structured Query Language" Often misunderstood: some more radical authors interpret NoSQL as "Prevent Structured Query Language":) In actuality, the NoSQL movement: Assumes that the majority of queries are simple key fetches that don't require SQL syntax Optimizes simple key fetches for quick response. Often contains a fallback to interpreting full SQL, with performance disadvantages.

67 Services Page 67 A typical NoSQL service Wednesday, March 09, :12 PM A typical NoSQL storage service Operations are: ValueType get(keytype key) Assert the binding of a key to a value. Subsequent puts update data. int put(keytype key, ValueType value) Gets the last value associated with a key (most of the time).

68 Services Page 68 Roots of NoSQL Wednesday, March 09, :13 PM Roots of NoSQL The most common use-case is retrieval by key. Values are just bags of bits; the user can given them structure as needed. The CAP theorem: one cannot build a distributed database system that exhibits all of Consistency, high Availability, and robustness in the presence of Partitioning (loss of messages).

69 Services Page 69 The CAP Theorem Wednesday, March 09, :15 PM The CAP Theorem The CAP conjecture (Eric Brewer, 2000): any distributed datastore can only exhibit two of the following three properties Consistency: all nodes have the same view of data. (High) Availability: data is instantly available from the system. Partitionability: the system continues to respond if messages are lost (due to system or network failure). Proved to be true by Gilbert and Lynch (2002).

70 Services Page 70 Impact of the CAP theorem Wednesday, March 09, :56 PM In the context of cloud services: Main contribution: cloud datastores can be categorized in terms of the two (of three) properties C,A,P that they exhibit. AppEngine Java Distributed Objects (JDO) are in class CP = Consistency + Partitionability Only other reasonable class is AP = Availability + Partionability We don't usually want a cloud datastore that loses data! (e.g., P)

71 Services Page 71 The class AP Wednesday, March 09, :58 PM The class AP contains datastores like: Amazon Dynamo Facebook's Cassandra LinkedIn's Project Voldemort Why so many? Everybody needed one. Google didn't publish theirs (AppEngine/BigTable) in open source.

72 Services Page 72 Inside Dynamo Wednesday, March 09, :16 PM Inside Dynamo An arbitrary choice Because it's very well documented

73 Services Page 73 What is dynamo? Wednesday, March 09, :17 PM What is dynamo? The back-end cloud datastore for amazon.com itself. Serves requests for shopping carts, purchases. On an eventually consistent datastore! How?

74 Services Page 74 Unique features of dynamo Wednesday, March 09, :27 PM Unique features of Dynamo Vector clocks for conflict detection. Business logic for conflict resolution.

75 Services Page 75 Vector clocks Wednesday, March 09, :56 PM Vector clocks Every change transaction contains a timestamp and a pointer to the previous version of the object. As transactions flow through the system, they are accumulated in a local history (queue) on each (redundant) storage node. Local history is Pruned if there are no conflicts. Resolved (in an application-specific manner) if conflicts occur.

76 Example: shopping cart Wednesday, March 09, :03 PM Services Page 76

77 Services Page 77 Business-based recovery Wednesday, March 09, :05 PM Business-based recovery What happens when a conflict occurs is based upon business rules. If object is a shopping cart, contents are merged. If object is a purchase record, apparent duplicate purchases are eliminated.

78 Services Page 78 Why? Wednesday, March 09, :16 PM Why Amazon "gets away with" Dynamo one would usually not want to store business data in an eventually consistent store. customer dissatisfaction: "buy this" responds with "you haven't bought it (yet)" Amazon "gets away with" doing that, by embedding business logic. using vector clock updates. for each kind of object, separately. This is a complex game, which is why Dynamo isn't available directly to their customers.