The World Wide Web as a Distributed Object System

Transcription

1 The World Wide Web as a Distributed Object System Travis Olds School of Computer Science The University of Adelaide SA, 5005, Australia [email protected] Abstract This paper considers the idea of the World Wide Web as a distributed object system, in contrast to the more traditional view of the Web as purely a distributed document system. There already exist significant indications of moves in this direct and some of the more compelling examples will be discussed. We believe this move is indeed a very positive one but question the overall approach that is taken. It is felt that not fully committing to this objective only results in the absence of many properties important for success. Those properties considered most critical are examined. The remainder of the paper presents an overview of our efforts: firstly in the use of object systems within individual components of a Web system, and secondly in looking towards achieving a genuinely distributed object Web system. 1 Introduction The World Wide Web is moving away from its roots as being purely a distributed document system towards what can better be categorised as a distributed object system. This statement is certainly justified given reference to a wealth of current standards, technology, and research. While this may be the case, replacing the Web with what could be considered a complete distributed object system is certainly not the deliberate, or intended, outcome of most of those involved. In fact, many would argue, that this is actually a most undesirable outcome because it would reduce the Web s flexibility and increase its complexity. Furthermore, it is conjectured that since this outcome is not the result of conscious effort, the resulting system, whilst characteristic of distributed object systems, will exhibit much unnecessary complexity and incoherence. Our approach to the Web is somewhat radical, arguing for something much closer to a genuine distributed object system and for a somewhat more direct and planned approach to this outcome. Before exploring things from this perspective however, some of the more convincing indicators of a move towards an object-based approach are discussed. This leads into examination of some of the more important deficiencies perceived in existing technology. Work is then presented that both demonstrates the benefits of strongly typed object-based approaches in the Web and provides compelling grounds for the basis for much of our beliefs. Finally, achieving our long-term objective of a genuine distributed object Web system is further discussed. 2 Signaling the move towards an object system The direction in which much of the World Wide Web is clearly moving is towards some form of object system. At the very least, object systems functionality will form the basis of many of the components within Web systems. Discussion of indicators of this move will focus around specifications of the World Wide Web Consortium (W3C). This is because standards, in addition to forming a critical component of existing technology, both reflect past activities considered as worthwhile steps forward and underpin all future mainstream efforts. Individual Web systems and other Web related research endeavors, on the other hand, whilst hopefully leaving some mark for future directions are far more likely to otherwise simply come and go. 2.1 The Document Object Model The W3C has developed its Document Object Model (DOM) [5] to support document structure navigation, and addition, modification, and deletion of elements and content within pages. The DOM is an Application Programming Interface (API) for documents. The interface essentially allows application programs to act upon a document as if it were represented as a graph of objects. The DOM is intended for both client and server side document processing and manipulation. Broad ranging and powerful functionality is provided for both of these situations. A good example of this functionality is DOM events which allows event listener registration for notification of document mutation and user interface actions. In the case of the client side, for example, such functionality could be used to support interactive document mutation on user mouse action within a web browser.

