Ikram Chabbouh

Mesaac Makpangou

FRACS : A Hybrid Fragmentation-Based CDN for E-commerce Applications FRACS : un CDN Hybride pour les Applications de Commerce Electonique Base sur la Fragmentation

Keywords: CDN, Web Applications, Dynamic content, cache and replication CDN, Applications Web, Contenu dynamique, cache et replication

In order to accelerate access to Web applications, content providers are increasingly relying on Content Delivery Networks. Currently, CDNs serve the dynamic content from the edge in two major ways : page assembly or edge computing. Page assembly assumes that the proportion of cacheable content is high, that the cached fragments are reusable and that they do not change very often, while edge computing generally assumes that the whole application is replicated on the edge, which is not always suitable. Besides, current CDNs do not provide a means of scaling the database component of a Web application. In this study we propose a hybrid CDN called FRACS which combines both page assembly and edge computing in order to address the needs of relatively static applications as well as more dynamic applications. FRACS automatically determines the replicable fragments of a Web application, then it modifies the application's code so as to generate fragmented pages in ESI format and to enable the server to serve the fragments separately. Moreover, FRACS maintains the consistency of all the manipulated fragments. Using the TPC-W benchmark we were able to achieve up to 60% savings in bandwidth and more than an 80% reduction in response time.

I. INTRODUCTION

A Web application is an application which produces dynamic content through the use of server side processing. In this paper we are particularly interested in Web applications which are written in common scripting languages (PHP, JSP, ASP etc.), and which make use of a backend database. It goes without saying that the generation of dynamic content comes at a cost, a performance cost. In order to accelerate access to Web applications, content providers are increasingly turning to content distribution technologies, namely CDNs (Content Delivery Networks). A CDN is "a dedicated network of servers deployed throughout the Internet that Web publishers can use to distribute their content on a subscription basis" . The main benefit of a CDN is to enable rapid, reliable retrieval from any end-user location by replicating the content of customer Web sites and serving it to clients from nearby servers. Currently, CDNs serve the dynamic content in two major ways :

-Page Assembly : the page is constructed by aggregating its corresponding fragments on the edge servers.

In this case, the edge servers do not generate the fragments, they simply cache those which have been generated by the origin server ; -Edge Computing : the page is computed on the edge by replicating or migrating the application's code (and possibly data) on the edge servers. Both approaches have advantages and drawbacks and each one targets a certain class of applications. Reusing cached fragments of a page reduces its generation time as the overhead of generating the existing fragments is eliminated. But caching the fragments assumes that the proportion of cacheable content is high, that the cached fragments are reusable and that they do not change very often. For applications that do not meet these assumptions, replicating the application turns out to be a more effective alternative than caching. However, due to security and privacy concerns most web applications as well as their back-end databases (if any) cannot be cached entirely. Moreover, maintaining the consistency of all the application data is likely to be a significant problem. Besides these limitations, current CDNs do not provide a means to scale the database component of a Web application. Hence, the CDN solution is not sufficient when the database system is the bottleneck [START_REF] Manjhi | Simultaneous scalability and security for data-intensive web applications[END_REF]. To sum up, fragment caching is best suited to relatively static applications, while edge computing is more appropriate for highly dynamic applications. Nonetheless, it is seldom possible to replicate the whole application on the edge of the network, and to the best of our knowledge there is no tool which automatically determines the replicable code fragments of a Web application. Furthermore, an acceleration solution must provide a way to scale the database component.

In this paper, we propose a fragmentation-based CDN called FRACS, which combines both page assembly and edge computing in order to deliver the content efficiently to end users. For now, the fragmentation has only been considered from a cache oriented point of view. The defined fragments are usually HTML fragments which are meant to be stored on a cache server. We extend the notion of fragment so as to include two new types of fragments : application fragments and code fragments. We define the three categories of fragments as follows :

Code fragments : a code fragment is a part of the application code. HTML fragments : an HTML fragment is the HTML code generated by a code fragment. Application fragments : an application fragment consists of a code fragment plus the data necessary to generate the HTML output. The code and the application fragments allow the acceleration system to take advantage of application replication even when the application cannot be replicated entirely. FRACS transforms the standard monolithic Web applications into their corresponding fragmented version. It also provides the support to replicate the defined application fragments and to assemble the dynamic pages at the edge of the network. The replication only relies on the HTTP protocol. Most importantly, FRACS maintains the consistency of the manipulated fragments. FRACS only requires a small amount of human configuration. Actually, the administrators are asked to provide a list of sensitive data (expressed in terms of database tables) that they do not want to be replicated. Based on this information, our system fragments the application code and determines which fragments can be replicated along with the required database tables. In this study, we focus on E-commerce applications as they are data intensive and clearly illustrate the impossibility of replicating the whole application while making use of a significant piece of cacheable data. FRACS consists in four logical modules : the adaptation module, the edge server module, the replication manager module and the consistency manager module. The adaptation module is responsible for creating the fragmented version of the application and for creating the replication scripts. It is also responsible for extracting useful information which allows the system to handle the fragments correctly. The edge server module allows edge servers to replicate application fragments properly and serve them to end users. The replication manager module manages the whole replication process. It is responsible for replicating the application fragments as well as redirecting the clients to the appropriate replica. Finally, the consistency manager module provides the support necessary to maintain the consistency of the replicated tables and the stored HTML fragments.

The rest of the paper is organized as follows : Section II covers related work and highlights its advantages and drawbacks. Section III presents and discusses the proposed solution and the corresponding architecture. Section IV reports our experimental results. Finally, Section V summarizes our contribution and outlines the open issues.

II. RELATED WORK

In order to address the shortcomings of total replication, it is necessary to be able to replicate the application partially. Hence, we first summarize the current approaches to fragmenting Web applications. Then we present the different systems which serve the content from the edge of the network. Finally, we describe the work related to scaling the database component of a Web application.

A. Fragmentation of the application

As mentioned in the introduction, the existing fragmentation techniques are only meant to serve page assembly (and not edge computing) purposes. Assembling a page at the edge of the network implies that Web pages are broken down into fragments and that these fragments are separately cacheable. There is no standard method to fragment Web pages and generally if the fragmentation is not supported originally by the Web site, it is still often added manually. However, automatic fragmentation has been investigated. Related studies determine the fragments by periodically comparing different HTML output versions generated by the same URL ( [START_REF] Ramaswamy | Techniques for efficient fragment detection in web pages[END_REF] and [START_REF] Kapoulas | Web fragmentation and content manipulation for constructing personalized portals[END_REF]). The main disadvantages of this approach are the overhead of fragmenting a page online and the redundant online processing. Partial replication of the code needs other kinds of fragments. It requires splitting the code up into minimal replicable units which have complementary or common functions. Functionally speaking there are two ways to consider code partitioning : from a service oriented view point or from a logical view point. Each Web application consists of three logical layers and offers a certain number of services (see figure 1). A particular service is composed of some functions belonging to the different logical layers. Service oriented partitioning consists in grouping together all the necessary code to execute a service, while logical partitioning consists in grouping all the code belonging to one specific layer. Thus one may replicate one or more services or one and more layers. To the best of our knowledge, there is no system which determines such fragments automatically.

B. Serving the content from the network edge

1) Page assembly: The ability to assemble dynamic pages from individual HTML fragments means that only non-cacheable, non-cached or expired fragments need to be fetched from the origin Web server, thereby decreasing the load of the server and lowering the bandwidth consumption of the Web application. The information on the fragments composing a page is usually piggybacked on the corresponding HTML code in a particular markup language. The markup language describing the fragments can be proprietary, however, a standardization effort has been made to develop a uniform programming model to assemble dynamic pages. The resulting markup language called ESI (Edge Side Includes) allows developers to identify content fragments and specifies a content invalidation protocol for transparent content management across ESI-compliant solutions. A certain number of commercial CDNs have already implemented ESI language (Akamai [1]). Akamai clients (content providers), use ESI to break the dynamic page into fragments with independent cacheability properties. These fragments are maintained as separate objects in the edge server's cache and are dynamically assembled into Web pages in response to user requests [START_REF] Dilley | Globally distributed content delivery[END_REF].

