|
Home
>
7. what projects have done
>
7.9 Architecture
|
Previous
Next 
|
|
|
|
|
|
|
|
need to follow up the technical details documents |
|
|
|
|
Please refer to this System Overview |
|
Interactive systems have been written using a variety of environments, including Servlets, JSP, ASP, Perl,
Tcl/Tk, etc.
Modelling has employed XML and UML. |
|
See Project system architecture document at:
Other technical details relating to the choice of JAVA based application server and IMS data "conversion"
can be found at:
|
|
The project has used Zope + CMF + Plone framework and added content but not extended the framework.
Technical details of the product are available on the Zope + CMF + Plone sites. |
|
See complete technical documents at:
|
|
|
|
|
Some very significant (aiming at 20000+ registered users) uPortal sites have been rolled out in the last
year and their experiences are being watch closely by the community. Two approaches are being taken:
Few Big Boxes vs. Many load-balanced Small Boxes. One site (University of British Columbia) started
with the former but is switching to the latter. Links to descriptions of the hardware specifications in use at
a selection of these sites can be found at http://www.bris.ac.uk/is/projects/portal/docs/hardware.
A potential bottleneck in the DMU-MLE is the MLE-QLS Broker - a firewall, SSL, XML and ODBC/ADO may
all act as a brake on performance. Such is the nature of middleware. Experience to date indicates the
performance is entirely adequate but it is not clear what approaches would be taken if performance
degraded in future. |
|
ODBC is potentially a performance bottleneck. Macromedia offers ClusterCATS which allows multiple
JRun servers be set up in a high-availability clustering configuration. |
|
Load-balancing approaches are available should Tomcat start to suffer performance problems. mySQL
has a reputation as a fast database for read-access but lacks the transactional integrity of some
alternative databases which might be desirable for write-access under significant loads. |
|
Some very significant (aiming at 20000+ registered users) uPortal sites have been rolled out in the last
year and their experiences are being watch closely by the community. Two approaches are being taken:
Few Big Boxes vs. Many load-balanced Small Boxes. One site (University of British Columbia) started
with the former but is switching to the latter. Links to descriptions of the hardware specifications in use at
a selection of these sites can be found at http://www.bris.ac.uk/is/projects/portal/docs/hardware.
A potential bottleneck in MARTINI are the XML middleware programs; such is the nature of middleware.
Experience to date indicates the performance is entirely adequate but it is not clear what approaches
would be taken if performance degraded in future. Scaleability tests not conducted as yet but file structure
envisages one XML file encompassing all possible databases, another to list and link all possible
queries of those databases and a third that defines all the queries themselves. |
|
There are potential problems with running Zope on multi-processor Solaris platforms
(http://www.zope.org/Members/glpb/solaris) but various options are available to mitigate these. Zope
Enterprise Objects (ZEO) would allow any future service to grow in an incremental way. |
|
Middleware layers may act as a brake on performance. Experience to date indicates the performance is
entirely adequate. The adoption of Resin as the application server gives options in the future to explore
load-balancing should the need arise(http://www.caucho.com/resin/ref/balance.xtp). |
|
|
|
|
|
|
|
The current prototype is a portal. The authorisation framework delivers a personalised information
environment to both staff and student users. As it stands the present interface could not be plumbed into
a different portal framework as the use of frames would cause problems. However, with little effort it
should be possible to "re-skin" the components exposed in the right-hand frame of the interface so that
they would render well as a channel/portlet in another framework. |
|
INSIDE has constructed a portal delivering personalised information for staff and students. If the
architecture employed has ensured a clean separation of presentation from the underlying logic and
content then the prospects for incorporation in other portal frameworks should be good. |
|
MARTINI is explicitly investigating using "standard" uPortal infrastructure to host the system. All the XML-
IMS translation software can be integrated within uPortal (various channels types in the uPortal
framework are specifically geared to rendering streams of XML from remote sources). A uPortal
Blackboard Access Channel has been developed by California Polytechnic that would fit nicely within the
UEA context (note, however, that use of this channel requires the availability of Blackboard Learning
System Enterprise). |
|
SMILE is a portal; however, currently it lacks any true personalisation (i.e. linked to the individual user).
SMILE offers the default CMF + Plone roles-based views (anonymous, authenticated, manager, member,
reviewer - staff and student have been configured but not yet implemented). SMILE has not yet achieved
deep integration of its SIS and VLE systems. It has achieved a degree of being joined-up by providing a
"one stop shop" at which users can find collected in one place the links they need to other campus
systems (see the "Quick Links" panel in the screenshots below). But there is no passing of
authentication credentials; a separate login is required at the systems (e.g. E-mail, VLE) to which you are
taken. |
|
Diet-TISR is not part of the presentation layer. |
|
|
|
|