2 Programming language and implementation independence are major design objectives for the DOM. The DOM is implementation independent in that it defines only the interface and the logical structure of documents. Whilst the logical structure of a document is a form of object graph, an implementation conforming to the DOM can physically represent documents in whatever form is convenient. The relationship between objects can also be implemented in any manner. Programming language independence effectively means that operations on documents through use of the DOM are mostly very weakly typed. 2.2 The XML Infomation Set The XML Information Set (Infoset) [8] defines an abstract data model for XML documents. It is intended that the XML Infoset provide a consistent set of definitions for use by other specifications needing to refer to information within an XML document. The XML Infoset, in effect, specifies the result of parsing an XML document, in the form of a collection of information items. A document s infoset is therefore comprised of a number of information items, each of which is an abstract description of some part of the document and has a set of associated named properties. The XML Infoset defines eleven different types of information items that a document s infoset may contain. However, each document infoset must at least contain exactly one document information item, since all other information items are accessible, either directly or indirectly, from the properties of the document information item. The XML infoset data model is abstract because it defines neither an interface nor implementation. Whilst the abstract model is certainly a form of object graph, or tree, there is no requirement that a document s infoset be physically represented in this form. Equally, there is no requirement that an infoset be accessible through an interface that exposes a tree structure. Increasingly specifications are defining their activities purely as infoset to infoset transformations. That is they define operations on data as if, whilst being operated over, that data were actually represented in the form of the XML Infoset. 2.3 XQuery XQuery [10] is designed to be a standardised query language for XML data, in much the same way that Structured Query Language (SQL) is a standard for relational data. XQuery is a simple, yet powerful, high-level functional language where each query is an expression to be evaluated, and new expressions can be created through composition of existing expressions. XQuery is defined in terms of a formal data model, not in terms of XML text. Every input to a query is an instance of the data model, as is the output of every query. XQuery is defined purely as a transformation from one instance of the data model to another. Access to a data model instance for input and the outputting of a data model instance are handled by calling predefined XQuery input and output functions. Not surprisingly in the XQuery data model every document is represented as a tree of nodes, or objects. The kinds of nodes that may occur are: document, element, attribute, text, namespace, processing instruction, and comment. Every node has a unique node identity that distinguishes it from all other nodes, including those that would otherwise be considered identical. In addition to nodes, the data model also allows atomic values which are values having simple types such as strings, booleans, integers, floats and doubles. The operations that XQuery supports allow the querying of not only content but also the structure of data. XQuery operations therefore make heavy use of the logical tree-based structuring of data. Nodes can be located using path expressions, new structures can be created with element constructors, content may be sorted, and existing documents can be restructured and combined to form new documents. Predictably, there has been much discussion recently regarding what are to be referred to as native XML databases. As the name suggests these are databases designed specifically for storage and retrieval of XML data. A native XML Database Management System (DBMS) is expected to provide all the features of any DBMS, such as secondary storage management, protection and the enforcement of integrity constraints, and query processing, but specifically tailor them to the management of XML data. Essentially, a native XML DBMSs fundamental characteristic is the ubiquitous use of the XML data model, or more likely the XQuery data model, throughout. This includes storage, processing and in its communications interfaces. 2.4 Web services Web services are envisioned as the means for constructing distributed application systems in the Web. A Web service can simply be considered to be a software entity that is identified by a URL and that exposes interfaces defined and described using XML. Other entities may discover these interface definitions, so as to allow them to interact with the Web service using XML-based messages. In this way Web services can be used as components in the construction of some greater Web-based software service. The Web Service Architecture (WSA) specification [6] is intended to provide the common definition of a Web

3 service, and set out its role within the larger distributed architectural framework. It identifies functional components, defines their interrelationships, and prescribes any constraints on each component required to achieve the intended outcomes of the architecture. It does not, however, specify how Web services are implemented. The Web Services Architecture (WSA) is an instance of what is referred to as a Service Oriented Architecture (SOA). An SOA is a particular type of distributed system in which the discrete software entities making up the system perform a single well-defined role, that is provide a service. The Web Service Description Language (WSDL) [7] provides the standardised means for describing Web services. A Web Service Description (WSD), written in WSDL, therefore acts as a description of the programmatic interface to a publicly accessible component within the distributed application. WSD s are machine readable and provide sufficient information for the Web service to be invoked, and for request and response information to be exchanged correctly. An important note about Web services is to clarify that Web services are in fact only defined at the abstract level. That is, Web services are only abstract entities whose actual implementation is what is referred to as an agent. Agents are therefore the actual concrete entities implementing a service, whilst a service is merely the abstract set of functionality provided. The important point in this regard is that the notion of a Web service is completely implementation independent, agents can be implemented in any programming language, and using any approach, that is convenient. The WSA, and individual Web services themselves, can be strongly contrasted with distributed object systems and their constituent entities. An instantiation of the WSA clearly consists of a number of distributed interconnected entities, Web Services, each of which exposes an objectlike interface for use by others. Obviously, perceptible similarities do not end here; being in fact quite easily extended much deeper. 3 Important properties absent in the mainstream approach Having identified a number of indicators of a move towards object systems in the World Wide Web it is appropriate to consider some of the perceived deficiencies in existing approaches. It is only intended that some of the deficiencies in existing technology, perceived as being more major, will be addressed here. These deficiencies are seen not only as those most critical for the formulation and construction of Web systems as genuine distributed object systems, but also still important, to varying degrees, if the Web is to even be treated at some abstract level as an object system. 3.1 Lack of a single physical data model The XML Infoset specification was created to address the lack of a data model, a representation in structural form, in the original specifications of XML. This omission however, in combination with the fact that a number of technologies have ancestry which predate XML itself, means that the XML Infoset is not the only model used for representing XML data. Whilst it is intended that the XML Infoset form the data model for other XML related specifications, including hopeful future revisions of existing specifications, much inconsistency presently remains. This is particularly the case for the Document Object model, which is certainly a vastly different model to that of the XML Infoset. Furthermore, many specifications, such as XQuery have moved towards being based on an augmented version of XML Infoset s, referred to as a Post-Schema Validation Infoset (PSVI), that adds type information and normalises data values. Whilst inconsistencies between the data models of different component technologies remain there is little hope for their use in the construction of large, non-trivial, distributed software systems. Such disparate component technologies only leads to systems where much unnecessary complexity results; and where protection and efficiency are far less than optimal. Although, data model inconsistency is probably a soluble problem, the lack of a physical data model is far more concerning and inherent. The trouble is that all specifications for a standard data model for Web data are only logical in nature and as such do not prescribe actual physical representations. The lack of such a standardised physical data model means component implementors are free to use whatever physical representation they find convenient, so long as they present the illusion of the representation defined by the logical data model. This flexibility limits the guarantees that can be made about the behaviour of a component, thereby complicating its failure semantics and reducing its powerfulness. The spill-on effect of this a far more complicated overall system, much more likely to malfunction, more difficult to construct and reason about, and likely to be less powerful and less efficient. 3.2 Lack of uniform data protection The stages in the life-cycle of data within a Web system can be broadly partitioned into that of computation, storage, and communications. Throughout all these stages in data s lifetime, data should be strongly protected against accidental or deliberate misuse. The role of protection

