Evelyn Rojas

Ana Cristina Barros
email: acbarros@inescporto.pt

Américo Azevedo

Antonio Batocchio
email: batocchi@fem.unicamp.br

Evelyn Paola

Soto Rojas

Américo Lopes De Azevedo

Business Model Development for Virtual Enterprises

Keywords: Virtual Enterprise, Business Model, Collaboration, Competitiveness

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The global economy is driven by or revolves around constant innovations. Therefore, many organizations seek today to create and capture innovations by systematically collaborating with outside partners [START_REF] Osterwalder | Clarifying Business Models: Origins, Present and Future of the Concept[END_REF]. One form of collaboration is the use of virtual enterprises and organizations are motivated to create them in order to perceive business goals they cannot achieve alone. These business goals may vary from the exploration of new market segments and opportunities to the reduction of costs or risk sharing [START_REF] Camarinha-Matos | Collaborative networks: value creation in a society. Knowledge Enterprise: Intelligent Strategies in Product Design, Manufacturing and Management[END_REF], [START_REF] Lambert | Supply chain partnerships: model validation and implementation[END_REF]. This main purpose for the formation of a virtual enterprise sets out its objective and will be the basis to establish its strategy, namely to define how it will achieve high levels of performance in the markets and industries it wants to operate [START_REF] Barney | Resource-based theory: Creating and sustaining competitive advantage[END_REF]. The interest in business model development is not a recent topic. According to Magretta [START_REF] Magretta | Why business models matter[END_REF] "A successful business model represents a better way than the existing alternatives. It may offer more value to a discrete group of customers. Or it may completely replace the old way of doing things and become the standard for the next generation of entrepreneurs to beat". Given the importance of innovation on the business model, this paper aims at identifying key business model elements necessary to build a business model for virtual enterprises. It features an in-depth literature study spanning various definitions, taxonomies, and ontologies about the business model and virtual enterprises themes. Subsequently, evidence from a pilot case study confirms its applicability in practice. This paper is organized as follows. Section 2 reviews the literature about business model definition and Virtual Enterprise (VE) characteristics in order to build a theoretical background that supports the identified business model elements for a VE. Section 3 presents the research methodology and section 4 the paper's theoretical contribution by describing the sixteen business model elements identified for the development of a business model for a VE. Evidence from the pilot case study is presented and discussed in Section 5. Finally, section 6 concludes the paper.

Literature Review

Business Model Definition

An organization's business model is its driver for success, because it operationalizes the entrepreneurial opportunity that creates competitive advantages for the organization in its market [START_REF] Franke | Venture capitalists' evaluations of start-up teams: Trade-offs, knock-out criteria, and the impact of VC experience[END_REF], [START_REF] Markides | Game-changing strategies: How to create new market space in established industries by breaking the rules[END_REF]. The success of many companies, e.g. Groupon, Ryanair, Amazon and Dell, can be attributed to the way they innovated their business models, challenging established industries and changing the rules of competition [START_REF] Kumar | From Market Driven to Market Driving[END_REF]. However, consensus about the definition of a business model has not been achieved among academics. Looking into the literature, we find several different constructs of the concept.

Amit and Zott [START_REF] Amit | Value Creation in E-Business[END_REF] point out that "…The business model depicts the content, structure, and governance of transactions designed so as to create value through the exploitation of business opportunities". The framework proposed by these authors contains three-design elements -content, structure and governance -and four design themes -novelty, lock-in, complementarities and efficiency. This business model definition is flexible enough to be applied it to different industries and stages of venture maturity.

For Osterwalder et al. [START_REF] Osterwalder | Clarifying Business Models: Origins, Present and Future of the Concept[END_REF] "…Business model is a conceptual tool that contains a big set of elements and their relationships and allows expressing the business logic of a specific firm. It is a description of the value a company offers to one or several segments of customers and of the architecture of the firm and its network of partners for creating, marketing, and delivering this value and relationship capital, to generate profitable and sustainable revenue streams".

Morris et al. [START_REF] Morris | The entrepreneur's business model: toward a unified perspective[END_REF] propose the following definition "…A business model is a concise representation of how an interrelated set of decision variables in the areas of venture strategy, architecture, and economics are addressed to create sustainable competitive advantage in defined markets". These authors value the relationship between business model and strategy, and argue that a good business model captures the core logic and dominant strategy of a venture.

Chesbrough [START_REF] Chesbrough | Business model innovation: it's not just about technology anymore[END_REF] argue that "…The business model is the heuristic logic that connects technical potential with the realization of economic value". The authors go beyond the creation of value by taking organizational aspects into consideration.

These various definitions are distinct, but complementary. Other points of view to define the business model have focused on: value creation [START_REF] Klueber | Business model design and implementation for e-services[END_REF], organizational aspects of the business model definition [START_REF] Timmers | Business Models for Electronic Markets[END_REF], [START_REF] Lechner | Business models and system architectures of virtual communities: from a sociological phenomenon to peer-to-peer architectures[END_REF], [START_REF] Gangakhedkar | Business Models for Electronic Commerce[END_REF], and performance and sustainability [START_REF] Afuah | Internet business models and strategies[END_REF], [START_REF] Rappa | The utility business model and the future of computing services[END_REF].

Based on the definitions from the literature reviewed, for the purpose of this paper, we define business model as follows: A business model explains how the logic of the organization is, the way it operates, and how it creates value for its stakeholders.

Previous works exist that have studied business model development in the context of business networks. Palo and Tähtinen [START_REF] Palo | A network perspective on business models for emerging technologybased services[END_REF] developed an empirically grounded conceptualization of a networked business model. The authors identified the generic elements of a business model in the field of technology-based services and propose to use these elements to build a networked business model.

Helander and Rissanen [START_REF] Helander | Value-creating networks approach to open source software business models[END_REF] developed a theoretical study in which they highlighted that in a network context the business model of a company must be linked to the business model of the other companies involved in the partnership. In addition, Komulainen et al. [START_REF] Komulainen | Business model scenarios in mobile advertising[END_REF] identified three core elements for a network business model: product/service, business actors and their roles, and value-creating exchanges among the actors. And yet, among the existing research literature, we do not find works oriented to the context of virtual enterprises. Therefore, this paper contributes to this body of literature by proposing a set of business model elements to be used by virtual enterprises.

Virtual Enterprise: Relevant Characteristics and Key Issues of Competitiveness

In an attempt to increase the global competitiveness of firms, in recent years a variety of new organizational structures based on collaboration have emerged. These structures are alliances between companies, created to overcome the various limitations and challenges of the market. Thus, companies that specialize in certain knowledge, which is focused on its core competencies, seek to align themselves with other companies to fully meet the requirements of new products and services demanded by the market. Virtual Enterprise is one form of collaborative networks that allows partners to exploit emerging business opportunities in a flexible way.

Virtual enterprises have been widely discussed over the past decade. The definition of virtual enterprise used in this paper is based on the definition proposed by Camarinha-Matos et al. [START_REF] Camarinha-Matos | Collaborative Networked Organizations -Concepts and practice in manufacturing enterprise[END_REF]: "…Virtual Enterprise represents a temporary alliance of organizations that come together to share skills or core competencies and resources", in order to answer to a specific business opportunity.

The concept of Virtual Enterprise (VE) is proposed as a competitiveness strategy that provides the features needed for companies to compete in the market and meet consumer needs, by means of shortening the time-to-market of their products and services. In addition, through the collaborative partnerships formed within the virtual enterprise, companies profit from further advantages, such as the division of costs, resources, and market expansion. An organization can play various roles within a VE during the different stages of the VE lifecycle. Indeed, various types of agents can be found inside and around a VE, acting in roles such as Broker of the VE, VE Coordinator, and Member of the VE. According to Molina et al. [START_REF] Molina | Virtual Enterprise Brokerage: A Structuredriven Strategy to Achieve Build to Order Supply Chains[END_REF] the broker is the key player in the formation of the VE, as it performs the process of partner search and selection by setting up appropriate infrastructure (considering physical, legal, social, cultural, and informational) for the formation of the VE.

The creation of a VE is triggered by the identification of a new business opportunity. Subsequently, partners with the skills needed for product development and manufacturing are selected. After the negotiation of contracts for signature, the virtual enterprise is ready to start its operations. Temporality is an important characteristic of virtual enterprises because it seeks to operate in the short run, and aims to achieve business opportunities in the short and medium term. Virtual enterprises are expected to overcome enormous spatial and temporal barriers, bringing together geographically dispersed resources.

The central feature of the virtual enterprise is the complementarity of skills between partners, i.e. each network partner dominates a sub-process or has a critical knowledge about a specific process, product, or market. All partners have to contribute directly or indirectly in creating customer value. Thus, the combination of skills provides synergy and greater flexibility to meet customer requirements. According to Larson [START_REF] Larsson | Engineering 2.0 -Exploring Lightweight Technologies for the Virtual Enterprise[END_REF] one of the potential success factors in this kind of collaboration is the ability to effectively and seamlessly assemble and utilize a pool of resources, derived from the various combinations of specific capabilities of the VE partners. Using this approach, partners can together achieve competitive advantages with minimum investment in permanent staff, fixed assets, and working capital.

Another feature of a virtual enterprise is its high flexibility. An organization can easily, join and leave at any time during the operation of the virtual enterprise. In a competitive environmental, the virtual enterprise is able to provide solutions that allow the replacement of partners, thus responding quickly to changing business needs. Table 1 summarizes the main characteristics of VE and some effects on competitiveness.

