Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Object-oriented Web Engineering for Large-scale Web Service Management Martin Gaedke, Hans-W. Gellersen, Albrecht Schmidt, Telecooperation Office (TecO) University of Karlsruhe Vincenz-Priessnitz Str. 1 76131 Karlsruhe, Germany Tel. +49 721 690249 Fax. +49 721 690216 Email:
[email protected] URL: http://www.teco.edu/
1. ABSTRACT The web implementation model is based on a low level technology and does not provide abstractions for capturing higher level design-concepts, therefor design decisions are difficult to track in an implementation, so that maintenance becomes a difficult and error-prone task. In this paper we introduce the WebComposition system addressing this problem. This system is based on a fine-grained object-oriented web application model. Services are logical units or business processes represented as groups of WebComposition components. The automatic creation for this class of components is possible using service factories, which are modeled on creational design patterns. Service factories enhance the planning for the evolution of the overall structure of large-scale web sites. WebComposition maintains access to all resources throughout the lifecycle for management and maintenance activities. Modifications of the model are made effective in the web by incrementally mapping the model to filebased resources.
2. INTRODUCTION 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
Ulf Stegemüller, Wolfgang Kurr
Hewlett-Packard GmbH Postfach 14 30 71004 Boeblingen, Germany
these in the sense of updating content. This implementation model is centered on the notion of resources, usually file-based [10]. For the originally intended use of the web, file-based 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 (CI) and to integrity of large webs. File-based resources are no longer easy to maintain, 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 applications. In development, management and maintenance of such applications, file-based resources as abstraction are less useful. These 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.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
1
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
2.1. MAPPING DESIGN CONCEPTS TO A WEB IMPLEMENTATION As the web implementation model based on resources is semantically 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 etc. 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 (for hypertext e.g. OOHDM, [10], RMM [9] and RMCase [4]), the reverse mapping and therfor management and maintenance of higher-level concepts is hard and only poorly supported [5], [10]. 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. In development of larger web applications, with maintenance typically carried out by site engineers and not by original designers/authors of content, the maintenance of design concepts introduces even more problems. In general, a multitude of people is 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 keep the semantic in the case of modification. Naturally, this easily leads to introduction of errors and loss of application integrity. 2.2. REUSE OF DESIGNS AND CODE Resources are specific entities to be served by web servers. Very little work has been done toward more abstract resources. To generate reusable resources there has to be abstraction from the implementation details. An example for abstractions are style-sheets in HTML that allows to factor out some reusable layout components from HTML
pages. Other examples are server-side include or server-side scripting for the reuse of HTML fragments in many resources. These abstractions, though, are very limited and by far not generally applicable. Design concepts often relate only 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. Design concepts that are reused have to be replicated in the implementation. This brings us back to the problem of maintaining integrity and consistency in the course of web evolution. Maintenance 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. Using filebased resources a more general design decision can not be captured in abstractions, therefor maintenance can not be localized in a single place. This requires the modification of all effected specific design artifacts. 2.3. WEB EVOLUTION We all experience that web application undergo very fast evolution, driven by the requirements to continuously 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 above. This effects 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 objectoriented model, WebComposition [7], for engineering webs, addressing issues of maintainability in general and hypertext structures in particular. After introduction of the model, we
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
2
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
briefly describe its implementation in the WebComposition system that maintains the model throughout the life cycle and links it to the actual web by means of automatic and incremental resource generation.
3. 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 modeling 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 modeling 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 prototypeinstance OO model, cf. [15], as opposed to a classoriented OO model, which we considered too heavy. Components may be abstract, i.e. function only as prototype for specific components. Abstract components are one mechanism to realize code sharing among objects. Another mechanism 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. 3.1. COMPONENTS
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, serializing/deserializing 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 the component and its web representations is a model-view-relationship. For primitive components, for instance a chunk of text, this mapping is straightforward. The operation can be thought as 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. 3.2. INHERITANCE The WebComposition model supports ordered multiple inheritance, allowing a component to have more than one parent. A component inherits all properties of its ancestors. Due to the fact that properties can have the same names in different prototypes a mechanism to avoid ambiguities is needed. In the model we use ordered multiple inheritance. For each component the parents must be ordered. A new component is instantiated by copying all properties of the parents in the specified order, starting with the lowest priority to the highest priority. Properties with same names as in higher priority parents overwrite the already copied name-value pair of a lower priority parent. See example 1.
Components are defined by their 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
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
3
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
P1: ( (a, value1), (b, value2), (c, value3), (d, value4)) (z, value9))
P2: ( (a, value5), (x, value6)) P3: ( (b, value7), (x, value8),
A: ( (a, value5), (b,value7), (c,value3), (d,value4), (x,value8), (z,value9)) Example 1: Component A inherits from P1, P2, P3
4. 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 the means of a Resource Generator. The system as shown in Figure 1 is transparent for the existing web; i.e. it does not require server modifications or the like.
Figure 1 WebComposition Architecture
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 the 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, lock, unlock and get operations. Components are uniquely identified through a UUID [11] 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. It can also support the application to which the component belongs. The last case is important as it facilitates the evolution of the application by itself, which can for instance be used for customization 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. We envision the component access protocol supports operations that extend write access to inherited properties. After modification instance properties are 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. These operations are invoked top-down from aggregation components to atomic components. For components of small granularity 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. The resource generator can perform both a complete installation of a web application and incremental modifications. For a complete installation, the resource generator proceeds topdown through the component hierarchy, top-down
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
4
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
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 only have to be newly generated.
5. LARGE-SCALE WEB SERVICE MANAGEMENT 5.1. A PROBLEM DESCRIPTION In this section we will discuss the use of this methodology and system for Web Engineering and Management of large-scale Web services Consider the following scenario: A web company sells products (hardware, software etc.) and provides their customer also with company- and product-related information like stock- and company-news, manuals, product updates, etc. The amount of information to be delivered varies due to the fact that some products are only available for a short time, manuals are translated to different languages and so on. Due to the fact, that the company is operating internationally customers can access the content in a language of their choice. Within the company groups from different locations all over the world have access to the system to provide customers with new updates and information. Of course, if closely related versions of the same products exist, the documentation effort should not be duplicated. Furthermore, as the company’s business is based on the web, a consistent user interface and corporate identity is a major reason for success. Of course, the question comes up "How to develop a component model of this web application"? We could envision a highly structured approach identifying components, specifying them with property editors at the level of detail required for resource generation and have a great deal of expressive power, evolution and maintainability. Yet it would be foolish to neglect the current practice of web application development. While we believe, that a more structured approach is required we also acknowledge that for example user interface
specialists and page designer can easier develop page layouts with existing WYSIWYG editors. Major reasons for success are corporate identity and fast providing of new information. This makes the maintenance of company layout concepts more difficult. To increase productivity without violating maintainability some interesting questions from a web-engineering viewpoint arise: • How can Authors and Developers provide content without knowing too much about hypertext and hypermedia. • How can product, news, or other information be authored once and presented in different views to customers? • How can we provide the information to international customer? • How can we deploy information and ensure link integrity over a number of Web-servers? • How can we easily restructure the whole site? • How can we ensure the development of corporate identity (logos, fonts, table-forms, presentation-styles and other) pages? In short, how can we manage large-scale Web Services? We address some of these questions by analyzing the problem area, finding a solution through abstraction and using the WebComposition method and high-level hypertext functionality to provide a maintainable web service. We refer to this web company scenario throughout this paragraph. We begin with analyzing and abstracting of what is provided by the company. The next sections cover issues concerning management and creation of many components with abstraction to business and logical units. 5.2. SERVICE The company´s web-site provides different products, news, manuals, stock information etc. to customers and employees. We can think about each product, news item etc. as a service that the company provides. For instance manual writer can use one service (manual-service) to provide different manuals to customer. We can also go one step further and use the same service to provide company- and stock-information even if the layout might not be the same but use the same functionality for providing information. Furthermore selling of products and download of updates for registered
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
5
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
users may be implemented as the same service as it uses nearly the same workflow. With this point of view we can say that e.g. each extra software-tool (add-on) for an existing product is provided as a company’s service. This definition allows defining a workflow, which automates the deployment of a software add-on. The providing of a new software add-on could be done through the webapplication itself, for instance by providing a form asking for the add-on files, name, short description, used for which product, information about the addon, and installation hints (if available). After posting the information the system itself would be able to set up a new service which provides customer with the new add-on. Using the information of the posted form the service can generate semantically typed nodes and links. For instance, the add-on service could link to the product page the add-on is used for and also display installation hints (if provided) in a corporate identity way. For developer of the same group the service could also display information about who of the team created the add-on service and link to his or her homepage, even if the creator does not know about hypertext. Concepts of typed nodes and links could be simulated by a component.
0..* Component
0..1
5.3. AUTOMATING SERVICE CREATION THROUGH SERVICE FACTORY
Service {abstract} UUID Name ShortDescr
add-on Service
ManualService
The creation of an add-on service could also mean the creation of a news service, which is displayed on the homepage linking to the add-on service. The author or creator of the service does not need to know that both services are provided through different web-server. It is important to mention that the system does not only know about URLs but also about versions and semantics of data (sent by forms or tools) that allows the complete redesign of the web-application without loosing information. In summary we say a service is a logical unit or a business process defined by a set of WebComposition components and inherits the functionality of the abstract service definition as illustrated in Error! Reference source not found.. Different people like marketing-specialists, user interface engineers and page designers, do the definition of a service in cooperation with the site engineer. The site engineer will then implement the service by specifying WebComposition components using techniques like prototyping and component sharing as described in an earlier section. This concept allows the usage of CI-Components defined earlier or the reuse of special design artifacts and navigation structures. The change of design of parts or the complete web application by redesigning components is therefor possible. In the next section we will discuss the use of a developed service and show a way to automate the creation of services of the same type.
other Services
Files Hints ...
Figure 2 Service Class diagram (UML style notation)
The instantiation process of services and objects is well known and described by creational design patterns [6]. The use of creational design patterns make a system independent of how its objects are created, composed, and represented. In the WebComposition system we use the prototype design pattern for the instantiation of components. A typical scenario is, when a developer-team wants to provide customer with a new add-on for a CASE-Tool. The CASE-Tool add-on should be provided as a download service and a news-service on the homepage should inform customer about the add-on by linking to the download page. In this scenario the responsible person fills in the important information about the add-on using a web-form, which posts the information to a cgi-application.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
6
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
In other words, the responsible person uses a special service (the web-form and the cgiapplication) to instantiate some other services (one news-service and one download-service). This service is especially responsible for the following scope of duties: • Service creation (what gets created by the information provided, how, where, and when it gets created) • Hypertext functionality (automated linking from news-service to download-service) • Corporate-identity (using one defined design for news on the homepage and one for downloads of the company´s CASE-Tool) • Content-deployment (for faster and better access the company provides their information on servers in the United States, Europe, and Asia) We call services of this type a service factory in dependence on the factory design pattern. Service factories have knowledge about the concrete infrastructure of the system (classes, databases, webserver etc.). The user instantiating a service with a service factory does not necessarily need to know how the created service is provided, e.g. using pure HTMLresources, a database, an XML-based solution or WebComposition components, to fullfil its duties. This yields the possibility for service factory developer who are probably site engineers or their assistants, to manage the overall content of the site. The definition of a service is a logical unit or a business process defined by a set of WebComposition components, as mentioned earlier in this section. Therefor a service factory in our system creates a set of WebComposition components based on prototypes. The following diagram Figure 3 shows the creation of a service and the impact on the component store. In this process the add-on service prototype as well as components for the corporate identity design of the pages and international language support are used.
Text-Content: English Manual
Service {abstract}
CompanyCI: PageLayout
UUID Name ShortDescr
Table Width=60% FontFace=Arial
add-on Service: English-Help
Use of Factory
Component Store
Text-Content: English Manual
Service {abstract}
CompanyCI: PageLayout
UUID Name ShortDescr
Table Width=60% FontFace=Arial
Text-Content: German Manual
add-on Service: English-Help
add-on Service: German-Help
Component Store
Figure 3 State Diagram for service-factory (UML style notation)
Naming a service lets us talk about them with all the people relate to the web-service, like site engineers, designer, content provider, hypertext specialist and so on. Like the name of a design pattern we can use the name of a special service (like news-service, add-on service in our scenario) to describe solutions for business process problems. Furthermore a site engineer can provide a catalogue or a repository of service factories describing their names, explaining when and in which problem context to apply. Other descriptions like general conventions for wording, components that make up the design, design alternatives could also improve business model and management of a large-scale web service. 5.4. MANAGING A SERVICE-COMPONENT ORIENTED SYSTEM When content provider use service factories frequently a new problem arises. The problem scope is maintenance and management of a large number of services. In this section we describe a solution using WebComposition for managing servicecomponent oriented large-scale web services by organizing services and automating recurrent tasks.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
7
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
The component server provides access to components in the component store. As all services, that means service factories and their instances are modeled as sets of components, we can provide tools not only for accessing and manipulating components, but also for the more coarse-grained servicecomponents. By examining the component store for service-components we can generate a business oriented view of the server, like number of services or evaluate service usage by user profiling (based on web-server log-files). An overall view on the system is especially important if there is a group of site engineers that has to coordinate their work. A "repository-view" on the component store, especially a view on all factories with descriptions of purpose, helps to maintain the logical evolution of the web site services. Changes of navigational structure, design and so on can be managed by accessing the components either identified by their containment in services, their name or description. In summary it has to be noted, that the WebComposition maintains a web application model equally useful for design, run time management, and maintenance. Using service factories to produce services (sets of WebComposition components) it is possible to simplify or automate development tasks. The transition from development to operation or from management to operation is smooth as the development model (components) can be mapped incrementally to operation model (resources). The consistent evolution of component structure can be managed due to definition of business or logical units in the same model. The transition from operation to maintenance and back to operation is virtually eliminated by tightly coupling the underlying models.
6. STATUS OF THE WEBCOMPOSITION SYSTEM A first prototype of the WebComposition system has already been fully implemented and used for support of a web application. The prototype operates in a heterogeneous environment with an SQL-Server based on Windows NT and a web-server running on Unix. In a project between TecO and Daimler-Benz Research this prototype was extended and we investigated the usability of the system in a largescale Intranet service. Within this project a component editor and a management tool have be
implemented as part of the WebComposition system. In cooperation with Hewlett-Packard, IT Service Center, Germany we developed a large-scale Intranet-application using the WebComposition approach. The system is operated by the Service Center and integrates an increasing number of webbased services provided by different business units in Germany and parts of Europe. The management of the application is done in terms of services and service factories. In this large-scale real world application we can demonstrate that the effort needed to maintain and manage the system, compared to the situation before using standard web technologies and tools, is considerably reduced.
7. SUMMARY AND FUTURE WORK With WebComposition webs are modeled in terms of components of arbitrary granularity. Components capture web entities for reuse, sharing and localization 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. In this paper, we deployed the object-oriented WebComposition model with object-oriented design patterns as pioneered by the gang-of-four [6]. We demonstrated the use of a service-oriented abstraction for a certain class of WebComposition components. By grouping these components to a service we could show the automatic service creation using service factories. Furthermore we explained how the service abstraction enhances the development of reusable hypertext structures and the management of large-scale web services. Further work on the WebComposition system will address system maintenance and usability and especially further research into disciplined web engineering. As for usability, we introduce the webcomposition markup language (wcml) based on XML [3] to achieve a maximum of flexibility and easily integrate WYSIWYG-editors and the like with the component model. For maintenance and automating web service evolution we are exploring the use of design patterns in the context of a disciplined web engineering approach. For this reason we are also investigating higher-level
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
8
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999 Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
abstractions on top of the WebComposition component model with the goal of integration with existing hypertext, information system and general software design methods.
8. REFERENCES [1] T. Berners-Lee, R. Cailliau, A. Luotonen, H.F. Nielsen and A. Secret. The World-Wide Web. Communications of the ACM, 37(8), 1994. [2] M. Bieber, F. Vitali, H. Ashman, V. Balasubramanian, H. Oinas-Kukkonen. Fourth generation hypermedia: some missing links for the Worls Wide Web. International Journal of HumanComputer Studies. Academic Press Limited, 1997. URL: http://ijhcs.open.ac.uk/bieber/bieber.html [3] T. Bray, J. Paoli, C. M. Sperberg-McQueen. Extensible Markup Language (XNL) 1.0 Specification. World Wide Web Consortium, Februar 1998. http://www.w3c.org/TR/REC-xml [4] 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.1 87/paper/187.html [5] FrontPage Home Page, Microsoft Corp., URL: http://www.microsoft.com/FrontPage/ [6] E. Gamma, R. Helm, R. Johnson and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.
[7] H.-W. Gellersen, R. Wicke and M. Gaedke. WebCompostion: an object-oriented support system for the Web engineering lifecycle, Computer Networks and ISDN Systems 29 (1997), p. 14291437. URL: http://www.teco.edu/~hwg/www6/PAPER232.html [8] F. Halasz and M. Schwartz. The Dexter Hypertext Reference Model, Communications of the ACM, February 1994. [9] T. Isakowitz, E.A. Stohr and P. Balasubramaninan. RMM: A Methodology for Structured Hypermedia Design, Communications of the ACM, August 1995. [10] NetObjects Home Page, URL: http://www.NetObjects.com/ [11] The Open Group. "Universal Unique Identifier. Appendix CAE Specification C706." DCE 1.1: Remote Procedure Call, 1997. URL: http://www.opengroup.org/ [12] Darrell Sano. Designing Large-Scale Web Sites. Wiley Computer Publishing, 1996. [13] 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/Over view.html [14] Rational Software. Unified Modeling Language, version 1.1. http://www.rational.com/uml/ [15] D. Ungar and R.B. Smith. Self: The Power of Simplicity, OOPSLA ’87 Proceedings, p. 227-42, 87. [16] World-Wide Web Consortium. XML: eXtensible Markup Language. http://www.w3c.org/XML
0-7695-0001-3/99 $10.00 (c) 1999 IEEE
9