4 has traditionally been handled by some form of type system provided by the support system of a given component technology. For example, the programming language type system in the case of computation within a programming language system. Not only does data need to be protected against misuse, protection must be achieved through both uniform enforcement and uniform expressibility of constraints. This is because without such uniformity, the protection offered cannot be guaranteed. This is due to the possibility of subversion of the type system during periods in which its constraints are less strongly enforced and the possibility of type incompatibilities, where less expressibility in one system results in loss of protection. A typically Web system is pieced together using a number of different implementation technologies and support systems, each providing facilities for one or more of the tasks necessary in the life-cycle of data. For example, programming languages are commonly used for computation, DBMSs and filesystems for storage, and communication is commonly either in the form of Web data items, such as XML, or some mechanism specific to the communicating entity technologies. The point here is that protection is clearly not uniform. Different component technologies enforce protection to varying degrees, if at all. Furthermore, even if each component technology strongly enforces protection, programming language types are most likely incompatible with DBMS schema, and different languages have stronger or weaker type systems to one another. 3.3 Lack of a powerful expressive type system Leading on from the need for uniform protection of data, guaranteeing protection has little worth unless the type system is sufficiently powerful to express the constraints necessary for the forms of data a system must support. The W3C s XML Schema [9] is often touted as the type system for the Web. The basis for this is that XML Schema is, to some extent, seen as the successor of Document Type Definitions (DTDs) - the original mechanism used in the XML recommendation for specifying constraints on the make-up of documents. XML Schemas have the significant benefit over DTDs of being themselves formulated in XML. Whilst XML Schema is also substantially more powerful in specificity to DTDs, it remains the case that XML Schema is designed for the typing of documents and not for the typing of data in general. The implication of this is that XML Schema can in fact be seen as equivalent to a context free grammar definition language, and not a full fledged type system. That is to say that XML Schema can constrain syntax. It cannot, however, express more general type constraints. Fortunately in the case of most of the types seen in basic XML documents, those of simple types such as floats and strings and of complex nested structures, all of which have literal values, constraints imposed on syntax can mostly be enough to affect necessary type constraints. Unfortunately, however, this is not the case for more general forms of data required in computation and storage. A prime example of this is that XML Schema cannot be used effectively to type constrain data values containing first-class functions. Furthermore, even basic documents do not escape entirely from the limitations of XML Schema. Importantly, references in a document, whilst being constrained to be well-formed URLs, are otherwise completely untyped. If Web systems are to be constructed so as to provide any guarantees as to their correctness and their protection of data, the type system used throughout needs to be significantly more complete than that which is offered by XML Schema. Whilst it is unclear what all the facilities necessary for this role may be, it is clear that such a type system must at least provide support for the typing of references, to allow guarantees of referential integrity to be made, and for the typing of first-class function values, since these are such an important part of almost all modern languages. 4 The beginnings of a Web object system We have already demonstrated an approach [3] to Web application safety, based in major part on the use of an orthogonally persistent object system [1, 2], that is simpler and more powerful than previous approaches. Our approach provides systemic enforcement of safety and results in a complete Web application server system that is implemented entirely within a strongly typed orthogonally persistent object system, with automatic storage management. 4.1 Overview of the approach A diagrammatic overview of our our approach, showing the important stages in the life cycle of a Web request is given in Figure 1. The key points relating to our approach are as follows. All storage in our system is of strongly typed object graphs, including first-class functions, and is completely orthogonal to the life-time of such data. All static and dynamic Web content is therefore represented in strongly typed structured form. All links within pages, including form actions, are represented as indirected strongly typed

