Build a web service and a consuming client application which meets the following requirements

• - Web service server and web service consumer must be written with different tools

  e.g. Apache Axis Java server, Visual C# .NET client

• - Must run on separate machines. Disparate platforms (Linux/Windows, PDA/server) even better
• - Must utilize a �WSDL first� or �schema first� design approach
• - Must allow ad hoc clients and other programs to connect the exposed web service as well. And make this
• - All code must actually function No mockups
• - Web services that �screenscrape� existing websites are acceptable (even encouraged)
• - Team size: two or three people

Detailed Requirements:

Several techniques demonstrated in the course need to be demonstrated. These include:

• - Must demonstrate asynchrony on the client
• - Must register its presence in a UDDI registry
• - Client must be able to find instances and locations of services in UDDI registry
• - Must incorporate use of some advanced WS-* standard. This can either be: WS-Security, WS-Addressing, WS-ReliableMessaging, or WS-Eventing.
• - Must demonstrate usage with an ad hoc interface client (e.g. AboveAll or InfoPath)
• - Must measure performance in some fashion

Grading Criteria

I will use the following criteria to evaluate your project

• Interface Design

  Well designed, well factored service interface with good XML document and type design. Part of this criteria

• Use of Web Service Standards

  Uses WSDL-first approach. Registers presence in UDDI, searches for backend web services in UDDI registries. Leverages one of required set of advanced WS-* standards

• Scalable Architecture and Performance Analysis

  At least one of the operations needs to be asynchronous. The writeup should describe why your backend web service (or the high volume operations which it uses) will scale. Some form of performance analysis and testing needs to be performed.

• Service Documentation

  Backend service should be documented well so that arbitrary clients can use it. Part of this includes registering the service in UDDI. Ideally there should also be a web page documenting the web service.

• Solution Quality

  The overall project is functional and testable with few bugs.

• Code Quality

  High quality maintainable and well-documented code

• Architecture Description

  You provide a good description of how the overall solution was built and what its major components are.

Prepare the WSDL and/or XML Schema which you will use to integrate your client and server. It does not have to be the final version. It should encompass all operations exposed by your backend.

The second phase of the web services project is to implement the web services backend for your project. Note that it is acceptable for the backend web service to not be final. The methods can be stubs which only return hardcoded example values. But each method should be functional to the point of at least returning sample values. However, I suggest just going ahead and implementing the full backend web service, since future weeks will be filled with other projects. I would also like the services to be registered in a public UDDI such as test.uddi.microsoft.com. Please create a provider name which includes "SIMS web services". For example, "Cal Berkeley SIMS web services course - Carolyn and Lisa". As a later phase I will expect that your service can register itself in any specified UDDI registry programmatically. .

The third phase of the web services project is to implement the web service client application. Most of you are doing yours with Visual Studio. You can build a Windows client application or a web-based Active Server Pages application.

The fourth phase of the web services project is to implement some advanced WS-* standard (WS-Security, WS-Addressing, WS-ReliableMessaging or WS-Eventing in both the server and the client. If you are building Visual Studio.NET clients Web Services Enhancements 2.0 will give you any either WS-Security or WS-Addressing out of the box. On an Apache Axis backend there are third party open source implementations of WS-Security, WS-Addressing and WS-ReliableMessaging. Lecture 9 mentions several of these. You may end up implementing either the front or backend (or both) of the standard yourself. In this case, either WS-Security username tokens or WS-Addressing routability are probably the easiest enhancements to implement by hand.

As an example of what you might do, you might want to have one of your operations requiring a signed message to insure the requesting user's identity. Another example enhancement would be to support WS-Addressing so that requests can be forwarded to the service, and replies can be routed back to the requestor. This eliminates the need to be directly connected via http.