Table 1. Virtual Enterprise and Competitiveness

Characteristics Effects on Competitiveness Source

Driven by opportunity

Explore specific business opportunities

The structure of the virtual enterprise allows it to respond quickly and effectively to a particular market demand, due to its high capacity for innovation and customer orientation.

[22], [START_REF] Camarinha-Matos | The Virtual Enterprise Concept[END_REF], [START_REF] Azevedo | A emergência da empresa virtual e os requerimentos para os sistemas de informação[END_REF], [START_REF] Bremer | Virtual organization models: Brazil and Mexico[END_REF] Network dynamics and temporary Permeate organizational boundaries, through partnerships, allows the virtual enterprise to explore new competitive advantages, extracting the maximum value from its partners.

[22], [START_REF] Camarinha-Matos | The Virtual Enterprise Concept[END_REF], [START_REF] Azevedo | A emergência da empresa virtual e os requerimentos para os sistemas de informação[END_REF], [START_REF] Bremer | Virtual organization models: Brazil and Mexico[END_REF]

Mutual

Sharing core competencies among partners

The combination of skills provides synergy and greater flexibility to meet customer requirements.

[22], [START_REF] Camarinha-Matos | The Virtual Enterprise Concept[END_REF], [START_REF] Azevedo | A emergência da empresa virtual e os requerimentos para os sistemas de informação[END_REF], [START_REF] Bremer | Virtual organization models: Brazil and Mexico[END_REF] Integration of business processes Sharing resources, information, and knowledge enables the network to gain competitive advantages by sharing available individual capacity.

[22], [START_REF] Camarinha-Matos | The Virtual Enterprise Concept[END_REF], [START_REF] Azevedo | A emergência da empresa virtual e os requerimentos para os sistemas de informação[END_REF], [START_REF] Bremer | Virtual organization models: Brazil and Mexico[END_REF],

[27]

Flexibility

Companies can participate in multiple networks simultaneously Resources can be easily reallocated to respond the opportunities of the constantly changing global market.

[22], [START_REF] Camarinha-Matos | The Virtual Enterprise Concept[END_REF] [25], [START_REF] Bremer | Virtual organization models: Brazil and Mexico[END_REF],

[27] An organization may easily enter or leave the network

Research Methodology

This work aims at identifying the key business model elements necessary to build a business model for virtual enterprises. Consequently, we formulate our research question as follows: What are the relevant elements for the business model development of a virtual enterprise? This study followed two steps. First, we reviewed the literature on both areas of business model development (section 2.1) and virtual enterprises (section 2.2), in order to identify the business model elements suitable for virtual enterprises. Second, we carried out a pilot case study to verify if the business model elements identified are considered in practice [START_REF] Yin | Case Study Research: Design and Methods[END_REF]. The case study selected is a virtual enterprise of five members formed in the Northern Region of Portugal to explore a customer need. The unit of analysis is the VE and the data collection method used was two semi-structured interviews, one with the VE broker and the other with a VE member. Interviewer bias was countered with the use of an interview guide, the presence of two interviewers, and tape recording of the interviews. In next sections we introduce the business model elements proposed and present the pilot case study.

Business Model Elements for Virtual Enterprises

From the business model components shown by several authors in the literature and the virtual enterprise characteristics identified in section 2.1, we present in Table 2 the sixteen business model elements for VE's proposed in this paper.

Table 2. VE features and Business Model Elements

VE

Characteristics Business Model Components Source

Driving by Business Opportunity

CUSTOMERS

Customer needs [START_REF] Molina | Virtual Enterprise Brokerage: A Structuredriven Strategy to Achieve Build to Order Supply Chains[END_REF], [START_REF] Camarinha-Matos | The Virtual Enterprise Concept[END_REF], [START_REF] Azevedo | A emergência da empresa virtual e os requerimentos para os sistemas de informação[END_REF], [START_REF] Bremer | Virtual organization models: Brazil and Mexico[END_REF] Value proposition [START_REF] Osterwalder | Clarifying Business Models: Origins, Present and Future of the Concept[END_REF], [START_REF] Morris | The entrepreneur's business model: toward a unified perspective[END_REF], [START_REF] Chesbrough | Business model innovation: it's not just about technology anymore[END_REF], [START_REF] Dubosson-Torbay | E-business model design, classification, and measurements[END_REF], [START_REF] Lehmann-Ortega | From buzzword to managerial tool: the role of business model in strategic innovation[END_REF], [START_REF] Casadesus-Masanell | From Strategy to Business Models and onto Tactics[END_REF] Complementarity Adaptation Dynamic participation

VALUE NETWORK

Key Activities [START_REF] Osterwalder | Clarifying Business Models: Origins, Present and Future of the Concept[END_REF], [START_REF] Camarinha-Matos | The Virtual Enterprise Concept[END_REF], [START_REF] Bremer | Virtual organization models: Brazil and Mexico[END_REF] Partners Evaluation Criteria Definition [START_REF] Baldo | IFIP International Federation for Information Processing[END_REF], [START_REF] Mat | Partner Selection: Criteria for Successful Collaborative Network[END_REF] Actors [START_REF] Amit | Value Creation in E-Business[END_REF], [START_REF] Timmers | Business Models for Electronic Markets[END_REF], [START_REF] Palo | A network perspective on business models for emerging technologybased services[END_REF], [START_REF] Komulainen | Business model scenarios in mobile advertising[END_REF], [START_REF] Hedman | The Business model: A means to comprehend the Management and Business Context of Information and Communication Technology[END_REF], [35], [36] Roles [START_REF] Palo | A network perspective on business models for emerging technologybased services[END_REF], [START_REF] Komulainen | Business model scenarios in mobile advertising[END_REF], [35] Core competences [START_REF] Palo | A network perspective on business models for emerging technologybased services[END_REF], [START_REF] Camarinha-Matos | The Virtual Enterprise Concept[END_REF], [START_REF] Bremer | Virtual organization models: Brazil and Mexico[END_REF] Sharing resources and processes Automation Polymorphism Flexibility

VALUE EXCHANGE

Shared Resources/Activities [START_REF] Palo | A network perspective on business models for emerging technologybased services[END_REF], [START_REF] Helander | Value-creating networks approach to open source software business models[END_REF], [START_REF] Camarinha-Matos | The Virtual Enterprise Concept[END_REF] Shared Information Technology Supporting [START_REF] Chesbrough | Business model innovation: it's not just about technology anymore[END_REF], [START_REF] Alt | Introduction to special section on business models[END_REF], [START_REF] Mason | The practice of business models[END_REF] VALUE CAPTURE Cost [START_REF] Osterwalder | Clarifying Business Models: Origins, Present and Future of the Concept[END_REF], [START_REF] Rappa | The utility business model and the future of computing services[END_REF], [START_REF] Brousseau | The economics of digital business models: A framework for analysing the economics of platforms[END_REF], [START_REF] Stewart | Internet marketing, business models and public policy[END_REF] Revenues [START_REF] Osterwalder | Clarifying Business Models: Origins, Present and Future of the Concept[END_REF], [START_REF] Morris | The entrepreneur's business model: toward a unified perspective[END_REF], [START_REF] Timmers | Business Models for Electronic Markets[END_REF], [START_REF] Alt | Introduction to special section on business models[END_REF], [START_REF] Stewart | Internet marketing, business models and public policy[END_REF], [START_REF] Yip | Using Strategy to Change Your Business Model[END_REF], [START_REF] Wikström | Business models in project business[END_REF], [START_REF] Teece | Business models, business strategy and innovation[END_REF], [START_REF] Westerlund | SME business models in global competition: a network perspective[END_REF], [START_REF] West | Value Capture and Value Networks in Open Source Vendor Strategies[END_REF] NETWORK GOVERNANCE

Flows of information [9], [13] Security policies

[9] KPI network performance [START_REF] Camarinha-Matos | Performance indicators for collaborative networks based on collaboration benefits[END_REF], [START_REF] Romero | Mechanisms for assessing and enhancing organisations' readiness for collaboration in collaborative networks[END_REF] Benefits Sharing [START_REF] Amit | Value Creation in E-Business[END_REF], [START_REF] Timmers | Business Models for Electronic Markets[END_REF] This business model elements identified for the context of virtual enterprises are showed in Figure 1. Starting with the identification of the customer's needs, a virtual enterprise defines its value offer to a customer through an innovative solution. This innovation is the basis for developing the value proposition. The Value Network is further characterized by the VE key activities; Partners evaluation criteria definition; the organizational actors, their roles and core competences. Here the VE defines how the access to the complementary skills between organizations and the different types of knowledge exchange in a network will influence the network value [START_REF] Helander | Value-creating networks approach to open source software business models[END_REF].

Value Exchange deals with the transfer and transformation of the various resources, the effective combination of resources and capabilities of all actors in the network and how they create value, not only for the network's end customer but also for the network's partners [START_REF] Komulainen | Business model scenarios in mobile advertising[END_REF]. The important elements to be considered are: technology requirements, shared resources, and shared information.

Value Capture or value appropriation, according to West [START_REF] West | Value Capture and Value Networks in Open Source Vendor Strategies[END_REF], explain how the value creation is captured in order to sustain the business activity. The Value Capture elements identified were: Cost structure and Revenues source.

Network Governance refers to the different instruments that assess the performance level of the network, maintain a strict control of information, resources and capabilities of all actors in the network. The Network Governance elements identified were: flows of information, security policies, KPI network performance and benefits sharing.

Case Study

