CHAPTER 26 MIDDLEWARE: CORBA and JAVA 26.1 Introduction 26.2 OMG and OMA 26.3 The OMG Object Model 26.4 CORBA 26.5 OMG developments 26.6 ODMG (Object Database Management Group) 26.7 Java - Introduction 26.8 The Java programming language and environment 26.9 The Java platform and components (JavaBeans) 26.10 Java developments 26.11 Ubiquitous computing 26.12 General mobile applications 26.13 Scripting languages 26.14 Summary 26.1 Introduction As high bandwidth Local Area Networks came into widespread use in the workplace during the 1980s the need to support the development of distributed software was recognised. Early work on remote procedure call, see Chapter 15, with associated services for naming and location, led to standard platforms such as ISOs ODP and OSFs DCE. These early platforms were based on the client-server model but over the years a higher level object model was seen to be desirable. Figure 26.1 illustrates the two approaches.
Client-server and object based platforms. Both use object concepts. In the client server approach objects are managed by servers, remain in the address space of their servers, and are invoked by RPC. The service provides a common interface to the objects it names and manages. In the more general object-based approach, objects are self standing and are named globally, conceptually independently of services. An invoked object might migrate to the address space of the invoker or might be invoked remotely. We are working at a higher level of abstraction; the implementation is not constrained. The Object Management Group (OMG) was formed to promote an object oriented approach to software design. In 1989 OMG issued a call for proposals for a new architecture OMA (Object Management Architecture) based on object invocation instead of client-server interaction: OMG CORBA (Common Object Request Broker Architecture) was defined. Since then the CORBA approach xhas gained wide industrial and commercial acceptance; the architecture has been refined and various implementations are available. We examine CORBA in some detail below. The client - server and object platforms are in practice substantial and, so far, have not made the development of distributed software easy. Since the advent of the World Wide Web (henceforth `the web') and web browsers in 1993 the browser interface has been the focus for supporting convenient distributed software development. Rather than heavyweight industrial or commercial applications this approach first gained popularity for adding animations to web pages. Sun Microsystems' Java programming language is widely used for this purpose.
The Java applet approach Figure 26.2 illustrates the Java applet approach. The web browser is Java-enabled; that is, it contains software for receiving and interpreting Java applications. An application's code and data is downloaded from a server to a client in intermediate code (bytecode) format. It is interpreted and runs at the client. Notice that we mask heterogeneity through interpretation - the interpreter produces object code that works with the local operating system and hardware as well as its immediate web browser environment. At this stage in the chapter we can begin to compare the two approaches to distributed computing, distributed objects and mobile programs: * The distributed object model assumes that an application comprises distributed objects that need to interwork. The platform is concerned with object naming, location and invocation. * The mobile program model assumes that applications are held centrally, are migrated once to the client and run there. * Both aim to work above heterogeneous software (operating systems) and hardware. The distributed object model typically uses an implementation where an object stays in place and is invoked by a, possibly remote, client. There are optimisations for homogeneous systems which may migrate objects. In general, only the invocation's arguments are transported and the platform has to ensure that they are understandable by the object and, as we saw for RPC systems in Chapter 15, a standard external data representation is used. The mobile (intermediate) code model downloads the whole application - code and data and interpretion at the client is used to achieve heterogeneity. Once the program is started it does not migrate again and communicates only with its parent server or locally. At present we do not have a general distributed computing model. Many research systems are investigating a more general approach to mobility and migration. At the time of writing we are seeing the emergence of support for developing more substantial, self-standing applications in Java and a convergence of web and distributed object technology. In this chapter the Java programming language is placed in the systems context of supporting applets (Java applications which depend on Java compliant web browsers). We then look at the state of the art in building applications from components and look forward to general interworking between heterogeneous platforms. Finally we broaden the context by looking briefly at ubiquitous computing and general mobility in applications. 26.2 OMG and OMA In 1989 the Object Management Group (OMG) was formed to develop, adopt and promote standards for the development and deployment of applications in distributed heterogeneous environments. Since then it has grown to some 700 members who contribute technology and ideas in response to RFPs (requests for proposals) issued by the OMG. Based on these responses the OMG adopts and issues specifications after some iterations via RFCs (request for comment). Its members include those who make products which implement the standards and those who build software which uses the standards. The vision is stated: `The members of OMG have a shared goal of developing and using integrated software systems. These systems should be built using a methodology that supports modular production of software; encourages reuse of code; allows for useful integration along lines of developers, operating systems, and hardware; and enhances long-range maintenance of that code. Members of OMG believe that the object-oriented approach to software construction best supports their goals. The OMG staff exists to support the vision of its membership and to promote object technology and its benefits.' The OMG home web page is at http://www.omg.org/ and a good source of information is ``CORBA and OMG Information Resources'' at http://www.acl.lanl.gov/CORBA/. The latter includes the OMG specifications and lists many books, papers and tutorials. The specificatiopns may also be obtained from OMG, for example (OMG, 95a,b; 96). An overview is given in (Vinoski 97) and further detail may be found in (Pope, 97). OMA Reference Model Component Definitions CORBA Architecture CORBA 1.1 was introduced in 1991 and defined the Interface Definition Language (IDL) and the Application Programming Interfaces (API) that enable client/server object interaction within a specific implementation of an Object Request Broker (ORB), see Figure 26.4. CORBA 2.0, adopted in December 1994, tackles interoperability by specifying how ORBs from different vendors can interoperate. An ORB is the middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. In so doing, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments. The main features of CORBA 2.0 are: * ORB core * OMG Interface Definition Language (IDL) * Interface Repository * Language Mappings * Stubs and Skeletons * Dynamic Invocation and Dispatch * Object Adapters * Inter-ORB protocols The function of each is outlined below; further information may be obtained from the references. Some of the concepts were introduced in Chapter 15 in the context of RPC systems; other issues are language-level concerns. 26.4.1 The ORB core The function of the ORB core is to support object invocation by clients on target objects. We therefore need a naming scheme for CORBA objects (see Section 5.7). When a CORBA object is created it is given an object reference, a unique identifier which is never reused. Object references can have standardized formats or proprietary formats. Objects are created by invoking a create operation on the appropriate factory object; an object reference is returned to the creator. An object reference may also be acquired through a directory lookup. For example, the CORBA Naming Service will supply the object reference for a named object; the Trading Service will supply the object reference for an object with specified properties. Object references may be stored persistently in files or databases for subsequent retrieval and use. A client with an object reference may invoke any interface operation (service) supported by that object. The ORB is responsible for making this happen and achieves the following transparencies: * location transparency The ORB must be able to locate the object from its reference. * implementation transparency The client need not know how the target object is implemented; in what programming language it was written nor the operating system or hardware on which it is running. * object execution state The ORB activates the object if necessary before delivering the request to it. * communications mechanism The underlying protocol used by the ORB is transparent to the client. 26.4.2 OMGs Interface Definition Language (IDL) As in all other object models we have seen, an object's interface is a specification of the operations and types that the object supports. Interfaces are defined in the OMG Interface Definition Language (OMG IDL). As for other platforms, the idea is that an IDL is programming language independent; interfaces are defined separately from object implementations. Objects may be written in different programming languages and still be able to communicate. The OMG IDL built-in types are: * long (signed and unsigned): 32-bit arithmetic types. * long long (signed and unsigned): 64-bit arithmetic types. * short (signed and unsigned): 16-bit arithmetic types. * float, double and long double: IEEE 754-1985 floating point types. * char and wchar: character and wide character types * boolean: boolean type * octet: 8-bit value * enum: enumerated type * any: a tagged type that can hold a value of any OMG IDL type, both * built-in and user-defined. The sizes of all types are specified in the standard to ensure interoperability across heterogeneous hardware implementations of CORBA. The constructed types are: * struct: a data aggregation construct, similar to C/C++ * discriminated union: a type composed of a type discriminator and a value * of one of several possible OMG IDL types that are specified in the union definition. OMG IDL also supports object reference types and template types whose exact characteristics are defined at declaration time (for example, strings and sequences). Interfaces can inherit from one or more other interfaces; technically this is restricted multiple inheritance without overloading of operation names. The importance of inheritance is that an interface is open for extension but closed against modification (Meyer, 89). 26.4.3 Other CORBA features The other features will be outlined. Some of the concepts were introduced in Chapter 15 in the context of RPC systems; others are language-level issues. Details are in the references. Interface repository When a program containing a CORBA object invocation is type-checked at compile time, the interface specification of the object is needed. This may be a remote object written in another programming language but in all cases it must be specified in IDL. An interface repository holds these specifications. An alternative method of obtaining an interface specification is by invoking the get-interface operation which every object inherits. An IR may be interrogated dynamically at run time as well as statically at compile time, see below. Language Mappings OMG has standardized language mappings for C, C++, Smalltalk and Ada95. The UNIX Bourne shell and COBOL are underway and Java has just started but has high priority. Mappings for Perl, Eiffel and Modula3 exist but have not been submitted to OMG for acceptance as standards. For each language it is necessary to be able to: * invoke CORBA objects from a program written in the language * create an IDL interface specification for objects implemented in the language For each language a mapping of the language types to OMG IDL types is needed. In addition to the built-in types and constructors types that are specific to IDLs must be mapped into the languages. An IDL interface is typically mapped to a class, as for C++, or an abstract data type, for C; an object reference may map to a pointer or an object instance. A CORBA object invocation is usually implemented as a function call in the language. Stubs and Skeletons OMG IDL compilers generate client-side stubs and server (target) - side skeletons. This automatic code generation from the IDL specification is an important component of IDL technology. The client side stub creates and issues the request on behalf of the client; the skeleton delivers the request to the CORBA object implementation. The programming languages that have mappings for CORBA usually implement a CORBA object-operation invocation as a function call in the language. In fact the function call invokes the stub which functions as a proxy for the possibly remote target object. The stub, with the assistance of the ORB, marshalls the arguments that are to be transmitted. The stub and skeleton functions are essentially those we studied in detail for RPC systems in Chapter 15. Dynamic Invocation and Dispatch CORBA supports two interfaces for dynamic invocation, roughly equivalent to the stub and the skeleton. These are the Dynamic Invocation Interface (DII) and the Dynamic Skeleton Interface (DSI). They can be seen as generic stub and skeletons which are provided directly by the ORB and are independent of the IDL interfaces of the objects being invoked. By this means it is possible for an object to be invoked without compile-time knowledge of its interface. This is useful for external objects such as gateways and browsers which may evolve independently of the CORBA platform and for which interface information may be obtained by Interface Repository lookup or by interaction with a human user. Object Adapters An object adapter is an object that adapts the interface of some object to that expected by its caller; it functions as a wrapper for external or legacy objects. There are language level semantic issues in this area - the problem cannot be assumed to be solvable in general. Inter-ORB protocols A given platform abstracts above heterogeneous hardware and software. Alas, several platforms have been developed and standardized and so the interworking of platforms has to be considered. CORBA 2.0 began to address interoperability. The ORB interoperability architecture is based on the General Inter-ORB Protocol (GIOP) which specifies transfer syntax and a standard set of message formats for ORB interoperation over any connection - oriented transport. The Internet Inter-ORB Protocol (IIOP) specifies how GIOP is built over TCP/IP. The architecture also provides for other environment specific inter-ORB protocols (ESIOPs). The first of these was for OSFs Distributed Computing Environment, the DCE Common Inter-ORB Protocol (DCE-CIOP). It can be used in environments where DCE is already installed and allows for integration of CORBA and DCE applications. Object references must be understandable across interoperating platforms. CORBA specifies a standard object reference format - the Interoperable Object Reference (IOR). An IOR contains information needed to locate and communicate with an object over one or more protocols. 26.5 OMG developments After CORBA became established the OMG reorganized itself in 1996, splitting the Technical Committee (TC) into two parts: the Domain TC and the Platform TC. The former includes task forces in the areas of medicine (master-patient indexing), telecommunications (management of quality of service for audio and video data) and business (a framework to support common business processes). The latter includes task forces in the areas od ORB object services (ORBOS - passing objects by value between applications) and common facilities such as systems management. OTS (Object Transaction Service) is an architecture relating various services, such as the Concurrency Control Service, and a protocol for implementing transactions using these services. The semantics are based on reading and writing objects rather than the higher level object operation semantics we have used throughout Part III. An important area is to support interworking of CORBA applicatiopns with the products of manufacturers such as Microsoft COM and Distributed COM (DCOM) applications. Perhaps most important is to unify web technology with CORBA. The Netscape Corporation have stated that they will allow remote CORBA objects and services to appear as browser plug-ins, using IIOP to forward to them. This would unify web technology and distributed object technology, allowing a software component marketplace to be built above a common infrastructure. 26.6 ODMG (Object Database Management Group) The ODMG is a consortium of object-oriented database management system (ODBMS) vendors and interested parties working on standards to allow portability of customer software across ODBMS products. By supporting the same interface, members expect to significantly accelerate progress towards effective adoption of the standard. The objectives of the ODMG are: * To develop a standard set of specifications that may be freely incorporated in database and applications programs in order to permit applications to access information stored in object database management systems (ODBMSs) in a uniform manner. * To make the definitions developed available to others for general industry use, and to submit them through appropriate channels for consideration by other standards-setting organizations, such as the International Standards Organization ("ISO"), the American National Standards Institute ("ANSI"), and the Object Management Group (OMG). Although not part of OMG, the consortium's work is therefore closely related to that of OMG. The first standard to be published was ODMG-93 but the second edition is now available (Cattell 1996) and should be consulted in preference; the first edition was quite heavily criticised and the problems are addressed in the second edition. A third edition is due later in 1997. For further information, see: http://www.odmg.org/ Details can be found there on the ODMG object model, object definition language (ODL), object query language (OQL) and Java language binding for the second edition. 26.7 Java Introduction In 1990 Sun Microsystems set up a team of six, led by Patrick Naughton, to think afresh about support for distributed software development over heterogeneous systems. They recognised the importance of a 'fun', easy to use interface and a language that allowed new media and devices to be programmed, and defined a minimal object oriented language called Oak. Sun turned the team into a company called First Person which was in place, in 1993, ready to work with the world-wide web and its browsers. Early in 1994 First Person decided to focus on a software system for online media with Oak as a `language-based operating system'. A browser was built and the first applet, the Duke icon waving over the Internet, was run. Oak was renamed Java by Sun and made available free on the Internet. The browser was named HotJava. The company JavaSoft became responsible for all Java and Internet development. Java is a language but its surrounding support system is evolving into a computing platform - a base on which software developers can build applications. Novel aspects compared with traditional platforms are as follows: * Java programs are mobile, that is, they can be migrated across a network. Data and the code to process it are transmitted together. A typical scenario is that Java programs (applets) are held on centralized servers and are downloaded on request. Note however that Java applications are mobile only once: their compiled images are loaded into Java interpreters and cannot move after they start executing. This is in contrast with some mobile programming languages, for example Scheme with state-saving continuations, where a program can be halted at any point and migrated to another node. * Heterogeneity is masked through interpretation. Programs are transferred as intermediate code (bytecode). Object code can be produced on-the-fly for heterogeneous systems provided thay have a Java interpreter. It is therefore unnecessary for an application to be ported to many different architectures. Java compilers also exist of course; just-in-time compilers such as Kaffe (Wilkinson, 97) translate a program's bytecode into native code after validating it. This allows long running Java programs to be executed faster than under an interpreter, whilst at the same time ensuring that they do not access unauthorized areas of memory. * A browser interface is often used; for example, the Netscape browser contains an embedded Java platform (is Java-compatible). The term applet was coined for a mini application that runs inside a web browser. A Java application is self-standing whereas an applet is not. * Security. Although importing code into a system appears dangerous (we fear mobile viruses) the fact that it is interpreted by the client's interpreter and runs on a well defined platform can be used to define its scope and confine its access. For example, an applet that is loaded over the network can't normally read or write files in the context of its executor; it can't make network connections except to the host that it came from. It can, however, invoke the public methods of other applets on the same page. Although Java interpreters attempt to execute their programs in this secure environment, some security breaches have been found (McGraw and Felton, 96; Felten, 97). A source of problems is that some programs which are rejected by a Java compiler may be accepted by a Java interpreter. The current popular use of Java is to develop applets for web pages. A Java applet is transferred, runs at the client site and may communicate externally only with its server. There is therefore support for mobile code but not yet for fully general distributed applications. For a distributed application we need components to be loaded at several locations and then to interwork. When this is supported, serious, large-scale applications can be written in Java. At the time of writing JavaBeans has been announced with this style of application development in mind, see below. 26.8 The Java programming language and environment Java is an object oriented language with syntax like C or C++ where it has elements in common with these languages. Object features include object types and classes, methods and (single) inheritance. For example, applets inherit the drawing and event handling methods of the Abstract Windowing Toolkit (AWT) Component class. Applets and applications use AWT classes to produce user interfaces. Drawing refers to anything related to representing an applet on-screen - drawing images, presenting user interface components such as buttons, or using graphics primitives. Event handling refers to detecting and processing user input such as mouse clicks and key presses, as well as more abstract events such as saving files and iconifying windows. Applets also inherit from the AWT Container class. This means that they are designed to hold Components - user interface objects such as buttons, labels, pop-up lists, and scrollbars. Another example is that each applet viewer has a SecurityManager object that checks for applet security violations. Other features of Java include user-defined exceptions and garbage collection. It is noteworthy that there are no pointers in Java; the aim is to support the programming of components that can be migrated without worrying about whether the component is self-contained There are many books available on all aspects of Java, for example (Arnold and Gosling, 96), (Campione and Walrath, 96). There is also a good deal of information available on web pages. A good starting point is the JavaSoft home page http://java.sun.com/ 26.8.1 Concurrent programming in Java Java is a concurrent programming language. Threads are defined as part of the language (the alternative is to use a threads package such as pthreads which is the approach taken for C and C++, see Section 10.8). Even the simplest applets run as multiple threads and applets typically create and use threads to synchronise with input, to perform output and in order to perform well without affecting the performance of the application they run in or of other applets. An applet can communicate with other programs as follows: * By invoking public methods of other applets on the same page, subject to security restrictions. Since applets are active (have internally bound threads) this is equivalent to sending a message to another applet. * By using the API defined in the java.applet package, which supports limited communication with the browser or applet viewer that contains it. For example, the applet may tell its browser which URL to display. * By using the API defined in the java.net package to communicate over the network with other programs. The other programs must be running on the host which delivered the applet to its current host. Putting together object orientation and concurrency, we have a world of mobile, active objects. A thread is created when a runnable object is started. For example, an object class Bart may be specified as inheriting from the class Runnable; Bart thus inherits a start operation. A new instance of the class may be created and caused to start running with a thread of execution by: new Bart().start(); Any number of threads may be created by this means as the program runs. A thread is created as part of a thread group; a thread belongs to the same group as its creator. The purpose of groups is to enforce security controls; for example, a thread may only be stopped by a thread in the same group. Certain operations such as stop, suspend and resume may be invoked on all the members of a group as well as on individual members. Thread control methods We have seen how a thread is started. The isAlive method returns true if a thread has been started and has not terminated. stop terminates a thread (it may not be restarted) but does not kill the thread object. When terminated and no longer referenced, thread objects may be garbage collected. suspend halts a thread until some other thread calls resume on it. sleep causes a thread to suspend for a specified time and then resume. join suspends the caller until the called, target thread completes (that is, it returns isAlive is false). A version of join allows the caller to specify a maximum time it is prepared to wait. interrupt causes sleep, wait or join to abort with an InterruptedException, which can be caught and dealt with in an application-specific way. Thread priorities and scheduling By default, each new thread has the same priority as the thread that created it. A change of thread priority can be achieved by calling Thread.setPriority with a priority argument between Thread.MIN_PRIORITY and Thread.MAX_PRIORITY. The Thread.yield method relinquishes control. Synchronised access to an object Class level static methods and blocks within static methods may be declared as synchronised. Such code executes atomically with respect to any other code specified as synchronised. We can envisage a lock for each object to implement this synchronisation. Note that it does not guarantee exclusive access to the object's data since a method which is not declared as synchronised may execute immediately. We saw this idea in Chapter 11 and noted that it was used in the Mesa language to alleviate the strict enforcement of exclusion in monitors; a method that reads an object's attribute that is unlikely to change should not have to wait for the monitor lock. In the terminology of part III, Java programmers need only synchronise potentially conflicting methods. Code in a synchronized method may make a call to another method in the same object without blocking; similarly within other objects for which the thread holds the locks. Only calls arising from other threads will be blocked. A thread which calls an unsynchronized method from a synchronized one continues to hold the object's lock. Condition synchronisation The methods wait, notify and notifyAll may be invoked only when the invoker holds the target object's lock; wait and notify should be used within synchronized code (as for wait and signal on a monitor's condition variables, see Chapter 11). On wait, the current thread is suspended and placed on an internal queue associated with the object. The object's lock is released but all other locks held by the thread are retained. On notify, if the object's internal wait queue is not empty, an arbitrarily chosen thread is removed from it. That thread must obtain the synchronisation lock which means that it will block at least until the thread calling notify releases the lock. It will continue to block if some other thread obtains the lock first. Finally, the thread resumes at the point of its wait. A notifyAll causes all the waiting threads to be freed from the object's internal wait queue. A version of wait allows a maximum wait time to be specified. If an interrupt occurs during wait the same notify mechanisms are carried out but control returns to an exception handling routine associated with the wait invocation. The concurrency control mechanisms are therefore familiar from Part II, being similar to those we saw for monitors. Thread creation is easy and multi-threaded programming has been made quite tractable for the general programmer. A brief summary of the concurrent programming operations has been given above but (Lea, 97) should be consulted for a full explanation and extensive examples. 26.9 The Java platform and components (JavaBeans) Applications of reasonable size are constructed from components - some bespoke (written specifically) and some re-used. JavaBeans is a software component model that allows independently developed Java components (Beans) to be combined and interwork. Reusable software components can be the push buttons, text fields list boxes, scrollbars or dialogues, typically sold by third parties as component sets, toolkits, or widget libraries. They might be as complex as calendars, spreadsheets, barcharts, graphical diagram editors or word processors. Components can be nested and arbitrarily complex. In language terms a Bean is a Java class which adheres to certain property and event interface conventions; that is, the interfaces and behaviour of independently developed components must be well-defined; this is the purpose of the JavaBeans model. What differentiates Beans from typical Java classes is introspection. Tools that recognize predefined patterns in method signatures and class definitions can "look inside" a Bean to determine its properties and behavior. A Bean's state can be manipulated at the time it is being assembled as a part within a larger application. Tools have been developed to support the design and testing of Beans: in Java terminology, the Beans Development Kit is a Java application which depends only on the Java Development Kit (JDK). There is also a tool (a BeanBox) for testing Beans which have a visual element and with which the user can interact. That is, the user can cause events by clicking on buttons (or words made into hypertext links) which cause methods to be invoked on the image. Not all software modules need be Beans. Beans are best suited to software components intended to be manipulated visually within builder tools. Some functionality, however, is still best provided through a textual interface, rather than a visual manipulation interface. For example, an SQL API would probably be better suited to packaging through a class library, rather than a Bean. Beans are intended for domain experts (financial analysts, scientists, linguists, factory process control experts), rather than systems programmers. The idea is to make applications easy for them to build. In summary, JavaBeans have the following properties: * Support for introspection allowing a builder tool to analyze how a bean works. * Support for customization allowing a user to alter the appearance and behaviour of a bean. * Support for events allowing beans to fire events, and informing builder tools about both the events they can fire and the events they can handle. * Support for properties allowing beans to be manipulated by program, as well as to support the customization mentioned above. * Support for persistence allowing beans that have been customized in an application builder to have their state saved and restored. 26.10 Java developments Interworking across heterogeneous platforms It is claimed that Java Beans are designed to function as first class components within a range of different industry component architectures, thus following an open interworking philosophy. The following products and standards are being considered: * OpenDoc (Apple, IBM and CILabs) * ActiveX/OLE/COM (Microsoft) * Netscape Navigator (Netscape) * CORBA Javasoft aims to provide first class CORBA IDL and CORBA IIOP support for Java and for JavaBeans. This would allow Java Bean components to be integrated with CORBA services. Java based CORBA implementations such as Java IDL also allow communication stubs to be delevered to a client program at run-time. Persistence and transactions We have seen that Java applets are not allowed to write to files within the client environment, yet some Java applications will require transactional support. Persistent storage within the parent server or a third party server can be used instead. The Java Transaction Service (JTS) offers transaction support at the service level. At the language level, several groups are adding persistence to Java, for example (Atkinson, 1996). 26.11 Ubiquitous computing As well as moving towards supporting traditional, large scale distributed computing applications the developers of Java and its related systems are looking to the future ubiquitous computing market. The requirements here are for simplicity and ease of use. A new diskless workstation architecture has been proposed, the JavaStation, a network computer, see http://www.sun.com/961029/JES/whitepapers/javastation/javast_ch1.html The cost of the workstation is intended to be low, although a network connection is essential. The idea is that applications are not held locally but are imported from central servers to run as and when they are needed. This gives a so-called 'thin client' or 'webtop' alternative to `fat client' PCs. In the home a variety of applications is needed, all transfers can be monitored and the users charged accordingly. The traditional PC might be more suitable here. In some specific workplace environments the approach seems more appropriate. A single software package may form the basis of the company's operation. New versions can be downloaded when they become available, making for easy propagation of software upgrades. We shall see network computers in government offices, travel agents, airports etc. Transactional support and persistent storage is needed by this style of application, see above. 26.12 General mobile applications Java is often called mobile code. As we have seen, a very simple form of mobility has been achieved - downloading of bytecode from a server to a client. The program is mobile once only; if it were to migrate again it would restart. A current research area is general support for mobility. As users and computers move around it may be desirable for some of their applications to be halted, migrated and restarted from the point at which they stopped. (Bates et al, 96; Halls et al, 96) describe a mobile object environment. The scenario is the office of the future. As the participants in an online conference move from room to room, some of the objects in their environments move with them. It is assumed that everyone wears a locating device, such as an active badge, and sensors detect their movements. Figure 26.5 gives the general idea.
A mobile object environment Mobile objects are written in Scheme, a functional language in which programs may be passed around at any point in their execution as closures and continuations. The work incorporates both mobile objects and CORBA style objects in a single environment. The topic may be followed up from the references and from: http://www.cl.cam.ac.uk/Research/SRG/opera/. An approach to ubiquitous computing which exploits this platform is to assume that applications may be acquired from network based storage services. Applications will typically have a browser style of interface and the environment is assumed to contain any number of anonymous processing servers. The application has been made stateless both at the client and at the server. When it needs to interact with the client it migrates there, together with all its state; when it needs server processing it migrates to some convenient processing server. The program transferred is stateful, client and server are stateless. Figure 26.6 illustrates the approach.
Stateful documents, stateless servers and lightweight clients 26.13 Scripting languages We have seen that building applications from independently developed components is exercising the Corba and Java communities where component frameworks such as ActiveX, OpenDoc, and JavaBeans are being developed. It has been argued (Johnson, 1994) that object orientation has not delivered the promised ease of development and reuse of software components. Strong typing, with static type checking, make it difficult to plug independently developed components together and the code inheritance used to build gereralisation/specialisation type hierarchies makes software complex and difficult to understand. An alternative approach is typified by what we have seen in Unix, Chapter 23. Here, arbitrary components may be composed into a pipeline with commnication between them in the form of byte streams; the Unix shells typify the scripting language approach. Shell scripts may include more advanced programming language like features, such as iteration, than earlier command languages such as IBMs JCL. More recent scripting languages include procedures. More recently, the need to build graphical user interfaces (GUIs) for applications has emphasised the need for a convenient way to make connections between a collection of graphical controls and the internal functions of the application. Tcl (Tool command language) and the associated Tk (X11 toolkit) were developed by (Ousterhout, 1994) with this application in mind. Other scripting languages are Perl (Wall et. al., 1996), Visual Basic for PCs, REXX (O'Hara and Gomberg, 1998) and many others. The growth of the Internet has also popularized scripting languages. Perl has become popular for writing CGI scripts and JavaScript is popular for scripting in Web pages. Ousterhout in http://www.sunlabs.com/people/john.ousterhout/scripting.html sees system programming languages such as C, C++ and Java as complementary to the scripting approach. Components are developed in these system programming languages and composed using a scripting language. He argues that component frameworks have been more successful on PCs (where Visual Basic provides a convenient scripting tool) than on other platforms such as Unix/CORBA where scripting is not included in the component framework. As we saw for Java, the ever-increasing speed of computer hardware makes it feasible to implement applications in an interpreted language with acceptable performance. As computers get faster, fewer applications will need to be implemented in a system programming language to achieve adequate performance. Already, the number of applications written in scripting languages is greater than the number of applications written in system programming languages; there are more Unix shell scripts than C programs, and under Windows there are more Visual Basic programmers and applications than C or C++. A comparison based on the number of lines of source code would yield a different result, but this reinforces the view that scripting is a high level language for glueing components together. Ousterhout acknowledges that `the Lisp family of languages lies somewhere between scripting and system programming, with some of the attributes of each. Lisp pioneered concepts such as interpretation and dynamic typing that are now common in scripting languages, as well as automatic storage management and integrated development environments, which are now used in both scripting and system programming languages'. The work on mobile objects reported above, employs these characteristics of Scheme. Scripting languages are already used extensively in application development and it will be interesting to follow the general perception of their importance as time goes by. 26.14 Summary The growth in acceptance of object oriented design concepts embodied by CORBA has been steady, if relatively slow. This style of platform was designed primarily for workplace, industrial and commercial distributed systems and was evolving through the late 1980s and early 1990s. Web browsers became available in 1993 and the explosive growth of popular interest in the Internet and the Web followed. Java took advantage of this popularly accepted style of interface and has become increasingly widely used, rather than "just another object-oriented language". Javasoft are looking to the ubiquitous computing market as well as working towards support for traditional distributed computing applications. Object concepts have stood the test of time in programming languages, operating systems and middleware platforms. Objects in themselves do not provide completely general interworking; there are many different object models and object platforms. We are starting to see an attempt to provide open interworking across heterogeneous platforms through component approaches. An alternative approach to providing the glue to compose applications from components is to use a scripting language. At the level of mechanism, processors have become fast enough to make on the fly interpretation of code a feasible means of running applications. We had previously seen static clients and servers with data passed between them in some standard external form. It is now possible to create programs which run above heterogeneous hardware and operating systems by interpreting intermediate code. A simple form of mobility and heterogeneity is achieved relatively easily by this means. There is currently a great deal of interest in more general support for mobility. Human users and their computers require to be mobile. It may be necessary in some modes of working to interrupt a running program, migrate it and restart it elsewhere from the point at which it was stopped. This is far beyond the simple downloading of a program's code and data we have seen for Java. Research projects are investigating languages such as Scheme which, with state-saving continuations, allows a program to be halted at any point and migrated to another node.