Comp150CPA: Clouds and Power-Aware Computing
Classroom Exercise 12
SOAP and Axis Answers
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.
- Why does the
services.xml file for Axis make you
explicitly list each Java method that should become a service?
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
makes it local to the server, and prevents outsiders from accessing it.
There are many reasons you might want something to be private:
- To prevent malicious use of insecure methods.
- To prevent denial-of-service attacks from spurious requests.
- To allow only local access to administrative functions.
- Why does Axis force you to deploy the service before writing
the client for it?
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
- List the ways that services might compete as business propositions, and give reasons why you might choose one service over another for an application.
Modes of competition include:
- Speed of response (e.g., if querying into public data, e.g.,
- Accuracy/completeness of response (e.g., if querying into privately
maintained "yellow pages" corpora).
- Richness of interface (e.g., if providing geophysical mapping data for
an application, "how many layers" are available?).
- Interoperability with other services (e.g., when you register your
location in a place, do other services "know" about that?)
- 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.
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,
- one service might not know about them (incomplete corporum).
- another service might return a list of fish markets instead (same data format, different data meaning.
- a third service might leave some data blank (WSDL says nothing about
what has to be in the fields).
- (Advanced) What kinds of java objects would not be appropriate to
expose via Axis services? Why?
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.
It is perhaps best to separate these from other reasons that Axis services
might not be useful to clouds:
- 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.
- 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.
In the latter case, the Axis service is implementable, but not necessarily
usable via flowless switching!
- 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.