The Virtual Enterprise in study is located in the Northern Region of Portugal and was conceived due to the vision of Firm A (network broker) to develop a new industrial equipment in collaboration with other organizations, following a network approach. Firm A is a market-leading company that provides solutions for surface adhesion, dry lubrication, and corrosion. Firm A considers the production technology and the level of training and knowledge of the painting line operators as core capabilities and driving factors of its quality. Therefore, since the operators' training process requires approximately two years for the worker to achieve a high level of expertise, Firm A decided to create a synergetic partnership to develop a robotic cell that would learn the operator's movements and recreate them. In this way, a virtual enterprise was created with five actors: Firm A as the network broker, two research laboratories providing knowledge on robotic technology (members B and C), Firm D as the equipment manufacturer, and Firm E providing software solutions. Previous experience of one respondent specifically emphasized that it is very difficult to work in a collaborative network environment without a leading company. In our case study Firm A is the leading member, responsible for assuring that the VE accomplishes its objective and for the negotiations within the VE members.

Our focus when conducting the semi-structured interviews was to explore whether the sixteen business model elements proposed in this paper through literature review, were in line with practice. The interviews were structured around themes. First, we focused on the customer needs (explained in the preceding paragraph) and the requirements for developing the robotic solution. When asked about the VE Value Network and its covering topics -VE key activities, partners' evaluation criteria definition, actors, roles, and core competences -the respondents were easily able to describe in great detail all these components. Respondents showed detailed understanding of the definition process of roles and responsibilities of each partner, and how the cost structure under contract was defined. A strong contributor to the increase of the level of trust among parties was the real-time information sharing with full visibility and transparency for all VE members. The information exchange is performed through a web-based platform provided by the research laboratory B, which includes mechanisms for monitoring and controlling the flow of information between organizations. Benefits sharing were perceived as cornerstones of the VE's business model. Through the cooperation and close relationships, each member of the virtual enterprise brings its expertise in the development of new industrial equipment creating a competitive differentiator in the market. Finally, the broker emphasized that in terms of evaluating the performance of the virtual enterprise, the most important aspect is the timely fulfillment of the activities planned. Evidence from the case study shows, that the defined business model elements are present in this case. However, further research is needed to validate these elements in other types and more complexes networks.

Conclusions and Further Research

The fast changing market has established new standards of competitiveness for all types of organizations and has required fundamental changes in their business strategies. Thus, business model innovations have gained strength in recent years, appearing as a great opportunity that brings benefits for organizations.

This paper contributes to both fields of business model development and virtual enterprises by proposing a set of elements for the development of a business model for virtual enterprises. We were able to identify sixteen elements needed to define the business model of a virtual enterprise: Customer needs; Value Proposition; VE Key Activities; Partners (Partners Evaluation Criteria Definition, actors, roles, core competences); Relations/Ties (shared resources and shared information); Technology Requirements; Cost, Revenues; and Network Governance (Flows of information, Security policies, KPI network performance and benefits sharing).

Through the development of a pilot case study we were able to collect evidence, that the defined business model elements are present in virtual enterprises. However, further research is needed to validate these elements in other types of networks.

Figure 1 .

 1 Figure 1. Business Model Elements for Virtual Enterprise

Acknowledgments. The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement n° FoF-ICT-2011.7.3 -285220 (Adventure Project -ADaptive Virtual ENterprise ManufacTURing Environment). The authors would like to thank INESC Porto for its support and the Adventure Project for their input and contributions.


Nils Jeners
email: nils.jeners@rwth-aachen.de

Wolfgang Prinz
email: wolfgang.prinz@fit.fraunhofer.de

From Groupware to Social Media -A Comparison of Conceptual Models

Keywords: groupware, social media, meta model, conceptual model

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Groupware has a long history [START_REF] Ellis | Groupware: some issues and experiences[END_REF]. All systems belonging to this class of applications are trying to help workers to organize their work and get it done. A lot of research and developments has been made for professional scenarios. Social Network Sites which rise since 1997 [START_REF] Boyd | Social network sites: Definition, history, and scholarship[END_REF], evolve from leisure or non-professional use cases within groups of friends or people with same interest. These systems do not try to represent business workflows or support organizational tasks. These systems try to keep leisure cooperation simple, e.g. arrange an evening with friends, or share pictures from a party.

Nowadays these systems are also used in professional environments. Not for marketing purpose only, but also for organizational communication (yammer.com) and setting project meetings (doodle.com) for example.

Big companies such as Cisco copy social network concepts of systems like Facebook and many others. Business applications like Cisco's Quad 1 and Jive2 evolved trying to bring social systems into a professional environment.

If we anticipate that there are groupware systems on the professional side, and social media on the leisure side, we want to identify the influences each of the system has to one another. Further we want to ask whether these two types remain on each side or merge and evolve to one system class that is either for professional and leisure usage scenarios.

Therefore we developed a generic model which can represent all the systems and tools that we are using in daily work and private cooperation. This generic model consists of abstract classes that are instantiated with each analyzed system. With the generic model in mind we are able to compare the systems component by component and find out whether the systems are based on similar concepts with different shapes, or not.

Common underlying concepts provide the potential to transform one system in to another. Legacy groupware systems can evolve and be enhanced to social systems, keeping the same set of features with another shape or different UI. To identify the key concepts and point on possible transformations we try to apply the meta model.

In the following we first present related approaches in modeling cooperative applications. This is followed by the presentation of our conceptual model and its instantiation for two example systems. Afterwards we will compare the particular adoption of core concepts by groupware and social media systems.

Background

A lot of models help to classify groupware in general. The Space/Time matrix of Johanson [START_REF] Johansen | Leading business teams[END_REF] and the 3C-Model of Teufel [START_REF] Teufel | Computerunterstützung für die Gruppenarbeit[END_REF] are the most famous of them. These models are suitable as a taxonomy, however an instantiation of these models is not possible.

The Zachman Framework is an early framework for information systems architecture [START_REF] Zachman | A framework for information systems architecture[END_REF] that can also be applied on groupware systems. Its basic concepts are roles and perspectives, which also fit on groupware and social media. The framework of Zachman is quite useful in terms of planning and developing applications. Like a pattern language it provides a mutual understanding for all stakeholders.

The basic building blocks of group communication support systems are roles, message objects, functions and rules [START_REF] Prinz | Relevance of the X.500 Directory to CSCW Applications[END_REF]. A so called CSCW system with the above mentioned building blocks access a common underlying system which provides services to applications and user access. TOSCA [START_REF] Prinz | TOSCA: Providing Organisational Information to CSCW applications[END_REF] and MOCCA [START_REF] Benford | MOCCA: An Environment for CSCW Applications[END_REF] understand CSCW systems as a heterogeneous collection of applications, paradigms and models and not a single system. Within this environment there are models that specify the environment. The four presented models (informational model, organizational model, workspace model, and room model) are considered as perspectives with an abstract view on the environment functionality.

Three aspects of groupware concept models defined by Ellis et al. [START_REF] Ellis | A conceptual model of groupware[END_REF] are the ontological model, the coordination model and the user-interface model. The ontological model consists of objects and the operations on these. Objects are modeled with attributes and values. Values can either be atomic or other objects. The operations are divided in four classes, namely view, create, modify, and destroy. Objects own an intended semantics or an operational semantics. The coordination model covers the dynamic aspects in terms of activities. Activities are performed by actors with a specific role. Procedures are sets of activities. The third aspect is the user interface, the appearance of the system, the user experience.

The reference architecture proposed in [START_REF] Peristeras | Towards a Reference Architecture for Collaborative Work Environments[END_REF] identifies several layers as well as architectural components. Most relevant for our approach are the basic services that realize access to the underlying data structures which implement the concepts identified in this paper. The generic CSCW model, proposed by Farias et al. [START_REF] Farias | A Conceptual Model for the Development of CSCW Systems[END_REF], consists of four concepts, namely activity, actor, information and service, whereas activity is the core that connects everything. An activity consists of a goal and a state. It is performed by an actor, uses information and supports services. The ARCON framework provides help in order to understand, design and implement collaborative networks [START_REF] Camarinha-Matos | A Modeling Framework for Collaborative Networked Organizations[END_REF]. A reference architecture that helps enterprises to cooperate in virtual enterprises is VERAM [START_REF] Zwegers | VERAM: virtual enterprise reference architecture and methodology[END_REF].

In summary, several approaches to identify generic architectures and building blocks exist. However, a comprehensive conceptual model that enables the modeling and comparison of different collaborative applications is yet missing. We will present our approach in the next section.

Conceptual Models

In our approach, we first defined elementary actions the user can perform at existing system like Email, Twitter, etc. We categorized these activities to generalize them in a meta model which covers these system. We instantiated the abstract classes with the applied techniques of the existing systems. Our proposed meta model (see fig. 1) consists of abstract classes, that describe the generic system for cooperative applications. Each system implements the abstract classes and inherits from them. The three top-level classes are action, object and system. Action denotes all activities and processes performed by either users of the system or the system itself. Object represents all virtual entities of the system namely person, container, artifact and attribute. The system class contains all systems represented in the meta model. Every implemented class of the model belongs to either one or several systems.

Meta Model

The action class is specialized in the two subclasses activity and process. Activities can be performed by persons who have a specific role and processes can be executed by the system itself, controlled by a rule. Both subclasses can transform (create, modify, and destroy) specific objects, e.g. create a new container, modify an attribute, or destroy an artifact.