5 Web server name space URL loc[fun(p) HTML] Session variables of content generator URL HTML view[o:loc[fun(p) HTML]] fun(p) HTML Web content generator referenced by URL Web page containing href or action link Structured representation of well-formed Web page, produced as result Figure 1: Web request life cycle with object-based representation pointers to their referent objects. Links are indirected to support external lookup based on URLs. All computation in our system is over typed and initialised values, with all updates of Web content being subject to strong type checking and referential integrity maintained for all pointers. Also, since our approach is based on a block structured programming language, operations of session oriented applications on session state can be completely statically checked. This is because dynamic content generators providing operations on session state are higher-order functions dynamically generated during the session and lexically nested within the scope of the function which created the session variable. Finally, all conversion to and from textual form for input and output are handled via system level processes, whose correctness can be guaranteed. 4.2 Benefits of the approach We have identified many benefits, mostly inherent to our approach. In summary, these benefits are that the following important safety properties are guaranteed: 1. all delivered HTML content is syntactically wellformed. 2. hyper-links in both static and dynamically generated content have referential integrity. 3. Web forms are consistent with the services processing form input. 4. the code of session operations has statically safe bindings to variables defined with session scope. These safety properties ensure that the following failures, otherwise exposed to human users of Web applications developed with traditional approaches, cannot occur within our approach: Malformed pages. Broken links. Inconsistencies in links to Web services responsible for processing user input. Failed session state linkage. In addition to the basic properties just outlined, our approach safely and efficiently supports many facilities desirable in the development of Web application systems. Some noteworthy examples are: Statically safe computation over Web content. System-wide safe and efficient shareability. It is important to emphasise the vital contribution that an othogonally persistent object system has in our approach. Orthogonal persistence enables us to avoid consideration of the issue of the need for persistence within the formulation of our approach. The result being a simplified model and the extension of the benefits of our approach to automatically include components that are required to persist. 4.3 Earlier realisation of the approaches benefits Hyper-programming [4] refers to a programming concept in which the source and executable representation of programs are unified. Hyper-progamming allows a much wider range of static checking of program safety than conventional approaches, and also promises to greatly simplify the task of incremental system development. At program construction, pointers to actual objects that will be involved in program execution are directly incorporated into the program description. These pointers replace the usual textual access path descriptions that are instead used to specify such objects for binding at link time. Hyper-programming therefore relies on the existence of referent objects within the environment of execution at program composition time, making use of this situation to allow direct binding and earlier checking.

