Comp150CPA: Clouds and Power-Aware Computing
Classroom Exercise 12
SOAP and Axis Answers
Spring 2011

group member 1: ____________________________ login: ______________

group member 2: ____________________________ login: ______________

group member 3: ____________________________ login: ______________

group member 4: ____________________________ login: ______________

group member 5: ____________________________ login: ______________

In class we have explored how to convert a Plain-Old-Java-Object (POJO) into a web service with Axis. Let's explore that in more detail.

  1. Why does the services.xml file for Axis make you explicitly list each Java method that should become a service?
    Answer: Some (otherwise public) Java methods need to remain private to the cloud. E.g., some functionality might not be exposed to the outside world. For example, consider a service that lists user locations. There might be a local admin interface that is not exposed to users, but nonetheless, must be declared public. Failing to list that in services.xml makes it local to the server, and prevents outsiders from accessing it.

    There are many reasons you might want something to be private:

    1. To prevent malicious use of insecure methods.
    2. To prevent denial-of-service attacks from spurious requests.
    3. To allow only local access to administrative functions.
    Etc.
  2. Why does Axis force you to deploy the service before writing the client for it?
    Answer: While the service is deployed on a server, the client (by necessity and almost by definition) is deployed somewhere else. Meanwhile, the client depends upon the location of the deployed instance and hard-codes it into its implementation. So it is not particularly useful to be able to deploy a client on the server, because by definition, it will not be used there.
  3. List the ways that services might compete as business propositions, and give reasons why you might choose one service over another for an application.
    Answer: Modes of competition include:
    1. Speed of response (e.g., if querying into public data, e.g., the internet).
    2. Accuracy/completeness of response (e.g., if querying into privately maintained "yellow pages" corpora).
    3. Richness of interface (e.g., if providing geophysical mapping data for an application, "how many layers" are available?).
    4. Interoperability with other services (e.g., when you register your location in a place, do other services "know" about that?)
  4. What kinds of things can go wrong if your program dynamically chooses one of several available services -- all with the same interface -- to provide some function.
    Answer: There is nothing in WSAPI or WSDL that says that the services have to return the same data. "The same interface" means that the data has the same kind, but not even that it "means" the same thing. So when you ask for local restaurants,
    1. one service might not know about them (incomplete corporum).
    2. another service might return a list of fish markets instead (same data format, different data meaning.
    3. a third service might leave some data blank (WSDL says nothing about what has to be in the fields).
  5. (Advanced) What kinds of java objects would not be appropriate to expose via Axis services? Why?
    Answer: There are several situations that it would be best to avoid. All of these revolve around the method not having enough information to proceed reasonably when implemented as a remote procedure call.
    1. Persistence: for obvious reasons, methods that utilize state from non-final global variables are not acceptable; these variables would lose state when the service was reset! Instead, one must read state from some (ideally globally consistent) persistence mechanism.
    2. Security: if an operation requires privilege, that privilege must be explicitly passed (as a token) to the method. Otherwise, providing access to the method would bypass any security protections.
    It is perhaps best to separate these from other reasons that Axis services might not be useful to clouds:
    1. Local state: Each instance must avoid any concept of local state that is distinct from (and not simply a cache of) the state of every other instance.
    In the latter case, the Axis service is implementable, but not necessarily usable via flowless switching!