Object is the abstract parent class of person, container, artifact and attribute. Person stands for every humane actor in the system, i.e. user, specified by roles. Containers are collections of objects. They can contain containers itself, persons and artifacts. Artifacts denote the basic entities of the system such as messages, files or any other objects the users can interact with. Attributes belong to objects and cannot stand alone. They are always attached to other objects (person, container, and artifact. The two attributes, already implemented are role and rule. Roles specifies person in terms of the activities they can perform. We distinguish between four kinds of roles: Organizational roles describe people in the context of their work hierarchy, e.g. boss, colleague, and partner. Activity roles specify the activities one person can perform, e.g. author, reader. Right roles show the rights a particular person has, e.g. manager, owner. The last kind of roles is the cultural roles. Rules are expressions that can stick to objects and if this rule is valid, a process will be performed. An example for this kind of rule is an autoreply mechanism in email systems or a notification mechanism in shared workspaces.

Instantiated Systems

We instantiated the proposed meta model exemplary with two common cooperation system. We compare email (Fig. 2) on the one hand with the social media system Yammer (Fig. 3) on the other. The instantiated models of the systems are on a more generic level, to not get lost in details and fit into this paper. Fig. 2 shows the basic building blocks of an IMAP email system like it is implemented in Outlook or Thunderbird. It has mails, contacts, folders. Mails are structured in several folders called inbox, outbox, etc., depending on their status (send, received, etc.) and have attributes e.g. from, to, subject, body, etc. There are three roles: author, sender, and receiver, which perform certain activities like write, send, and read. Fig. 3 shows the enterprise social network called Yammer. It mainly consists of posts in certain networks (groups). Posts can contain polls, events, embedded images of videos and different other content. Posts can be liked (as in Facebook) and tagged (called topic) to be searchable. There also are three roles called admin, author, reader, which perform activities like read, write, tag, invite. The two systems are mainly used to exchange certain information with others. Email applies a sending metaphor, where the author writes a message and sends it to the desired receiver. The data (mail) is not owned by the author or the system. The author and the receiver, they both hold a copy. Yammer provides a sharing metaphor.

The author writes a post, and saves it in the system. The data (post) is stored in the centralized system and everybody (with respective rights) can access the data.

While the appearance of these two systems is different, the purpose of the systems is the same. Whether it is called mail or post, does not change the entity which holds the information, but it indicates a different concept.

Comparison of Core Concepts

In this section we compare the particular instantiation of core concepts and their effect. First we look at the people concept group as well as the relation of people into larger sets. The following table 1 identifies four relations. The classic group concept is primarily used in shared folder or teamroom systems, mainly for the purpose of defining access rights. Social media systems relate people by friends and follower networks or in circles (Google+). The difference is that groups are symmetric, while the networks can be asymmetric. This means that all members of a group know each other, i.e. each user knows that the information he provides is accessible to all group members. Friends and follower networks are not as transparent, since they are created individually by each user. Thus two users who belong to the same network of another user do not necessarily know each other. Thus information sharing is more directed to the personal network of a user and not to a symmetric group. In an organizational context this can cause problems as it is often not clear if important information is received by all required people in case that they did not configure their own network accordingly.

Another aspect is the relation and organization of objects into container illustrated in the following table 2. Again the classic approach is the folder approach that organizes objects into a hierarchical order. Most social media systems apply tags to organize and structure object. The advantage is an easier networking of information as long as tags are applied in a disciplined way.

This brief comparison of the implementation of relations of two core concepts indicates that social media systems apply a network-based relationship while classic applications apply a group-or folder-based approach.

Table 3 shows how information is shared among the different systems. In common shared workspace systems, a group respectively a community is the entity in which information is shared. The members of a group are known to everybody within the group. This concept is used to map existing groups, e.g. project groups. A follower network is established by people who are interested in posts from the author. This concept is applied in Twitter and can be compared to subscriber systems of newsfeeds. Walls like in Facebook often tend to be semi-public. A wall belongs to one person and everybody can write to the walls of friends which is not the same as sending a message how it is done in inbox systems. A sender actively decides who the message receives.

Conclusion

This paper presents a conceptual model enabling the instantiation for different collaborative applications and thus their comparison. We have illustrated the instantiation for email as well as the social media system Yammer. The comparison has shown that most model elements are applied by both, yet in a different manner.

The comparison has shown that the two systems do not differ in a great manner, but rather in small pieces how something is called at what core concept is followed.

With believe that this paper contributes to a more systematic understanding of the core elements of collaborative applications. Our next steps will focus on further applications of the model with the aim of further refinement and validation.

1 Fig. 1 .

 11 Fig. 1. Meta model of cooperative systems.

Fig. 2 .Fig. 3 .

 23 Fig. 2. The instantiated meta model with email.

Table 1 .

 1 Relation of people.

		mutual	container visibility purpose
	group	yes	yes	public	Access management
	friends	yes	no	public	Notification management of sender/receiver, publicity two-way
	follower	no	no	public	Notification management of receiver, publicity one-way
	circle/lists no	yes	private	Notification management of sender

Table 2 .

 2 Container of objects.

		cardinality container visibility purpose
	folder, workspace 1:m	yes	public	access management, hierarchy, group
	tags	m:n	no	public	filtering

Table 3 .

 3 Sharing / Messaging / Activity stream concepts.

		responsibility	visibility	purpose
	groups, communities admin or all members public/private	common goal/interest
	follower	user	private	user interest
	walls	friends	friends	public friendship
	inbox	contacts	private	1:1 messages

www.cisco.com/web/products/quad/

www.jivesoftware.com/


Robert John Walters

Stephen Crouch

Phillip Bennett

Building Computational Grids using Ubiquitous Web Technologies

Keywords: Lightweight grid computing, computational grid, Applet, m-grid

Grid computing is an exciting development which promises to be the enabling technology for many users with periodic requirements for massive computing power. There are a number of Grid computing infrastructures available which are fully featured, powerful, efficient and secure. However, for novice users, these systems are not easy to setup and use which presents a significant barrier to their adoption. M-grid offers an alternative approach which permits the creation of a computational grid able to accept tasks from any user with access to the web and distribute them to machines running standard a web browser without any security implications.

Introduction

One of the most widespread applications of grid technology is a computational grid [1-3] whereby a network of machines is organized to permit the distribution of processing power to users with computationally intense tasks. Such a system accepts tasks from users, distributes them for processing and collects the results to pass back to the users. To achieve this, software is installed on all of the machines involved. It is often also necessary to install software on users' machines to present their tasks to the system. This software [1-7] is crafted to ensure the resulting grid offers the very best performance and security but is usually quite extensive and requires considerable configuration. This is not a problem for experts using dedicated hardware but it can be an insurmountable barrier for the interested potential user who needs a light weight system which they can install and use with a minimum of initial effort.

M-Grid in Outline

The heart of a computational grid is a mechanism for tasks to be sent to other machines for execution. This is risky for the receiving machine ("node") since it involves executing code supplied by a third party (Fig. 1). This code might be poor quality; or even be malicious. The traditional solution is to ensure tasks are only ac-cepted from trustworthy users. Nodes then trust coordinating systems only to distribute safe code [START_REF] Grandison | A survey of Trust in Internet Applications[END_REF]. M-grid avoids these issues by using a mechanism for remote execution of code which is available on nearly every machine: the sandbox used by web browsers to execute java applets [START_REF] Chen | Poison Java[END_REF][START_REF] Flannagan | Java in a Nutshell[END_REF][11]. No software needs to be installed as the sandbox is available within the web browsing software on most machines. The sandbox insulates the host from bad behaviour by applets. Preventing applets from damaging of interfering with their hosts, places some limitations on applets but it was felt that these are outweighed by the fact they can be run on virtually any machine without formality. The coordinating machine supplies tasks to nodes as applets dynamically embedded into web pages. All that is necessary for a machine to join m-grid as a computational node is a java enabled browser. Users with jobs to execute upload these (as java applets) to m-grid using a web based interface. A proof of concept system [START_REF] Walters | M-grid: Using Ubiquitous Web Technologies to create a Computational Grid[END_REF] was built using the ASP technology provided within the Microsoft IIS web server supplied the Windows operating system [START_REF] Buser | Beginning Active Server Pages 3[END_REF][14][START_REF] Bergsten | The Apache Jakarta Tomcat 5.5 Servlet/JSP Container[END_REF]. The system has now been completely redeveloped using JSP [11,[START_REF] Bergsten | The Apache Jakarta Tomcat 5.5 Servlet/JSP Container[END_REF]16]. At the same time, some additional features have been added, enabling users to specify that tasks be executed many times with different parameters, some resilience to the failure of nodes to return results and optional security features.

Joining and using M-Grid

There are three roles to a computational grid: the computation nodes, the users with tasks to execute and the coordinator who arbitrates between the other two. Since there is no software to install and no security/trust relationships to establish, joining m-grid as a computational node is trivial; almost any machine can take part. All that is required is open the m-grid page with a Java-enabled browser.

A user who wishes to use m-grid to execute a task first embeds their task into an applet (see below). They then upload this to the m-grid using their web browser.

The coordinator role is the only element which requires any effort to establish. The co-ordinating machine needs to run the Tomcat Java Application container (available free from Apache Software Foundation) [16]. All that then needs to be done is for the m-grid application files to be copied to the correct directory and the URL of the m-grid home page to be advertised.

The Lifecycle of an m-grid Task

A user with task to perform follows the link to the job submission page from the m-grid home page which guides them through the submission process of specifying the jar file containing their applet and an optional file of (sets of) parameters. When a processing node becomes available, the co-ordinator selects a job from those waiting for execution, embeds it in a web page and serves this up to the node. Where a file of parameters is supplied, each line is supplied to a separate instance of the applet. An applet/parameter pair is referred to as a "job instance".

On completion, the applet returns its results to the coordinator which identifies and stores the results ready to be returned to owner upon request. The results are retained by the coordinator until they are deleted by the task owner.

Constructing a Task for Submission to m-grid

In common with most computational grid infrastructures, users wishing to m-grid to execute a task for them must supply it in a form which palatable to the grid infrastructure. In the case of m-grid this means that it must be an applet in a single jar file which can execute within the sandbox of a standard browser. M-grid adds some further requirements which concerned with marshalling outputs at the co-ordinator.

The m-grid task development kit provides resources needed to create applets in the required form. The main class of the applet must inherit from the supplied "MGri-dApplet" class (which itself inherits from the standard applet class). This class encapsulates the various methods for the developer to read parameters and write results. For development, output methods write onto face of the applet. When submitted to m-grid these methods are substituted with others which also marshal and return the output to the task owner (via the coordinator).

Submitting a task to m-grid

A user with a task to submit to m-grid navigates to the m-grid job submission page and uploads their jar file containing the applet together with an optional text file containing the necessary parameters (if required).

Once received by the m-grid coordinator, classes relating to methods provided by the MGridApplet class are substituted with alternatives which include additional functionality required for the applet to read its parameters and return results. The jar file is also checked for all necessary class files and the class containing the main method is identified. A unique job number is allocated for each set of parameters in the file. This job number, the modified user jar file and the parameters are then stored to await execution. Where no parameters file is supplied, a single job instance is stored. This process is shown in Fig. 2. Fig. 2. Uploading a task to m-grid

Execution of a Task

When a node becomes available, the coordinator checks for job instances awaiting execution. It there are no waiting instances, a place holder page is served states that there is no work awaiting execution and causes the node to check again after a short delay. If there are job instances awaiting execution, one is selected, embedded in a page and served up to the node.

The coordinator monitors the status of job instances. Any job instance taking an excessive period of time to produce a result will be downloaded to further nodes as they become available. The coordinator accepts and records the first result it receives; repeat results arrive are discarded. See Fig. 3.

Fig. 3. Job instance execution

M-Grid in Action

A new user's first contact with m-grid will be the homepage. If they wish to volunteer processing capability, all they need to do is to follow the link to "Volunteer your CPU". That's all. If m-grid has work to be done, they will see applets appear in the page, work and send back results. If m-grid is idle the page says so and periodically checks for tasks. When the user decides that they no longer wish to be supporting m-grid's computation they simply close the browser window or navigate to a different page. Fig. 4 shows an m-grid application executing. A user with a task follows the "Submit a job" link to the page shown in Fig. 5. Using this page they first name to their task for later identification. They then give m-grid the location of the jar file containing their applet and a text file of parameters, if required.

The user may then use the "View Jobs" page to see a list of their tasks. The page displays the name of the task and the status of all the job instances within the task. In the example shown in Fig. , there is one task named Task 1 of three job instances, of which the second instance has been allocated (downloaded) to a node and the third is waiting. The first has completed and the link points to a text file containing the outcome, unless an exception occurred in which case details of the event will appear instead.

Issues and Further Work

M-grid has its limitations which will prevent it from challenging more conventional grid infrastructures. Most are inherited from the applet mechanism which it uses. For example, m-grid user applications/tasks cannot use of the local file system on the machine where it is executing and an applet's communications are limited. These constraints are imposed on applets in return for being allowed the privilege to execute without formality. The implementation of m-grid described here has improved on the first implementation in a number of respects:

As m-grid is now a web application running within a container, the previous constrain that the coordinator role be executed on a machine running a Microsoft operating system has been relaxed. M-grid may now be run on any platform for which a suitable application container is available.

Users are now permitted to use any number of classes (provided they are packed into a single jar file).

This implementation is able to survive and complete tasks properly if an appl doesn't complete, for whatever reason. This same behaviour permits it to handle tasks which throw exceptions.

The new implementation permits users to execute a piece of code many times with different parameters to inject this into the system as a single task.

The requirements placed on the user when building their applet have also been simplified by encapsulating them all into the single MGridApplet pure virtual class from which all m-grid applets inherit.

One issued which hasn't been investigated in detail is the performance penalty associated with executing tasks as applets inside a web browser. However, casual observation suggests that the actual performance penalty is modest.

Conclusion

Mainstream grid software is highly sophisticated and provides the very best performance and security. These are large, complex systems which demand significant quantities of hardware, time and effort to establish. However, this is a real barrier for the potential user who is curious about the potential of grid computing and would like to know more.

Much of the difficulty associated with building grid systems arises from the need to install and configure software on all of the machines which will take part. The problem is not just the logistics of reaching the machines the software. It is also many users don't have full control of their machines. Hence a "trial" installation of a grid infrastructure can require obtaining permissions as well as the physical installation. By using the applet mechanism, m-grid avoids most of these difficulties.

The new implementation of m-grid permits a novice potential user to set up a computational grid with very little effort and minimal cooperation from others who have access to java enabled browsers. They can then experiment with the operation of a computational grid. By the time they reach the limits of the m-grid, they will be in a strong position to select, install and operate one of the "full size" grid infrastructures.

Fig. 1 .

 1 Fig. 1. Distribution of Applets to Nodes

Fig. 4 .Fig. 5 .Fig. 6 .

 456 Fig. 4. An m-grid applet executing


Yun Liu

Hua Yuan
email: yuanhua@uestc.edu.cn

Peiji Shao
email: shaopj@uestc.edu.cn

Identification of the Virtual Organization Breeding Environment Based on the Cooperation Network

Keywords: Cooperation Network, Virtual Organization Breeding Environment, Complex Network, Community Identification

Current studies argue that through building the virtual organization breeding environment one can quickly find partners and create a virtual enterprise. The creation of the virtual organization breeding environment requires its own social capital to satisfy some social requirements, but such researches are few This paper, based on complex network theory, proposes a new method to identify the virtual organization breeding environment, which consists of four steps: first is to build the cooperation network from the history of cooperation between enterprises, then is to translate social requirements of the virtual organization breeding environment into structural characteristics, next is to establish the problem model, and final is to design the algorithm of searching for sub-networks (namely virtual organization breeding environments) in the cooperation network, which must meet specific structural characteristics. The proposed method in this paper is based on practical cooperation networks, and therefore is a good guidance to the creation of the virtual organization breeding environment.

Introduction

Afsamanesh et al. argued that in a virtual organization breeding environment (VBE) it was far less costly and much more effective to quickly build a virtual enterprise (VE) [START_REF] Afsarmanesh | A Framework for Management of Virtual Organization Breeding Environments[END_REF]. According to their theories, the planner could select its partners primarily from VBE members; only when there is a lack of skills or capacity inside the VBE, enterprises can be recruited from outside [START_REF] Camarinha-Matos | Towards a Framework for Creation of Dynamic Virtual Organizations[END_REF]. Swierzowicz et al. introduced the concept of social requirements for VBEs and utilized it in a case study to check if it was feasible to create a VBE among 10 steel manufacturers [START_REF] Swierzowicz | Social Requirements for Virtual Organization Breeding Environments[END_REF]. They concluded that some future work should be done, including developing algorithms to identify sub-networks that fulfill a given set of social requirements, within a given network of organizations [START_REF] Swierzowicz | Social Requirements for Virtual Organization Breeding Environments[END_REF].

This paper assumes that the emergence of the VBE is the result of the voluntary, participatory gathering of some enterprises [START_REF] Swierzowicz | Social Requirements for Virtual Organization Breeding Environments[END_REF]. In the past these enterprises have ever cooperated with each other for a long time, so the history of cooperation between them can provide a clue to identify the VBE. This paper proposes a method based on practical cooperation networks in which there are some enterprises that tie together closely and may consist of VBEs.

This paper modifies social requirements put forward by Swierzowicz et al. and translates them into structural characteristics which VBE members should satisfy. Then based on complex network theory, this paper suggests that the problem of identifying virtual organization breeding environments can be changed to the problem of detecting communities in the complex network.

The paper is organized as follows. In section 2, the method based on the cooperation network is presented in detail. In section 3, this method is applied to a case to demonstrate its value. Section 4 is a discussion and section 5 concludes the paper.

2

A New Method Based on the Cooperation Network

Building the Cooperation Network

The cooperation network can be depicted as a graph

) , ( E V G =
, which consists of a set of nodes, denoted as V, and a set of links (also called arcs or edges), denoted as E [START_REF] Otte | Social Network Analysis: A Powerful Strategy, also for the Information Sciences[END_REF]. In the social science field, a node is often referred to as an actor (that is an enterprise), and a link, is an ordered pair (i,j) representing a relationship from node i to node j.

A graph can be represented by a matrix M = ( ij w ). If there is a link from node i to node j, ij w is equal to 1; otherwise 0. In this paper, the matrix M is symmetrical

(that is ji ij w w =
) and there is a reciprocal relationship between node i and node j.

In this situation, the value of wij or wji means the times of actor (enterprise) i and actor (enterprise) j cooperates.

The first step to build the cooperation network is to investigate the history of cooperation between enterprises from newspaper and websites. Such data should be collected as project names, years, participating enterprises and activities undertaken by them.

Then, data can be represented by a matrix in which the rows are all projects and the columns are all enterprises. Each cell of the matrix describes if an enterprise participated a project. If yes, this cell equals 1; otherwise 0. Enterprises are categorized by their primary activities in the cooperation (that are their core competences) and coded. For example, enterprises usually undertaking design are coded as G1, G2, and G3 … It is often the case that network researchers, who see the world in "relational" terms, turn above matrix into an actor-by-actor relational matrix [START_REF] Hanneman | Introduction to Social Network Methods[END_REF]. In this actor-by-actor matrix, each cell measures how many times pairs of actors were co-present at the same event [START_REF] Hanneman | Introduction to Social Network Methods[END_REF].

Next is to turn such matrix to the cooperation network and Fig. 1 shows one sample. In this cooperation network, types of nodes represent enterprises' categories, for example rectangles for designers. Size of nodes indicates strength of enterprises' core competences, and thickness (also known as weights) of links indicates times of cooperation. The Degree ) deg(v is the number of nodes that the node v is connected to [START_REF] Hershkop | Email Mining Toolkit Technical Manual[END_REF].

High degrees usually indicate high levels of being active and wide social influence [START_REF] Hu | A Comparison of Evaluation Networks and Collaboration Networks in Open Source Software Communities[END_REF]. In Fig. 1, nodes with high degrees have large size.

The distances between nodes in a network may be an important macrocharacteristic of the network as a whole [START_REF] Hanneman | Introduction to Social Network Methods[END_REF]. In this paper, the (geodesic) distance ) , ( t s d G is the number of links in the shortest possible walk from node s to node t [START_REF] Hanneman | Introduction to Social Network Methods[END_REF].

The diameter of a network is the largest (geodesic) distance in the (connected) network. } ) , ( max{

, G t s G t s d diam ∈ = (1)

Social Requirements and Corresponding Structural Characteristics of the Network

According to Camarinha-Matos et al., the VBE is an association of organizations and their related supporting institutions that have both the potential and the will to cooperate with each other through the establishment of a "base" long-term cooperation agreement and interoperable infrastructure [START_REF] Camarinha-Matos | Collaborative Networks: a New Scientific Discipline[END_REF]. When one of its members identifies a business opportunity, this member selects a subset of organizations to form a VE/VO [START_REF] Camarinha-Matos | Collaborative Networks: a New Scientific Discipline[END_REF].

A VBE is regulated open and have a controlled boarder, namely at any time new members can join the VBE by complying with its general operating principles [START_REF] Afsarmanesh | A Framework for Management of Virtual Organization Breeding Environments[END_REF]. Afsamanesh et al. argued that there may be different levels of membership, but in this paper, the VBE specifies tight members. Swierzowicz et al. suggested that social requirements be used to define structural characteristics of a network and then be used to check its social capital [START_REF] Swierzowicz | Social Requirements for Virtual Organization Breeding Environments[END_REF]. They also noticed that social requirements are usually at a higher level of abstraction, and therefore, a "translation" between social requirements and structural characteristics of the network is usually required [START_REF] Swierzowicz | Social Requirements for Virtual Organization Breeding Environments[END_REF].

Swierzowicz et al. proposed a set of social requirements that are common to all VBEs, such as the size, the interconnectedness of members, and the distance between members for fast and least mediated communication while forming VO [START_REF] Swierzowicz | Social Requirements for Virtual Organization Breeding Environments[END_REF]. This paper assumes that the emergence of the VBE is the result of the voluntary, participatory gathering of some enterprises [START_REF] Swierzowicz | Social Requirements for Virtual Organization Breeding Environments[END_REF]. Under this situation, social requirements can be modified to:

Core competences of members complement each other, and the number of members owning the same core competence is more than one; Members have ever cooperated with each other; Times of cooperation is larger than a specific value. The VBE in the cooperation network G can be depicted as a sub-network

G E V VBE vbe vbe ⊂ = ) , (
) , in which vbe V represents all members in the VBE and vbe E represents relationships between members.

In the cooperation network, all participating enterprises in a project form a clique in which each node is the neighboring node of others. So this paper argues that, if a node is one member of the VBE, its neighbors in this clique may also be members of the VBE. Table 1 shows above social requirements and corresponding structural characteristics of the network.

The size of VBE is greater than or equal to m if types of required nodes (namely required core competences) equal to m. The diameter of VBE is 1 because members in the VBE form a clique.

The weights of all links are larger than a specific value. The specific value f is computed as the following:

First is to sort weights of all links in the cooperation network from large to small, next is to select the specific weight, that is, the sum of weights locating before it and itself is larger than 80% of the total.

The Problem Model

In the cooperation network

) , ( E V G = , the node V u ∈ is designated as the start node, then subsets (sub-network) G X ⊂
satisfying the following structural characteristics can be searched from it.

       = = > = ≥ ∈ ∈ ∈ ∑ 1 )} , ( max min{ ) ( ) ( , ) ( , , t s d X diam f w m x type m X size X X t s VBE t s st X x (2)
If X exists, it would be the VBE. If an enterprise participates many projects, the degree of the node representing this enterprise in the cooperation network would be very high. While a VBE exists, it can be concluded that this enterprise must be one member of the VBE. So this paper searches the subsets X from such node.

Algorithm

The identification of the VBE is very similar to community detection in complex networks. Communities within the network can loosely be defined as subsets of nodes which are more densely linked, when compared to the rest of the network [START_REF] Newman | Detecting Community Structure in Networks[END_REF]. The problem of community detection has been the subject of discussion in various disciplines [START_REF] Newman | Detecting Community Structure in Networks[END_REF][START_REF] Danon | Comparing Community Structure Identification[END_REF]. Costa reported a simple and powerful hub-based community finding methodology, especially aiming at those networks in which nodes organized around hubs into communities [START_REF] Costa | Hub-Based Community Finding[END_REF]. Here, a hub referred to a node in a network exhibiting high degree [START_REF] Costa | Hub-Based Community Finding[END_REF].

The identification of the VBE does not need to partition the cooperation network into communities, but rather search for subsets that satisfy structural characteristics in (2). However, Costa's methodology is still a good reference.

While identifying the VBE, first is to get nodes

} | { V u u i i ∈
in the cooperation network that have high degrees, next is to check iteratively if there is subsets X that includes i u and satisfies structural characteristics in [START_REF] Camarinha-Matos | Towards a Framework for Creation of Dynamic Virtual Organizations[END_REF]. Above algorithm is shown as the following:

program put the nodes that have higher degrees than the average in

} | { V u u i i ∈ compute the
Y u i U if ∑ ∈ = Xi x m x type ) ( X = Xi output X end end end

Case Study

The production mode in the heavy equipment manufacturing industry is usually orderto-make, and in order to respond to business opportunities agilely the system integrator must unite some independent enterprises to form a temporary alliance (that is the VE). Fig. 2 shows the value chain of the heavy equipment manufacturing industry. In this value chain there are system integrators, industry design & research institutes, heavy equipment manufacturers, logistics service providers, industrial equipment installation companies and users, which have different core competences. After a the algorithm in 2.4, results show that there is not a sub-network (subsets) that satisfies structural characteristics in [START_REF] Camarinha-Matos | Towards a Framework for Creation of Dynamic Virtual Organizations[END_REF]. But there exist 6 would-be VBEs.

Fig. 4 shows these 6 would-be VBEs, and the reason why they cannot satisfies structural characteristics in ( 2) is that the number of types of nodes in them do not achieve m. These 6 would-be VBEs overlap, and G1, X1 and F2 are the nodes that are shared the most. The authors compare these 6 would-be VBEs through computing their densities, which are 2.8333, 3.1667, 3.6667, 3.1667, 3.1667 and 3.5 separately. It is found that the possibility of 3 to develop into a true VBE is greatest.

Discussion

In the case study, no sub-networks satisfy all social requirements; this is because Chinese companies are taking place foreign companies to become system integrator gradually. At first, users ran fast in this competition. Because of user preference and the limitation of the location, there is little possibility that enterprises cooperated again in the next project, thus resulted in that enterprises could not aggregate. Under this situation, the requirement of the size can be relaxed, and sub-networks that satisfy other requirements can be found and they form original VBE. Then enterprises that enable the VBE to satisfy all social requirements should be attracted to join the VBE.

In this paper, the VBE specifies tight members. That is, tight members must be found first, and they form original VBE, then loose members can be attracted into the VBE. When there is a lack of skills or capacity inside the VBE, enterprises can be recruited from outside [START_REF] Camarinha-Matos | Towards a Framework for Creation of Dynamic Virtual Organizations[END_REF]. After that, if they want, they can join the VBE.

In the case study, Industry design & research institutes and large Chinese heavy equipment manufacturers grow up slowly and compete with users, so enterprises aggregate around these hubs. In the cooperation network in Fig. 3, because the node of G1 is large than others due to stronger core competences, it is suggested that it can lead the VBE to recruit new members.

Conclusion

This paper proposes a method based on the cooperation network, which can help the VBE planner identify sub-networks so that it develops the VBE. Now this method is applied only to the situation that VBE is the result of the participatory gathering of voluntary enterprises [START_REF] Swierzowicz | Social Requirements for Virtual Organization Breeding Environments[END_REF], other situations such as the creation of a VBE by a third authority [START_REF] Swierzowicz | Social Requirements for Virtual Organization Breeding Environments[END_REF] needs future study.

Fig. 1 .

 1 Fig. 1. The cooperation network Structural characteristics to measure networks offer as follows: The Degree

Fig. 2 .

 2 Fig. 2. The value chain

Fig. 4 .

 4 Fig. 4. The would-be VBEs

Table 1 .

 1 Social requirements and corresponding structural characteristics of the network.

		Social requirements		Structural characteristics
	Size	Core	competences	of	size	VBE (	)	≥	m	and
		members complement each other, and the number of		∑	x type ) (	=	m
		members owning the same	∈ VBE x
		core competence is more
		than one
	Distance	Members cooperated with each other have ever	diam =1	( VBE	)	=	min{	max , VBE t s ∈	d	VBE	(	s	,	t	)}
	Interconnectedness	Times of cooperation is larger than a specific value	s	w VBE st > t ∈ ,	f

period of cooperation, some of them linked very closely and may have the potential and the will to establish the VBE.

Data Collection and Processing

CDCM is one kind of products of the heavy equipment manufacturing industry, and authors in this paper collected data of 11 products manufactured from 2006 to 2009 in China, which included 29 units (each product may have more than one unit). Such data is collected as project names, years, participating enterprises and activities undertaken by them. Because these projects attract many enterprises to participate, their cooperation usually be reported in the newspaper and they also advertise their work in their own websites. Thus, it is not difficult for the authors to collect data from the Internet.

The cooperation network generated from above data is shown in Fig. 3, which has 42 nodes. Weights of links between nodes represent times of cooperation.

Results

In Fig. 3, nodes that have degrees above the average are G1, Y2, F2, C4, G5, X1, F4, C2, X5, Y1(from large to small). Putting them in } | { V u u i i ∈ and computing with


Luis M Camarinha-Matos

Patricia Macedo

Filipa Ferrada

Ana Inês Oliveira

Collaborative Business Scenarios in a Service-enhanced Products Ecosystem

Keywords: Collaborative networks, Services ecosystem, Business scenarios Guiding use case

Effective support to highly customized and service-enhanced products along their life cycle requires new organizational structures, involving the manufacturers, customers and local suppliers in a process of co-creation and co-innovation. In order to properly develop supporting infrastructures, tools and governance models, it is necessary to first identify representative business scenarios which enable individual requirements to be viewed in relation to one another in the context of the overall use case / target domain. In this context, a set of relevant business scenarios derived from the requirements of the solar energy domain are identified and discussed.

Introduction

The notion of service-enhanced product and the associated idea of service-enhanced manufacturing represent a growing trend, particularly in the context of complex products. The motivation is that buyers of manufactured products increasingly want more than the physical product itself, they might want finance options to buy it, insurance to protect it, expertise to install it, support to maintain it fully operational during its life cycle, advice on how to maximize returns from it, expertise to manage it, etc. [START_REF] Marceau | Service enhanced manufacturing in the building and construction product system[END_REF], [START_REF] Shen | Research on Organization Mode Selection of Service-enhanced Manufacturing Enterprise[END_REF].

This has led to the idea of bundling products and services together in customized packages for clients. For the case of complex products, e.g. solar energy plants or intelligent buildings, services are increasingly necessary to ensure that sophisticated component sub-systems can be designed, integrated, operated and maintained as final complex products. In this context, the distinction between delivery of products and services has become less distinct or blurred. As a result, the term "servitization" is also used when referring to provision of services to clients of manufacturing firms [START_REF] Tether | Servitization: The extent and motivations for service provision amongst UK manufacturers[END_REF].

ICT and particularly Internet technologies developments also led to putting greater focus on knowledge and high value added when it comes to design such services. This requires not only a shift from 'goods dominant logic' to 'service dominant logic', but also associated changes in the organizational structures and business models. Provision of integrated services along the life cycle of complex products requires collaboration among multiple stakeholders. More than a shift from product-oriented enterprise to customer-oriented enterprise, a shift to a 'community or ecosystem oriented' model is needed.

On the other hand, despite the developments in ICT and the globalization of the economy, proximity is becoming increasingly important for innovation and growth. In fact, easy interconnectivity is now just a pre-requisite rather than a differentiator in achieving competitive advantage. Therefore, the notion of glocal enterprise emerged to represent the idea of thinking and acting globally, while being aware and responding adequately to local specificities, namely in collaboration with local stakeholders and customers.

This paper presents preliminary results of the GloNet project in this direction.

The GloNet Project

GloNet aims at designing, developing, and deploying an agile virtual enterprise environment for networks of SMEs involved in highly customized and serviceenhanced products through end-to-end collaboration with customers and local suppliers (co-creation) [START_REF] Camarinha-Matos | Collaborative Networks in Support of Service-enhanced Products[END_REF]. The notion of glocal enterprise is implemented in GloNet with value creation from global networked operations and involving global supply chain management, product-service linkage, and management of distributed production units. Further to service-based enhancement, there is a growing trend in manufacturing to move towards highly customized products, ultimately one-of-a-kind, which is reflected in the term mass customization. In fact, mass customization refers to a customer co-design process of products and services which meet the needs/choices of each individual customer with regard to the variety of different product features. Important challenges in such manufacturing contexts can be elicited from the requirements of complex technical infrastructures, solar energy parks, intelligent buildings, etc.

The guiding use case in GloNet is focused on the production and life cycle support of solar energy parks. The norm of operation in this industry is that of one-of-a-kind production. The results (products and services) are typically delivered through complementary competences shared between different project participants. A key challenge is the design and delivery of multi-stakeholder complex services along the product life cycle (typically 20 years). Focused issues: (i) Information / knowledge representation (product catalogue, processes descriptions, best practices, company profiles, brochures, etc.); (ii) User-customized interfaces, dynamically adjusted to assist different stakeholders (smart enterprise approach); (iii) Services provision through cloud; (iv) Broker-customer interaction support: from order to (product/service) design (open innovation approach); (v) Negotiation support; (vi) Workflow for negotiated order solution & its monitoring; and (vii) Forecast risks & suggest prevention measures.

The GloNet project started in Sep 2011 with a planned duration of 3 years, and involves the following partners: CAS (Germany), UNINOVA (Portugal), University of Amsterdam (Netherlands), iPLON (Germany), SKILL (Spain), Steinbeis (Germany), KOMIX (Czech Republic), and PROLON (Denmark).

Use Case Characteristics

The development of business scenarios is an important technique that helps in better characterizing requirements, identifying and understanding business needs, and thus provides important inputs for the next phase of GloNet when a system's architecture has to be designed.

Although the concept is not precisely defined in the literature, the adopted notion here is that a business scenario represents a significant business need or problem in the target domain. In other words, it provides a reasonably extensive description of a business problem, which enables individual requirements to be viewed in relation to one another in the context of the overall use case / target domain [START_REF] Opengroup | Business Scenarios[END_REF].

In order to identify the set of relevant business scenarios for GloNet the following method is adopted (as illustrated in Fig. 1):

1) Start with the guiding use case of GloNet (solar energy plants) and identify its main abstract characteristics, leading to an abstract use case.

2) Analyze the needs of the abstract use case and suggest a set of relevant business scenarios. 3) Confirm the relevance of the scenarios in the context of other use cases.

