Coordinating Java Agents for Financial ... - Semantic Scholar

Coordinating Java Agents for Financial Applications on the WWW Paolo Ciancarini1, Andreas Knoche2 , Davide Rossi1, Robert Tolksdorf2, and Fabio Vitali1 1

Dept. of Computer Science, Universit`a of Bologna, Dept. of Computer Science, Mura Anteo Zamboni 7, I-40127 Bologna mailto:[email protected] 2 Technische Universit¨at Berlin, Fachbereich Informatik, FLP/KIT, Sekr. FR 6–10, Franklinstr. 28/29, D-10587 Berlin mailto:[email protected]

Abstract. Innovative interactive applications on the Web require active processing and coordination of services and components, which are currently 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 today’s Webapplications 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. PageSpace is an ideal candidate to solve to a large class of financial information needs.

Keywords: Java, Linda, Coordination, Web Applications, Open Distributed Systems

1 Introduction The extreme success of the World Wide Web in recent years makes Internet the foremost candidate as the networking environment for most, the distributed applications to 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: – a middleware environment at servers by offering coordination facilities amongst distributed agents.

– a middleware environments at clients by offering coordination facilities to applets and plug-ins by means of libraries, allowing programmers to turn them into local agents. – a middleware environments both at the server and at the clients by a seamless integration of both environments. 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 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.

2 WWW Technologies for Financial Services The 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. Although advanced WWW applications already 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. It is personalised for confidentiality and for the 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.

3 Key Technologies for the PageSpace Environment 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 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 provides the conceptual platform for the coordination of activities amongst asynchronously working collaborating agents. In PageSpace we use concepts from coordination languages such as Linda ([5]), Laura ([8]), and Shade ([2]) to provide the basic coordination facilities. – Web-technology provides a wide-spread communication and presentation platform to PageSpace. Browsers allow at least the access to the PageSpace and with HTML a uniform graphical interface for the applications can be defined. – Java-technology provides a uniform processing platform. Java is popularised by its integration into standard Web-browsers and is available on all major hardware platforms. In PageSpace it has been chosen as the programming language for all agents. 3.1 Coordination Technology 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 withdrawal 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: – Uncoupling of agents The basic paradigm of communication is uncoupled in that the sending and receiving agents do not know about each other. This mechanism therefore needs no identificationscheme of agents, and is more abstract than directed communication. – Associative addressing Templates address data are received associatively. They therefore do specify what data is requested in, not what message. – Nondeterminism Associative addressing by templates is non-deterministic, as it does not prescribe the choice of which data to select. The implementation of the selection is left to a mechanism “behind the stages”. – Concurrency Agents being coordinated in a coordinated system implicitly perform their work in a concurrent manner. There are no assumptions about the order of execution or communication. The only requirement is induced by the potential blocking of input operations, since data must be generated by some agent before it can be received. – Separation of concerns Coordination languages focus on coordination solely. They demonstrate that a separation of concerns leads to a solution of a coordination problem that is independent of how computation is performed. The benefits of this separation are concentration on a single problem and abstraction from the solution of other problems such as computation. 3.2 Web and Java Technology 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. 1. Communication between entities is standardised by a set of well-defined protocols (e.g. HTTP, CGI, etc.). HTTP establishes the uniform information transport mechanism based on a fixed set of methods. CGI defines an interface between a Web-Server and a program written in an arbitrary language and executed on the same machine. 2. Resources are referenced by a global naming scheme, the Unified Resource Locator (URL). 3. The logical structure of a text is described using the Hypertext Markup Language (HTML) that offers the possibility to link related documents and to create simple form-based interfaces. 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. With respect of the outlined qualities, Java is the language of choice for the PageSpace: 1. Hardware independence is a basic demand open distributed applications. 2. Embedding applets in documents enhances the user-interface of PageSpace applications. 3. The runtime linking provided by the Java Interpreter will simplify the transport of agents.

4 The PageSpace Architecture 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: – The User Interface agents, by which users connect to the PageSpace. It is located at a browser that connects to the PageSpace. – The Homeagent, which is the representation of the user within the PageSpace. The Homeagent requests services on behalf of the user and is independent of the user interface agent. – The Application agents, which are the inhabitants of the PageSpace that offer and use services to other agents. They are active processes that are distributed somewhere in the PageSpace. – The Coordination environment, which provides the glue that enables all agents to coordinate their work by communication and synchronisation. – The Kernel agents, of which exactly one agent resides on every machine in the PageSpace. They offer services to agents requiring knowledge on location and privileges, like creating new agents. – The Gateway agents, which integrate services provided within other middleware environments, such as CORBA, DCE, or other PageSpaces.

Kernelagent

HTTP

Homeagent out

in

in out

PageSpace

in out

out in Appls erv agent ic

Applagent

e

res

ult

ult

res Eg. CORBA World

Gatewayagent

Applagent

vice

ser

Kernelagent

Fig. 1. The logical structure of a PageSpace application

In a typical application, several application agents autonomously perform a complex distributed computation by coordinating among themselves immersed in the shared space. Human users interact with the

agents that perform the computations through interface agents. These interfaces are not directly connected to the shared space, but connect via HTTP to an associated homeagent. This carries out the necessary interactions with the other agents on behalf of the user. Gateway agents provide gateways to other environments, (in figure 1, the CORBA-world). Kernel agents provide special, usually locationdependent, services to the agents. All agents (with the possible exception of interfaces) are programmed in Java using special PageSpace classes and executed as byte-code by Java virtual machines. As an example, an auction could take place in the PageSpace environment. The auctioneer would put items on sale and wait for bids from the audience. After the allotted time has expired, the person who placed the highest bid gets the item, and the auctioneer proceeds with the next item. In the following subsections, each type of agent is discussed using the auction example. 4.1 The User Interface Agents The interface agent is the way data from application 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 the interface agent depends largely on the capabilities of the machine of the user, from Newton PDAs with a simple HTML 2.0 browser, to sophisticated Java-enabled browsers on a Unix workstation. As an interface agent is only interested in displaying data, all computations are performed by the corresponding application agent within the PageSpace. This is a way to rethink the role of clients and servers, and applying them to the coordination system: the interface agent does the interface, while the application agent does the coordination with other agents. The interface can be divided in three parts: – the Commands, a set of controls that perform general actions on the PageSpace, such as activating or removing agents; – the Message Board, a list of waiting messages from the currently active agents that require attention from the user. Each message is a link activating a different Page; – the Page, the actual interface for the application that holds the attention of the user. 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 shared space, and act accordingly. This allows the user to keep several different pages active and switch from one to the next one without the need to notify the application agents themselves. For instance, figure 2 shows a user interface agent displaying the page of a poker application, while figure 4 shows an interface to the auction application. Switching from one application to the other is simply matter of displaying the appropriate page. 4.2 The Homeagent The homeagent is the module that allows the integration of user-initiated directional connections in the style of HTTP and the peer-to-peer bidirectional communication channels that are characteristics of coordination technologies. The homeagent is an intermediate agent that lies permanently in the PageSpace and receives messages for the other agents from the user through the interface agent. The homeagent 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 the agents currently performing the distributed computations. The homeagent is expected to accommodate the best possible communication channel with the user, and acts on her behalf during her absences. The sophistication of the homeagent is central to the success of the claim we make to be able to exploit HTTP connections for coordinated distributed computations. A single homeagent exists for every user that has active agents on the PageSpace. On the one hand, the homeagent 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.

Fig. 2. A user interface agent for a poker application

For instance, a user could take part to several auctions at the same time, and have other applications active as well. The homeagent will collect the messages from the appropriate agents, and relays them to the user whenever he or she asks for them.

4.3 The Application Agents 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, application agents perform the purpose of the application, autonomously interacting among themselves. Application agents use and provide application specific services from and for other agents. Those agents that require interaction with a human user can do so by delivering to the interface agent, via the homeagent, the Page providing the actual interface. 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. Application agents 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.

4.4 The Kernel Agents and the Coordination Environment Kernel agents are agents that have administrative tasks within the PageSpace. They are able to do privileged things that are prohibited to the other agents. Each machine belonging to the same PageSpace has exactly one kernel agent constantly running. Kernel agents monitor application agents and the platform for faults. Also, they offer a set of common privileged services to other agents. For example, they can provide the functionality necessary to support mobile application agents ([3]), such as starting an agent with some state, stopping an agent by brute force, keeping a list of active agents, storing checkpoints of agent-states, informing agents about their location, moving agents to some other machine. In addition, kernel agents actually implement ”behind the stages” the coordination structure that called the coordination environment. Figure 3 shows the PageSpace implementation with distribution visible.

HTTP

Homeagent

Applagent out

in

out

in

Applagent

Machine C Applagent

in

t

ou

out

in

Kernelagent

Machine A Machine B

Kernelagent out

in

out

in

Applagent

Gatewayagent Fig. 3. The distributed implementation of the PageSpace platform

PageSpace agents 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. 4.5 The Gateway Agents The gateways provide access to external environments (NNTP news, CORBA objects, DBMS applications, etc). Like homeagents, they provide an interface between external entities and the PageSpace.

In some sense, they perform a task similar to homeagents, in that they allow the PageSpace to interact with an external world. Just as homeagents have an HTTP/CGI interface to communicate with the user interface, and a PageSpace interface to access the shared tuple-space, so gateways will need an interface to the external, specific environment and an interface to the PageSpace environment. The auction could be connected to external data bases and engines, providing additional services on the items being sold. Gateway agents will query the external data repositories and place them in the shared space, for the other agents to use.

5 Financial Applications of 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: – Branch support: providing financial services to geographically distributed bank branches without overloading the central mainframe. – Distribution of financial data: making real-time financial information available to the different entities of the bank, irrelevantly of their physical location and reference computer architecture. – Improved use of financial data: providing better integration between the information source and the analysis and management tools. – Home banking: providing banking and financial services to customers at their homes through the Internet at large. 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 of new services for electronic commerce on these updated infrastructures, 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, financial institutions seem to 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. We will examine now the auction example with greater details:

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: Phase 0: The auctioneer provides information about the auction using messages to newsgroups and mailing lists, and providing a WWW site. The auctioneer provides for an information package explaining the modalities for the users interested in the auction. Users can either simply observe the auction, or actively participate to the bidding. In the first case, they will be informed of the bids, but they are not allowed to place a bid and buy an item. In the second case, they could actively participate to the bidding, sending bids for an item. The auctioneer will start an application agent providing the environment for the auction. All participants and observers will activate their own application agents to handle their bids. To do so, they will ask their homeagent (which we assume already active, coordinating other application agents of the user) to start up a new specialized application agent. All communications relevant to the auction will then only happen among these agents. Phase 1: The auctioneer puts an item up for auction by setting a time out for the reception of bids and notifying the connected users of the new item and its base price. As soon as the new item is put on sale, the auction agent will notify all participants and observers the relevant data about the new item. These agents may have some sophisticated bidding policies that do not require a direct user intervention, or may simply pass the data items to their relevant homeagents. Phase 2: As soon as the interface agents contact their respective homeagents, the information about the new auction item is made available to the participants. They can now submit the auctioneer a new bid, or request the system to unsubscribe from the current item, i.e. by stopping to receive updates for the current item and waiting for the next one. Phase 3: The auctioneer accepts any valid bid (i.e. larger than the current bid) from registered participants, and resets the time out value. Every new bid causes a notification of the new value to all participants and observers. Again, the new value is delivered immediately to the application agents, who will use it directly if enough sophistication drives the agent, or pass it to the homeagent to be delivered to the user on the next connection. When no new valid offer is received within the time out period, the auction stops and the item is considered sold. The auctioneer notifies all users that the sale is closed, and starts a new auction for the next item, resetting the list of participants. The interface agent for the auction system is shown in Figure 4. It 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.deutschebank.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.

Fig. 4. The interface agent of the auction system

6 Related Approaches 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]). The approach is two-sided: on 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 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.

7 Conclusions By combining three existing technology – 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.

8 References 1 A. Beitz and others. Integrating WWW and Middleware, Proc. 1st Australian World Wide Web Conference , Norsearch Publishing, 1995. 2 S. Castellani, P. Ciancarini, and D. Rossi. The ShaPE of ShaDE: a coordination system. Technical Report UBLCS 96-5, Dipartimento di Scienze dell’Informazione, Universit`a di Bologna, Italy, 1996, available as ftp://ftp.cs.unibo.it/pub/techreports/96-05.ps.gz. 3 P. Ciancarini, A. Knoche, R. Tolksdorf, F. Vitali. PageSpace : An Architecture to Coordinate Distributed Applications on the Web. In Proc. 5th Int. WWW Conference, Paris, April 1996, Computer Networks and ISDN Systems 28(7-11):941-952, 1996. 4 Y. Gutfreund, J. Nicol, R. Sasnett, and V. Phuah. WWWinda: An Orchestration Service for WWW Browsers and Accessories. In Electronic Proc. of the 2nd Conf. on the WWW: Mosaic and the Web , December 1994, available as http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/Agents.html. 5 David Gelernter and Nicholas Carriero. Linda in Context. Communications of the ACM, 32(4):444458, 1989. 6 O. Rees, N. Edwards, M. Madsen, M. Beasley, A. McClenaghan. A Web of Distributed Objects. In Proc. 4th Int. World Wide Web Conference: The Web revolution, Boston, MA, December 1995, World Wide Web Journal 1(1):75-88, 1995. 7 W. Schoenfeldinger. WWW Meets Linda. In Proc. 4th Int. World Wide Web Conference: The Web revolution, Boston, MA, December 1995, World Wide Web Journal 1(1):259-276, 1995. 8 R. Tolksdorf. Coordinating Services in Open Distributed Systems with Laura. In Proc. of Coordination’96, Cesena, 1996, Lecture Notes in Computer Science 1061:386-402, Springer Verlag, 1996.