The Course Schedule Report Web Service

Fall 2004 Infosys 290-3

OVERVIEW

The Course Report Web Service is a special feature of the SylViA project developed as a final project for the course Web Services: Concepts, Design and Implementation (Infosys 290-3). The service leverages the data store in the the SylViA Project's application to help professors coordinate their schedules. A request to the service contains a date span as well as a list of courses to query. The response contains all exams and assignments due in those courses in the given time frame. Professors can use the service to ensure that their exams and major assignments do not conflict with their students' other courses. The web service is no longer functioning due to significant changes in the SylViA schema, and because the backend server has been removed.

ARCHITECTURE

The backend of the web service is built on Apache Axis using WSDL2Java to generate stub classes and classes that correspond to the types in our schema. We then built a thick windows client in C# using VisualStudio.NET. There were some interoperability problems between these two implementations. We also built a standalone application in C# using VisualStudio .Net that publishes web services in a UDDI registery.

During the Fall 2004 semester, the SylViA viewer application itself was built on Cocoon and uses pipelines to transform the xml files that contain syllabus data into HTML or XML views. The server interacts with the SylViA viewer over HTTP to access these views. We wrote a specialized transform that returns all assignments and exams in a given course's xml file. The server code then extracts only the events within the correct time frame, and it aggregates results from different courses to form the body of the response. We used the DOM to manipulate XML in Java, since it was the most convenient and straightforward.

INTEROPERABILITY ISSUES

We had to change all the dates in our schema to strings because C#'s datatype for dates does not conform to the standards followed by Java or XML. We also had to create a wrapper classaround the events returned in order to deal with C#'s idiosyncratic handling of serialized arrays.

Our schema in our WSDL originally used the namespace of SylViA schema, as web service data types were derived from that schema. However, as that namespace contains characters that are not allowed in Java package names, we had to create a new namespace for the WSDL2Java transformation to be handled correctly.

SPECIAL FEATURES

The server implements the most basic parts of the WS-Addressing specification. It is prepared to accept SOAP headers for MessageID, To, ReplyTo/Address, and Action. It then returns SOAP headers including MessageID, To, RelatesTo, and Action. The MessageID is randomly generated and the Action is derived from the WSDL according the standards in the spec. The outgoing To header is the same as the incoming ReplyTo/Address header and the outgoing RelatesTo corresponds to the incoming MessageID.

The backend of the service does nothing to verify the input. The client must provide correct input. The body of a message coming into the server consists of a date span and list of courses the user is interested in. The correct format for the date input is yyyy-mm-dd (ex: 2004-08-15). Any other format will result in invalid results. The SylViA viewer at that time only had data for the Fall 2004 semester, and an appropriate date span to restrict the users to is 2004-08-15 to 2004-12-10. Course numbers should be restricted to only the numbers (ex: 255 or 290-3) and should not include any other information such as the department code (ex: IS290-8). Only those courses that participated in The Syllabus Project can be queried by the service. Those courses are: 202, 203, 237, 255, 290-3, 290-8, 290-10 and 290-16. Queries to any other courses will result in invalid results.

To ensure that the user inputs information that will result in events, the client restricts the users to selecting from the above date span and course list. The client makes an inquiry to the service's registry with test.uddi.microsoft.com. If the access point of the service is different from the access point within the client, the access point is changed, and the request is sent to that access point. The client provides the service with the WS-Addressing information that it requires, using Microsoft's Web Service Extensions. The client is able to call the service asynchronously, using the polling method. While the request is being sent and the response received, the client uses a progress bar to indicate that the response has not yet been received. The polling period is restricted to 30 seconds. Rather than displaying all of the information received, the client only displayes the event date, the event's course, and whether the event is an assignment or exam. If the event is an assignment, the assignment title is displayed, and if the event is an exam, "Exam" is displayed.

The standalone UDDI publishing application is currently configured to only publish the Course Schedule Report Service. It can be easily reconfigured to publish any service to any UDDI registry by changing the source code. The publishing application allows a user to enter their .Net user id and password, information about their business, providor and service, and the registry they wish to publish to. The service information is then sent to the registry, where it is posted.

We do not believe that the service is scalable because as yet the SylViA viewer has not proven to be scalable beyond the SIMS community. Any increase in the syllabus application's scalability will increase the scalability of the service.

We have successfully tested the service with two ad hoc client generators: Mindreef's Soap Scope and Above All Software's Above All Studio.