Possible iterations with phase 2 are included here. 4) Develop detailed descriptions of the selected business scenarios. 5) Confirm the details and refine descriptions in consultation with end-users representative of the use cases / application domains.

D

Business scenarios

Fig. 1 -Identification of relevant business scenarios

As mentioned before, the guiding use case is the solar plants domain, with particular emphasis on the maintenance and operation of the power plants. The other two use cases, which share similar abstract characteristics, are the building automation and the physical incubator facilities for enterprises.

The main characteristics of the target business cases can be summarized by: a. Product characteristics -Complex (physical) product, involving several sub-systems -Long life-cycle, but having components with different life-cycles -Need for business services provision along the life-cycle (service-enhanced product); new services are likely to be demanded -Integrated business services typically combine contributions from multiple stakeholders -Mass customization, nearly one-of-a-kind product (and properly adapted services).

b. Stakeholders characteristics. The manufacturing and service provision for such products involve a large diversity of stakeholders performing a number of roles:

-Product / project designers -Product manufacturers, including sub-systems / components providers -Service providers -Support entities, including financial, insurance, training, cloud infrastructure provision, regulator entities, etc.

-Customers and users differentiation. c. Organizational structures. Stakeholders can appear organized in a number of networked structures that reflect a variety of relationships, some sense of community, and different levels of collaboration maturity. These include:

-Long-term strategic alliances -which typically involve product / project designers, manufacturers, service providers, and some support entities, configuring a kind of virtual organizations breeding environment (VBE) [START_REF] Afsarmanesh | Models, Methodologies, and Tools Supporting Establishment and Management of Second-Generation VBEs[END_REF], [START_REF] Camarinha-Matos | Collaborative Networks: Reference Modeling[END_REF].

A VBE represents an association of organizations and a number of related supporting institutions, adhering to a base long term (formal or informal) cooperation agreement, and adopting common operating principles and infrastructures, with the main goal of increasing their preparedness towards rapid configuration of goal-oriented networks (Virtual Organizations/Virtual Enterprises -VO/VE).

-Customer related communities -involving, besides the customer, local noncritical components suppliers, services providers, and a variety of support entities. Although this group might not be well organized and structured, it shares some minimal bonds like geographical vicinity, culture, business environment, legal regulations, etc.

-Goal-oriented networks -in which intense and well focused cooperation and/or collaboration (towards a common goal or a set of compatible goals) is practiced among their partners. Two inter-related cases are foreseen:

-Product development network -a dynamic (temporary) VE involved in the development of the physical product and design of associated services.

-Product servicing network -a long-term VE organized to provide integrated (multi-stakeholder) business services along the product life-cycle. A product servicing VE might have (a few) members in common with the product development VE, but typically corresponds to a different organizational structure. A mechanism of inheritance between the product development VE and product servicing VE needs to be established. The recruitment base (constituency) for these networks include, preferentially, the manufacturers VBE and the customer related community, but it might also include outside entities (see Fig. 2).