6 Hyper-programming has been successfully applied to application development within closed world orthogonally persistent system. We are currently exploring the hyper-programming concept within the open system that is the Web. We envisage a hyper-programming system that supports program development external to the application server, with URLs forming the pointers that replace textual access paths. We see hyper-programming as being able to extend the benefits of a strongly typed objectbased representation, that being safety and increased capabilities, to the phases of system development and maintenance. 4.4 Present limitations The only major current limitation of our approach is its lack of standardised support facilities. Importantly, only a subset of data can be sufficiently type protected with means compatible with standard mechanisms available when data is communicated outside the system. This restricts the openness of the system for any non-proprietary components. These limitations, however, are considered to merely limit the current applicability of some of the possible benefits of our approach. 5 Achieving a genuine distributed object Web system It is clear from our work so far, and that of others, that object systems have many advantages for the representation of individual components of a Web system over systems which adopt purely document-based content representations. It is believed, however, that further exploitation of object-based representations offers even greater benefits and promises even further opportunities. Our aim is, essentially, to support safe distributed computation over Web content in much the same way that we believe we have mostly achieved this in the nondistributed context. Whilst the requirements here are much the same as in that case, the need for standardised mechanisms is even more critical. Our long-term goal is therefore to achieve a situation in which the Web is as close as possible to being what could be considered a genuine distributed object system. We believe this situation guarantees maximum safety whilst also providing maximum capabilities for the applications taking advantage of the environment. We seek to achieve this situation since it would allow all data to: have a uniform representation, be protected against misuse by means of a single type system, and be geographically distributed Figure 2 provides a simplified illustration of how we would hope such as system to look. Key points in the Web browser/client Server Secondary storage Server Server Main memory Legend Site boundary Site component boundary Document Object URL reference Figure 2: An example distributed object Web system figure are references and object graphs representing document entities. These emphasise the important concept of what is essentially a two level addressing scheme. Intradocument references are mostly implicit within a document, whilst inter-document references are made explicit by way of URLs. URLs are the standardised means for communicating references and as such delineate collections for communication. It is considered for the sake of implementation flexibility, that both forms of references may be physically represented by a variety of means. String-form URLs are certainly only necessary during transit, whilst direct memory addresses are otherwise generally more efficient. Whilst in reality individual components may choose to what extend they wish to be faithful in actually adopting the available attributes for data under their control, those that fully do so should be able to derive maximum benefit. On the other hand, components that choose to disregard these attributes merely offer limited functionality and protection. We are presently working towards achieving our goal and see the following as integral ingredients: 1. an object based representation for all data throughout its entire lifetime. 2. a type system with sufficient expressive power to protect all data throughout its entire lifetime. 3. strongly typed URLs for adding a level of indirection to references to support distribution. Finally, it is worthwhile noting that in contrast to more traditional distributed object systems, a distributed object system for the Web must provide additional flexibility to allow subsystem autonomy. It is seen as important that individual components be able to opt-in, or out, of different guarantees they provide. For example components should

7 be able to choose whether to: cooperate to preserve distributed referential integrity, provide some limited form of referential integrity such as a guarantee of referent type but not existence, or provide no referential integrity whatsoever. Supporting such functionality certainly requires significant investigation. 6 Conclusion The World Wide Web as a distributed object system is put forward as a considerably positive step forward. Significant indications of existing moves in this direction are presented. Whilst this effort offers much promise, it is shown not to currently be enough for the complete realisation of the potential of the Web as a distributed object system. Some of the more important of these deficiencies are examined. We seek to support a situation that realises the benefits of object systems for the Web. Having demonstrated an object-based single server system that can guarantee safe web application execution is presented as compelling evidence of these beginnings. Present work on further realisation of these benefits also shows promise. Finally, proceeding onwards toward a genuine distributed object Web system is introduced. Whilst achieving this goal is still some time off, it is hoped that this introduction serves at least to stimulate interest. [6] World Wide Web Consortium (W3C). Web service architecture (work in progress). TR/2003/WD-ws-arch /. [7] World Wide Web Consortium (W3C). Web service description working group /ws/desc/. [8] World Wide Web Consortium (W3C). XML information set. [9] World Wide Web Consortium (W3C). Xml schema. [10] World Wide Web Consortium (W3C). XQery 1.0: An XML query language. xquery/. References [1] M. P. Atkinson, P. J. Bailey, K. J. Chisholm, W. P. Cockshott, and R. Morrison. An approach to persistent programming. Computer Journal, 26(4): , [2] M. P. Atkinson and R. Morrison. Orthogonally persistent object systems. International Journal on Very Large Data Bases (VLDB), 4(3): , [3] H. Detmold, K. Falkner, D. Munro, T. Olds, R. Morrison, and S. Norcross. An integrated approach to static safety of web applications. In the 12th International World Wide Web Conference (WWW03), p309-detmold.html. [4] G. N. C. Kirby, R. C. H. Connor, Q. I. Cutts, and R. Morrison. Persistent hyper-programs. In Persistent Object Systems, pages Springer, [5] World Wide Web Consortium (W3C). Document object model (DOM) specifications.