A Data Mart Approach for Monitoring Web Services Usage and Evaluating Quality of Services Sérgio Manuel Serra da Cruz, Linair Maria Campos, Maria Luiza Machado Campos, Paulo F. Pires 1 Departamento de Ciência da Computação (DCC/IM) Núcleo de Computação Eletrônica (NCE) Universidade Federal do Rio de Janeiro (UFRJ) Av. Brigadeiro Trompvsky s/n Bloco C – Cidade Universitária – Ilha do Fundão – Rio de Janeiro – RJ CEP 20.001-970 – Brasil e-mail: {serra, mluiza, paulopires}@nce.ufrj.br,
[email protected]
Abstract Web servers log data constitute an important resource to track users’ activity within a Web site, especially when organized and integrated with other sources of data on the so called clickstream data marts. These data marts support flexible and complex analyses, which are the basis to obtain great understanding of customer behavior and achieve efficient operation of electronic business initiatives. With the proliferation of Web services as a new trend to enterprise application integration and interoperability, it seems natural to use a similar approach to monitor services usage and to evaluate quality of services. This paper presents a data mart proposition generated from Web services log data that can reveal usage patterns on Web services giving a highly improved understanding of behavior and service provider performance.
1. Introduction As the Internet grows and enterprises move their business to the Web, the opportunity to explore this new communication channel opens new perspectives and challenges. Monitoring customer interactions on the Web provides companies with a rich set of information, registered at Web server access logs, to complement existing customer profiles originated from other applications. Web server access logs constitute an important source of information generated by user activity. When properly explored, they can help e-business initiatives to achieve efficient operations and to obtain a better understanding of their customer behavior. As these logs comprise huge amounts of data they need special processing to actually generate useful information. The most popular approach to explore such information uses data marts built from these Web log data, also called clickstream data marts [16, 22]. In this approach, raw log data is transformed, integrated to other customer data and structured in the Data Warehouse environment to support complex and more sophisticated analyses. Several works have been conducted on the subject of Web log analyses. Such works propose log wareho using and mining strategies [18] as well as extensions to the log’s content [6, 25, 35]. They usually address consumer profile issues and QoS (Quality of Services) aspects; however, they are constrained to the boundaries of a single company. The arising paradigm of Web services is creating a new model of interaction in the Web environment, which requires richer information than that captured in the traditional 1
CAPES/Brazil grant holder
Web server log. Web services can be defined as modular programs, generally independent and self-describing, which can be discovered and invoked across the Internet or an enterprise intranet. Web services technology provides the underpinning to a new business opportunity, i.e., the possibility to provide value-added components built through the integration and composition of Web services available on the Web [10]. Web services composition is the ability of one business to offer value-added services to its customers through the combination of basic Web services, possibly offered by different companies [10, 11, 15]. Therefore, a Web services composition defines a business process that may cross the physical boundaries of a given company. The source of information of Web server logs comes from links accessed by users. Therefore, such logs are not capable of capturing more complex interactions, such as service utilization and/or composition, which are typical B2B interactions supported by the Web services technology. Moreover, the company’s Web server log ends on the threshold of its own Web site. It does not cross the firewall’s boundaries. It does not know about its partner’s services, even if it is an important part of its services, as the end customer perceives it. Therefore, there is a need of new mechanisms for capturing and logging the Web usage that considers the specific needs of the business process supported by the Web services technology. In this paper we present an approach for monitoring Web Services usage and evaluating quality of services through a Web Services Log Architecture, named WSLogA [9]. The main goal of this paper is to provide a scenario to discuss how data captured by WSLogA can be structured to support decision-making. We propose two multidimensional schemas over the WSLogA data, which allow Web administrators and marketers to take advantage of Web services log information. The first one, a generic model, will help to identify access trends, taking a comprehensive view of how Web users are interacting with the Web service and answering important questions with regard to Web services operation. The second one exemplifies one possible scenario of customer interest for products and services, and may vary according to analytical purposes. The remainder of this paper is organized as follows: in Section 2 we will discuss relevant topics concerning Web services technology, important to understand the proposed Web Services Log Architecture. In Section 3, we present this architecture, explaining its role, uses and implementation. In Section 4 we provide details on the log contents, important to give the basis to build our proposed data marts on Web services log data, presented next in Section 5. In Section 6 we present some related works and finally, in Section 7. the conclusion and future works. 2. Web Services Over the past few years, business have interacted using ad hoc approaches, which use and take advantage of Internet infrastructure. Now, Web services are emerging and promising a systematic and extensible framework for application-to-application integration, built on top of existing Web protocols and based on XML standards [33]. Web services are based on the convergence of four trends [32]: ubiquitous infrastructure, as Web services operate over the Internet infrastructure; XML, as Web services contracts are defined in XML and communications occur via XML-based messages; business standards, as in order to facilitate the interaction between companies, all cooperating parties must fully understand Web services semantics; proven approaches, because Web services incorporate aspects of middleware, i.e., they support both RPC-oriented and message-oriented system equally well.
In order to fully explore business opportunities supported by this new process model based on Web services compositions it is important to take into account two issues: quality of services requirements, which addresses administrative issues like performance and availability, and customer’s electronic behavior analysis, which addresses marketing and merchandising perspectives. Requirements regarding quality of services (QoS) offered by Web Services are referred in many works [13, 26, 27]. Among the QoS requirements proposed by Mani [26] and Menascé [27] the following are highlighted in this work due to their relevance: availability, accessibility, integrity, performance and reliability. Also, according to Myerson [28], as Web services begin to be widely used, customers will be asking for SLA (Service-Level Agreements), a formal contract between the service provider and the client, to ensure their quality. This kind of concern makes evident the importance of quality of services to customers. 3. Web Services Log Overview In this section we provide a general explanation of the Web Services Log Architecture, presenting the different views it addresses, some important analyses that can be made based on Web services log data, and an overview of the architecture’s implementation. This explanation will be useful to understand the main contribution of WSLogA towards our Web services data mart proposal. 3.1. Roles in Web Services Log Analysis Considering the interaction model of a business process based on Web services compositions, we have defined four roles in which Web services log analysis can be useful: the first is the customer of the Web services composition who benefits from the composed Web service; the second is the composite Web services provider which publishes services accessed by customers. The composite Web services provider uses basic services provided by third parties. The third role is represented by the third parties and is known as the basic Web service provider, it provides the basic services used by the composite Web services provider. The last role is called WSLogA probing authority and it is responsible for testing Web services QoS features. Such role may be implemented by third parties or locally at the composite Web services provider, or yet at the basic Web services provider [9]. Web services log analysis may accomplish two goals. The first is to supply integrated business process view towards client personalization. The second is to support services quality monitoring. It is important to emphasize that the composite and the basic Web services providers may be interested in both goals. They may assume different points of view towards Web services analysis, depending on how they need to face it. The former, for example, may be willing to know his customer profile while the latter is more concerned with performance and availability issues. However, the basic Web services provider may also be commercializing a product, as, for instance in Amazon.com [1]. Amazon provides Web services that may be used to search for products on its Web site, but Amazon also sells these products. In this case, besides service performance, it is also desirable to monitor the products selling rates. It is important thereafter to identify these points of view, as they serve to organize which set of data is important to log, facilitating the dimensional modeling design for further analyses, adapting it to different needs.
3.2. Web Services Log Analysis One of the uses of Web services log analysis is the ability to foresee the big picture of service composition. For instance, suppose a tourism Web site is offering a car rental service. Moreover, consider that such a service is actually provided by a partner of the tourism Web site. Customers of the Web site may frequently make use of the car rental service or they may often leave the site without renting cars. If the manager of the tourism Web site knows about such customer behavior, he can determine if the car rental is a profitable service or if it does not aggregate any value to the business. Besides, it is also important to monitor the quality standards of aggregated services. Customers may abandon the site due to third parties bad response times or availability issues. For instance, customers of the tourism Web site may decide to choose another site if they want to rent cars but the car rental service is often unavailable. Monitoring Web services log may also detect and prevent server bottlenecks. Through Web services logs analysis a Web services client may check QoS as exemplified on the following table, and intervene if necessary (see Table 1). Table 1. Some interventions based on Web services log analysis OCCURRENCE INTERVENTION There is no log entrance for a given service on a Verify the service availability and accessibility. If no given time interval. problem is detected and the situation remains, it is important to verify why the service is not being used. Service requests are higher at a given time of Call service with higher priority at this time. the day. Service response time is higher than expected. Verify network status and services number of accesses. If higher times persist, may be a hint to review load balancing on servers or contact service provider.
Web services log analysis can also be used to support dynamic Web services composition when associated to private Web services registries, in which user identification mechanisms are provided. Web services registries are infrastructures which store information about Web services providers and Web services. The use of the identification mechanisms in these registries is important to provide consistent user identification and tracking throughout associated log entries. The Web services standard for registries is the UDDI (Universal Description Discovery and Integration) [30], which lacks discovery features based on QoS requirements. Although log features cannot solve description issues related to service discovery, it does provide monitoring and auditing mechanisms that may support business partner selection concerning QoS requirements, as long as the registry supplies a pointer to a document describing the service QoS capabilities. Besides QoS aspects there are also other kind of information that can be logged such as data obtained from service call. Consider, for example, our car rental Web services. It might be useful to know, according to our customers’ preference, which car models are most rented, how long do they stay with the car, and how much they are willing to pay. In order to succeed on the Web services log analysis these data should not be ignored. It is worth noting that in traditional Web server log approaches this kind of information is not available, because they do not capture details of service execution, just registering the service call. 3.3. Web Services Log Architecture There are at least two ways to implement a Web services log. One of them is changing the source code of each service in order to call another service or component,
responsible for logging. However, this solution has a main disadvantage: we do not have ownership over third parties’ code and we cannot guarantee they are willing to change it on someone else behalf. Furthermore, modifying existing application may be time consuming and error prone. The other alternative is the use of SOAP (Simple Object Access Protocol) intermediaries [17]. Although the use of SOAP protocol is not mandatory on the Web services architecture, it is by far the most used message protocol by now, due to its ubiquitous presence over the Web. A SOAP intermediary is an application, possibly a Web service, that is capable of both receiving and forwarding SOAP messages and that makes additional processing before or after forwarding the message to its destination. The use of a SOAP intermediary to implement Web services log prevents us from changing the service code, providing independence and flexibility on log management, allowing a log structure to be adapted according to eventual new business needs without modifications on the existent Web services [14]. Another important feature of SOAP intermediaries is that they can deal with optional SOAP headers, which encapsulate extensions of the message format, without having to modify the structure of the SOAP message. SOAP headers may allow extensions like encryption, object references, transactions, billing, authentication, and so on. Those extensions may also be stored at the Web services log for further OLAP processing. The drawbacks of this approach are related to transaction control and security issues like the reliability of the Web services provider who interacts with intermediaries. Security issues are of prime importance whenever intermediaries are involved, because they are vulnerable to malicious attacks, as, for instance, the interception of a message by unauthorized users, which may modify the contents of SOAP headers. For these reasons it is important to assure that intermediaries make use of security mechanisms, such as encryption and digital signatures, in order to minimize these concerns. Moreover, transactions control is equally important because it is necessary to guarantee that the transaction context is preserved propagated as a whole through all the intermediaries, with no errors or breaks, to ensure correct execution of a request [19]. WSLogA makes use of SOAP intermediaries, providing mechanisms for recording a rich set of information on the usage of Web services. Through the WSLogA log it is possible to store Web services input and outputs like the following: billing, identification, authentication, payment processing, etc. Moreover, data concerning the service usage can be recorded, such as: response time and total resource usage of a service for a specified user. The latter category of data can ensure appropriate QoS levels for different applications and customers. For instance, a multimedia Web service might require a throughput and bandwidth, while a banking Web service might require security and transactional QoS. WSLogA is composed of four main components: SOAP handlers, a flat log file, log configuration parameters and a probing authority. SOAP handlers are the implementation of SOAP intermediaries and are used to provide the underpinning to a flexible log generation, once they ma y intercept the SOAP message on different sides (basic Web services provider, composite Web services provider and probing authority) adding layers of different kind of information, captured on each side, to the log file. The log file is a flat ASCII file. Its format is similar to Web server log files, as those are also flat ASCII files generated periodically and their structure is composed of records with fields. Log contents are recorded by handlers, and may vary according to the SOAP message content intercepted by the handler. Details of the log contents are provided in section 4.
Log configuration parameters are provided as an XML file and contain data such as log name, date time format, probing interval (e.g., to call a service every hour), probing frequency (e.g., to do probing every day, or to do probing on Mondays), probing authority (e.g., the URL of the probing service) and date time referee which states the date time used to register standard date and time measures. The probing authority is a third party responsible for providing and managing probes related to Web services being monitored under its responsibility. Probes are special Web services that, from time to time, call another services to test their QoS features like availability, reliability and performance (response time, process time etc), tagging their log entries as a special customer. It is important to remind that the log may lay at the basic or the composite Web services providers, while handlers must be located on both service providers as well as on the WSLogA probing authority. The later may be used as trusted probing referee, providing reliable QoS metering and a standard time. Our proposal is focused on composite service provider analysis. Therefore, in this particular case, the lo g is located on the composite service provider side.
Figure 1. WSLogA architecture.
4. Web Services Log Contents Users of Web services may have quality as well as business requirements. Table 2 gives us a summary of the most important user requirements as well as the metrics and log fields used to support them. In Table 2, the term service refers to the Web service method called. In related log fields, “service name”, “service calling date/time” and “user identification” are always considered, because requirements always involve a period of time, a user and a service. Based on surveyed user requirements [24, 26, 27], our Web services log contains the following data: user identification, message request date/time, message request arrival date/time, message response date/time, service execution begin date/time, service execution end date/time, soap fault code, soap fault actor, detailed error data, service name, service method name, service instructions (e.g., priority and security level), service input parameters, security attribute, priority attribute, soap response message size, product requested (if it is the case), service response code, service response description. The security attribute is used to indicate if a service may be called optionally in a secure mode instead of its default non-secure mode. Similarly, the priority attribute is used to indicate if a service may be called optionally at a higher priority instead of its default priority level.
Table 2. Web services users’ requirements REQUIREMENT REQUIREMENT METRICS TYPE DESCRIPTION CONSIDERED Frequency of use Service use frequency. Number of non probed calls Periods of greater service divided by time interval use. Average SOAP message size Periods of greater data traffic. Availability Time percentage in which Number of well succeeded the service is available probed requisitions divided by probing time interval Reliability Percentage of well Number of well succeeded succeeded requisitions probed requisitions divided by total number of probed requisitions in a probing time interval Security Percentage of secure Total number of non probed services by security level secure services’ requisitions of Percentage of non secure a given level divided by total services number of non probed secure services’ requisitions Priority Percentage of priority Total number of non probed services by priority level priority services’ requisitions Percentage of non priority of a given level divided by total services number of non probed priority services’ requisitions Response time Time spent by the message Response sending minus in the service provider. request arrival date/time. Process time
Time spent by the service to Beginning execution date/time accomplish its task in a minus Ending execution given time interval date/time
Marshalling time
Time spent in marshalling and unmarshalling SOAP messages.
Time between requisition arrival and service call plus time between service response and sending response to solicitant.
Latency time
Time spent by the message transiting over the network to reach its destination.
Time between sending a requisition by a solicitant and its response arrival * 2
Customer profile
What products are purchased most frequently Percentage of Sales of promotion products Percentage of Sales per product What products are selected most frequently Percentage of searches of promotion products
Product code count Total product count Selling product code count Total selling product count Searching product code count Total searching product count Product price Product selling price Status of service response
RELATED LOG FIELDS 2 SOAP response message size SOAP response message date/time SOAP response message date/time and status SOAP response message date/time and status
Security level Security attribute (Indicates if service may be invoked in secure mode) Priority level Priority attribute (Indicates if service may be invoked in priority mode) Service request arrival and response sending date/time Beginning execution date/time Ending execution date/time Requisition arrival date/time Service response date/time Solicitant response sending date/time Solicitant response sending date/time Solicitant request sending date/time Product code Product selling price Status of service response Type of product request (indicates if the user request is for searching or buying the product)
These data are comma separated. Some of them are optional, as, for instance, fault code and fault actor, and some of them are composed data, as, for instance, service input 2
(besides service name, calling date and time, and user id)
parameters. Composite data units are separated by semicolons, and some of them, specially detailed error data and service instructions, can be used to obtain extended information on log registers. WSLogA uses SOAP headers to get those extended information, if available, and expects them to be in special tags. Detailed error data must come within optional tag, and are defined by the service’s provider. They may be used to provide detailed information about eventual failures due to service abnormal behavior or network problems. Service instructions may be used to provide additional information concerning service use context and must come within optional tag. One example of special instruction is the priority instruction, which may be used to register that the service was called with special priority. Another special instruction tag is the product instruction. Product requested information is optional and may be used when the caller is interested in product tracking. In this case it must come within the tag. This tag contains five other child tags: , , , and . If the product tag is present, all its child tags are optional, except . Note that product may not only be a good but also a service accomplishment like NASDAQ stocks information for instance. It is important to understand, though, that these tags are extension mechanisms and each provider must deal with them according to its own needs, that is, further log analysis must consider or not these log entries, if available, and deal with them accordingly. Also, many of them (e.g., product) will be present only if the service requestor provides them in the SOAP header of the service call. 5. Data Marts on Web Services Log Data Many analyses may be supported by Web services log data marts. Our purpose is to provide a general model for monitoring QoS, like performance and availability. This is represented in the star schema illustrated in Figure 2. This schema may be extended according to user needs, including additional information such as service reputation (used to obtain basic insights about the user experience dealing with the Web services), and may vary according to many different industry domains, such as: financial, retail, banking, manufacturing and others. In this paper we provide a simple example useful for monitoring sales as illustrated in Figure 3. From Web services log data, ETL (extraction, transformation and loading) processes may populate a Web data mart. In our example, this data mart may be used for two goals: Web services administration and products sales analysis. For this we provide two fact tables, with some shared dimensions. Table 2 illustrates some relevant questions that need to be answered when monitoring Web services QoS. The data mart may be of great help in this case, once we provide the proper dimensions. This will be discussed in more detail in the next topics. 5.1. Monitoring Web Services Quality of Services Different variables may be analyzed concerning QoS, such as Response_Time, Message_Size and Initialization_Time. These variables are derived from Table 2 and represented on the administration fact table in Figure 2.
Figure 2. Web services log data mart – Administration.
Different dimensions may be used to provide consolidated analyses upon these variables. The Status dimension supports queries concerning reliability and availability. For example, selecting the total amount of services requisitions in May, 2003, by Web service’s method which ended with a Status different from “OK”, divided by the total amount of services requisitions (by Web service’s method) in May, 2003, gives us a Web service’s method reliability indicator. This information may be used as basis for Web services code maintenance. Note that we have included a service requisition attribute in the fact table, just for convenience, for the sake of SQL queries readability, as suggested by Kimball [19]. Its value is always 1. The Origin dimension supports queries concerning service misuse. For example, if the total amount of a Web services requisition from a given origin in an hour is much larger than the others, it may be someone, by mistake or not, repeatedly calling the service in a loop. This information may be used for user suspension or warning. The Date and Time dimensions are self-explanatory and should be used in conjunction with others, to limit the scope of analysis in time. The Web service dimension is the main dimension for this data mart and supports the other dimensions involved in the analyses. It is useful for providing comparative performance information when used with the Web service Host dimension. We can have, for example the average response time by Web services host as a hint for possible poor Web services performance. If one Web services host average response time is far above the others and all the Web services from the same host have approximately the same average response time, perhaps we should blame the Web services host and warn the Web services provider. This might be especially useful if we were logging Web services calls at the basic Web services provider.
The Method dimension defines the grain of the QoS analysis; it should be used in conjunction with the other dimensions. Method’s version control as well as Web services version control is important as they are slowly changing dimensions [20], and we should be interested in monitoring eventual performance deterioration or improvement due to new service’s versions. The Priority dimension may be used in conjunction with Date and Time dimensions to analyze if a Web services method called with priority has improved performance times, compared with the same services method non-priority calls. It is important to observe that priority calls usually have higher prices. 5.2. Monitoring Sales Our products sales fact table considers two variables: Selling_Price and Product_Sales, as illustrated in Figure 3. These variables will vary according to the domain being analyzed as discussed before. Also, different dimensions may be used to provide consolidated analyses upon these variables. The Origin dimension may provide answers concerning customer profile. For example, which customers spent most. This information may be used fo r customer’s special treatment as, for instance, Web service’s method call with priority when a profitable customer is involved. The Web service dimension is useful for providing comparative selling information when used with the Product dimension. We can have, for example, that a Web service of a given category is linked to low selling rates. Tabulating this information with other information provided by the QoS dimension, like the service provider, may indicate a reason to change the Web services by another, perhaps from other basic Web services provider. Note that we have included the product_sales attribute, whose value is also always equal to 1, as we did on the administration fact table.
Figure 3. Web services log data mart – Product Model.
The Causal dimension may provide hints to indicate the cause which lead the customer to buy the product. Causal dimensions were first proposed by Kimball [21]. Although we cannot assure which was the real cause, we can at least estimate. For example, if a product has a price discount in June, this may be a good reason to justify its good selling performance in that month. Also, if a product may be purchased in ten installments with no interest taxes in May, as its payment type indicates, this may lead to product selling increase. Besides, if the product has been advertised in the Web page or on the newspapers, and the product selling increases, this may indicate that the advertisement succeeded. Another selling’s increase may come from packages, i.e., when two products are sold together. For the sake of simplicity we don’t track here which products are combined in the sale. The Product dimension actually defines the grain of the sales fact table, and is the basis of detailed analyses that most of the times involve other dimensions. The Web Page dimension provides information about the product’s context of acquisition. We assume that products may be acquired in more than one page. This dimension may help answer the question: “In which page a product has better sales?”. 6. Related Work Current Web site data collection methods and analyses rely primarily on Web server logs. Traditionally this source of information was used to ensure smooth site maintenance or operation, monitor Web traffic and inspect possible bottlenecks to meet customer demand and response times. However, at least three problems arise with the use of Web server log data: colossal volumes of data, incomplete or redundant data and lack of integration with non-Web data [18]. To address those problems there are tools tailored to deal with this kind of data [22, 23]. However, those tools are based on statistical analysis and their reports are not flexible enough to cover user profiles or user loyalty. Web log data can be explored to offer much more than Web statistics; complemented with further data they become an important source of information for decision making. Up to now few works have been conducted on logging and analyzing Web services usage information. Akkiraju et al. [3] proposed a framework blend ing logging facilities to private Web services registries. However, no details are provided about the log structure or how to implement it. Irani [17] proposed the use of intermediaries to provide information about authentication, auditing and management of services through the use of logs, but he also does not provide any detail on the log structure. Azevedo [4] proposed a Web services log model based on XML to monitor Web services execution. However, the log granularity is inadequate because it records consolidated data making it harder for dimensional analyses. 7. Conclusions and future work Web services are a new paradigm, which facilitates the development of business process based on services available on the Web. The Web services technology is new and still maturing. Currently, it is lacking adequate mechanisms to monitor their usage. Our work extends the current Web services technology, providing the necessary mechanisms for logging and monitoring Web services. In it, we have implemented a Web services log on the composite service provider side, using Axis and Tomcat [34], to keep track of a set of Web services performance.
WSLogA specifies a generic architecture for logging Web services usage. Through the WSLogA log it is possible to build different data schemas over which different analysis needs can be addressed. In this paper we presented a Web services log model and a generic dimensional model, based on log data, to analyze quality of services. This model may be extended to analyze commercial aspects according to different industry domains and multidimensional structuring is a natural candidate in Web services utilization data mart. As an example we provided a simple dimensional model to analyze products selling offered on a Web site. With this model we have shown that it is possible to extract relevant information from the Web services log, that are not possible to be extracted from existing Web servers log, such as marshaling and initialization times, or even product sales data. We also have shown that this information may be extended, according to user needs, through the addition of new dimensions and associated facts, providing a flexible and powerful mechanism of Web services analysis, addressing administrative as wells as commercial interests. To the best of our knowledge, no Web services model has been proposed to address the different needs of Web services analysis. In this work we have proposed such model, which may be used as grounds for further efforts concerning Web services log standards. Future works may explore Web Services log data marts used in conjunction with other data marts in data warehouse bus architecture (as proposed by Kimball). They should be compatible with the existing conformed dimensions, such as, product, time, and date. Also, according to Burt et al., QoS is important to enable timely, or even dynamic, composition of e-business initiatives; for example, to select a replacement component when a primary component fails to deliver QoS guarantees [8]. Through Web services log we are able to extract QoS indicators such as: mean response time, mean time between failures and availability. Analytical processing may be responsible for dynamically updating these data on the document describing services QoS capabilities, and this document may be used as grounds for choosing one service instead of other. References 1. AMAZON.COM Homepage. Available at http://www.webservices.org/index.php/article/view/959/. Last access: 02/20/2003. 2. Andresen, J., Larsen, R. S., Giversen, A., Pedersen, T. B., Jensen, A., Skyt, J.: Analyzing Clickstream Using Subsessions, Third International Workshop on Data Warehousing and OLAP, Washington DC, USA, November 2000, Proceedings, pp. 2532. 3. Akkiraju, R., Flaxer, D., Chang, H., Chao, T., Zhang, L., Wu, F., Jeng., J. A Framework for Enabling Dynamic e-Business Via Web Services. Available at: www.research.ibm.com/CoopDS/OOPSLA2001.pdf. Last Access: 03/22/2003. 4. Azevedo JR, V., Webtransact- EM: a model for dynamic execution of semantically equivalent Web services. Master Thesis UFRJ, COPPE, 2003. From the Portuguese: Webtransact-EM: um modelo para execução dinâmica de serviços Web semanticamente equivalentes. 5. Berendt, B., Spiliopoulou, M., Nakagawa, M. Wiltshire, J.: Measuring the Accuracy of Sessionizers for Web Usage Analysis, Web Mining Workshop at the First SIAM International Conference on Data Mining, Chicago, USA, April 2001, Proceedings, pp. 7-14. 6. Bonchi, F., Giannotti, f., Gozzi, C., Manco, G., Nanni, M., Pedreschi, D., Renso, C., Ruggieri, S.: Web Log data Warehousing and Mining for Intelligent Web Caching. Elsevier, Data & Knowledge Engineering 39, 2001, pp. 165-189.
7. Bucklin R. E., Lattin, J. M., Ansari, A., Bell, D., Coupey, E. Gupta, S., Little, J. D. C., Mela, C. Montgomery, A. Steckel, J. Choice and the Internet: From Clickstream To Research Stream. Marketing Letters, 2002,Vol. 13, No. 3, pp. 245-258. 8. Burt, C.C., Bryant, B. R., Raje R., R., Olson A., Auguston M.: Quality of Service (QoS) Standards for Model Driven Architecture, Southeastern Software Engineering Conference, Huntsville, Alabama, USA, April 2002, Proceedings, pp. 521-529. 9. Campos, L. M.; Cruz, S. M. S.; Campos, M. L. M.; Pires, P. F. WSLogA: A Web Service Log Architecture Based on SOAP Intermediaries. Rio de Janeiro: NCE/UFRJ, 2003. 5p. (Technical Report, 02). 10. Casati, F., Ilnicki, S., Jin, L., et al.: Adaptive and Dynamic Service Composition in eFlow, 12th International Conference on Advanced Information Systems Engineering, Stockholm, Sweden, June 2000, Proceedings, pp. 13-31. 11. Casati, F., Shan, M., Dynamic and adaptive composition of e-services, Information Systems, 2001, v. 26, n. 3, pp. 143-163. 12. Chatterjee, P., Hoffman, D., L., Novak, T. P., Modeling clickstream: Implications for Web-Based Advertising Efforts. Working Paper, May 1998, Vanderbilt University, Nashville 1998. 13. Conti, M., Kumar, M.: THEME II: Web Services, Collaboration, and Workflow Quality of Service in Web Services, 34th Annual Hawaii International Conference on System Sciences, Hawaii, USA, January 2001, Proceedings, Vol. 9, pp. 03-06. 14. Graham, S., Simeonov,.S, Boubez, T., Daniels, G., Davis D., Nakamura Y., Neyama., R., Building Web Services with Java: Making Sense of XML, SOAP, WSDL and UDDI. 1 ed., SAMS, 2001. 15. Heuvel, W., Yang, J., Papazoglou, M. P.: Service Representation, Discovery, and Composition for E- marketplaces, 9th International Conference Cooperative Information Systems, Trento, Italy, September 2001, Proceedings, pp. 270-284. 16. Inmon, W., H., architecture for managing click stream data. Available at: http://www.billinmon.com/library/whiteprs/clickstream.pdf. Last access 08/10/2002. 17. Irani, R., Web Services Intermediaries – Adding value to Web Services. Available at: http://www.Webservicesarchitec.com/content/articles/irani07print.asp. Last access 09/28/2002. 18. Joshi, K. P., Joshi, A., Yesha, Y., Krishnapuram, R.: Warehousing and Mining Web Logs, 2nd ACM Workshop on Web Information and Data Management, Kansas City, Missouri, USA, November 1999, Proceedings, pp 63-68. 19. Kimball, R., Factless fact Table, DBMS Online September 1996. Available at: http://www.dbmsmag.com/9609d05.html. Last Access 04/29/2003. 20. Kimball, R., Slowly Changing Dimensions, DBMS Online April 1996. Available at: http://www.dbmsmag.com/9604d05.html. Last Access 04/29/2003. 21. Kimball, R., Causal (not casual) dimensions, DBMS Online November 1996. Available at: http://www.dbmsmag.com/9611d05.html. Last Access 04/29/2003. 22. Kimball, R., Merz, R., The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse, 1 ed., New York, USA, John Wiley & Sons. 2000. 23. Kohavi, R.: Mining E-Commerce Data: The Good, the Bad, and the Ugly, 7th ACM International Conference on Knowledge Discovery and Data Mining, San Francisco, California, USA, August 2001, Proceedings, pp. 8-13. 24. Kumar M., Rangachari A., Jhingram A., and Mohan R.: Sales promotions on the Internet. 3rd Usenix Workshop on Electronic Commerce, Boston, Massachusetts, USA, August 1998, Proceedings, pp. 167-176.
25. Lee, J., Podlaseck, M.: Visualization and Analysis of Clickstream Data of Online Stores for Understanding Web Merchandising, Electronic Commerce and Web Technologies, First International Conference, London, UK, September 2000, Proceedings, vol. 1875, pp. 145-154. 26. Mani, A., Nagarajan, A., Improving the performance of your Web services. January 2002. Available at: http://www-106.ibm.com/developerworks/library/ws-quality.html. Last access: 02/03/2002. 27. Menascé, D. A. QoS Issues in Web Services, IEEE, Internet Computing November/December 2002, Vol. 6, No. 6, pp. 72-75. 28. Myerson, J. M., Guarantee your Web service with an SLA – Introduction, architecture, and testing mechanisms. Available at: http://www-106.ibm.com/developerworks/Webservices/library/ws-sla/. Last access 02/10/2003. 29. SOAP - Simple Object Access Protocol (SOAP) 1.1. W3C Note 08 May 2000. Available at: http://www.w3.org/TR/SOAP/. Last access 12/20/2002. 30. UDDI – UDDI Technical White Paper. Available at: http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf. Last access 02/20/2003. 31. W3C - World Wide Web Committee Web Usage Characterization Activity. W3C Working Draft: Web Characterization Terminology & Definitions Sheet. Available at: http://www.w3.org/1999/05/WCA-terms/ 32. Vinoski, S., Where is the Middleware? IEEE Internet Computing, pp. 83-85, March 2002. 33. W3C (World Wide Web Consortium) Recommendation, Extensible Markup Language (XML) 1.0 (Second Edition). Available at: http://www.w3.org/TR/REC-xml, October 2000. Last access: 03/01/2003. 34. XML APACHE GROUP, “The Axis Project”. Available at: http://xml.apache.org/axis, 2002. 35. Zaïane, O. R., Xin, M., Han, J.: Discovering Web Access Patterns and Trends by Appling OLAP and Data Mining Technology on Web Logs, Advances in Digital Libraries Conference, Santa Barbara, California, USA, April 1998, Proceedings, pp. 19-29.