These networked structures need to cope with a variety of membership levels. Instead of a binary "member / not member" situation, multiple degrees of membership have to be considered (e.g. core members, regular members, associated members, etc.) with different levels of rights and responsibilities. The degree of membership might not even be a constant parameter for each entity but rather vary with the context or perspective of analysis, which leads to different geometries of the networks. These networks need to interact and may span over a wide geographical distribution.

Manufacturers network

Relevant Business Scenarios

Identification of relevant business scenarios. When addressing the issue of identifying and selecting relevant business scenarios in GloNet it is important to consider the specificities of a research project and its defined goals. As such, the relevance of business scenarios cannot be determined by the current operational business practices of single companies, but rather by their contribution to identify the "backbone" (models, infrastructure, tools, and processes) for a new way of doing business in a collaborative networked environment. In other words, the selected scenarios should help in creating the conditions to get prepared to effectively doing business in a different way.

Under this perspective, it is also important to consider the need for some base or "enabling" scenarios, which just create the proper conditions for the development of other scenarios that are more directly appealing to an end-user. For instance, while for end-user companies it might be relevant to have a scenario focused on the formation of goal-oriented networks (in response to a business opportunity), it is also clear that the agility of the consortium formation process very much depends on the existence of a long-term strategic network that promotes the preparedness of its members for collaboration. Therefore, the effectiveness of the mentioned scenario depends on the consideration of an "enabler" scenario focused on the management of long-term networks or business ecosystems.

