CMSC 621- FALL 2006
Base Project - 100 points
The primary goal of the project is to build a distributed, policy controlled
web-services framework. Policies provide high level (human and) machine
understandable norms of behavior for entities in open systems such as the web.
In this context, one may think of them as constraints on services. There has
been increasing interest in using policies with the web in general and web
services in particular. The W3C for instance has a project on a "Policy
Aware Web". A secondary goal is to make you familiar with the tools of the
trade being used to implement many distributed systems today. They are
represented by an increasingly large alphabet soup -- XML, SOAP,
Requirements -- The Barebones Infrastructure -- 75 points
This describes the underlying distributed infrastructure you will create to access and invoke web services. There will be multiple sites hosting a collection of webservices. Each site will provide a mechanism for the user to ask for a certain service. To invoke a service, a site needs to first "discover" all sites that host the webservice that it is looking for, and then invoke the webservice so as to balance the load on each site. Service descriptions should be provided in WSDL. You may assume that there is no disambiguation involved -- all services called "foo" offer the same service and interface. There should be minimal centralized components (single points of failure) in your system. You may want to develop a GUI for your system; however you will be graded based on the overall functionality and not on how fancy the GUI is. Similarly, we do not care what the services actually are -- they could be something simple. You may however want to have a few different services that load machines differently.
Requirements -- The State of
All sites are required to support and honor Webservice Policy (WS-Policy) framework, the reference to which is provided below. For instance, a service could say that it will only allow itself to be executed by those who can provide a password. A request for service could say that it will only use those providers who are willing to accept end-end encryption of data/results flowing between them. In this project, we are not concerned with how policies are created, or how complex boolean combinations of policies can be created. You will get full credit if you can parse and correctly implement policies specified in the format required by WS-Policy that use simple conjunctions or disjunctions.
The description of the system above, like in real life, is underspecified. There are a variety of ways to implement the ideas described above. For instance, for service discovery you may want to build a distributed mechanism based on algorithms like "Chord" or use a completely replicated registry at each site or create a centralized registry which is cached at sites and so on. Similar ideas can be used for finding the least loaded site. Perhaps even the load and service information can be merged? Should request forwarding be allowed -- if site A requests B for some service, B may in turn request C for the same service if it is overloaded and return results to A transparently
You may need to make additional assumptions to come up with a concrete design and then a reference implementation. Hence, state your assumptions clearly in your design, and make sure you justify your design choices. Your assumptions will be evaluated based on how it helps your design and how "real" they are. We will also look at your design rationale
Extra Credit -- Exploring Research Issues -- Upto 25 points
You can choose to implement complex web service policies for extra credit. This might let you provide negotiable constraints, or handle dynamic modification of policies via delegations or revocations. Basically, you will learn how to use an existing policy language and framework, such as Rei, and then integrate it into the web services framework. It can either be done at the WS-Policy level, or outside. If you choose to explore this path, please make sure you talk to the instructor beforehand to scope it out.
Experiments
A part of your project is to design and carry out an experimental validation to convince us that your system works. This is true for both the base task as well as the extra credit. You should also analyze your system for scalability -- number of hosts, number of tasks, etc, reliability -- how does the system behave on random site failures, performance -- can you tune some parameters to make the system perform better. You should experiment with different workload mixtures. Comment on the results you get -- try to identify what assumptions you made or implementation mechanisms of your system cause particular scalability patterns. Try and identify both the strengths and weaknesses of your system. If you use your experimental results to refine your design, make sure you bring this out in your report.
Mechanics
You will do this project in groups. The group shall have two members.
Permission to do the project individually will be granted rarely. In any case,
such individuals will still be judged against the same criteria as regular
groups.
Deadlines
Some general suggestions
As should be evident to most of you, it is imperative for a project of this complexity and involving teams that you design your system before you code! In your design, you will need to make assumptions as you flesh in the details of the system. Please make sure that you state them in your design document. Make a timeline for your work, and try and stick to it. Where you divide tasks, make sure you clearly define points of articulation and interfaces between modules. As you form groups, please make sure that you can find a common time to meet. This is especially true for those who are part time students and hold jobs which will restrict your schedule. Please comment your code well -- it will help both you and us. You in figuring out code your partners have written, us in grading it. Also, at the minimum use some form of revision control on your source tree. CS/UCS machines have systems such as CVS and RCS available for your use. This will help if lightening strikes, UPC fails and machines/disks crash, making your recent changes disappear! Please do create makefiles/ant scripts -- you may in fact prefer to use freeware IDEs such as Eclipse.
You are allowed to discuss the project across groups. Clearly, you are not
allowed to share solutions. You may read papers and textbooks in this area as
well -- some pointers are provided in this document. However, you should cite
the sources you have consulted. Also, be sure to mention any students (in or
out-of class)/professors/individuals you consulted regarding the project. We
would encourage you to do this project using Java on the CS/UCS Unix systems.
We strongly suggest that unless you are a very proficient Java programmer with
XML knowledge, you look at tools provided by Apache's Axis project to create
and manage web services. You may also want to check out Tungsten, developed by
a lot of folks who are involved with the Axis project. However, you are free to
choose another imperative language should you so desire. We would like to see
your final demo on multiple machines and not as multiple instances of your
application on a single machine.
References
1. Web services: Introduction to webservices, WSDL, SOAP
2. Service Discovery: Jini , Service Location Protocol , UDDI , Chord
3. Policy Frameworks: WS-Policy Specification, WS-Policy framework, Rei, Rein, KAoS Paper 1, KAoS Paper 2
4. Frameworks for deploying webservices: Apache Axis (Java), Tungsten, Apache Axis (C++)
5. Miscellaneous: Eclipse, Apache Ant, CVS, Jakarta Commons