The context in which an intelligent tutoring system is to be used will have a bearing on the architecture chosen to deliver the service. While the following considerations for determining an appropriate architecture are listed separately, they will obviously be interrelated. As most ITS are initially research tools, delivery will be strongly influenced by the context and constraints of the experiments for which the tutors are designed. Delivery mechanisms may also vary according to:
• Type of subject matter and software architecture • Type of student
• Type of hardware/network facility • Type of education provider
If a high-speed link with sufficient processing power to meet demand is available (and high demand flows are given priority) the distinction between a stand-alone application and a distributed one becomes transparent. The advantage of running an entire stand-alone application on a local machine disappears.
There are significant advantages to using a distributed architecture from the point of view of the service provider. Centralization of key components allows for the reuse of data, eliminates the requirement of having to update multiple copies when adding modules, and allows for the sharing of computing resources and data.
An interesting factor is that the quality of functioning of a tutor may be improved by collecting a large, varied set of sample cases from multiple sources. If it has a case- based machine learning module included in its operation, an ITS will better refine its capabilities by collecting cases in a central repository.
ASIMIL, a flight simulator collects error cases that have already been processed and reuses them if the same error arises again, saving on processing and latency of reply. (Aka and Frasson 2002).
The distributed models used in Intelligent Tutors build on either traditional Web- Based technology or new technologies that allow applications to interact in a more autonomous manner. Agents can behave independently and collaboratively. They can also be mobile on a network. The agent can be seen as situated in its own context, interacting with other agents as part of a community to solve a given problem. Intelligence is often viewed as “emergent” – the result of problem solving by a community of agents which is greater than the sum of its parts. (Luger and Stubblefield 1997).
Traditional Web-Based, 3-Tier Architecture
The World Wide Web, given its ubiquitous nature, is already involved in the remote distribution of Intelligent Tutoring Systems. It provides a means of teaching that is platform, location and time independent. There is now a vast infrastructure available to educators and students.
The number of students that can be taught at one time is only limited by network capacity and computational power.
The traditional delivery architecture for the World Wide Web has been to run an HTTP server with a database. Upon request, the server runs a script that accesses the database for appropriate data and returns a dynamically generated web page to the client that made the request. The server starts multiple processes (on different ports) to handle concurrent requests. Java applets, Flash files, etc can be embedded in a web page to act as an interface. Applets and JavaScript can be used to run some of the programming needed for the tutor to operate on the client machine. Technologies used for the server-side scripting that makes these ITS adaptive include ASP, PHP, JSP, CGI and Servlets.
Agent distributed
Once the notion of modules and intelligence is blended with the distributed system it is not a great leap to consider ITS components as agents themselves.
Many of the intelligent tutors claim to be using “Agents” when in fact they may be cousins of agents – parts of a concurrent/distributed system. The distinction drawn by Wooldridge is that agents are autonomous and make their decisions at run time whereas the synchronization and co-ordination structures in a regular distributed system are hardwired. Secondly, Agents encounter each other as “self-interested entities” rather than being assumed to have a common interest in making the overall system function correctly. (Wooldridge 2002)
Regardless of their title, some ITSs are built as distributed systems based on either of two styles of technology: tuple-based or RPC–based. Tuple-based systems use a central space, like a database that various agents write and read to. This allows them to exchange parameters according to either a closed set of rules, or via an open “standardized” means of exchange. JavaSpaces is one technology that implements this approach. WCL, KQML and other domain-specific languages are used for communication. (Papadopoulos 2001)
RPC (the original Remote Procedure Call for distributed systems) has been adapted to deal with Object Oriented concepts of message passing to invoke and receive services from a remote server. This model is not all that different from a normal HTTP web server model, with the exception that it uses object and message
exchange protocols rather than a text-based exchange. DCOM, .NET, CORBA and RMI are technologies that can be used as middleware brokers for “agent” exchange. (Oberg 2001). While HTTP can be avoided, these technologies rely on the TCP/UDP transport layer of the IP suite of protocols to shift their datagrams around the
Internet. It is possible to integrate an HTTP-based component to such a system. As mentioned previously, FIPA has provided widely accepted standards for agents and JADE implements these standards in Java using RMI middleware.
Stand-Alone Applications
The main value in using a stand-alone application is when the processing and network services cannot support a distributed system. Any intelligent system
involved in parsing a semantic or hierarchical network of nodes is going to require a deal of processing ability if it is to remain viable when expanded fully. If multimedia and communications play a major role in the learner’s interface, then having a dial- up 56kbps connection will be a likely bottleneck. In these circumstances a stand- alone application may be a better option.
Users of the reading tutor LISTEN spend 20% of their time waiting for the tutor to process the input and respond with the required feedback. (Mostow et al. 2002). A situation like this where auditory data has to be parsed and evaluated over a 56kbps modem would be completely unworkable. (The evaluation of ITS performance below deals with response latency in more detail.)
The major drawback, of course is that a stand-alone application cannot be readily modified. In this situation, Java’s Web Start technology might be useful. If the program is not outrageously large – an uncongested modem connection will
download 12-18Mb in an hour – it is conceivable that the application be downloaded from a central repository. Web Start always updates to the most recent version and no installation procedures are required. (Sun Microsystems 2003). Newmarch has
used Web Start to download working Java programs for students to manipulate locally. The entire environment needed to run the program is established and sandbox security is created on the local machine. The disadvantage of the system is its inability to permit socket creation and thus networking from the downloaded program. (Newmarch 2002).