Technical Description

The Academic History Web Service handles AcademicHistory, Ping, and service Statistics Query-Request messages.  This service will be deployed at various academic institutions and invoked by AcademyOne applications to import student academic histories and monitor the remotely deployed service and report on its status.  For more details on the definition and content of these objects and messages, see the Academic History analysis template. 

This service will utilize open source EAI and SOA infrastructure from the OpenEAI and Apache projects to make the service and its deployment open and transparent.  Many institutions deploying this service will either not have EAI or SOA infrastructure or the people deploying the service may not be familiar with their existing infrastructure.  In order to ensure the quickest possible deployment, the service will be packaged within a lightweight Apache ServiceMix deployment that will include all infrastructure required to deploy, configure, and start the service in one easy deployment process without highly specialized assistance.  This will allow AcademyOne and/or InVivo staff to assist most institutions with setup and testing of the service in a conference call and web meeting. 

Users of AcademyOne will want to import their academic history from institutions into the AcademyOne application.  They will select the option to import, specify the institution, and provide their principal and credential at that institution.  The AcademyOne application will then invoke the Academic History Web Service at the target institution.  This request is an AcademicHistory.Query-Request made via web service protocols. 

AcademyOne will likely also need to monitor the status of these remote services in order to support their users and assist institutions with managing and troubleshooting any remotely deployed services.

Messages handled by the Academic History Web Service

1. com.academyone.Student.AcademicHistory.Query-Request
2. com.academyone.Service.Ping.Query-Request
3. com.academyone.Service.Statistics.Query-Request

1.       com.academyone.Student.AcademicHistory.Query-Request

The Academic History Web Service authenticates the requesting client application (AcademyOne) using certificate authentication features of the web services framework in which it is running.  It then handles the query request by authenticating the user with a configurable authenticator and, if the user is authentic, building the academic history with a configurable academic history provider. 

2.       com.academyone.Services.Ping.Query-Request

The Academic History Web Service authenticates the requesting client application (AcademyOne) using certificate authentication features of the web services framework in which it is running.  It then handles the query request by providing a configurable response in the ping text. 

3.       com.adacemyone.Services.Statistics.Query-Request

The Academic History Web Service authenticates the requesting client application (AcademyOne) using certificate authentication features of the web services framework in which it is running.  It then handles the query request by querying the embedded service statistics database, materializing the results, and returning them in the response. 

Components of the Academic History Web Service

The Academic History Web Service consists of the following components:

1.      A package of Apache ServiceMix tweaked to support the typical deployment of the AcademicHistory web service assembly.

2.      A web service assembly that contains a handler that passes requests off to the following commands.  The service assembly will contain everything needed to run the service in another standard JBI enterprise service bus should an institution have other such infrastructure like Sun Glassfish, OpenESB, or others besides ServiceMix.

3.      A request command that consumes com.academyone.Student.AcademicHistory.Query-Request messages and uses a configurable Authenticator and a configurable AcadmicHistoryRepository object to retrieve an academic history for the appropriate user. This command also maintains service statistics.

4.      An Authenticator framework with relevant implementations that allows us to configure how users will be authenticated. For example, if the student will be authenticated via username and password in enterprise LDAP, an LdapAuthenticator will be configured and used.  However, if the user is being authenticated against SunGard Banner a BannerAuthenticator would be configured and use[[saw1]|#_msocom_1] .

5.      An AcademicHistoryRepository framework that allows us to configure from which repository (that is, student information system) the academic history will be built.  We will provide a general relational database implementation called the RdbmsAcademicHistoryRepository.  This should take care of many student systems with one implementation.  As long as the AcademicHistory can be represented with an SQL query, this one implementation will materialize the academic history.  We may also provide any other custom implementations we think are necessary[[saw2]|#_msocom_2] .

6.      A request command that consumes com.academyone.Services.Ping.Query-Request messages and returns a configurable ping response.

7.      A request command that consumes com.academyone.Services.Statistics.Query-Request messages and returns the current service statistics.

8.      Test Suites to test all operations of the service.

Technical description of each component

Steve Wheat will update this section as he works on the prototype this week along with the draft user guide.

 [[saw1]|#_msoanchor_1]Note: we should specify here which will  be our target Authenticators for this initial implementation.
 [[saw2]|#_msoanchor_2]Note: we should identify any custom AcademicHistoryRepository implementations we think we need to provide beyond the general RDBMS implementation.