In this context, and after extensive consultation with end-users and system developers, the following business scenarios are considered in the GloNet environment: processes of operation and maintenance of the product 5. Advanced Supervision Services for the Collaborative Network -Handling advanced processes / functionalities of operation and maintenance and network coordination 6. Shared Resources Repository Management -Management of the shared repository of community resources: general sharable information / knowledge (e.g. processes), software tools, lessons learned, etc. 7. Product Portfolio Management -Management of all information related to products: product catalog, product model, historic data on the product (sensorial data, product updates / changes, etc.) … single 'access point' along the product life-cycle. 8. Semi-automated Learning-based Decision Support -to assess the feasibility of building semi-automated learning-based decision making support system for complex products.

Management of Long-term

In terms of representation of business scenarios, the following main elements are considered: (i) Description and purpose, (ii) Goals, outcomes and main features, (iii) Environment and actors, (iv) Details on actors, roles and responsibilities, (v) Business processes, and (vi) Required software services.

In addition to tables and textual descriptions, the following formalisms are adopted to help characterizing the business scenarios: i* (i-star) -to describe actors, individual and common goals, tasks, and their inter-relationships; and BPMN -to represent business processes.

Examples. As an illustration, let us consider the following scenarios:

E1. Management of Long-term Collaborative Network. A Long-term

Collaborative Network is a strategic alliance of organizations adhering to a base long term cooperation agreement while also adopting common operating principles and infrastructure, thus a kind of VBE (Virtual Organizations Breeding Environment). In this case the Solar Plants VBE alliance brings together and supports collaboration among otherwise independent and mostly small organizations which are currently involved in solar plants industry. As such, through the formation of energy-related VBE alliances for instance, collaboration among their stakeholders increase, since they can join their efforts, capabilities, and capacities, to better fulfill the emerged opportunities in the market. A system to support the management of this kind of network provides services to manage member's profiles and VBE's ontology, to support performance management and to manage trust among VBE member.

Strategic goals for this scenario include: Manage admission and withdrawal of members in the VBE; Ensure that complete information about member's profile and competencies are available; Ensure secure access to VBE members; Promote trust among VBE's members; Promote the adoption of a common ontology Fig. 3 (in i* notation) shows the main actors as well as their inter-dependencies in terms of (hard) goals (e.g. Join VBE), soft goals (e.g. Members trust), and resources (e.g. VBE ontology).

Fig. 3 -i* Strategic Dependency model for Long-term Collaborative Network

A more detailed description is shown in Fig. 4, where a zoom in is made on the VBE Coordinator actor.

E2. Co-design and Co-innovation.

This scenario aims at providing an environment that supports and promotes the collaborative design and development of products and services as well as the emergence of innovative solutions. It thus includes the aspects of mass customization as well as the emergence of new products / new solutions to identified needs, through collaboration between manufacturers and the customer and members of the customer's community.

Strategic goals for this scenario include: Co-design and co-development of products, Provide co-innovation support, and Guarantee customer satisfaction & VO partners satisfaction. Fig. 6 shows the main actors and their inter-dependencies for this scenario.

Implementation Issues

GloNet adopts a cloud-based approach [START_REF] Camarinha-Matos | Collaborative Networks in Support of Service-enhanced Products[END_REF] for the development of its ICT environment so that its supporting services can dynamically upgrade without influencing the nodes and stakeholders in the environment. Regarding the base platform the following main characteristics are planned:

Cloud-based infrastructure, based on open-source technologies, adopting relevant standards and based on OSGi. Incremental pool of services, knowledge, and other resources (scalability characteristic). Supporting the notion of extended or service-enhanced product -combination of physical product with a set of linked support services (e.g. maintenance, remote diagnosis, remote user assistance, training, insurance services, etc.). A product model will become available in a Business Services Provision Space as a single entry point for product-related information and services along its life cycle. The product servicing virtual enterprise (see Fig. 2) will naturally be linked to this product model. Besides the cloud-based platform, the environment includes two main (virtual) spaces: (i) Collaborative solution space -where new products and services are designed, developed / customized (co-creation/mass customization) through the interplay of the various stakeholders (product development virtual enterprise); (ii) Business services provision space -where models of products and associated services are kept along the product life cycle, supported by the product support virtual enterprise.

The GloNet platform being developed is aimed to provide not only the mechanisms to compose software services via business processes, but also to model business services and bundle them together with the product.

Since the term 'service' is used by both the business and software communities, it is important to clarify the corresponding meanings and inter-relationships. Fig. 8 summarizes the adopted interpretation.As illustrated, the concept of business service corresponds to an external (i.e. client-oriented) view while the software service is one of the mechanisms to materialize a business service.

Business service

Business process

Software services

A series of activities or tasks that produce a specific outcome. A number of activities or sub-processes that are executed in a certain sequence (chain of activities)… a unit of internal behavior.

Represents the added value that an organization delivers to its environment. Some goods or service that a business component offers to other business components and/or to external parties (e.g. customer).

Users only know about the service itself, along with some relevant properties: price, agreed service levels, terms and conditions. They Software services are the executing elements that perform the business process activities.

Manual activities can also have a "software representation" (interface with the human resource).

Fig. 8 -Relationship between business service and software service

Conclusions

Effective development and exploitation of complex products require that the physical product is enhanced with a number of associated (business) services. These services are likely to integrate contributions from multiple stakeholders and thus require a collaboration environment. Furthermore, the involvement of the customer, and other local stakeholders associated to the customer, in the process of design, development and delivery are important in a context of mass customization and to leverage the 'proximity' factor. GloNet is developing an environment to support such co-design and co-innovation processes for complex and long-life cycle service-enhanced products.

One of the open issues is to assess the adequacy of a cloud computing implementation approach and determine which business models are needed for that approach. Although the advantages of cloud computing for SMEs have been extensively discussed, there are a number of critical issues that remain, namely the lack of interoperability among cloud providers, which raises the issue of risk of business continuity, particularly acute when we address products with a long life cycle, such as the solar energy plants. The business models prevalent in current cloud computing solutions also seem limited when it comes to supporting collaborative networks environments.

Fig. 2 -

 2 Fig. 2 -Main organizational structures in GloNet

Fig. 4 -Fig. 5 -

 45 Fig. 4i* Partial Strategic Rational Model for Long-term Collaborative Network scenario

Fig. 6

 6 Fig. 6 -i* Strategic Rational model for Co-design and Co-innovation

Fig. 7 -

 7 Fig. 7 -BPMN diagram of the Co-innovation Process

  don't need to know what people, processes and technology are being used, nor what other supplier services are contributing to the result.realizesA business service is realized by a business process.

  exposed" as web services

Table 1 .

 1 Mapping to the solar plant use case

	Abstract elements	Solar plant use case
	Product	Complex	Power plant itself.
		(physical)
		product
		Long life-cycle	Typically 20~25 years for the power plant; many
			components / subsystems have shorter lives and need to
			be periodically replaced.
		Business	Examples include: Plant operation & management,
		services	Panel cleaning & preventive maintenance, Training,
			Diagnosis, Performance improvement support, etc.
		Mass	Although sharing some general characteristics, each

  Collaborative Network -Management of the strategic long-term alliance of product designers & manufacturers 2. Formation of Goal-oriented Collaborative Network -Consortia formation for virtual enterprises: product development VE, Product servicing VE 3. Co-design and Co-innovation -Environment and processes to support collaboration with customers and local suppliers (co-creation) 4. Base Operation and Management of Product Servicing -Handling the "trivial"

Acknowledgments. This work was funded in part by the European Commission through the GloNet project (FP7 programme). The authors also thank the contributions from their partners in this project.