forthcoming in the Proceedings of the Second International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology (PAAM'97)
Paolo Ciancarini
Dept. of Computer Science;
Università of Bologna; Mura Anteo Zamboni, 7; I-40127 Bologna
- ciancarini@cs.unibo.it
Andreas Knoche
Technische Universität Berlin;
Project KIT-PageSpace; FR 6-10; Franklinstr. 28/29; D-10587 Berlin -
knoche@cs.tu-berlin.de
Davide Rossi
Dept. of Computer Science;
Università of Bologna; Mura Anteo Zamboni, 7; I-40127 Bologna
- rossi@cs.unibo.it
Robert Tolksdorf
Technische Universität Berlin;
Project KIT-PageSpace; FR 6-10; Franklinstr. 28/29; D-10587 Berlin -
tolk@cs.tu-berlin.de
Fabio Vitali
Dept. of Computer Science;
Università of Bologna; Mura Anteo Zamboni, 7; I-40127 Bologna
- fabio@cs.unibo.it
Keywords: Java, Linda, Coordination, Web Applications, Open Distributed Systems
Innovative interactive applications on the Web require active processing and coordination of services and components are limited by the lack of integrated mechanisms for coordination.
The PageSpace is a platform providing a unified approach to coordination of independent modules on the WWW, creating an environment where active components can communicate and act in a really distributed system, overcoming the limitations of traditional approaches. With the PageSpace architecture, distributed applications on top of the Web and the Internet are empowered, as the platform decentralises activity. By combining coordination technology with the Web and Java, the centralised, server-bound structure of todays Web-applications is replaced with a truly open distributed system.
Financial institutions are open to innovative technologies for new information services for their offices and remote branches. The PageSpace is an ideal candidate to provide solutions to a large class of financial information needs.
The extreme success of the World Wide Web in recent years makes Internet the foremost candidate as the networking environment for most, if not all, the distributed applications that will be used in the near future.
Within the Internet, the World Wide Web has become the standard integrative platform to access Internet services, being the best suited architecture to build applications on top of. Most application domains are turning to the World Wide Web as the environment of choice for building innovative and sophisticated applications leveraging on the open standards, the diffusion and the multi-architecture nature of the environment.
However, the Web in its current state does not provide enough support for those applications, like groupware or workflow modelling, that require coordination of the activities of the users as core part of their mechanisms. In facts, the Web provides no integrated support for the coordination of distributed applications. Existing applications are either server-centric (interfacing applications via CGI to a mainframe-like central server machine), client-centric (applets providing application services to users without a real distribution concept), or not integrated at all with the Web (applications with user interface implemented in applets or plug-ins connecting with some proprietary protocol to a proprietary server). All these approaches do not really satisfy the idea of distributed applications on the Web: they are either not really distributed, or not integrated with the Web.
In this paper we present the architecture of the PageSpace, a platform to support distributed applications on the WWW ([3]). The PageSpace architecture is designed to provide a flexible solution to all coordination needs of distributed modules running within Web browsers. The PageSpace, completely implemented in Java, aims at providing a controllable and graceful down- or up-sizing of quality in the communication process of coordinated modules, allowing for bidirectional low-level TCP connections as well as regular or sporadic polling using the HTTP protocol.
PageSpace aims at providing a middleware layer for the communication between remote modules that overcomes both server-centric and client-centric limitations. It has the potential to provide:
An interesting field to test innovative and sophisticated applications on the WWW is the financial domain. Electronic commerce is one of the hottest application fields being foreseen for the WWW. Because of their need to distribute and coordinate information in a timely, secure and reliable manner over an etherogeneous network, financial applications are a critical and important testbed for coordination technologies.
In the section 2, the problems and needs of some financial applications are discussed. In section 3, the technological building blocks of the PageSpace project are introduced. Section 4 contains a description of the architecture of the PageSpace environment. In section 5 we draw a few reflections about the merits of the architecture for the financial domain. Section 6 contains a few conclusive remarks about the project, as well as a brief discussion of related research efforts.
The domain field of financial institutions (e.g. banks, investment and mutual funds) is a lively, fast-growing, and important market for network technologies. Financial institutions must face new relevant factors like market globalization, novel financial instruments, increased demand of value-added services finalised to end-users (home-virtual banking), and effective management of the related information problems.
Technologies currently used for implementing information and operation services in financial institutions are strongly conventional and proprietary. Although they guarantee a high quality for conventional services, new ones that have to be designed, implemented, and integrated are often not satisfactory, insufficient or too expensive to be used. Web technologies could find a fertile ground in financial institutions for several reasons. Their ease of use, their promisingly low costs, and especially their still increasing diffusion among final customers make Web infrastructures interesting for both Internet and intranet applications for financial institutions.
The widespread interest in the World Wide Web by the financial institutions is witnessed by the number of sites supporting financial data or research on financial applications of WWW technology. For instance Bank24 (http://www.bank24.de) offers home banking services over the WWW, in Germany. Analogously, in April 1996, the Cassa di Risparmio di Spoleto (http://www.caribusiness.it/carispo) inaugurated the first Internet home banking service in Italy. At the other end of the spectrum of financial services currently offered over the Internet we will mention the Schwab site (http://www.schwab.com), where customers can freely trade stocks using the Internet for a very competitive fee. More examples of innovative uses of WWW technologies in financial markets can be found in (http://www.wiso.gwdg.de/ifbg/finance.html). However, the level of service currently offered to external customers via the Internet is very low, because for security reasons and lack of adequate interactivity support from the WWW infrastructure customers can usually only review their own accounts.
However, although advanced applications on WWW already now include e-mail systems, audio-video realtime/anytime conferencing, financial data retrieval, etc., the current technology of Web middleware is not really adequate to support the services necessary to develop interactive Internet and intranet multiuser applications. Furthermore, it is important to note that the usual kind of service banks provide is not public. In fact, it is personalised towards confidentiality and towards recognition of the customers personal financial situation and interests. Thus, there is a strong demand on providing secure, personalised, and confidential online services to customers, for example personal account monitoring and portfolio management.
The PageSpace provides a platform on top of the WWW to support applications and to make them available using the standard Web interface. It does so by introducing a notion of active entities - called agents - that are executed somewhere in the net. These agents are able to use and provide services from and to other agents, without requiring centralised coordination from servers.
The PageSpace copes with the requirements of open distributed systems to provide an infrastructure in which agents use and offer services from and to others, providing the communication and synchronisation - in one word the coordination - that allow these agents to work concurrently.
Distributed PageSpace applications involve heterogeneous machine, network and operating-system architectures. Coordinating agents in such an environment requires to make these heterogeneities transparent to the programmer. Transparency of network heterogeneity is achieved by using the Internet underlying the communication platform. Transparency of different hardware architecture and operating systems is obtained through the platform independent byte-code provided by Java language, one of the main building blocks of PageSpace.
An open distributed system exhibits a potentially high dynamics by unrestrictedly joining and leaving agents. An open distributed system has no time of beginning or end and is formed by the agents that currently join it. There should be no restriction for agents on when they join or leave, for example to allow their replacement by new versions.
Coordinating open systems means to avoid restrictions and to provide mechanisms that can deal with these dynamics. In the PageSpace, this is achieved by using coordination technology as the final building block. It allows it to mask the absence of an agent by asynchrony, and to abstract from the presence of a specific agent by associative addressing.
Distributed cooperative applications usually support asynchronous collaboration. This requires that users can leave or shutdown the user interface without affecting their participation in the application. PageSpace therefore clearly distinguish the software agent that performs activity on behalf of the user, from the interface and access mechanism to this agent and its activities. This is manifested by uncoupling the access interface - located in a running Web browser - from some agent process that is active all the time and represents the user on the network. This philosophy very naturally fits with the fact that HTTP connections are directional and initiated by the client.
Open distributed applications work at a very large scale - potentially world-wide. The PageSpace architecture aims at a scalable design by introducing as much distribution and mutual independence of agents as possible.
The PageSpace is built on a set of existing technologies:
Coordination technology has been initiated by the language Linda ([5]) developed at Yale University. Coordination technology is used for parallel and distributed processing by means of a shared data space, called the tuple space. It provides particular operations on the tuple space focused on: (1) the creation of activities, (2) their synchronisation, (3) the communication amongst activities.
The tuple space is a collection of finite ordered sets, called tuples. A tuple may contain values and/or placeholders for value (in which case they are called templates). Tuples are placed, read or withdrawn in the tuple space by agents performing a limited set of operations. Tuples can be read or withdrawn by agents when they matches with the read or withdraw template. If no matching tuple is available, these operations block the execution of the program, until some other agent performs an out with a matching tuple. The blocking of read and withdraw operations, together with the value-binding to templates, provide a powerful combination of synchronisation techniques with communication.
The key-concepts of coordination technologies are at the core of the goals of PageSpace in supporting open distributed applications. The following list identifies characteristic concepts of coordination that we take as key-issues for solutions of the coordination problem in open systems:
We understand the World Wide Web as a distributed system of communicating agents. They form an information system guided by a set of three simple protocols.
The World Wide Web is the platform of choice for PageSpace. Its popularity provides a uniform access to applications, its platform independence allows uniform user-interfaces for PageSpace applications.
The Java programming language was designed to be as simple and small as possible but with the power of a class-based object-oriented language. In 1990, Sun started to define the Java language by taking inspiration from C++, but without its unclean and unsafe features. New principles and structures were inherited from other object-oriented languages such as Eiffel, or SmallTalk. The massive growth of the WWW demanded a portable and distributed programming platform to embed applications in the Web. It turned out that Java, a clean and safe derivation of C++ created by Sun, easily could match these requirements and its release became the major Web-related event in 1995.
The Java compiler translates sources to an intermediate machine-independent and platform-independent byte-code that is interpreted by a Java virtual machine. Because of the architecture-neutral definition of the intermediate code, only the virtual machine has to be adapted to a specific machine and operating system. Further advantages arise from the run-time linking that can retrieve required classes from the net. Furthermore, since loading applets embedded in HTML documents across the network may have important effect on security, several layers of defence are provided to prevent programmers from creating malicious applications capable of harming personal data, privacy or confidentiality.
In respect of the outlined qualities, Java is the language of choice for the PageSpace:
The PageSpace is populated by agents. Some of them are concerned with the application itself, others have more specific tasks. We distinguish the following entities in the PageSpace, each denoted by a different Greek letter:
Figure 1: The logical structure of a PageSpace application
In a typical application, several Delta agents autonomously perform a complex distributed computation by coordinating among themselves immersed in the Gamma tuple-space. Human users interact with the Delta performing the computations through Alpha interfaces. Alpha interfaces are not directly connected to the Gamma space, but connect via HTTP to an associated Beta agent. This carries out the necessary interactions with the other Delta agents on behalf of the user. Zeta agents provide gateways to other environments, (in figure 1, the CORBA-world). Epsilon agents provide special, usually location-dependent, services to the Deltas.
All agents (with the possible exception of Alpha) are programmed in Java using special PageSpace classes and executed as byte-code by Java virtual machines.
The Alpha interface is the way data from agents is displayed to the human user. It can be as simple as a plain HTML document, or as complex as a heavily graphical Java applet. The sophistication of Alpha interface depends largely on the capabilities of the machine of the user, from Newton PDAs with a simple HTML 1.0 browser, to evoluted Java-enabled browsers on a Unix workstation.
Since an Alpha is only interested in displaying data, all computations are performed on the corresponding Delta agent within the PageSpace. This is a way to rethink the role of clients and servers, and applying them to the coordination system as well: the Alpha does the interface, while the Delta does the coordination with other agents.
The alpha interface can be divided in three parts:
Whenever the user selects a message in the Message Board, the appropriate interface is shown in the Page panel, allowing the user to acknowledge new messages from the Gamma space, and act accordingly. Figure 2 shows an Alpha interface displaying the page of a poker playing application.
Figure 2: An Alpha interface for a poker application
The Beta homeagent is the module that allows the integration of user-initiated directional connections in the style of HTTP with the peer-to-peer bidirectional communication channels that are characteristics of coordination technologies.
The Beta agent is an intermediate agent that lies permanently in the PageSpace and receives messages for the Deltas from the user through the Alpha interface. The Beta agent acts as a reliable and persistent collector and relayer of information from and to the user. It constitutes the only connection between the user and her Delta agents actually performing the distributed computations.
The Beta agent is expected to accommodate the best possible communication channel with the user, and acts on her behalf during her absences. The sophistication of the Beta agent is central to the success of the claim we make to be able to exploit HTTP connections for coordinated distributed computations.
A single Beta agent exists for every user that has active agents on the PageSpace. On the one hand, the Beta agent will collect all the messages from a user's agents, and will deliver them as soon as possible to the user. On the other hand, it will receive all the messages that the user addresses to her agents, and will deliver them on the PageSpace.
We are supposing that several independent applications run within the same PageSpace. For instance, some users are keeping attention to a flow of changing data (e.g. stock exchange values), others are taking part to a distributed auction, others are relaxing playing distributed games.
Within the PageSpace, Delta agents perform the purpose of the application, autonomously interacting among themselves. Delta agents use and provide application specific services from and for other Delta agents. Those Delta agents that require interaction with a human user can do so by delivering to the Alpha interface via the Beta homeagent the Page providing the actual interface by which the user can interact. This is an HTML page containing links, forms and/or Java applets. The software agents can be assumed to be reliably accessible by other agents for the whole length of the computation, while the user can come and go at her leisure.
Deltas can exhibit a varying degree of autonomy for responding to other agents requests even in the absence of the human master. The response can range from a simple "My master cannot respond" to a more complex and autonomous behaviour. For instance, a user can instruct her auction agent to wait until the object she is interested in is being offered and then to perform offers of $100 higher than the current level until the maximum price of $5000 is reached, and then leave.
Epsilons are agents that have administrative tasks within the PageSpace. They are able to do privileged things that are prohibited to Delta and Betas. Each machine belonging to the same PageSpace has exactly one Epsilon agent constantly running.
Epsilon agents offer a set of common privileged services to Deltas and Betas, such as:
In addition, Epsilon actually implements "behind the stages" the coordination structure that we call the Gamma environment. Figure 3 shows the implementation of the PageSpace platform where distribution is visible.
Figure 3: The distributed implementation of the PageSpace platform
PageSpace agents (Beta, Deltas, Epsilons and Zetas) communicate indirectly by manipulating the shared information space. They do so using the primitives of the embedded coordination language, i.e. by placing, reading and withdrawing tuples in and from the tuple-space.
The Zeta gateways provide access to other external environment, such as NNTP news, CORBA objects, DBMS applications, etc. Similarly to Betas, they provide an interface between an external entity and the PageSpace.
In some sense, they perform a task similar to Betas, in that they allow the PageSpace to interact with an external world. Just as Betas have an HTTP/CGI interface to communicate with the Alpha interface, and a PageSpace interface to access the shared tuple-space, so Zeta gateways will need an interface to the external, specific environment and an interface to the PageSpace environment.
Many financial institutions are already now strongly interested in building intranet systems and applications for elaborate financial data, which is currently expensive to get and difficult to manage and redistribute, because of the low level of the network technologies that are currently used. Many of these new applications will need the coordination services offered by the PageSpace platform.
The PageSpace technologies can be applied to develop solutions for several needs, including:
An important objective for financial applications on the WWW is to offer to branch offices of banks some of the services available centrally, by reengineering conventional services on less expensive intranets. At first the objective is to provide branches with the information flows coming from providers. This will be followed by the implementation on these updated infrastructures of new services for electronic commerce, typically using advanced and customised Web interfaces.
The real problem in the existing network infrastructures of financial institutions is that the conventional, mainframe-centric organisation of their information systems is not adequate to support the current trend in which branch offices need more and more information to offer value-adding services.
Therefore an important testbed for WWW technologies is supporting those branches of financial institutions that need and rely upon realtime information delivery systems. An important example is the logic distribution of stock exchange data to all the geographically distributed branches of a bank. Another example is the distribution of software updates, that is an expensive operation involving several people and sometimes decreasing the quality of services offered by the branches.
Currently, branch services relying upon data coming from the central branch are typically implemented in a conventional way using a central mainframe host, which usually is already overloaded with other managing tasks on behalf of the central branch. This solution is not elegant, not efficient, and in any case not satisfactory from the point of view of information integration capabilities. Most of the current Web applications also rely on these centralised architectures.
Hence, it seems that financial institutions will be obliged to develop a new generation of distributed multiuser applications to satisfy the above mentioned new demands. We believe that the PageSpace environment may show to be a powerful tool to realise this new generation of networking applications and services.
Another class of interesting applications for the financial market is workflow applications. The auction bidding system realised within the PageSpace project is a running example demonstrating the WWW potential for creating this kind of applications in the field of electronic commerce.
The auction system has three types of users: the Auctioneer, who sells items to the highest offer, the Participants, who buy items by taking part to the auction, and the Observers, passive audience to the auction. The World Wide Web allows the auctioneer and the participants to communicate during the bidding, and the observers to follow the bidding.
Briefly, the activities of the users can be divided in the following phases:
An alpha interface for the auction system is shown in Figure 4.
Figure 4: The alpha interface of the auction system
The interface is divided in three parts. The top left frame displays the item currently offered. The top right frame allows users to place bids, and on the bottom the currently valid bid is displayed. Every time a new valid bid is received by the auctioneer, all bottom frames are updated with the new value. After a time out, an animation of a mallet hitting a surface is displayed to signify a final sale.
The auction system is only a demonstration example of the possibilities of coordination systems, and especially of PageSpace, for the financial environments. Many needs for which the PageSpace platform would be useful abound. For instance, currently the necessity of offering stock exchange services is typically satisfied using specialist information providers that use proprietary networks to carry data from international stock exchanges to banks all over the world. This specialist service, that is typically offered on per-station costs, is currently too expensive to be offered to a high number of customers geographically distributed, for instance through home-banking services. A PageSpace architecture would allow an easy distribution and update of information flows within the existing user applications.
Of course, there are already some information providers offering such services for free, for instance through mirroring teletext pages (see for instance the German stock exchange (http://www.deutsche-bank.de/cgi/stock), or the Italian Stock Exchange (http://www.alpcom.it/borsa/) prices). Clearly, though, financial institutions will not use such cheap, unreliable sources for financial data.
Several research efforts currently involving the Web are concerned with enhancing various functional features. Being based on a client-server software architecture, the WWW subject to be extended in three different parts: either the server, or the client, or the communication protocol, or a combination of them. Here we present a few academic and industrial projects that show examples of these extensions.
The WU Linda Toolkit ([7]) is a simple interface between a WWW browser and an HTTP server based on a Linda tuple space implementation. Access to a shared tuple space is provided, and users can fill in an HTML form with the appropriate Linda command to interact with it. The main application on show is a disc-load viewer that allows a first glance check of current disk usage of the computers of a cluster. Each computer posts tuples describing its current load. These tuples are then collected and shown in a graphical manner by the application. The system is also planned to support a stock exchange simulation and a multiuser game.
The WWWinda ([4]) approach is based on a modular browser. Since the integration between WWW browsers and their helper applications is usually quite rudimentary (it is only possible to activate the external application and to deliver the data to be displayed), the WWWinda research team designed a flexible, modular WWW browser architecture based on the Linda coordination language. Several independent tools, each implementing a different part of the whole WWW browser, are activated according to needs, sharing screen space, HTTP responses, and user interaction. This allows for a highly modular architecture, where new services and tools can be added without modifications to the others. In order to allow collaboration between modules, they are implemented according to the Linda coordination technology: all modules make use of a shared workspace. Tuples allow to extend the simple ``activate with this data'' paradigm of browsers' helper applications to a better signalling protocol. Current examples include a musical orchestration system (called ``distributed karaoke'', in which several independent instruments (possibly even running on different machines) extract from the shared tuple space the tune to be played note by note. No instrument is aware of how many other instruments are present, and new ones can be added on the fly, even in the middle of a note.
Middleware standards such as CORBA and DCE are the results of the effort of industry committees consecrated to making commercial applications interoperate as smoothly and as painlessly as possible for the application designer, the system developers, and for the final users. These platforms provide standard ways to define, locate and request computational services from participating applications, both locally and remotely. Middleware solutions may help the WWW define a standard and unique way to access and execute remote services, letting it potentially become the standard interface to all networked services available now and in the future.
For instance ANSA is pursuing the integration of WWW technologies and CORBA-related standards ([6]). Their approach is two-sided: on the one hand, they are creating a standard set of CGI gateways to allow bidirectional interaction between a CORBA based environment and HTTP tools (CORBA clients accessing to HTTP resources and HTTP software accessing CORBA distributed objects). On the other hand, they are building a set of WWW tools to integrate and replace HTTP: a server that can provide services using both HTTP and IIOP (the Internet Inter-ORB Protocol providing the connection layer to all CORBA 2.0 compliant platforms) and an Arena-based browser using IIOP as its connection mechanism.
On the other hand, Marco is a CGI gateway to OSF's DCE servers ([1]) developed as a demonstration of a proposed general architecture for integrating generic middleware components into the WWW through CGI. Two modules are identified: a ``type manager'', which knows about data contained in the middleware services connected, and a ``trader'', which knows about the details of service instances and interface descriptions of the services connected. A general interaction protocol is defined, allowing clients to identify the service through a two-step request, receive an HTML form document suited to the kind of service requested, and perform the most efficient request.
Finally, Sun is marketing NEO (http://www.sun.com/sunsoft/neo/external/dev-corner/faq/neo-faq.html), a set of administrative and developers' tools to easily create and maintain distributed applications. NEO supports existing standards, and in particular the CORBA brokers and IDLs. One of the developers' tools that are being offered as part of NEO is JOE (http://www.sun.com/sunsoft/neo/external/prod_specs/JOE_Overview.html), a set of Java libraries that allow Web applets to transparently communicate with NEO applications and, by extension, with the CORBA environment. Joe includes an ORB (CORBA's object request brokers) that is automatically downloaded onto Web browsers with the Java applets. Joe also includes an IDL (Interface Definition Language) compiler that automatically generates associated Java classes from interface definitions of NEO objects.
By combining three existing technology - namely WWW, Java, and coordination languages - it is possible to build a flexible platform to support open distributed applications. The necessary mechanisms turn out to be simple and require no extensions to the building blocks used. The protocols needed seem to be simple and scalable. PageSpace adds value to its building blocks by providing a highly abstract coordination mechanism for the development of open distributed applications. In particular, it aims at making use of the client-initiated connections characteristics of the HTTP protocol for all its connection requirements.
We believe that more initiatives will flourish in the next years for providing financial institutions with innovative applications, thereby creating a new important market for Web technology. In order to ensure the infrastructure needed for innovation, financial institutions are going to update their internal information services considering Web and intranet technologies as a pervasive networking and developing environment. Moreover, they will take advantage of the local and global features of WWW, exploiting them in the integration of their information systems to offer both conventional services (e.g. personal account monitoring and management) and innovative, value adding services (e.g. integrated electronic commerce, private and corporate banking) over the Internet. But they will also look for more advance features not usually available with the standard WWW applications. The PageSpace project may provide some useful approaches for enhancing traditional technologies in this regard.
The PageSpace environment has undergone a first development phase creating a generic platform for distributed, coordinated, collaborative applications. In a second phase, starting in 1997, the project will focus on providing support for financial services to remote branches of financial institutions. Further information on the PageSpace project can be found at http://www.cs.tu-berlin.de/~pagespc.
PageSpace is supported by the EU as ESPRIT Open LTR Project #20179. We would like to thank C. del Rosso for his help in drafting this document and his collaboration in the project.