2) Edge Computing: When the dynamic content cannot be cached, it turns out to be more efficient to generate it on the edge of the network. This is commonly achieved by replicating the application on the edge servers. By generating the documents locally, the edge servers of a CDN reduce the amount of wide-area traffic, leading to a better client-perceived performance. Though edge computing does not impose a particular replication granule, most of the studies related to edge computing consider the whole application code as the replication granule. Moreover, existing studies generally focus on read-only applications. An interesting study proposes an architecture, referred to as ACDN [START_REF] Rabinovich | Computing on the edge : A plateform for replicating internet applications[END_REF], which relies on the HTTP protocol and Web servers. Each ACDN server is a standard Web server that also contains a set of CGI scripts implementing ACDN-specific functionalities. Using the different scripts, a server monitors its own load and decides whether to send a replication request to a Global Central Replicator which keeps track of application replicas in the system. ACDN implementation is based on the concept of metafile. A metafile consists of two parts : the list of all the files comprising the application together with their last-modified dates ; and the initialization script that the recipient server must run before accepting any request. The main shortcoming of ACDN is that it solely considers read-only web applications. Moreover the metafiles describing the replicable parts of the application are produced manually.

C. Scaling the database component of a Web application

There are two major ways to scale the back end database : either by replicating the database (totally or partially), or by caching the result of database queries and reusing them.

1) Replication of the database: Middleware systems like C-JDBC [START_REF] Cecchet | C-jdbc : A middleware framework for database clustering[END_REF] and Ganymed [START_REF] Plattner | Ganymed : Scalable replication for transactional web applications[END_REF] propose replicating the database in a cluster of servers. The focus of these studies is to improve the throughput of the underlying database within a cluster environment. Other studies ( [START_REF] Sivasubramanian | Globedb : Autonomic data replication for web applications[END_REF]), focus on improving the client perceived-performance and reducing wide-area update traffic. [START_REF] Sivasubramanian | Globedb : Autonomic data replication for web applications[END_REF] proposes a system called GlobeDB for replicating read/write Web applications. GlobeDB automatically replicates a part of the application database and its relative access code. The underlying principle behind GlobeDB is to place each data unit only where it is accessed in order to facilitate consistency management. The replicated data units are clusters of database records calculated periodically based on the access statistics that are collected from the different edge servers. GlobeDB has two main disadvantages. On the one hand, it replicates all of the application's code at all replica servers. On the other hand, GlobeDB can only handle simple queries 1 , all complex queries (matching more than one row) are forwarded to the origin server which incurs a wide-area latency. GlobeDB provides sequential consistency. A system is defined to be sequentially consistent if the result of any execution of possibly concurrent operations is the same as if those operations were executed in some sequential order and the order in which they appear in the transaction is preserved [START_REF] Lamport | How to make a multiprocessor computer that correctly executes multiprocess programs[END_REF]. In order to serialize the concurrent updates, each data cluster is assigned a master server which is the only server capable of updating the cluster. Any update to the cluster is immediately forwarded to the master of this cluster , which processes the stream of update requests and propagates the result to replicas. This reasoning only holds if the update operations are performed on only one data unit at a time.

2) Caching the database query result: Several commercial database caching systems (DBCache [START_REF] Bornhvd | Adaptative database caching with dbcache[END_REF] and MTCache [START_REF] Larson | Mtcache : Mid-tier database caching for sql server[END_REF], oracle Oracle9i Database Cache [START_REF]Oracle9i Application Server[END_REF], Tangosol [22]), propose caching the result of selected queries and keeping them consistent with the underlying database. The query result is typically stored on the origin server or on a cluster of servers. Data-intensive Web applications can also use a third-party Database Scalability Service Provider (DSSP) which caches application queries results and answers queries on their behalf. The challenge of this solution is to ensure the consistency of the stored results when the database is updated. To address the problem, several systems ( [START_REF] Amiri | Dbproxy : A dynamic data cache for web applications[END_REF], [START_REF] Luo | Middle-tier database caching for e-business[END_REF], [START_REF] Li | Cache portal ii : Acceleration of very large data center-hosted database-driven web applications[END_REF]) require the backend database server to track the contents of the proxy caches and forward relevant updates to each proxy server. Another system called S3 [START_REF] Garrod | Scalable consistency management for web database caches[END_REF], proposes a distributed consistency management infrastructure that uses a publish/subscribe support to propagate update notifications. In a topicbased publish/subscribe system, a client receives all publications to each group to which it is subscribed. S3 users connect directly to proxy servers which store materialized views of query results instead of centralized home servers. When a dynamic Web application issues a database query, the proxy responds immediately using its database cache if possible. If the query result is not stored in the cache, the proxy forwards the request to the centralized database server and caches the reply. The proxy cache subscribes to some set of multicast groups when it caches a query, and broadcasts to some set of multicast groups for each update it issues. S3 proposes two strategies to associate database requests with topic-based multicast groups :

-associating multicast groups with the data on which queries depend, -associating multicast groups with the data which updates affect.

The main disadvantage of S3 is that the current version of the system requires manual inspection the application's queries templates and definition of the multicast groups.

III. FRACS SOLUTION

In order to improve the performance of Web applications, we propose a system called FRACS, which transforms a monolithic Web application into its corresponding fragmented version and which provides support for replicating the defined fragments on the network edge. Besides, FRACS provides the support for caching the generated HTML fragments whenever this is possible. This allows us to handle relatively static applications as well as more dynamic ones. Most importantly, FRACS maintains the consistency of the manipulated fragments.

Figure 2 depicts the global architecture of the system. FRACS consists in four logical modules : the adaptation module, the edge server module, the replication manager module and the consistency manager module. The adaptation module determines the fragments of a Web application that can be served from the edge, then it transforms the application's code so as to enable the server to generate fragmented pages and to support individual manipulation of fragments. It also creates replication scripts that automate the effective replication of application fragments.

The end users usually arrive on the origin server the first time they make a request. The replication manager module which is colocated with the origin server determines which edge server should process the request and redirects the users to this server. The replication manager is responsible for creating new replicas in the system. An edge server may host fragments of the application and have a local cache of fragments. In the current implementation, we chose to replicate all the replicable fragments of the application at once. Finally, as its name suggests, the consistency manager manages the different aspects related to consistency, the latter uses a distributed approach to propagate the updates in the system.

A. Adaptation Module

The adaptation module is responsible for transforming the application in order to enable it to generate fragmented pages in ESI format and to support separate generation of fragments. This module performs three main actions. First, it identifies the interesting code fragments which can be generated individually and collects metadata characterizing them. Second, based on some coonfiguration data the adaptation module modifies the code in order to generate fragmented pages. Finally, this module identifies the replicable fragments and creates the scripts which will be used to replicate them. The adaptation module performs offline tasks so that the overhead of the adaptation does not impact the user's observed response time.

1) Fragmentation and metadata collection: The first challenge of the adaptation module is to fragment the Web pages efficiently and at a minimal cost. For Web applications that originally support the fragment handling, the problem does not arise. But when the sites are not originally fragmented some processing must be done in order to identify the fragments that will be cached and to enable the servers to generate them separately. The adaptation module considers the independent scripts of a page as separate code fragments (which is equivalent to service oriented partitioning). This choice ensures that the different code fragments can be executed independently of one another with little modification to the cost. The HTML fragments produced by these code fragments represent interesting candidate fragments which are likely to be reused by the caches. The fragmentation system is a complex system (see [START_REF] Chabbouh | A configuration tool for caching dynamic pages[END_REF] for details). The basic idea of the fragmentation system is to parse the application code statically rather than the HTML output. Static analysis avoids superfluous online processing and facilitates the identification of the fragments and their characteristics. The fragmentation system comprises a parser which extracts information from the code. It goes without saying that in order to handle a Web application, the fragmentation system must have the parser corresponding to the programming language of the Web application in question. The fragmentation system is designed to support the integration of new parsers, however the current implementation only comprises a PHP parser. Firstly, the fragmentation system collects information from the code. Static analysis of the code facilitates the metadata extraction as the code draws a clear separation between the static and the dynamic content and contains the exact set of variables that are actually used and the exact set of database accesses (unlike the output pages where the code has already been executed and the HTML generated). We mainly gather the following information from the code :

