Project White: Architecture Overview Document ============================================= John Quigley Version 00.01, {localdate} {localtime} Project White is an undertaking to achieve the design and development of a cutting-edge commercial programming language for distributed and decentralized mobile networks. Introduction ------------ The White Programming Language will closely adhere to the vision of Ambient Intelligence and the Ambient-oriented paradigm as set forth by the European Commision's _Information Society Technologies Advisory Group_ and the Department of Computer Science at Vrije University in Brussels, Belgium. The language will build upon these fundamental concepts, integrating ideas synthesized by ourselves, as well as those at the vanguard of today's language reasearch. The language will provide a robust and powerful system for implementing massively distributed entities. [NOTE] The project's guiding principles shall be *simplicity* and *openness* of design, and *commercial* viability. Ambient Intelligence -------------------- The concept of ambient intelligence, or _AmI_, is a vision where humans are surrounded by computing and networking technology unobtrusively embedded in their surroundings. The concept of ambient intelligence was developed by the ISTAG advisory group to the European Commissions DG Information Society and the Media. AmI puts the emphasis on user-friendliness, efficient and distributed services support, user empowerment, and support for human interactions. This vision assumes a shift away from PCs to a variety of devices which are unobtrusively embedded in our environment and which are accessed via intelligent interfaces. In order for AmI to become a reality a number of key technologies are required: - Unobtrusive hardware - Dependability and security - Natural feeling human interfaces - Dynamic and massively distributed device networks - Seamless mobile/fixed web-based communication infrastructure Briefly, systems and technologies need to be sensitive, responsive, interconnected, contextualised, transparent and intelligent. Ambient-Oriented Programming ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ambient-Oriented programming is a programming paradigm whose properties are derived from the characteristics of hardware platforms for mobile computing. Mobile hardware devices are often provided with wireless networks facilities, allowing them to engage in collaboration with their environment. However, the autonomous nature of these devices as well as the volatile connections over their wireless infrastructure has its repercussions on the software that employs them. The basic assumption of the Ambient-Oriented Programming paradigm is that languages should incorporate possible network failures at the heart of their programming model. Motivation ~~~~~~~~~~ Software concurrency, even in the context of a local system, is a very challenging concept to both grasp and properly implement. With the proliferation of mobile and embedded devices in today's world, it is believed that the demand for, and complexity of, concurrent systems will rise exponentially. To readily suppress complexity, today's programmer needs a set of tools at her disposal that provide primitives for dealing with the network and concurrent computations. This robust set of primitive functionality should abstract away the complexity inherent in the core machinations of concurrent software, allowing the programmer to think about the more high-level and immediate concerns of how to break their problem up into discrete components, capable of asynchronous execution. The research into distributed programming languages fits into the larger picture of desiging the programming language of tomorrow. Such languages will be used to construct programs that will be deployed into far more complex environments than contemporary computer networks. Next-generation programs will have to be always-on, dynamically updatable, in constant interaction with numerous other programs residing on different virtual and physical entities. These entities may include cellular phones, PDAs, notebooks, servers, people's clothes, kitchen appliances, cars. Large-scale sensor networks composed of RFID tags will form giant processor clouds. All of these require a totally new paradigm of distributed computing. This vision on programs, programming languages and computing is reflected in the broader context of Ambient Intelligence (AmI), a fairly recent research orientation and deemed very important by the European Union's IST Advisory Group. ISTAG has put forth AmI as one of the research areas in which Europe should invest over the coming years. Challenges ~~~~~~~~~~ There are a number of areas in which some major research breakthroughs are necessary in order to achieve the goals of Ambient Intelligence and Pervasive Computing. Certainly, new programming languages should be developed in order to ease the writing of AmI programs. The language, and by extension the programming environment, should relieve the programmer of the huge burden in writing concurrent, distributed, pervasive programs. There are a number of issues to solve for the language designers, however. Communication ^^^^^^^^^^^^^ Communication between distributed objects is key. A language has to provide means to cope with wireless devices moving out of one another's communication range. One cannot expect the programmer to sprinkle his code with if-statements to ensure communication between programs can be established. The Ambient-Oriented programming paradigm tries to tackle these issues by strictly adhering to non-blocking communication primitives, i.e. asynchronous message send and message receipt. This fosters a more event-driven programming style, which we feel is more appropriate for modelling distributed systems which interact so closely with the (inherently event-driven) real world. Before two programs are able to communicate, both services must first discover one another. Hence, programming languages designed for pervasive computing strongly benefit from a built-in service discovery mechanism. Such a mechanism allows a program to discover services based on abstract service descriptions at runtime in the nearby environment. Real-time Constraints ^^^^^^^^^^^^^^^^^^^^^ Real-time messaging facilities are an important aspect missing from today's experimental distributed programming languages. [IMPORTANT] In distributed systems, the time needed to complete a communication must be bound. As objects in the White system share no state directly, inter-object messaging is chosen mechanism for data sharing. It is believed that no distributed language will be adopted in the commercial space without the ability to impose strict timing constraints on any and all communication between objects. Without such constraints, there can be no guarantees made that a computation will ever complete. While some guarantees will be possible with the use of non-blocking futures, this is not enough for mission critical applications. White's futures will provide non-blocking functionality as a default behavior, but will also maintain an internal timer that will raise an exception if a future is accessed that hasn't received a response in some pre-determined window of time. Fault Tolerance ^^^^^^^^^^^^^^^ Another very difficult issue are partial failures in distributed systems. Devices may crash or run out of battery power, and communication links may fail at any point in time. Such partial failures have to be dealt with and require far more advanced programming structures than contemporary try-catch mechanisms. One interesting research track which my colleagues and I are currently exploring is the notion of time as a first-class citizen of the language. In other words, by reifying time, we hope to be able to influence the past and future of a computation. This is similar to what systems like Croquet and Virtual Time/Timewarp try to do. Related to the issue of failure is the issue of persistent data and transactional semantics which guarantee atomic execution of a piece of code. Security ^^^^^^^^ Security is also an extremely important issue in a world of wireless programs continually moving about, sharing and transmitting data. Again, it is our vision that the programming language should be designed as a secure language from the ground up. The capability-based object model of the distributed programming language E is one example of such a securely designed programming language. Such a capability-based model matches well with proper object-oriented programming rules (encapsulation + message passing) and proves that security can be achieved in more dynamic ways, as opposed to the often static security policies as exemplified by Java's sandbox security model. System Runtime ^^^^^^^^^^^^^^ Finally, one should not forget that programs for the 21st century will not fit the static edit-compile-link-run-debug cycle so typical for mainstream languages like Java or C++. We need to move away from such rigid source-code-in-files development. We need something much more dynamic, much more long-lasting and much easier to update. An image-based approach as taken by Self or Smalltalk fosters more dynamic updates to running programs and even to the system itself. A solid meta-level architecture (e.g. in the form of a metaobject protocol, as in CLOS) can aid the programmer in writing more malleable, more extensible, more updatable software. One major issue which the image-based approaches have yet to solve is to be able to control the scope of changes in the system more adequately, such that images run less risk of becoming corrupted. Researchers in Bern have proposed novel language features such as Changeboxes and Classboxes to cope with these issues. Simplicity ^^^^^^^^^^ Having said all this, we also want the language to be small, beautiful and minimal. This striving towards minimality follows from our firm belief that small and minimal languages are easier to understand, have cleaner semantics (and are hence less prone to hard-to-find bugs and more easily verifiable), easier to learn and implement. The languages Self and Smalltalk serve as our principal examples in this matter. From a technical point of view, one has to deal with the large heterogeneity of all these different devices, regarding processing power, battery lifetime, UI capabilities, OSses, languages, etc. Portability is a key element here. On the one hand, the Java Virtual Machine has given developers an extremely valuable cross-platform target. Recent developments such as the Squawk JVM even allow Java to run on the bare metal, in embedded devices. On the other hand, the JVM has many limitations regarding its support for always-on, dynamically updatable software. Moreover, we need an efficient and portable communication protocol for distributed communication. Mobile Networks ~~~~~~~~~~~~~~~ The White language will facilitate programming for pervasive, wireless networks. These distributed systems differ from traditional distributed systems in the following ways. Whereas traditional distributed systems are often composed of heavyweight, computationally intensive nodes, pervasive systems can be better thought of as consisting of small, computationally scarce and even embedded devices. Most importantly, many of these devices are mobile, such as cell phones, or embedded in mobile devices such as a car. In traditional distributed systems, components are interconnected via fast, wired, reliable communication links. In a pervasive computing setting, connections are usually wireless, slower and less reliable. Because the nodes in a pervasive computing network may be mobile, the mobility of the device may directly influence its network connection with other devices. It is also easy to imagine that the mobile network may be considered overtly hostile or lossy. In traditional distributed systems, one usually knows beforehand which node hosts which kind of 'service'. Hence, addressing techniques based on URLs or IP addresses are widespread. Moreover, the client-server paradigm is widespread. In pervasive computing systems, devices may federate in a spontaneous fashion in an ad hoc network. Hence, devices have to advertise and discover the services they provide or require at runtime. Moreover, a peer-to-peer oriented network model is better suited for ad hoc wireless networks, since reliance on a server should be minimised.