Design
The design of the channels was dictated by uPortal channel design guidelines and the Web services were based on the design of the existing NIIMLE services.
uPortal custom channels
The source code packages for the uPortal channels are shown below.

Figure 1: uPortal source code packages
IMS Enterprise Web Services packages
IMS Enterprise Web Services packages (org.imsglobal.www.specs.*) and classes were inherited from NIIMLE. The NIIMLE developers generated the IMS classes from the Web service descriptions (WSDL files) published as part of the IMS Enterprise Web Services specification using the Apache Axis WSDL2Java tool. WSDL2Java takes a set of Web service descriptions and generates Java classes for IMS Enterprise objects and Java classes and interfaces to for stubs, service interfaces and service implementations. The generated classes provided a framework for implementation of the services. The SUNIWE uPortal custom channels used the IMS Enterprise classes for data returned from the services.
uPortal packages
Some uPortal packages (org.jasig.portal.*) are shown in the diagram above. Most have been trimmed from the diagram to save space. There are a lot of uPortal packages. The source code for custom channels is in the same place as the source code for uPortal itself. uPortal runs as a web application within Tomcat. The process of developing a channel includes keeping a local copy of the entire source code for uPortal, adding the source for the custom channel to it, and running the uPortal build script to build the code and deploy it to Tomcat.
SUNIWE custom channel classes
SUNIWE portal content was implemented as uPortal Custom channels. The classes implementing the channels are shown below.

Figure 2: SUNIWE channel source code
The uk.ac.suniwe.common package contains:
-
classes implementing common utilities
-
common JavaBeans used by the service classes
-
properties files
Each custom channel has a package which contains the controlling class of the channel, e.g. CPersonalInformation.java. The controlling class responds to events from uPortal, determines which screen to display and invokes the screen rendering class. Rendering classes are stored in a views package under each channel package. Each screen of the channel has a class which handles rendering of the screen. This involves calling Web services to get the data, storing the returned data in JavaBeans, getting an XML representation of the data, transforming the XML into presentational XHTML, and forwarding the XHTML to uPortal for further processing. The XHTML then undergoes uPortal transformations to position and style the content ready for display in the portal.

Figure 3: SUNIWE channel stylesheets
Each screen has a XSL stylesheet which is used by the channel to transform the XML received from the Web services into XHTML. The XHTML includes uPortal CSS markup to ensure that the channel content assumes the look and feel of the current uPortal theme/skin. The stylesheets are stored in a different are of the uPortal source tree from the channel source code.
Each channel also has a corresponding stylesheet list (SSL) file. This contains a list of stylesheets for the channel and rules for when to use the stylesheets. This enables different presentation of the same content depending on the type of browser or platform.
Web services
The source code packages for the Web services are shown below.

Figure 4: Web services source code packages
Client package
This package includes the command line test client written by Greg McClure for simple testing of the Web services. It also includes SQL scripts and sample anonymised data for populating the MySQL test database.
IMS Enterprise Web Services packages
The same Web services packages and classes were used as in the uPortal channel implementations. The IMS classes referenced classes in the SUNIWE packages for the implementation of the service operations.
SUNIWE implementation packages
SUNIWE implementation classes (uk.ac.suniwe.*) handled service requests, queried databases to get the data and constructed service responses.

Figure 5: SUNIWE Web service implementation classes
The common package (uk.ac.suniwe.common) contained:
-
classes implementing common utilities
-
common JavaBeans used by the service classes
-
properties files
Each service had a package of classes which implemented operations of that service. Service packages followed the same pattern of classes. For example, the Group Management Service package (uk.ac.suniwe.gms) contained:
-
GroupManagementServiceSuniweImpl.java – implemented the service operations
-
SuniweGMSSQL.java – handled querying the database and populating JavaBeans with the data
-
SuniweGMSTransformer.java – handled transforming data from the JavaBeans into IMS objects