-the variables and the functions used by the scripts, -the beginning and the end offsets of the scripts, -the database queries made by the scripts. The variables used by a script consist in HTTP and CGI elements in general (commonly the GET method arguments and the cookies) and the programmer's defined variables. On the one hand, the variables and functions used by the scripts allow us to find the independent scripts (code fragments) of a particular page. On the other hand, these variables help us to characterize the code fragments efficiently so as to increase the cached fragments reuse rate (see section III-B). The beginning and the end offsets are used to locate the fragments position inside a page. Finally, the database queries are useful for the consistency management.

2) Transformation of the code: In order to generate fragmented Web pages, particular tagging instructions are inserted at the beginning and at the end of the identified code fragments. When the code of the dynamic page is executed, the tagging instructions result in surrounding the HTML fragments by ESI tags. The ESI tags are not only used to demarcate the fragments but also to describe their attributes. The attributes mainly consist in the name of the fragment, the variables that it depends on and some data characterizing the database dependencies. The adaptation module also inserts into the code particular functions which capture the queries made by the fragment, and changes the hypertext links (to the origin server) accordingly so as to point to the local host. This is done via a variable which is replaced by the appropriate value at the runtime. Finally, in order to make a code fragment separately fetchable the adaptation module reifies it by stripping its body from the page and storing it as a separate program, then it replaces its occurrence with the appropriate inclusion instruction. Henceforth, a dynamic page will be assimilated to a template containing references to underlying fragments.

3) Replication scripts creation: FRACS replicates application fragments (i.e. code fragments plus the accessed tables). The code fragments could have been replicated without the corresponding backend database (see figure 3), the edge servers would be able to generate the pages near the clients, but the database requests would still have to be executed on the origin server database.

A study [START_REF] Yuan | Evaluation of edge caching/offloading for dynamic content delivery[END_REF] has demonstrated that this configuration is worse than the traditional centralized architecture because client requests to the edge servers often trigger multiple requests from the edge server to the origin server across the WAN. Therefore, it is more interesting to replicate the code and the database together as long as consistency is maintained. Additionally, replicating the database tables makes it possible to scale the database component of a data-intensive Web application. The main problem is then to determine the fragments to replicate. The code fragments identified in the previous step are good candidates for the replication. In order to decide whether a code fragment is replicable, the adaptation module identifies the tables accessed by the code fragment then it compares them against the unreplicable tables specified by the administrator. If all the accessed tables are replicable the code fragment is marked replicable, otherwise it is marked unreplicable.

In order to replicate an application fragment, an edge server needs to copy the fragment code, to create the required database tables and to fill them with the appropriate data. As we will see in section III-D, the replication decision is made by the replication manager. The replication manager has to send all the data necessary to replicate the application fragment as well as the replication script to the edge server. The replication manager itself uses another replication script to perform the actions above. The adaptation module automatically creates the different replication scripts which will be used by the replication manager and the edge servers to create and delete the application fragments. For this purpose, the adaptation module reuses some of the data collected during the static analysis, namely : the path of a code fragment and the database tables used by the latter. It should be noticed that the adaptation module has the creation scripts (SQL instructions) of all the replicable tables. For example, figure 4, represents the replication manager's script used to collect the data necessary to replicate the the code fragment "search.php" which uses the table "item". As we can see in the figure, the first set of instructions (1) copies the content of the table "item" into a file named "item.dat". Then (2) moves this file into a directory which is to be compressed and sent to the client. ( 3), ( 4) and ( 5) respectively copy the script which contains the sql code to create the table "item", the code of the fragment to replicate and the replication scripts which will be used by the edge server in order to create and delete the application fragment. Instruction (6) copies the file containing the configuration data of the fragment (search.cnf). This file mainly contains the address of the replication manager and the pertinence criteria of a replica. Finally, instruction [START_REF] Dilley | Globally distributed content delivery[END_REF] compresses the directory and creates the tarball which will be sent to the edge server. Figure 5, details the script used by the edge server so as to replicate code fragment search.php (i.e. createsearch.sh). The first set of Fig. 5. Edge Server Shell Script : createsearch.sh instructions (1), creates the database tpcw, then uses the script tpcw item schema to create the item table, and finally loads the data contained in the file "item.dat" into the item table . (2) creates the application directories.

(3) and ( 4) copy the code fragment and the configuration file into the appropriate directories. Figure 6, depicts the script used to delete the application fragment. The script simply drops the created tables and removes the code fragment.

B. The edge server module

Edge servers are simply servers of the CDN which are located on the edge of the network. Each edge server has a local store of applications, a cache of fragments and a consistency manager. In FRACS, an edge server may host a replica of the application either temporarily or permanently, and has a local cache of HTML fragments. FRACS needs to collect some measurements on the edge servers, for efficiency and scalability concerns, edge servers monitor their own state.

1) Replication of the application fragments: When the replication manager decides to replicate fragments of the application on a target edge server, it sends a POST query to a particular program on the target edge server. This program is responsible for uncompressing the request body and running the embedded replication script. As mentioned previously, in the current implementation we chose to replicate all the replicable fragments of the application at once, rather than separately. Once the replica has been installed, the edge server starts receiving user requests. Before servicing a user, an edge server has to fetch the session objects related to this user (see section III-D for details). When the content requested by the end users is replicable, the edge server generates it locally. The edge servers can make both selection queries (SELECT) and modification queries (UPDATE, DELETE, INSERT INTO) to the local database. When a locally generated fragment makes a request to the database, this request is automatically detected by the instructions inserted into the code by the adaptation module, and sent to the consistency manager. The consistency manager is responsible for propagating the updates so as to maintain the consistency of the replicated tables.

2) Cache of HTML fragments: The edge server has a cache of fragments which caches the locally generated HTML fragments. It is important to note that the HTML fragments can be cached by any ESI compliant server, nonetheless, in this paper we only focus on the caching of locally generated HTML fragments. The cache uses the templates of the dynamic pages in order to cache and reuse the fragments. The template of a page describes the different fragments belonging to the page as well as their attributes. The template is described by the ESI tags inserted into the code by the adaptation module. When an edge server generates a dynamic page for the first time, it analyzes the HTML generated so as to find metadata of the page, then caches the different fragments. Upon receiving a second request for the page, the edge server checks the corresponding template, fetches or generates the missing fragments and reconstructs the page. In order to take full advantage of the cached content, an edge server should only regenerate the missing and stale fragments for every new request. This implies that the edge server knows in advance about the fragments it is supposed to return when it receives a request. This is not easy to achieve unless the exact URL has already been requested. We address this limitation by introducing what we call filters. A filter is a piece of information associated with a script which is used to produce a unique identifier per HTML fragment produced by the script. Generally, the attribution of an identifier to an HTML fragment is done after the generation of the page containing the HTML fragment in question. The filters make it possible for an edge server to calculate in advance the identifiers of fragments that should be present in a page provided that the template of the page has already been accessed. Actually, the output of a code fragment depends on a set of variables defined in the environment in which the corresponding script is running. Naturally, it also depends on the content of the database (if the displayed information is retrieved from a database), but updating the database does not affect the key of fragment, it can at most render the fragment stale. Let us take a simple example to illustrate the principle of filters. Figure 7 represents a page containing two fragments whose output respectively depend on param1 and param2, passed to the program via the query string. The filter associated with a code fragment contains the identifier of the code fragment and the variables that the HTML fragment depends on. In this example, say that "C1" is the identifier of the first code fragment and "C2" is the identifier of the second fragment. Then, the identifier of the second fragment contains "C2" and "param2". If we assume for the sake of simplicity that the HTML fragment key is the concatenation of the filter's fields, then the HTML fragments produced by the respective requests to the URLs : http ://server/page.php ?param1=aa&param2=bb and http ://server/page.php ?param1=aa&param2=cc will be identified by the respective keys : "C2.bb" and "C2.cc". These keys can be calculated provided that the template is already stored. Therefore, the HTML fragment produced by a code fragment can be reused to assemble any other page containing the same fragment (example the fragment identified by "C1.aa"). The cache of HTML fragments introduces the constraint of maintaining the consistency of the stored content. This issue is addressed by the consistency manager.

