The course project is :
Build a consuming client application which meets the following requirements.
Covers lectures 1 through 6. The emphasis is on the SOAP, WSDL And UDDI standards.
Specific topics included will be many of the following. All topics covered in class
however are fair game.
- Must write a desktop application which consumes an informational backend web service.
The desktop application can be written with AboveAll Studio or Visual Studio.NET.
- Write an application for mobile devices which consumes the same web service.
This should be written with either Microsoft's .NET Compact Framework or
Good Technology's GoodAccess Web Services
- Optionally write the backend web service itself in Visual Studio .NET
An actual exam is at
Covers metadata repositories, WS-Security, WS-Eventing, WS-Addressing.
- motivation behind web services
- definition of a web service
- characteristics of a good web service
- identification of components of a web service architecture in a diagram
- SOAP message structure
- identifying purpose of elements in SOAP envelope example
- design purpose between differentiating between header and body elements
- description of purpose of locating elements in specific places in SOAP
- purpose of SOAP faults
- meaning of SOAP mustUnderstand
- WSDL architecture components
- purpose of various parts in specific WSDL examples
- basic steps in creating and exposing a .NET web service
- describe methods of testing web services
- list potential web services uses including some specific example web services
- discuss characteristics of informational web services versus transactional web services
- differences of SOAP versus other distributed system capabilities
- good and bad parts of CORBA, DCOM and Java RMI
- why use asynchronous web services
- how does .NET expose asynch web services
- three basic methods of invoking async web services
- .NET methods of blocking for web service invocation
- motivation for a web services registry
- basic abstractions in UDDI standard
- meaning of components in XML data model in UDDI
- the two types of tModels and the purposes
- meaning of specific UDDI API calls
- how do UDDI abstractions map to WSDL abstractions
- standard methods to populate UDDI registries with WSDL information
- methods of extending UDDI registries with information on services and their endpoints
Helsinski asks students to write a report on a topic, and gives an extensive referenec
Typical reports were
- Semantic Web Services - report by Mikko Laukkanen [Review1 -> REST ][Review2 ->Service Oriented Architecture]
- BPEL4WS - report by Simo Viitanen [Review1->REST ][Review2->Semantic Web Services]]
- XML Basics: XML, XML Schema, Namespaces - report by Aleksanteri Aaltonen - [Review1 -> SOAP & WSDL ] [Review2 -> Service Oriented Architecture]
- WS-Policy Framework - report by Tuomas M T Nurmela [Review1->WS-Trust][Review2->WS-Reliability]
- REST - report by Michael Przybilski [Review1->Semantic Web Services][Review2 ->Service Oriented Architecture]
The Chapstick shopping centre is one of Australia's largest shopping
centres and hosts a large number of shops of different kinds.
Chapstick already has an extensive Web site, but is contemplating
moving towards an online system to support ecommerce activities.
You will need to implement a client and one or more servers
using a socket-based protocol.
The client will need to be able to make the following requests
to the Chapstick central server:
What types of shops are currently in the shopping mall?
The response should be a list such as:
Men's apparel, Giftware, Toys/Games, etc.
For a given shop type, what shops of that type are in the
Where is a particular shop located? This should be in
"map coordinates" such as F15
For a particular shop, what is its catalogue?
The result should be a list of items sold by the shop
and the price of each item
Buy an item from a shop. The purchase request should
include some credit card information
Errors should be handled appropriately
A client talking to a single server. The server handles
all of the Chapstick requests.
The server keeps lists of the shops, of their types
and has a catalogue for each shop.
All of this can be done using local files and/or
lists and tables kept in memory.
This level demonstrates that you can specify a protocol for
a client and a single server and implement this protocol in a
The specification given above will gain a Pass grade if done
satisfactorily. Higher grades will be given
on completion of additional functionality.
Each additional function will gain an extra grade
(to a maximum of HD). The
additional functions are
All databases are managed by a database system such as Access,
Oracle or MySQL. The server communicates with the database by
This level shows that you can manage a typical 3-tier system
with presentation, logic and database handled separately.
Each shop runs its own server. Chapstick will forward
certain requests (such as catalogue) directly to the
shop's server rather than maintaining information
on its own server.
This level demonstrates that you can deal with a multi-tier system
with many servers at the backend
All sensitive accesses are performed using security mechanisms,
such as encryption and validation. Each server
should be able to validate its identity using certificates
This level shows that you can handle the authorisation, security
and privacy issues that can arise
Web access to the Chapstick service should be made available.
This will mean a CGI script/Java servlet/etc that can act
as a client to the Chapstick server. This will involve
a set of Web pages and HTTP backends to handle form requests.
This is in addition to an ordinary client, not as a replacement
This level will add alternative access mechanisms to the service,
which makes it Web-accessible to humans
Jan Newmarch (http://jan.newmarch.name)
Last modified: Mon Dec 5 11:23:19 EST 2005
Copyright ©Jan Newmarch
Access count since May 2005 is:
This page is http://jan.newmarch.name:443/webservices/assignments.html