|
Home
>
7. what projects have done
>
7.3 Requirements
|
Previous
Next 
|
|
|
|
|
|
|
|
|
|
|
Details of what we are currently using:
Deployment machine: Linux Server with 2 x Pentium 3 1 GHz processors; 2 Gb RAM, 34 Gb Hard Disk
Development machine: Windows 2000 Workstation with Pentium 3 800 Mhz processor; 512 Mb RAM; 24
Gb Hard disk. N.B. The system works works fine on this, at least with a small number of concurrent
users. The development and deployment environment currently occupies about 300 Mb. |
|
The GIMIS architecture does not 'require' any specific hardware. It is designed to run on almost any
platform/OS combination.
It works well on any of the following and by implication, the hardware that they support/require:
Win32 (9x to XP)
Unix (almost any flavour)
Linux
Solaris
Mac OS |
|
INSIDE integration server and INSIDE development server (Intel/Linux), PCs, Macs, etc.
USB swipe card readers. |
|
In general, MARTINI requires a Web server, an application server, and an authentication server.
MARTINI's demonstrator is now running on a PC under the Windows 2000 server operating system. The
hardware required is simply a P3 processor with 512M memory. The necessity for any hardware upgrade
required for deployment of MARTINI system has yet to be determined.
There is no specific hardware that the MARTINI system must have in order to work properly. |
|
Zope is platform independent, however we host the service on a Sun E450 server, Solaris 8. |
|
We have run TISR on the following:
1 GHz P3, 384 Mb RAM, Win2k; 667 MHz PPC, 1 Gb RAM, Mac OS X; AMD Althlon 1 Ghz, 384 Mb RAM,
Win2K
Suggested Minimum requirement: P3 1 Ghz / PPC 667 Mhz 256 Mb RAM 100 Mbit Ethernet 40 Gb Hard
disk Linux Windows NT/2K/XP -tested and supported Mac OSX - limited testing Solaris (on Sun hardware) |
|
|
|
|
Java 1.3 or higher; uPortal version 2; Postgres database management system. |
|
Web Server
ColdFusion Server 5+
Database Connection Drivers (ODBC etc.)
MySQL 4.01+ |
|
mySQL, Access, Ingres, Oracle, SQL, SITS, Apache, Tomcat, Java Server Pages, Java Servlets |
|
Web Server
Java Virtual Machine (Run Time Environment 1.4.1)
Web Objects 5.0
LDAP directory / Active directory server
Since MARTINI system is developed in pure Java code under the WebObjects development environment,
it is able to run on different platforms. In relation to the compatibility between WebObjects and the OS, the
designers of WebObjects state that it is compatible with Mac OS, Windows 2000, Solaris and UNIX
system. Thus, in order to run MARTINI system, any machine/server needs one of the afore-mentioned
OSs installed. |
|
Zope version 2.6, CMF 1.3, Plone branch 1.0, LDAP directory. |
|
Apart from the data sources to connect to:
An LDAP server with TISR schemas
(we are using Netscape Directory Server 4.16 switched to iPlanet for Demonstrator)
Castor
JDOM
Servlet engine (we are using Resin)
EJB Host (we are using Resin)
TISR.war
TISR.jar |
|
|
|
|
Any Web browser which supports HTTP 1.0 or above and HTML 3.2 or above. |
|
Web Browser (IE 4+, Opera 5+ , NS 6.2+, Konqueror (Linux) et al) |
|
Web browser. Most of the popular releases are supported. |
|
Web Browser supporting HTTP 1.0/1.1 |
|
Web Browser (IE 5+, Opera 5+ , NS 6.2+, Lynx) desired, however will work adequately on earlier versions. |
|
For simple application, a standards compliant web browser.
The TISR sample application uses SVGs for graphics. These graphics add eyecandy and are not
necessary for the successful operation of TISR. The sample stylesheets may be edited to remove the
SVG elements. |
|
|
|
|
The interface has been designed according to usability standards and good practice, including provision
for users with disabilities. See Deliverable D2.2
http://mle.dmu.ac.uk/deliver/dmu_VDesk_Design_2_2.doc (Section 3) and Deliverable D2.1
http://mle.dmu.ac.uk/deliver/dmu_User_Service_Assess_2_1.doc(Section 4.3). The first version of the
interface was evaluated by external consultants. See Deliverables D6.1a2
http://mle.dmu.ac.uk/deliver/DMU_6_1_appendix_2.doc and D6.2a
http://mle.dmu.ac.uk/deliver/DMU_OU_Usability_6_2.doc. Subsequent versions have taken account of
these reports. |
|
Through the adoption of the Section 508 standard, the GIMIS interface is built with the aim of providing
equal access to users of all capabilities.
The design is also optimised for external users who may be on slow connections; to this end, the design
produces results that are as compact as possible. |
|
As a result of Government and University initiatives and SENDA (Special Educational Needs and
Disability Act 2001) investigations into accessibility issues are underway. Although current web
applications and pages are not at present adapted, we are aware of the need to do so. The findings of
these investigations are presented in:
C. Boldyreff "Determination and Evaluation of Web Accessibility", Eleventh IEEE International Workshops
on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE'02) June 10 - 12, 2002,
IEEE Computer Society. |
|
MARTINI explicitly addresses accessibility. Variant of interface using HTML and CSS designed and
checked to be Bobby-compliant. (The MARTINI software has meet the requirement of Bobby AA Approval
in both GUI and TEXT-based interface). |
|
W3C AA compliant
With the aim that regardless of IT equipment, geographical location, special needs or browser
preference information can be accessed in a way that best suits required needs.
Northumbria Sight Service also evaluated the site for usability / accessability. |
|
Output is all XML. Administrators can produce style sheets with XSLT to meet needs. Sample style
sheets produce XHTML output. |
|
|
|
|
Significant effort has been expended on usability requirements - the project has a national profile in this
regard alone.
See Accessibility awareness above. |
|
See Accessibility awareness above. The present interface uses frames; the left hand navigation frame
relies on Javascript. |
|
Limitations of the present system are noted under Accessibility awareness? above. |
|
See Accessibility awareness above |
|
Many would judge the Plone interface to be "cool" - it is certainly likely to gain much more mindshare than
the default CMF skin. See Accessibility awareness above. |
|
N/A as this is middleware. As all output is XML then implementers have complete flexibility in terms of
how it is rendered. The demonstrator requires the Adobe SVG plug-in for navigation - this doesn't work
with Mozilla. |
|
|
|
|
The MLE-QLS Broker provides additional security via a read-only connection to the SIS. However, does
this rule out any future option of students maintaining some part of their administrative record (e.g. home
address) themselves? Whilst DMU may not yet be culturally ready to consider the devolution of
maintenance of part of the student record to the students themselves, clearly the notion of "self-service
portals" demands such functionality. If other organisations are to benefit from this approach to
middleware then the software needs to support information push as well as pull. Presumably it is a
question of implementing some insert, delete or update statements (in SQL terms) to add to the wide
variety of examples of select statements?
The most innovative component of the product - the MLE-QLS Broker - is also the most proprietary in
terms of the toolkit (Visual Basic) and the platform (Windows) required. This is not a criticism just a
reservation; this decision to take this route represented a path of least resistance in terms of in-house
expertise and the nature of the back-end SIS. For such middleware to be adopted widely it the approach
needs to be recast in a more open, less platform dependent alternative.
The Broker has been developed to explore use of IMS protocols against a SIS. It would be very instructive
to explore how the same approach fared against VLEs that claimed to support the IMS specification.
A potential bottleneck in the DMU-MLE is the MLE-QLS Broker (see Architecture: scaleable?). This should
be stress tested. |
|
No access to the software was possible; the following comments are necessarily inferences based on
remote use of the demonstrator and the available documentation.
GIMIS provides a wide spectrum of read-only reports against live data. What about the issue of live
update (or, more conservatively, triggering some sort of workflow within which an amended record is
approved (or rejected) before entering the live system)? Whilst Writtle may not yet be culturally ready to
consider the devolution of maintenance of some information to the end-users themselves (e.g. the
student term-time address), clearly the notion of "self-service portals" demands such functionality. If other
organisations are to benefit from the GIMIS framework then the software needs to support information
push as well as pull. Presumably this is a question of implementing some insert, delete or update
statements (in SQL terms) to add to the current examples of select statements.
The project should test whether their product can interwork with other portal frameworks (e.g. uPortal)
and adapt/extend their code to achieve this. Such development and testing might proceed on two levels:
Superficial - "re-skin" the components exposed in the right-hand frame of the existing interface so that
they would render as a channel/portlet in another framework.
Deep - explore the opportunites offered by the ColdFusion MX/JRun platform. Can, for example, GIMIS
and uPortal run side by side on a J2EE application server and integrate advantageously?
The system needs to be secured with SSL.
A potential bottleneck in GIMIS is the ODBC middleware layer (see Architecture: scaleable?). This should
be stress tested. |
|
It is desirable that the present system should be secured using SSL. |
|
The project is switching from a WebObjects to a uPortal framework. The demonstrator is currently
WebObjects-hosted and no access to the software was possible. The following comments are
necessarily inferences based on remote use of the demonstrator and the available documentation.
It is not clear that the IMS - XML translation software is in use within the demonstrator.
It is not yet clear that "deep" integration of systems has been achieved:
Use of the Library Account screen (see screenshots below) suggests that passing of authentication
credentials is occurring, but when you try some of the Aleph links as the top of this screen then you are
prompted to re-authenticate.
Use of the Unit Enrolments leads immediately to a login screen for the "UEA ENROLMENT ENQUIRY
SYSTEM".
The Library Account screen spawns a new browser window. The uPortal framework should allow a richer
range of channel types to be explored so that the Aleph system appears within rather than outside the
portal. The degree of integration of Aleph will in part be limited by the extent to which this system can be
"re-skinned" for use within other portals; ExLibris have indicated in product presentations such flexibility
is on their roadmap.
The other screens (Intercalation, Student Comments, IT Service Data) are either empty or simple links to
other sites (Accommodation)
The Address Details screen provides a read-only view of part of the student record. However, does this
rule out any future option of students maintaining some part of their administrative record (e.g. home
address) themselves? Whilst UEA may not yet be culturally ready to consider the devolution of
maintenance of part of the student record to the students themselves, clearly the notion of "self-service
portals" demands such functionality. If other organisations are to benefit from the IMS - XML middleware
then the software needs to support information push as well as pull. Presumably it is a question of
implementing some insert, delete or update statements (in SQL terms) to add to the examples of select
statements?
The system needs to be secured with SSL.
A potential bottleneck in MARTINI is the XML - IMS conversion program (see Architecture: scaleable?).
This should be stress tested.
The modularity of the most innovative part of the product, the XML - IMS conversion program, should be
tested in the context of the DMU-MLE system (also uPortal-based). |
|
As a proof of concept SMILE has yet to demonstrate significant integration and personalisation.
One vehicle for achieving both might be the eVision-hosted Module catalogue. Currently there is no
passing of authentication credentials (despite the "Logged on" header in the screenshot below) between
Zope and eVision. This may be a significant challenge (irrespective of the second participating system)
and will require approaches such as that employed by Yale's Central Authentication Service
(http://www.yale.edu/tp/cas/) or the
ANGEL User Manager (http://www.angel.ac.uk).
The user can query the Module catalogue - but it does not automatically select the modules on which a
student user is currently enrolled or the students for which a staff user is responsible - and so an
opportunity to provide personalised information is missed. Currently the information is presented in
terms of the eVision skin; can this be transformed so as to be rendered within the Plone skin?
More generically it would be helpful to see some examples of CMFPortlets being used to embed remote
Web services within the SMILE portal (the Resource Discovery Network being an attractive source of RSS
feeds).
The system needs to be secured with SSL. |
|
It would be a virtue if a database schema script for an open source database (e.g. MySQL or Postgres)
could be also provided.
It would be instructive to stress test Diet-TISR, with and without SSL, by way of assessing Resin's load
balancing options (some of which are software-only and would involve no additional hardware purchase).
If a distributable demonstrator could be wrapped up in the context of a uPortal instance then it would
provide an invaluable worked example for sites exploring this and other portal frameworks. |
|
|
|
|