3) Monitoring: For scalability concerns, each edge server monitors its own parameters and sends periodical reports to a central monitor in the CDN. All the edge servers measure their load and send it to the central monitor. The load of a server is estimated by the number of active connections. Moreover, each edge server which replicates the application compares the current load to a threshold contained in the configuration file sent with the replication script. If the load is superior to the threshold, the edge server sends an alert to the monitor, which in turn sends it to the concerned replication manager. Each edge server which has a replica of the application also measures the amount of data served and the amount of update data received during the last period. These measurements are used locally to check the relevance of the replica. In our study, the relevance of a replica is estimated by the bandwidth saving it achieves. The edge server compares the volume of updates received against the volume of data served. If the volume of updates is greater than the volume of data served, it means that the cost of maintaining a replica uptodate outweighs its benefits. Nonetheless, the edge server cannot delete the replica immediately, it has to send a deletion query to the replication manager which decides ultimately whether or not to delete the replica.

C. Consistency Manager Module

The consistency manager is a complex system, its internal logic is beyond the scope of this paper, however we will give a brief overview of its functioning and complexity. The consistency manager has two main functions : to maintain the consistency of the replicated databases and to ensure the freshness of the stored HTML fragments.

1) Consistency of the replicated database tables: Based on how strictly the databases are kept consistent, algorithms can be classified into two categories : strong database consistency and weak database consistency. Weak consistency is the model in which the modifications are not propagated instantly, and hence, different edge servers may work on different versions of the same database. On the other hand, in a strong consistency model every modification query must be acknowledged. A server will not update an object until it receives all the acknowledgement messages from the edge servers which are supposed to apply the modifications. Instead of sending the modifications instantly to the edge servers, we propose logging these requests and sending them periodically. A priori, sending modification queries in batch ensures weak consistency, however we choose a small period so that the data is not older than a certain threshold. The threshold used in the experiments with TPC-W is one minute. The consistency manager logs the modifications made locally during the specified period, and sends them to the replication manager which multicasts them to the edge servers which replicate the tables involved. Upon receiving the set of updates, the edge servers simply apply them to the local database. For now, we do not check whether the updates are conflictual.

2) Consistency of the cached HTML fragments: The HTML fragments may become stale for two reasons : either the code fragment which generated them has changed, or the database tables accessed by the corresponding code fragments have been modified. In this study we assume that the code of the application is not modified (though as we will explain in section V, modifying the application code is not a major hurdle). In order to invalidate the cached HTML fragments we associate to a fragment its database dependencies when the fragment makes a selection query to the database, then we check whether a modification query invalidates the locally stored HTML fragments. As explained previously, the local selection and the modification queries are captured by functions inserted into the code by the adaptation module and sent to the local replication manager along with the identifier of the fragment which issued them. When the replication manager receives a selection query it translates the latter into its relative Disjunctive Normal Form (DNF). After that, it calculates the MD5s of the resulting clauses and stores the mapping between the fragments identifiers and the MD5s of the clauses that they depend on. Then, the different clauses of the DNF are inserted into a predicates tree whose leaves are the previously calculated MD5s. The predicates tree is designed to facilitate the comparison of the stored clauses against a new literal. Finally, it subscribes to the notification server for these MD5s. When a modification query is sent to the consistency manager, the latter translates it as well into its corresponding DNF, then it traverses the tree following the matching branches so as to find the MD5s of invalidated clauses. An update notification is sent to the notification server which is responsible for the MD5s. It must be noted that it is not usually possible to decide whether a modification invalidates a fragment or not (unless additional requests are made to the database), in such cases we adopt the pessimistic approach by invalidating all the suspect fragments. The algorithm which determines the fragments to invalidate has a sublinear complexity : c(n) = O(n p ), where p is comprised between 0 and 1.

D. The replication manager module

The replication manager has to redirect the clients, administer the replication process and keep track of the application replicas in the system. There is one replication manager per application, it is colocated with the origin server.

1) Redirection of the clients: The replication manager receives requests from both end users and edge servers. The clients usually arrive on the origin server at first independently from the requested content. As concerns the edge servers, they only request a fragment from the replication manager when the fragment is not replicable because they replicate all the replicable fragments of the application at once. When the requested content is not replicable, the request is directly transmitted to the origin server. Otherwise, the replication manager redirects the client to any nearby edge server which has a replica of the application and which is not overloaded. The redirection is made via the 307 HTTP status code (temporary redirect), so that the client is compelled to turn back to the replication manager for the next session. If all the edge servers near the client are overloaded the replication manager may create a new replica on the least loaded edge server in the neighborhood.

2) Replication of the application: When all the replica servers in the neighborhood of a client are loaded, the replication manager checks whether it is possible and relevant to create a new replica of the application, otherwise it simply distributes the requests evenly among the loaded replica servers. Each new replica spawns new traffic in order to maintain the consistency of all the replicas in the system. Therefore, the system should offer a reasonable tradeoff between performance improvement and consistency management. We introduce a maximum number of replicas in order to make sure that the bandwidth consumed by the creation of a replica and the consistency messages between the existing replicas is never larger than a certain proportion of the overall traffic. This maximum number of replicas is calculated based on the average proportion of the traffic we are willing to dedicate to the creation and the maintenance of the replicas. When the replication manager decides to replicate the application, it queries the central monitor of the CDN in order to locate the candidate target edge servers in a particular region. Then, the replication manager runs the appropriate replication script which produces a compressed file comprising all the necessary data for the replication. This file is sent in the body of a POST request to a program residing in the target edge server. Thence, the replication only relies on the HTTP protocol. The replication manager receives deletion queries from the edge servers in order for them to have permission to delete their replicas. This helps to limit the number of replicas in the system. If the number of existing replicas is near the maximum number of replicas, the replication manager agrees to delete the replica.

3) Session management: End-user session state is a common aspect of E-commerce applications. As pointed out by a recent study [START_REF] Davis | Edgecomputing : Extending enterprise applications to the edge of the internet[END_REF], the dynamic mapping of users to the appropriate application instance across the network introduces the problem of "session affinity". Having one centralized database to provide persistent session storage would add unnecessary latency in servicing the request and might even cancel out the benefits of moving an application to the edge. In FRACS, the replication manager allows client session objects to be replicated across edge servers in the network. The first time a user is mapped to an edge server, the server asks the replication manager whether there is a session object for this user. If the session object exists, the replication manager returns the identifier of the last server which has requested this object (and presumably modified it) and thus which has the latest version of it. Otherwise a new session object is created for the user on the edge server and is cached locally. The replication manager records the identifier of this server as the latest server to have requested that particular session object. The session objects are set to expire after a specified TTL.

IV. EXPERIMENTS

We chose the TPC-W benchmark in order to evaluate the benefits of FRACS. TPC-W specifies an E-commerce workload that simulates the activities of a retail store web site. Users are emulated via several Remote Browsers Emulators (RBEs). Emulated users can browse and order products from the site. The benchmark defines two categories of Web interactions : browsing and ordering. Browsing interactions include displaying the home page, searching for an item, viewing product details, etc., while ordering interactions include the more resource intensive ones such as buying an item, updating items in the shopping cart, displaying an order, etc. The RBEs can be configured to generate different interaction mixes :

-Browsing mix : 95% browsing and 5% ordering, -Shopping mix : 80% browsing and 20% ordering, -Ordering mix : 50% browsing and 50% ordering. The schema defined in the specification of TPC-W consists of eight tables : customer, address, order, order line, credit card transaction, item, author and country. We only consider three tables replicable : item, author and country.

In our experiments we mainly study the response time because it is the parameter which is usually, implicitly, used by clients to evaluate the performance of an E-commerce application. The four modules of FRACS are all implemented but have different levels of maturity. The adaptation module, is fully implemented and tested with other PHP benchmarks, while the other modules have only been tested with TPC-W. In addition, the current version of the system uses a simulation of a central monitor which relies on a static ditribution of the clients and the edge servers.

