Object-Oriented Web Engineering

Object-Oriented Web Engineering

Hans-Werner Gellersen（来自中国系统分析员）　　　2003年03月01日

Resource-based Web Implementation Originally, the World-Wide Web was designed as information medium for distributed research teams. A deliberately simple implementation model was chosen to make it as simple as possible for authors to contribute documents to the web, and to maintain these in the sense of updating content. This implementation model is centered around the notion of resources, usually file-based. For the originally intended use of the web, resources presented a useful abstraction, as they related to relatively self-contained chunks of information such as research publications and home pages. Such chunks of information typically could be set up and maintained independently of other resources, so that resources were the appropriate abstraction for composition and modification. The use of the web, though, has moved far beyond the originally anticipated scope. In its use as information medium, the web has moved into high standard publishing with complex requirements related to corporate identity and to integrity of large webs. Resources are no longer easily maintained by themselves as they have to adhere to web site conventions regarding layout, interlinking, navigation and so on. Further, the web is not only used as information medium but has become a general integration platform for distributed appications. In development, management and maintenance of such applications, resources as abstraction are not very useful. Resources are too coarse-grained and too specific as entities for design, reuse, management and modification of web applications. Problems with the resource-based web implementation model are discussed in the subsequent section with respect to design, reuse and evolution. Mapping Design Concepts to a Web Implementation As the web implementation model based on resources is semantically so poor, the mapping of higher-level design concepts to a web implementation is hardly reversible. Higher-level design concepts such as graph structures in hypertext, dialogue in session-based applications, user interface objects in interactive applications (and so on ...) get lost in a web implementation because of the simplicity of the underlying model. For example, hypertext graphs, navigation structures and other hypertext concepts are implemented in Web links embedded in resources; once implemented, the relationship between these links, that is their "hypertext meaning", is lost. While design methods and tools are available for mapping higher-level concepts to web implementations are available (for hypertext e.g. OOHDM [3], RMM [4] and RMCase [5]), management and maintenance of higher-level concepts is hard. A specific instance of this problem is link integrity which has been much discussed but which is really just one instance of a very general problem in web application maintenance. The maintenance of design concepts is all the more problematic, as there is a split of roles in development of larger web applications, with maintenance carried out by site engineers and not by original designers/authors of content. In general, a multitude of people are involved in a web application life cycle in all sorts of different roles. This results in the problem of site engineers having to mentally reconstruct higher-level concepts from an implementation at hand in order to maintain them and protect in the case of modification. Naturally, this easily leads to introduction of errors and loss of application integrity. Reuse of Designs and Code Resources are specific entities to be served by web servers. Very little work has been done toward abstract resources abstracting from some implementation detail in order to be reusable. An example for abstractions are style sheets in HTML that allow to factor out some reusable layout components from HTML pages, or server-side includes for reuse of HTML fragments in many resources. These abstractions, though, are very limited and by far not generally applicable. Design concepts often relate not too exactly one resource but for example to fragments within a resource, to structures composed of such fragments, or to interlinked resources. As these concepts are not easily accessible from within a resource-based web implementation, they are hard to reuse. Further, design concepts may be abstract and would have to be abstracted out from a specific implementation. For reuse, design concepts have to replicated in an implementation, which in turn brings us back to the problem of maintaining integrity in the course of web evolution. Maintainance of integrity would at least require a replication of modifications, and would very likely lead to a violation of integrity. The lack of support for inheritance in web resources represents yet another key problem. In design, generalization and specialization are fundamental concepts for organization of web sites and web applications, for instance describing general page designs which can be refined to more specific designs for certain categories of pages. As more general design decisions can not be captured in abstractions, their maintenance can not be localized but requires modification of all effected specific design artifacts. Web Evolution We all experience that web application undergo very fast evolution, driven by the requirements to continously update content, and to take up latest technological options. Unfortunately, resources are a poor abstraction in the course of evolution, as modifications are seldomly localized in single resources. Rather, evolution effects concepts as described in the sections above, for example structural concepts composed of fragments that are embedded in a number of resources, or general concepts mapped to a range of specific code fragments. In the following section we describe an object-oriented model, WebComposition[6], for engineering webs, addressing issues of maintainability in general and hypertext structures in particular. After introduction of the model, we briefly describe its implementation in the WebComposition system which maintains the model throughout the life cycle and links it to the actual web by means of automatic and incremental resource generation. The WebComposition Model In WebComposition, web entities are modeled as component objects with a state and a set of operations specifying the component behavior. Components can model web entities of arbitrary granularity. A component may for example model entities as small as individual links, anchors or other resource fragments. Of course, a component may also be associated with a complete resource, for instance an HTML page or a Perl Script generating an HTML page. A component may even model a group of resources, for example modelling a dialog sequence implemented in a number of interlinked forms. Components can reference other components to model aggregation (has-part) or specialization (inherits-from). For example, a component modeling a page could reference components modelling parts of the page; a component modeling a navigation structure could reference components modeling involved links and anchors. By means of a dedicated reference type, components can reference prototype components from which they inherit state and behavior (WebComposition is based on a prototype-instance OO model, cf. [7], as opposed to a class-oriented OO model which we considered too heavy). Components may be abstract, i.e. function only as prototype for specific components. Abstract components are one means to realize code sharing among objects. Another means for code sharing is to allow multiple references on the same component, e.g. for a component modeling an HTML fragment that is replicated in multiple HTML pages. Sharing is fundamental not only for reuse but also for maintainability as it helps keeping modifications local. Components are defined by state and behavior. The state is defined by a list of typed properties (name-value-pairs). For example, a component modeling an HTML element would have properties relating to that element's attributes. The behavior is defined by a set of operations. All components have to provide operations getProperties, setProperties and generateCode. The first two operations realize read respectively write access for manipulation of component state. Together, they implement the persistence service of a component, serialising/deserialising component state for persistent storage in the Component Store (cf. next section). The generateCode operation implements the presentation service of a component, mapping its state to a representation in the web, for instance a mapping to HTML code. The relationship between component and its web representations is a model-view-relationship. For primitive components, for instance a chunk of text, this mapping is straightforward, and the operation can be thought of as consisting of a simple print statement. For composite components the mapping involves delegation of mapping to its children components. For simple composites such as a list, generateCode could simply iterate over its children, invoking their respective operations. In more complex cases, for instance tables, the composite has to generate its own code in addition to the code of its children. WebComposition System The WebComposition system implements the model in a persistent database, the Component Store, maintains controlled access for component manipulation throughout the life cycle through a Component Server, and facilitates the incremental mapping of stored component models to a web implementation by means of a Resource Generator. The system is transparent for the existing web, i.e. it does not require server modifications or the like. The component store is based on a standard RDBMS, as the prototype-instance model (in contrast to class-oriented OO models) can be mapped in a straightforward way to tables and relationships. Our current implementation is based on Microsoft SQL Server but database-specific code has been kept at a minimum for the sake of portability. The component server provides access to components through a component access protocol. This protocol is transaction-oriented and supports check-in, checkout, unlock and get operations. Components are uniquely identified through a UUID and a version number. The component server can serve components to any kind of application, for instance to tools for explicit editing of components, to management tools monitoring web applications, or even to the application to which the component belongs. The last case is important as it facilitates application-driven evolution of itself which can for instance be used for customisation of applications. The component server does not distinguish between instances and prototypes (in fact, there is no such distinction in the model anyway, cf. previous section). The component server though distinguishes between the properties a component defines itself and those properties inherited from other components. It grants read access to all properties but restricts write access to the instance-specific properties. Not yet implemented in the component access protocol but considered is a mutation operations extending write access to inherited properties which after modification become instance properties no longer subject to inheritance. The resource generator creates file-based resources from the component model of a web application. All the information required for mapping components to the file system is contained in the components' generateCode operations which are invoked top-down from aggregation components to atomic components. For components of small grain this operation returns code fragments of file-based resources. For components at the granularity of resources, this operation returns a filename. And for higher-level components, the operation may return a directory path or nil (when it returns nil, the directory tree is not further subdivided). The resource generator can perform both a complete installation of a web application, and incremental modifications. For a complete installation, the resource generator proceeds top-down through the component hierarchy, top-down making directories, opening files and filling files with code. For incremental code generation, the resource generator makes use of the component store's revision control. In this process, it generates those resources that contain components that have been modified. As resources themselves are represented by components, the dependencies among components can be evaluated to identify those resources that have to be newly generated. Summary With WebComposition webs are modelled in terms of components of arbitrary granularity. Components capture web entities for reuse, sharing and localisation of modifications. Components can capture those web entities that are basic units for more complex patterns, but that are hidden in resources in a standard web implementation. One instance of such patterns are hypertext structures which are based on links and anchors that can be made explicit in the WebComposition model. We would propose that based on the object-oriented WebComposition model, object-oriented design patterns as pioneered by the gang-of-four [8] may be used for development of reusable hypertext structures. References 1. FrontPage Home Page, Microsoft Corp., URL: http://www.microsoft.com/FrontPage/ 2. NetObjects Home Page, URL: http://www.NetObjects.com/ 3. D. Schwabe and G. Rossi.From Domain, Fifth International World Wide Web Conference, Paris, France, 1996. URL: http://www5conf.inria.fr/fich_html/papers/P35/Overview.html 4. T. Isakowitz, E.A. Stohr and P. Balasubramaninan. RMM: A Methodology for Structured Hypermedia Design, Communications of the ACM, August 1995. 5. Alicia Diaz, Tomas Isakowitz, Vanesa Maiorana and Gabriel Gilabert. RMC: A Tool to Design WWW Applications, The World Wide Web Journal, Issue One, Dec. 1995. URL: http://www.w3.org/pub/WWW/Journal/1/isakowitz.187/paper/187.html 6. H.-W. Gellersen, R. Wicke and M. GaedkeWebCompostion: an object-oriented support system for the Web engineering lifecycle, Computer Networks and ISDN Systems 29 (1997), p. 1429-1437. URL: http://www.teco.edu/~hwg/www6/PAPER232.html 7. D. Ungar and R.B. Smith. Self: The Power of Simplicity, OOPSLA '87 Proceedings, p. 227-242, 1987. 8. E. Gamma, R. Helm, R. Johnson and J. VlissidesDesign Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.