Figure 8 depicts the test bed. We deployed our prototype across eight similar edge servers. The servers run First of all, in order to have an idea of the effectiveness of the acceleration we compared the performances of our solution, on the one hand, with the basic configuration (i.e. with no acceleration tool), and on the other hand with the configuration where a simple cache of HTML fragments is deployed. In the first configuration, the edge server forwards all the requests to the origin server. In the second configuration, the edge server assembles the dynamic page by caching and reusing the cacheable fragments, and when the fragments are not stored or cannot be cached the requests are forwarded to the origin server. The third configuration corresponds to FRACS. In this experiment, the measurements were made on the edge servers. The response time is calculated as the difference between the moment a request is made to the edge server and the moment when the edge server sends back the response to the client. This response time approximates the response time observed by the end users as they are served by nearby edge servers. Figure 9 presents the average response time for the shopping mix workload with the different configurations. Figure 10 draws a parallel between the instantaneous response time of the three configurations. The reader's attention should be drawn to some details which may be misleading at first glance. For instance, one would expect the origin server's response time to be constant throughout time in configuration 1 (as no acceleration mechanism is deployed), however we observe that the response time sometimes decreases tremendously. This is due to some caching mechanisms used by both SQL and Apache servers. As concerns the second and the third configurations, we notice, in contrast, that the response is sometimes very high. This is due to a shortcoming of our current implementation. In fact, we only developed a basic proxy for our experiments which closes the connections after every request. This is particularly penalizing when a large number of missing fragments have to be fetched from a remote location. Finally, we can see that the response time rapidly decreases in configuration 2 for a certain number of requests thanks to the stored fragments. The same is true for configuration 3 and we can clearly observe in figure 10 (c) the moment when the edge server has obtained a fragment of the application. Our system also diminishes the bandwidth consumption of the Web application insofar as it reuses the cached HTML fragments, whenever this is possible, and it generates the fragments locally or on nearby servers otherwise. Figure 11 and figure 12 respectively depict the average percentage of the reused content for the three different workload mixes and the corresponding reduction in response time. We can clearly observe that the percentage of the reused content is very high for all the workload mixes. This stems from the fragmentation method we are using (a thorough description of the fragmentation module can be found in [START_REF] Chabbouh | Caching dynamic content with automatic fragmentation[END_REF]). However, our system generates some traffic in order to maintain the consistency of the stored content. In our experiments with TPC-W we fixed the period to propagate the updates to 5 minutes. But even for the ordering mix workload, the bandwidth consumed by the update messages was barely 3% of the bandwidth consumed

V. CONCLUSIONS AND FUTURE WORK

In this paper we propose a hybrid CDN called FRACS which transforms a standard Web application into its corresponding fragmented version. FRACS determines and deploys the fragments of an application that can be served from the edge. The system we propose combines both page assembly and edge computing in order to deliver the dynamic content efficiently from the edge of the network. FRACS reduces the E-commerce applications response time as well as bandwidth consumption by replicating the application fragments at the edge of the network and caching them whenever this is possible. Moreover FRACS maintains the consistency of all the manipulated data. We have evaluated the performances of the system using the TPC-W benchmark and the results we obtained were very satisfactory. In order to validate our approach on different types of applications, we are currently investigating the RUBiS benchmark [START_REF] Rubis | [END_REF] which is an auction site prototype modeled on eBay. There are also some issues which have not been addressed in this paper and which we want to investigate as future work. For instance, as we said in section III, we assume that the code fragments are not modified. The modification of the application programs is likely to be done by a human administrator on the origin server. Thus we can simply introduce a new module through which the administrators can execute their modifications. This module would be a sort of wrapper which applies the modifications and which triggers invalidation messages for all the code and HTML fragments concerned by the modifications. For now, we replicate all the replicable fragments of the application at once, it should be interesting to try to define clusters of application fragments which for instance minimize the number of exchanged update messages between the different replicas. We also implicitly assume that the simultaneous database updates on the different edge servers are not conflictual ; it would be more realistic to consider some mechanisms to handle this potential problem. Finally, in order to evaluate the real benefits of the approach, it would be pertinent to compare our results with some existing systems.

  Fig. 3. Configuration

6 )Fig. 4 .

 64 Fig. 4. Replication Manager Shell Script

Fig. 6 .

 6 Fig. 6. Edge Server Shell Script : deletesearch.sh

  Fig. 7. Filters

Fig. 8 .

 8 Fig. 8. Test Bed

Fig. 9 .

 9 Fig. 9. Average response time

Fig. 10 .

 10 Fig. 10. Instantaneous response time

Fig. 12 .

 12 Fig. 12. Response time savings


J M Spiewak

B Jouvencel

P Fraisse

A New Design Of AUV For Shallow Water Applications: H160

Keywords: AUV, Vehicle description, Shallow water, Sea trials

This paper focuses on the design and control of a new Autonomous Underwater Vehicle (AUV) named H160. The first prototype of this AUV has been designed through a collaboration of two partners, which are the LIRMM laboratory and ECA-HYTEC company. We present an overview of this project regarding the development of this vehicle including the software and hardware architecture, modelling and control. In addition, the first experimental results relying on real experimental conditions are displayed and commented.

INTRODUCTION

Underwater robotic vehicles are helpful equipment for scientists to explore oceans and seas. Many examples have revealed that ROV (Remotely Operating Vehicle) and AUV are used for diverse applications such as inspection, object recovery or surveys. We can distinguish a "depth limit" for the different types of existing AUV. Indeed, from about 300 meters, the structure, the dimensions and the characteristics of these vehicles change. On the one hand, the AUVs specified for deep water, as for example Hugin 3000 from Kongsberg Simrad, Sea Oracle from Bluefin Robotics and Alistar 3000 from ECA, have a maximum depth of 3000 meters, a high autonomy, nonnegligible dimensions and a weight that requires a heavy logistic. On the other hand, some AUVs (Remus from Hydroid, Gavia from Hyfmind) with less autonomy, reduced dimensions, more modular parts and a reduced logistic, are the perfect tool for the investigation of shallow water. In the context of partnership between the LIRMM (Montpellier Laboratory of Computer Science, Robotics and Microelectronics) and the french company HYTEC (specialist in the design and manufacture of remote controlled systems in "hostile" environments), the first prototype of AUV H160 has been developed. In 2004, our original choice was positioned on a small vehicle with a 2 to 4 knots forward speed for 3 or 4 hours mission duration, with a reduced logistic. This prototype has been developed in the purpose of navigation and positioning with dead reckoning data and GPS fix. At the surface, the torpedo should be able to transmit trials data to our missions' computer. The desired applications are inspection, survey, bathymetry measurement, acoustic image acquisition, videos or still biology missions in shallow water and also the possibility to navigate within 1 or 2 meters depth (lagoon, lake) with a near zero pitch angle. Different components of H160 are detailed in the next section of this paper including sensors, mechanical structure and software architecture. Section 3 briefly describes the model and the control law of the vehicle. Furthermore, different sea trials relying on real missions are displayed in section 4. At last, section 5 concludes this work and proposes some issues in order to improve both the control and hardware architecture.

VEHICLE DESCRIPTION

H160 is a small size and low cost torpedo-shaped AUV dedicated for shallow water applications, up to 160 meters. The dimensions of the vehicle can be resumed as 1.8 meters long for a 0.2 meters diameter with a weight of 60 kg (Fig. 1).

Fig. 1 :

 1 Fig.1: Sensors equipment (without Sidescan Sonar and CTD Sensor)


Dag Øivind Madsen

USING GOOGLE TRENDS IN MANAGEMENT FASHION RESEARCH: A SHORT NOTE

Keywords: Google Trends, management fashion, management concepts, management ideas, Internet

published or not. The documents may come

INTRODUCTION 1.1 Google Trends

Google Trends (GT) (www.google.com/trends/) is a free analytic tool for measuring and monitoring Internet search data [START_REF] Choi | Predicting the present with google trends[END_REF]. In the words of [START_REF] Choi | Predicting the present with google trends[END_REF], GT can be used to "predict the present". GT contains Google search data dating back to 2004, and can measure and monitor trends in web searches over time.

Several researchers have pointed out that GT provides early indicators of future behavior. GT has been applied in a variety of research fields, including health care [START_REF] Nuti | The Use of Google Trends in Health Care Research: A Systematic Review[END_REF], software engineering [START_REF] Rech | Discovering trends in software engineering with google trend[END_REF] and political science [START_REF] Mellon | Where and when can we use Google Trends to measure issue salience?[END_REF][START_REF] Mellon | Internet search data and issue salience: The properties of Google Trends as a measure of issue salience[END_REF]. In epidemiological research, GT has been used to predict disease infections [START_REF] Pelat | More diseases tracked by using Google Trends[END_REF][START_REF] Seifter | The utility of "Google Trends" for epidemiological research: Lyme disease as an example[END_REF]. For example, when a large number of people search for the term "flu" this indicates an outbreak. In economic research, GT can be used to predict economic behavior and future economic activities, e.g. housing prices [START_REF] Wu | The future of prediction: how Google searches foreshadow housing prices and quantities[END_REF] or inflation expectations [START_REF] Guzman | Internet search behavior as an economic forecasting tool: The case of inflation expectations[END_REF].

Purpose

Against the brief background described above, this short paper explores how GT can be applied in research on "management fashions" (see e.g. [START_REF] Collins | Management fads and fashions[END_REF][START_REF] Ten Bos | Management Fashion and Organizational Behaviour[END_REF]. To the best of the author's knowledge, GT has not previously been discussed in the context of management fashions, or more generally in management research, for that matter. In this paper, it is argued that GT could have a natural application in the study of management fashion. After all, a key question of interest to management fashion researchers is how the popularity of management concepts and ideas evolves over time. This paper points out the main pros and cons associated with using this tool. Moreover, the paper discusses the possibilities for using GT to reveal expectations in the management fashion market, provide indicators of future consumer demand, as well as indicate "outbreaks" of contagious management concepts and ideas.

Structure

The rest of the paper proceeds as follows. Section 2 looks at the use of GT in other academic research fields. Section 3 focuses on the use of GT in management fashion research and provides illustrative examples of how it can be used to study the evolution of different management concepts and ideas. Section 4 evaluates the pros and cons of using GT in management fashion research. In Section 5 discusses the broader implications for research on management fashions. Section 6 concludes the paper by discussing shortcomings and ideas for future research.

USE OF GOOGLE TRENDS IN DIFFERENT ACADEMIC RESEARCH FIELDS

Online and offline behavior

In recent years, there has been an increased recognition that online behavior, e.g. on social media platforms such as Twitter, can predict offline real-world behavior and outcomes [START_REF] Asur | Predicting the future with social media[END_REF][START_REF] Digrazia | More Tweets, More Votes: Social Media as a Quantitative Indicator of Political Behavior[END_REF]. There are number of tools available for monitoring social media activities [START_REF] Laine | Monitoring social media: tools, characteristics and implications[END_REF]. In a similar vein, GT is an analytic tool which can be used to monitor Google search activity. The next section looks at research which shows that GT can be used to gain insight into many types of offline behavior.

GT in academic research

Using GT in academic research is not new. GT is widely used in a wide range of academic research fields, including health care research [START_REF] Nuti | The Use of Google Trends in Health Care Research: A Systematic Review[END_REF], epidemiology [START_REF] Pelat | More diseases tracked by using Google Trends[END_REF][START_REF] Seifter | The utility of "Google Trends" for epidemiological research: Lyme disease as an example[END_REF], software engineering [START_REF] Rech | Discovering trends in software engineering with google trend[END_REF], political science [START_REF] Mellon | Where and when can we use Google Trends to measure issue salience?[END_REF][START_REF] Mellon | Internet search data and issue salience: The properties of Google Trends as a measure of issue salience[END_REF], and economic research [START_REF] Guzman | Internet search behavior as an economic forecasting tool: The case of inflation expectations[END_REF][START_REF] Wu | The future of prediction: how Google searches foreshadow housing prices and quantities[END_REF].

In epidemiological research [START_REF] Pelat | More diseases tracked by using Google Trends[END_REF][START_REF] Seifter | The utility of "Google Trends" for epidemiological research: Lyme disease as an example[END_REF], GT has been used to predict disease infections. For example, when lots of people search for the term "flu" this indicates an outbreak is about to occur. In political science GT has been used to measure issue salience [START_REF] Mellon | Where and when can we use Google Trends to measure issue salience?[END_REF][START_REF] Mellon | Internet search data and issue salience: The properties of Google Trends as a measure of issue salience[END_REF], which is a measure of how important an issue is to voters. Finally, in economics GT has been used to predict economic behavior and future economic activities. For example, search data can be used to make predictions about the housing market [START_REF] Wu | The future of prediction: how Google searches foreshadow housing prices and quantities[END_REF] or inflation expectations [START_REF] Guzman | Internet search behavior as an economic forecasting tool: The case of inflation expectations[END_REF]. In the words of Wu and Brynjolfsson (2009, p. 13) "the abundance data from Google Trends allows researchers to study numerous topics".

GT and managerial/organizational behavior

This brief exploratory literature review has shown that GT is used to predict behavior in a wide range of research fields. However, the review did reveal any research employing GT in the context of managerial and organizational behavior. Given GT's apparent relevance for understanding political and economic behavior, it seems plausible that GT could be employed by researchers in studies of managerial and organizational behavior as well. In the next section, the discussion turns to how Internet search engines such as Google may be used by managers in the management fashion consumption process, and in what ways management fashion researchers could apply GT as an analytic tool to monitor such search activity.

USING GOOGLE TRENDS IN MANAGEMENT FASHION RESEARCH

Management fashion research

Management fashion research is an important research area in management and organizational behavior (see e.g. [START_REF] Collins | Management fads and fashions[END_REF][START_REF] Ten Bos | Management Fashion and Organizational Behaviour[END_REF]. A key focus of management fashion research is on mapping trends in the popularity of different management concepts and ideas. The lifecycle of fashionable management concepts and ideas is typically illustrated using a bell-shaped curve. The assumption is that fashions are fleeting and transient phenomena, which after a take-off and growth phase, become widely popular before going out of fashion and waning away.

Over the course of the last decades a large number of management concepts and ideas have been introduced (see e.g. [START_REF] Hindle | Guide to management ideas and gurus[END_REF]. Well-known examples of fashionable management concepts and ideas include Knowledge Management, Balanced Scorecard and Lean. However, not all management concepts and ideas succeed in becoming popular. To this point, Jung and Kieser (2012, p. 329) note that management fashions are those "management concepts that relatively speedily gain large shares in the public management discourse."

Management fashion researchers tend to view the diffusion and popularization of management concepts and ideas as happening within a management fashion market shaped by supply and demand side forces [START_REF] Abrahamson | Management Fashions[END_REF]. A criticism of management fashion research is that it has focused heavily on the supply-side, and has largely taken supply-side discourse (e.g. citations in newspapers and professional magazines) as a proxy for take-up by organizations and managers on the demand side [START_REF] Benders | What's in a fashion? Interpretive viability and management fashions[END_REF][START_REF] Clark | The fashion of management fashion: A surge too far?[END_REF]. To this point, research has shown that it is not always the case that supply-side activity and demand-side use "coevolve" (Nijholt & Benders, 2007). For example, there might be much "talk" on the supply-side without this being reflected in actual take-up by organizations and managers.

Studying the actual impact of management fashions can therefore prove to be a challenging task (Nijholt & Benders, 2007). Print-media indicators do not provide a complete picture of a fashion's impact [START_REF] Benders | Using print media indicators in management fashion research[END_REF]. Therefore, different research methods and data sources should be combined to provide a fuller picture of a fashion's impact [START_REF] Madsen | Doing research on 'management fashions': methodological challenges and opportunities[END_REF]. However, to date, the possibility of using Internet search data has not be addressed in the management fashion literature. As will be discussed in the following, GT can possibly be used as of one of the colors in a pallet used to "paint an overall picture" (cf. Nijholt & Benders, 2007, p. 638) of a management fashion's impact.

Google and the consumption of management fashions

Little is known about how managers use Internet search engines to gather information. However, we know from surveys that the Internet is heavily used in everyday life in countries such as the United States (e.g. [START_REF] Rainie | Internet, broadband, and cell phone statistics[END_REF]. "Googling" for information has become part of our everyday vocabulary, which indicates that Google has become institutionalized as perhaps the single most important Internet search engine. Recent research also shows that the Internet and social media platforms are used not only in everyday life, but are also increasingly used by professionals in organizations [START_REF] Skeels | When social networks cross boundaries: a case study of workplace use of Facebook and LinkedIn[END_REF].

Search engines such as Google may shape the way we search for information. For example, in the marketing literature, it has been shown that Internet has shaped how consumers search for information when they are considering buying goods and services [START_REF] Peterson | Consumer information search behavior and the Internet[END_REF][START_REF] Ratchford | The impact of the Internet on information search for automobiles[END_REF]. It is conceivable that the Internet also shapes how consumers of management fashions (i.e. managers in organizations) search for and become aware of new management concepts and ideas. Traditional printed books and articles may not have as prominent a role as they had in the past due to the advent of search engines and various social media platforms which can be accessed at the press of a button (Madsen & Slåtten, 2015b).

However, currently little is known about what role Internet search engines, and Googling in particular, may be playing in the consumption of management concepts and ideas. How are managers using searching engines when learning about new concepts and ideas? What role do search engines play in the "awareness stage" where managers encounter, become aware of and learn about new management concepts and ideas (cf. [START_REF] Madsen | How do managers encounter fashionable management concepts? A study of balanced scorecard adopters in Scandinavia[END_REF][START_REF] Van Rossem | Managers' awareness of fashionable management concepts: An empirical study[END_REF][START_REF] Van Veen | Diffusion, translation and the neglected role of managers in the fashion setting process: The case of MANS[END_REF]? Furthermore, we know little about how search activity changes over time, as a fashion progresses through its lifecycle. It could be that search engines are primarily used in the early phase of the management fashion lifecycle, when concepts and ideas are poorly understood and are perceived as novel and newsworthy.

Studying the trends in interest in management concepts and ideas

This section provides some examples of how researchers could use GT to study the evolution of management concepts and ideas. The examples of management concepts and ideas utilized in this section (e.g. Big Data, Balanced Scorecard) are often cited in Bain & Company's bi-annual survey of popular management tools and trends (e.g. [START_REF] Rigby | Management Tools & Trends[END_REF] or Gartner's annual hype cycle report for emerging technologies (e.g. [START_REF] Gartner | Gartner's 2015 Hype Cycle for Emerging Technologies Identifies the Computing Innovations That Organizations Should Monitor[END_REF].

GT allows researchers to search for terms such as "Big Data" or "Balanced Scorecard". Figure 1 shows the interest in "Big Data" over time. Figure 1 clearly indicates that there has been an "explosion" in the interest in Big Data, which took place around 2011-2012. Moreover, the interest has as of 2016 not yet peaked, even though the rate of increase has slowed down recently. Figure 2 shows the interest over time for the search term "Balanced Scorecard", another well-known management concept which was introduced in 1992 [START_REF] Kaplan | The balanced scorecard -Measures that drive performance[END_REF]. In prior research it has been noted that there was a strong "hype" associated with this concept around the turn of the century [START_REF] Ax | Bundling and diffusion of management accounting innovationsthe case of the balanced scorecard in Sweden[END_REF]Madsen & Slåtten, 2015a). Figure 2 shows that the interest has been steadily falling for several years. However, at the same time, recent research shows that Balanced Scorecard is alive and well in organizational practice, more than two decades after it was introduced [START_REF] Frigo | The balanced scorecard: 20 years and counting[END_REF][START_REF] Hoque | 20 years of studies on the Balanced Scorecard: Trends, accomplishments, gaps and opportunities for future research[END_REF][START_REF] Rigby | Management Tools & Trends[END_REF]. In other words, a concept such the Balanced Scorecard may be widely used even though search activity has waned.

Comparisons

Another possibility offered by GT is do side-by-side comparisons of management concepts and ideas. In Figure 3, the search terms "Data Mining" and "Big Data" are compared. As Figure 3 clearly shows, Big Data has overtaken Data Mining in terms of relative level of interest. One possible explanation of this development is that Big Data in some ways is a relabeling and repackaging of Data Mining. 3.5 Regional differences GT could also shed light on differences across regions and markets. Figure 4 shows that the interest in "Big Data" is currently highest in India and countries in East Asia.

Related searches

GT also provides useful information about related topics and queries. Figure 5 shows topics and queries related to the search term "CRM", which is the acronym used for the Customer Relationship Management concept. Figure 5 shows that typical related topics and queries include software vendors such as Microsoft, SAP and Salesforce.com. This type of information underscores these actors' important positions in the CRM management fashion market.

More generally, this function in GT could provide an indication of the interest in complementary products and services related to management fashions. Previous management fashion research has shown that there is a wide range of complementary products and services for fashions such as Knowledge Management [START_REF] Klincewicz | Management fashions: Turning best-selling ideas into objects and institutions[END_REF] and the Balanced Scorecard (Madsen & Slåtten, 2015a).

PROS AND CONS OF USING GOOGLE TRENDS IN MANAGEMENT FASHION RESEARCH

This section takes a closer look at the pros and cons of using Google Trends in management fashion research. As will be discussed in greater detail, the pros are generally related to GT's user-friendliness and availability, while the cons are related to limited possibilities for in-depth analysis.

Pros

Perhaps the most obvious benefits of using GT is that it is fast and free. Using GT, it becomes very easy for researchers, students and journalists alike to monitor developments more or less in real time. As shown in the previous section, GT allows researchers to not only look at the interest in individual search terms, but also compare different search terms, differences across countries/regions, as well as explore related topics and queries.

Another benefit is that GT provides data which can possibly be used to provide a window into the decision-making of management fashion consumers (i.e. managers). As Wu and Brynjolfsson (2009, p. 13) point out: "Rather than rely on painstaking surveys and census data, predefined metrics and backwardlooking financial reports, social science researchers can use query data to learn the intentions of buyers, sellers, employers, gamers, gardeners, lovers, travelers and all manner of other decision-makers even before they execute their decisions." GT could provide a macro-level view of managers' interest in management concept and ideas, which is not easily captured by other research methods such as surveys.

Furthermore, Wu and Brynjolfsson (2009, p. 13) point out that search data reveal the intentions of managers and is not strategic: "It distills the collective intelligence and unfiltered intentions of millions of people and businesses at a point in their decision-making process that precedes actual transactions. Because search is generally not strategic, it provides honest signals of decision-makers intentions."

In a similar vein, [START_REF] Guzman | Internet search behavior as an economic forecasting tool: The case of inflation expectations[END_REF] points out that a key benefit of GT data is that reveals expectations in the market. This is because people search for things they would like to learn about, issues that they care or perhaps worry about. In the context of management fashion, GT data may provide insight about what management issues managers are interested in and would like to learn more about, and what aspects of business they are interesting in improving (e.g. areas where managers perceive performance gaps).

Cons

Despite these pros, there are also several cons. One limitation of GT is that the data is adjusted and normalized 1 , which makes it difficult to conduct in-depth analysis of GT data. GT can only shed light on relative popularity of search terms across regions. The analysis is also limited to Google search data, and does not cover other search engines such as Yahoo etc.

Another problem is related to the fact that GT data only dates back to 2004. This could be a problem when researching management fashion, as several contemporary management concepts and ideas date back to the 1990s or even earlier, e.g. the Total Quality Management movement (see e.g. [START_REF] Dahlgaard-Park | The quality movement: Where are you going?[END_REF][START_REF] Jung | Crossing the management fashion border: The adoption of business process reengineering services by management consultants offering total quality management services in the United States, 1992-2004[END_REF] or Knowledge Management (see e.g. [START_REF] Klincewicz | Management fashions: Turning best-selling ideas into objects and institutions[END_REF]. Over time, this will problem will diminish in importance. For never management concepts and ideas such as Big Data Analytics, Cloud Computing etc. this will be of minimal or no importance, as these concepts did not really take off until the mid-2000s or later.

Finally, another limitation of GT is that it does not take into account linguistic differences or local variations of management concepts and ideas. For example, management concepts and ideas are often translated to local circumstances [START_REF] Røvik | Trender og translasjonerideer som former det 21. århundrets organisasjon[END_REF]. For instance, this has been seen in the case of the Balanced Scorecard where local Scandinavian variations of the term are commonly used (Madsen & Slåtten, 2015a). As of today, GT is unable to capture such linguistic translations and variations.

DISCUSSION

This section discusses the findings of the paper in the context of research on management fashions. The discussion is centered around three topics: (1) search behavior and managerial behavior, (2) virality, outbreaks and management fashions, and (3) supply-demand dynamics.

Search behavior and managerial behavior

The research reviewed in Section 2 of this paper has shown that online search behavior can predict economic behavior and outcomes such as house prices and inflation expectations [START_REF] Choi | Predicting the present with google trends[END_REF][START_REF] Guzman | Internet search behavior as an economic forecasting tool: The case of inflation expectations[END_REF][START_REF] Wu | The future of prediction: how Google searches foreshadow housing prices and quantities[END_REF]. It is conceivable that GT could shed light on managerial and organizational behavior as well. In the context of the management fashion market, increases in search activity may predict increased interest in certain managerial issues and problems, and may be used to "forecast" future adoption behavior.

In the brief literature review in this paper it was noted that in a political science context GT has been used to measure how important an issue is to voters [START_REF] Mellon | Where and when can we use Google Trends to measure issue salience?[END_REF][START_REF] Mellon | Internet search data and issue salience: The properties of Google Trends as a measure of issue salience[END_REF]. Translated to a management fashion context, GT could potentially be a measure of how important a management problem or issue is to managers. For example, if there is a general increase in searches for "analytics" this could signal that managers are looking for tools and solutions which could help with analyzing large amounts of data.

Virality, outbreaks and management fashions

As shown in Section 2, GT has been applied in epidemiological research [START_REF] Pelat | More diseases tracked by using Google Trends[END_REF][START_REF] Seifter | The utility of "Google Trends" for epidemiological research: Lyme disease as an example[END_REF] where it has been used to predicting disease outbreaks [START_REF] Carneiro | Google trends: a web-based tool for real-time surveillance of disease outbreaks[END_REF]. The notion of an "outbreak" has also been used in the context of contagious management concepts and ideas. A recent theoretical perspective on the "spread" of management conceps and ideas is Røvik's virus theory [START_REF] Røvik | From Fashion to Virus: An Alternative Theory of Organizations' Handling of Management Ideas[END_REF]. The virus theory offers a way of think about what causes concepts and ideas to reach epidemic proportions. Therefore, it is possible to GT could be used to predict outbreaks in the context of management concepts and ideas. When many managers search for the same idea this indicates that an outbreak is about to occur and that a concept/idea is highly infectious. For example, the sudden spike in search for the term "Big Data" in 2011-2012 may have been an early signal that an outbreak was about to occur.

Supply-demand dynamics

GT could also potentially influence the dynamics between suppliers and consumers in the management fashion market. Today it can be observed that consulting firms and software solution vendors are advertising on search engines such as Google. This is an indication that suppliers of fashions are realizing the importance of search engines in reaching potential fashion consumers.

On the supply side, actors such as consultants could use GT to "reveal expectations" (cf. [START_REF] Guzman | Internet search behavior as an economic forecasting tool: The case of inflation expectations[END_REF] in the management fashion market. Suppliers can possibly use GT data to tailor their repertoire of management solutions, or adjust how they present their knowledge products to consumers in the management fashion market. For example, when many managers search for and show interest in "Big Data" or "Analytics" this indicates that these things are seen issues of concern in the business community.

Insights from GT data can also possibly be used by suppliers (e.g. consultants) in the fashion-setting process. For example, GT data may reveal what types of buzzwords work when communicating with fashion consumers. In other words, GT can help suppliers connect with the zeitzeist. Furthermore, suppliers can use agenda-setting processes [START_REF] Kosicki | Problems and opportunities in agenda-setting research[END_REF] to try and influence the type of issues managers think about and how they think about them [START_REF] Weaver | Issue salience and public opinion: Are there consequences of agenda-setting?[END_REF]. In turn, this may trigger interest and searches by curious management fashion consumers.

CONCLUSION

Contributions

This short paper has explored the potential of using GT as an analytic tool in management fashion research. The paper has shown that GT has both pros and cons when used in the context of management fashions. Furthermore, the use of Internet search data has implications for debates in the literature on management fashions. In this paper, it is argued that using Internet search data such as GT could possibly reveal intentions and expectations in the management fashion market, provide early indicators of future fashion consumer demand, and as well as indicate outbreaks of contagious management concepts and ideas.

Limitations

This paper should be seen as an early attempt aimed at investigating whether GT can be used in management fashion research. Being speculative in nature, the paper has several limitations which should be considered carefully. For example, the paper has only looked at GT. In the future, researchers could also look at other similar analytic tools, e.g. for other search engines such as Yahoo or social media platforms such as Twitter. GT only captures one part of the activity around management fashions and does not offer a full picture of the impact of a fashionable management idea. To use the painting metaphor, search data is only one color in the palette used to paint a picture of the impact of management fashions.

Future research

With these limitations in mind, there are several possible extensions of this paper. One possible extension is to study how search activity coevolves with print-media discourse [START_REF] Benders | Using print media indicators in management fashion research[END_REF] and social media discourse (Madsen & Slåtten, 2015b). Another possible area would be to investigate the relationship between search behavior and the adoption of management fashions. In the context of the Balanced Scorecard, this paper has shown that even though search activity has tapered off, recent surveys indicate that Balanced Scorecard usage remains high (e.g. [START_REF] Rigby | Management Tools & Trends[END_REF]. It would also be interesting to investigate how search behavior changes over the course of the management fashion lifecycle. It is possible that search behavior is most intense in the early stages when the level of awareness and knowledge is low, and that, as the average knowledge level in the business community rises, search activity tapers off.

Qualitative approaches could also provide useful insights into how managers search for knowledge online, e.g. what are their intentions and expectations [START_REF] Guzman | Internet search behavior as an economic forecasting tool: The case of inflation expectations[END_REF][START_REF] Wu | The future of prediction: how Google searches foreshadow housing prices and quantities[END_REF]. For example, interviews with managers could shed light on how and why they utilize Internet search engines to learn about new management concepts and ideas. In addition, such investigations could provide a window into managers' decision-making process and motivations for seeking out new management knowledge.

Finally, Wu and Brynjolfsson (2009, p. 13) have noted that "the abundance data from Google Trends allows researchers to study numerous topics". There are possibly numerous other applications in the field of managerial and organizational behavior. This paper should be seen as an enticement for further research on GT in the context of organizations and management.

Figure 1 :

 1 Figure 1: "Big Data" Data source: Google Trends (www.google.com/trends), 02/15/2016

Figure 2 :

 2 Figure 2: Search term "Balanced Scorecard" Data source: Google Trends (www.google.com/trends), 02/15/2016

Figure 3 :

 3 Figure 3: Search terms "Data Mining" vs. "Big Data" Data source: Google Trends (www.google.com/trends), 02/15/2016

Figure 4 :

 4 Figure 4: Regional interest in "big data" Data source: Google Trends (www.google.com/trends), 02/15/2016

Figure 5 :

 5 Figure 5: Related searches to "CRM" Data source: Google Trends (www.google.com/trends), 02/15/2016

Table 1 : Pros and cons of using GT

 1

	Pros

AUTHOR PROFILE:

Dag Øivind Madsen earned his Ph.D. at the Norwegian School of Economics (NHH) in 2011. He currently works at the University College of Southeast Norway.