A Design Blueprint for Virtual Organizations in a Service Oriented Landscape
AA Design Blueprint for Virtual Organizations in a Service OrientedLandscape
Wajeeha Khalil and Erich SchikutaUniversity of Vienna, Faculty of Computer ScienceResearch Group Workflow Systems and TechnologyW¨ahringerstr. 29, A-1090 Vienna, Austriaemail: [email protected]
Abstract “United we stand, divided we fall” is a well known saying. We are living in the era of virtual collaborations.Advancement on conceptual and technological level has enhanced the way people communicate. Everything-as-a-Service once a dream, now becoming a reality.Problem nature has also been changed over the time. Today, e-Collaborations are applied to all thedomains possible. Extensive data and computing resources are in need and assistance from human expertsis also becoming essential. This puts a great responsibility on Information Technology (IT) researchers anddevelopers to provide generic platforms where user can easily communicate and solve their problems. Torealize this concept, distributed computing has offered many paradigms, e.g. cluster, grid, cloud computing.Virtual Organization (VO) is a logical orchestration of globally dispersed resources to achieve common goals.Existing paradigms and technology are used to form Virtual Organization, but lack of standards re-mained a critical issue for last two decades. Our research endeavor focuses on developing a design blueprintfor Virtual Organization building process. The proposed standardization process is a two phase activity.First phase provides requirement analysis and the second phase presents a Reference Architecture for Vir-tual Organization (RAVO). This form of standardization is chosen to accommodate both technological andparadigm shift. We categorize our efforts in two parts. First part consists of a pattern to identify therequirements and components of a Virtual Organization. Second part details a generic framework based onthe concept of Everything-as-a-Service. “Resource/Service as a utility” once a dream, is now a reality we are living with. Utility computing is nota new concept, but rather it has quite a long history. Among the earliest references is by John McCarthy .Last two decades of Information Technology (IT) development has witnessed the specific efforts doneto make this statement of John McCarthy a reality. Utility computing is providing basics for the currentday resource utilization. Cluster, grids and now cloud computing have made this vision a reality. E-Collaborations also called virtual organizations have been evolved with the technological and paradigm shift.Cluster computing offered more centralized resource pool, while grid computing remaind in need via hardwareand computation cycles offerings to the scientific community. Grid computing models observed a deadlockafter the introduction of cloud computing concepts. This situation was a result of missing economic businessmodels, although some work was done on this issue even by the authors [1, 2, 3, 4]. Based on Pay-as-you-usecriteria, cloud computing is still in early stage. However, the economic component of cloud computing is John McCarthy, speaking at the MIT Centennial in 1961, “Architects of the Information Society, Thirty-Five Years of theLaboratory for Computer Science at MIT”, edited by Hal Abelson a r X i v : . [ c s . C Y ] D ec central focus of actual research [5, 6, 7]. Research efforts are going on to establish the basis of cloudcomputing as Every-thing-as-a-Service paradigm.Infrastructure providing resources as a utility must be dynamic, scalable and reliable. Orchestration of re-sources across the globe, named as Virtual Organization (VO)/Virtual Enterprize (VE) has been extensivelydeployed to achieve this target. Change in the hardware and software technology, computing paradigmsalgorithm and procedures, incorporation of knowledge rather information and data, made the concepts ofVO vague. Though VO had been created utilizing the best technology known to that time, but the successwas short lived. There are three main issues, which has to be considered in order to understand: • Advancement in hardware/software technology. • Birth of new computing paradigms. • Changed nature of resources and requirements from end user.We are living in the age of transformation. A paradigm shift is one that effects the society as a whole.According to Peter Drucker such transformation place over fifty to sixty-year periods [8]. In his book “Post-Capitalist Society”, he outlines three earlier periods of dramatic changes in the Western World. • The rise of medieval craft guilds and urban centuries. Long distance trade (thirteenth-Century Europe)[8]. • The renaissance period of Gutenburg’s printing press and Lutheran Reformation (1455-1519) [8]. • The industrial revolution, starting with Watt’s steam engine (1776-1815) [8].Existing technologies and paradigms do not vanish with the birth of new concepts rather they adopt whatis positive and remove what is not required. Technology and paradigm used to form VO have also facedthis transformation. For example networking, distributed computing, cluster computing, grid computing,utility computing and now cloud computing, all are related and are improvements of the existing concepts.When technology changes or improves, paradigm needs an upgrade too. New methods and algorithms arecreated to support the hardware. Another main factor is the requirements from the user community. Theuser community puts a demand on the technology and computing paradigm and they evolve accordingly.“Resources/Services as a utility” is main theme of collaboration. To achieve the goal(s), organizationsand individuals gather all the resources available. The spectrum of availability has covered the wholeglobe. Today, time and space are not a limit due to Information and Communication Technology (ICT)advancements. This revolution has an impact on the resources types. Initial collaborations offered onlystorage and downloading (P2P networks), computing cycles and storage space (grid computing and clustercomputing). Main focus remained at hardware and software sharing, but VOs for scientific research initiatedanother requirement, i.e. need of a human expert to guide the beginners in the said domain. Expertbecomes an integral part of collaborations. Also, the two way contribution (duplex) motivated us to reviewand categorize the resource in the vicinity of VO. The categorization we presented is also vigilant to depictthe general pattern of resources in any domain.VO is the right place for both technology and computing paradigm to merge and achieve the objectives.In the past two decades collaborative computing has remained main concern of technology produced. Opti-mization of time and heterogeneous resources by building VO is the key point of today’s research directions.Vision of a VO has evolved with the networking and distributed computing concepts.Research community recognizes VO with different names, e.g. collaboratories [9] [10], E-Science or E-Research [9] [11], distributed work groups or virtual teams [9] [12], virtual environments, virtual enterprize[13] and online communities [9] [14]. Initially, focus was to improve business by utilizing the ability to gatherresources which are scattered across the dimensions of time, space and structure. With the advent of moderntechnology, VO has encompassed almost all fields of life. We can say that every human will be soon part ofa VO. VO’s concepts need to be revisited with this evolution in general. VOs have been visioned from thebusiness perspective in early 1990s. Pervasiveness of technology and improvements in computing paradigmshas extended the domain of VO to cover all the areas where individuals and organizations meet to achieve2ome goal (formal Virtual organization) or without any specific common objective, e.g. social networks(informal VO). To the best of our knowledge, till now there are no standard procedures or patterns forhow VO should be created and evolve to accommodate the changes in its integral parts or entities. Lack ofstandards for VO motivated us to provide a standard vision of E-collaboration incorporating both paradigmand technology shift as a Reference Architecture (RA) to achieve common objective(s) in any domain. Ourresearch efforts also introduced new concepts regarding resources and stakeholder of a VO.To provide a standard for VO, we consider the existing technologies and paradigms. Service Oriented Ar-chitecture (SOA), Web 2.0 and Web 3.0 are the underlying technological platform, and computing paradigmsinclude utility computing and cloud computing.During our research process we studied the existing infrastructures available for VO. Utilizing electroniccollaborations for achieving common goals is a tradition rather a requirement. Distributed resources aregathered using an infrastructure and are exploited to obtain the said results. In IT world such collaborationis known as VO. Idea is to provide resources as a utility to the end user. Service-Oriented infrastructures needto act dynamically to fulfil the demands from organizations and businesses. We encountered the followingaddressable issues: • Does existing electronic collaboration approaches follow a standard? • Can we define patterns without predefined standards? • Does existing infrastructures fulfil the requirements of participating entities? • Are the existing infrastructures dynamic and adaptable to the rapidly updating IT and business world? • Can we design a generic platform to integrate resources from multiple domains using essential andoptional parts?Our research aims to answer these questions. VO’s creation process lacks standards/patterns/methods[9]. We analyzed existing VOs and the process of their creation through available documentation. We foundthe following answers to the above questions: • Currently, there exist no specific standards for building VO or E-collaboration. • Existing infrastructures are modified for specific domain needs and cannot be generalized to all thedomains. Since, existing technology is used without following any standard for creating a VO, it ishard to foresee incoming demands from the participants. • We require a generic platform to integrate resources from a single domain or multiple domains. • Defining a generic platform on the basis of Everything-as-a-Service (XaaS)[15] concept is a solution.Definition of participating components as: – Essential parts – Optional partsWe present the following solutions for these obstacles: • Generalized patterns for building a VO. • Defining components of a VO. • Providing new definitions and examples of
Resources and
Stakeholder in different domains and justi-fying them in real world. • Presenting a Reference Architecture for Virtual Organization (RAVO) which can be applied as astarting point for any community (belonging to a single or multiple domains) to collaborate.3he layout of the paper is as follows: In the next section 2 we introduce the notion of Virtual Organization.In section 3 we present the principal steps for building a virtual organization, which we map to the processof our blueprint design. The generic reference architecture for virtual organizations, which we call RAVO, islaid out in section 4. For justification of our approach a proof-of-concept implementation based on RAVO ispresented in section 5. Finally the paper is closed with a conclusion of the findings.
A Virtual Organization is a non-physical communication model with the purpose is of a common goal. It isbuilt up from people and organizations with respect to geographical limits and nature. Additionally, a VirtualOrganization provides typically a collection of logical and physical resources distributed across the globe.From a conceptual point of view a
Virtual Organization resembles a detailed non-physical problems solvingenvironment. Many definitions have been presented and many different terms arose, e.g. collaboratories[9, 10], E-Science or E-Research [9, 11], distributed work groups or virtual teams [9, 12], virtual environments,and online communities [9, 14]. A Virtual Organization can comprise a group of individuals whose membersand resources may be dispersed geographically and institutionally, yet who function as a coherent unitthrough the use of a Cyber Infrastructure [9]. Virtual Organizations are typically enabled by and provideshared and, in most cases, real-time access to centralized or distributed resources, such as community specifictools, applications, data, instruments, and experimental operations, which was a key research areas of theauthors [16, 17, 18] in the past. The different types of Virtual Organizations depend upon mode of operation,goals they achieve and life span for which they exists.Regardless of the objectives, Virtual Organizations possess some common characteristics. Virtual Or-ganizations provide distributed access across space and time. Structures and processes running a VirtualOrganization are dynamic. Email, video conferencing, telepresence, awareness, social computing and groupmanagement tools are used to enable collaboration among the participants [9]. Operational organizationsare supported by simulation, database and analytical services. In daily life we come across many VirtualOrganizations in terms of social networks as well (e.g. Facebook, MySpace). It can be phrased that soonevery human on this earth will considered to be a part of some Virtual Organization serving its purpose inthe said organization.Generally, a Virtual Organization provides a global problem solving platform. It is difficult to specify orrestrict the domain for which they are serving. Some advantageous roles played by Virtual Organizations arefacilitator of access (BIRN [19], LEAD [20], nanoHUB [21]), caBig[22], LHC Computing Grid, enhancer ofProblem Solving Processes (TeraGrid [23]) and key to Competitiveness (GEON [24]). Virtual Organizationshave served in the field of earthquake engineering (Southern California Earthquake Center (SCEC)), cancerresearch (Cancer Biomedical Informatics Grid (caBIG) [22]), climate research (Earth System Grid [25]),high-energy physics (Large Hadron Collider), and computer science. Other communities are now formingVirtual Organizations to study system-level science. These Virtual Organizations are addressing problemsthat are too large and complex for any individual or institution to tackle alone. It simply is not possibleto assemble at a single location all of the expertise required to design a modern accelerator, to understandcancer, or to predict the likelihood of future earthquakes. Virtual Organizations allow humanity to tacklepreviously intractable problems [9].
The creation of a Virtual Organization is time consuming and should be a well planned activity. In thissection we will discuss Virtual Organization and technology from different perspectives. Both aspects arerequired to support each other. Technology provides the basic infrastructure for a Virtual Organization toexist. A Virtual Organization in turn places demands on Information Technology and shapes the evolutionof technology. For the last decade the Virtual Organization is one of the most discussed collaborationenvironment; but still no standards exist. From this discussions we assume a step wise approach which is4elpful in the creation of Virtual Organization. It can be separated in two phases which are detailed below.
The definition of a Virtual Organization starts with a series of questions, which are very critical in order toproceed. These questions (Qx) are listed in the following: • Q1: Why to form a Virtual Organization? What are the reasons of an organization to create a VirtualOrganization? • Q2: What is the motivation behind participation? Why should other persons, institutes, serviceproviders, etc. want to participate in a Virtual Organization? • Q3: What services are offered by a Virtual Organization? • Q4: How are these services fared? What is the type of the resources/business model? • Q5: Who are the intended users? Who will eventually use and get benefited from this Virtual Orga-nization? • Q6: What is the life of (membership of) a Virtual Organization? Are temporal alliance or permanentparticipation expected?
Based on these Q&A activity it is necessary to identify the building blocks of a Virtual Organization. Gannon[26] has identified main components of a Virtual Organization. These components are • Common interest.
The reason to form a Virtual Organization, • Users. the participants of a Virtual Organization, • Tools and services.
This is a crucial part of a Virtual Organization, which maintains the overall workingenvironment and saves the existing patterns to be reused in order to reduce time to solve similarproblems. A Virtual Organization requires a collection of shared analysis tools (e.g. visualization toolsand provenance tools). Tools can be integrated into specific Virtual Organization work flows and canbe shared and reused. They are used to collect data and publish results. • Data.
A Virtual Organization contains two types of data, generally categorized as meta data andoperational data that is being operated by tools.The component identification process provides the basic building blocks. The designer of a Virtual Orga-nization can decide what to be improved and further included in the design process. Also, each componentcan be given a unique definition by the designer in context of a Virtual Organization being created. Detailedinformation about creation, management and application area of Virtual Organizations is available in [9].
According to Gerrit Muller [27] there are two simultaneous trends, • Increasing complexity, scope and size of the system of interest, its context and the organizations creatingsystem [27]. • Increasing dynamics and integration: shorter time market, more interoperability, rapid changes andadaption in the field, in a highly competitive market, for example cost and performance pressure [27].5hese trends form basis for our proposed RA as well. VOs are developed as distributed system at multiplelocations, by multiple entities, consisting of multiple applications by multiple vendors, merging multipledomains for providing solutions to multiple problems. RA comes in scene where the multiplicity reaches acritical mass triggering a need to facilitate product creation and life cycle support in this distributed openworld [27]. We detail the RAVO in the subsequent sections. We define RAVO as “an open source templatethat does not only depict the architectural patterns and terminology, but also defines the boundaries whereheterogeneous resources from different domains merge collaboratively into a common framework”. A RAhas a life span and is dependent on the target architecture and possibly other RAs. As guideline for oureffort we closely analyzed the RA presented by SHAMAN (European Commission, ICT-216736), GERRITMULLER [27] and NEXOF[28]. RAVO provides • A common lexicon and taxonomy. • A common (Architectural) vision. • Modularization and complementary context. • A layered approach(bottom-up).
A common vision facilitates the participating entities to work as a team to achieve their decided goals.Modularization helps to integrate different domains thereby decreasing the efforts and context informationmake the dynamic nature of the architecture consistent.We aim for developing a RA which allows for new forms of IT infrastructure coping with new collaborativeprocessing paradigms, as grid computing and cloud computing. Thus we have to deliver an environmentto allow for the new
Internet of Services and Things accommodating the novel service stack, as IaaS, PaaSand SaaS. Architecture is classified into different layers according to the service each layer provides. Layeredarchitecture is chosen because it helps to group different components (logical and physical) according to thedegree of relatedness and required functionality.
RAVO is based on SPI model. Layered approach is used to achieve the goal of providing all the resources asa service. Layers are distributed into 3 broad categories, IaaS, PaaS, SaaSFigure 1 presents the framework for VO using the SPI model. The layers are distributed into 3 broadcategories, IaaS, PaaS and SaaS thus resulting in XaaS.
Software as a Service Layer
In context of RAVO, SaaS is composed of a Service layer. It contains Domain Specific Applications (DSA)accessible by all users. DSAs are the combination of several user interfaces and Business Models found in theVO layer. Users, who only use the platform to solve their domain specific problems and do not contributeto the VO, find an entry point at this layer. • Service Layer : It has open source, downloadable software, categorized in domains. The Service layerpackages several services provided by the VO layer to be subscribable entities. These entities includegeneric functionality to query information from the problem domain as well as the means to performdata mining on the compound data created or provided by the combination of the services.
Platform as a Service Layer
In RAVO two layers, namely VO layer and Abstract layer, cover PaaS.6igure 1: XaaS Skeleton of RAVO7
Abstract Layer : This layer is composed of essential tools which enable the whole framework to beexploited in a dynamic manner. The set of tools consist of provenance, workflow, graphical tools andany other domain specific tools which are used to enhance the reuse of the resources for a diverse setof problem solving activity. Each tool provides its own functionality, its own user interface description[29], as well as an abstract API (identical for each tool) to access the resource in Factory layer. • VO Layer : This layer is the entry point for user. It provides the realization of the user interfacedescription and defines a business model on top of the Abstract layer to set usage cost according tousage statistics. Participating entities can agree on a usage model and build a cost trust for sellingtheir resources. In context of VO, contributor/subject users (who not only use the resources offeredby a VO but also contribute to the VO) are authorized to access the system on this layer. All haveaccess to the system on PaaS layer.
Infrastructure as a Service Layer
In RAVO logical and physical resources are considered to be the part of IaaS. This part consists of twosub-layers in RAVO: Factory layer and Infrastructure Enabler layer. Only users with administrative rightshave access to this layer. • Factory Layer : Belongs to the IaaS category and contains resources for RAVO. Resources are describedas physical and logical resources. Physical resources comprise of hardware devices for storage andcomputation cycles in a distributed manner. Logical resources contain expert’s knowledge that supportsthe problem solution activity thereby reducing time to reach the specified goal. • Infrastructure Enabler Layer : Allows access to the resources provided by the Factory layer. It consistsof protocols, procedures and methods to contact the desired resources for a problem solving activity.It acts as a glue or medium to reach the desired resources based on user request.
Everything as a Service Layer
All layers are providing their functionality in a pure Service-Oriented manner so we can say that RAVO isXaaS.
VOs is a broad category of distributed systems. It is envisioned as a combined effort of multiple entities(organizations, people, HW, SW) for achieving a goal. Building RA for VO is effective in many ways.RAVO forms basis for VOs belonging to any domain. It improves the effectiveness by managing synergy,providing guidance for collaboration, generic framework, managing and sharing the architectural patterns.Interoperability is the most critical aspect of collaborative computing and VOs main feature. It determinesthe usability, performance and dependability of user level applications [27]. Integration cost and time are alsoimportant factors in context of interoperability. RAVO supports interoperability by defining a negotiationmodel/trust for the participating entities thereby supporting the effective re-use of patterns. Many RAfocuses the technical architecture only. According to SAF meeting conclusion, A RA should address [27], • Technical architecture. • Business architecture. • Customer context.RAVO well addresses these three aspects. It presents a technical architecture specifying the must par-ticipating modules, APIs, protocols and platform to support VO. RAVO offers a Business Model which isopen according to the participating entities conditions for resource sharing. Business Model and customer8igure 2: Viewpoints in Reference Architecture for Virtual Organizationcontext overlap. RAVO explicitly defines roles of participating entities as
Subject , Consumer , Producer and administrators . Elaboration of roles makes it easy to dynamically update the Business Model as an entitychanges the role. RAVO supports feedback from the participating entities which is helpful in improving andmaintaining the existing RA. These concepts are already detailed in RAVO section.RA is a perceived image of existing technologies. Designing RA is a challenging job because it needssufficient proof to justify its need in the said context. RAVO focuses on VOs. To the best of our knowledge,there is no standard pattern or framework which can be used to create a VO from scratch. Our vision isto provide the VO community a complete framework for identifying main components and abstract a lifecycle to create VO from scratch. It grasps knowledge from existing structures such as NEXOF [28] andSHAMANs (European Commission,ICT-216736). Guidelines are used to modify the requirements into anRA which supports creation, dynamic evolution and maintenance of a VO.
Viewpoint is defined as a specification of the conventions for constructing and using a view. A patternor template from which to develop individual views by establishing the purposes and audience for a viewand the techniques for its creation and analysis [30]. View is a representation or description of the entiresystem from a single perspective. Stakeholder is the viewer, who perceives the system according to her role.Viewpoint has a name, stakeholders addressed by it and concerns to be addressed by the viewpoint, andthe language, modeling techniques or analytical methods to be used in constructing a view based on theviewpoint [30]. According to these definitions, viewpoints extracted from the concerns of the stakeholdersare shown in Figure 2. These viewpoints are detailed in the following sections.
Stakeholders collaborate to form a VO. All participants of a VO have an objective (personal or organizational)to achieve via this collaboration. Sub-viewpoints are, • Domain definition: Depends on the type of problem solution, target domain can be one or multiple.Thus, stakeholders can be from one or multiple domains. • Participation Level: Participation can be individual or at organizational. • Duration: Stakeholder remain part of the VO according to the membership duration agreed uponamong the collaborative entities. It can vary depending on the type of VO, partial or permanent(either participation is required for a specific part or throughout) and a Business Model in case ofprofitable organizations. • Types of Contribution: It is decided by the role assigned to a specific stakeholder in the context of aVO. 9 .4.2 Requirements and Vision
This viewpoint formulates the boundaries of a VO and its participants. All the participants must clearly puttheir requirement and goals while building collaboration. These requirements should reflect any assumptionmade on the architecture and the respective requirements stemming from the assumptions. Once require-ments are defined (in form of a list, catalogue), VO has a vision to achieve and targets are set accordingly.
Trust governance viewpoint is very important to any collaboration specially for VOs. Keeping stakeholdersand resources glued together to achieve a target is only achievable via strong trust. Following sub-viewpointsare defined in this context: • Trust/Policy formation: Experts and planners from participating entities prepare an agreed uponpolicy/model/contract. This policy defines the rules for participating and leaving VO, contributingand consuming resources, penalties for violation and measures to keep consistent and just to all thestakeholders. • Objective Catalogue: This viewpoint provides the list of all the contracts and agreements in a docu-mented form necessary for authentication, authorization and stakeholder management. • Reviewing Policy: Due to dynamic nature of VO, the policies and contracts are reviewed to be in theaccordance of change in requirements, technological updates, removal and entrance of participants. • Business Perspective: This viewpoint is optional depending upon the type of VO. Profitable VO havea Business Model for metering, billing in addition to authentication and user management.
This view point provides details of participating components for realizing the VO on technological and systemlevel. It is further divided into 4 sub-viewpoints which are briefed here as, • Data: This viewpoint aims to depict the types of data utilized in collaboration. Two broad iden-tifications are found as meta data and operational data . Problem nature, domain and participatingentities decide on the data source and security in collaborative efforts. Data and relationship betweendifferent components can be represented using Table, Mat, UML Class diagrams, Activity diagramsand Component diagrams. • Applications and Tools: This viewpoint describes the list of running applications and tools utilizedin a problem solving activity. This view can be further divided according to requirement. Rolesof stakeholders also decide the access to different available tools and applications at multiple levels(Interface, infrastructure, platform and so on). Distribution and relationship among applications,tools and components can be shown using UML Component diagram. • Resources: This viewpoint explains the list of resources (Table, List), their owners, availability, usagecost (in case of profitable organization) and access rights. We have to sub-viewpoints: – Subject: An important viewpoint which defines stakeholder which consume and contribute to theresources simultaneously. – Enabler: This viewpoint details the stakholders which are related to deployment, configuration,monitoring and lifestyle management. Roles assigned in this viewpoint are developers, adminis-trators, business providers, planners and experts. • Log catalogs: This viewpoint keep track of activities which are carried out during problem solvingactivities. Dynamic collaboration environments need to this record for the feedback and improvement.10 .4.5 Technology Viewpoint
This viewpoint lists the best available technology currently deployed. If new technology is employed whichis not listed then it should be added to the list later. It is very helpful keeping VO consistent with theupcoming demands from business and user requirements and advancement in new computing paradigms andmethods. Platforms used for collaboration have remained in a constant up-gradation. Choice must be madeon technology by giving weighage to QoS, security, cost effective and timely solution to the end user. Animportant sub-viewpoint of technological aspect is virtualization. It provides the way to reuse hardwarecost, respond dynamically and maximize resource utilization and easy relocation. Virtualization viewpointdeals with logical resources rather than physical resources.All these viewpoints are shown in the diagram Figure 2 These viewpoints can be represented usingLists, Tables, UML tools, and other requirement specification tools available. They are also extendable andorganizations can add any further categories according to their goals.
RAVO is composed of multiple layers and each layer provides a set of components which are the building blockof a VO. Selection of these building blocks is subjected to various aspects (i.e. life span, nature (dynamic orstatic), type, formal, informal and so on). We define interfaces for these components by specifying parameters(mandatory and optional), methods and necessary conditions for their executions.
VO needs to keep specific information in general, when created. It possesses some characteristics, (e.g.Unique ID, Date Created, Description about purpose domain etc). It also requires to maintain informationabout participating organizations and individuals.
It is a must to maintain and update the information about the resource providers in a VO. Organizationoffering resources, time period for which resources are made available and access rights are potential char-acteristics.
Query Interface.
RAVO proposes Query Interface as a mandatory component at Service Layer. User isfacilitated with remote or desktop access. Query Interface enables user to search for their problem solutionin Knowledge base. Knowledge base contains history of problems solved previously. On successful queryuser is provided with appropriate output. In case of no matching solution, query is processed and problemsolutions is provided to user and Knowledge base is updated. Query Interface must provide login facility,identify the query type, check for existing solutions and must maintain a tolerable response time.
Domain Specific Application (DSA).
DSA is a mandatory component DSA provide user with theability to either download the applications and run on their own systems or use them at VO platform forproblem solution. The range of applications depends on the domain and type of VO. Stakeholder can sharetheir applications paid or non-paid basis. Sharing of application can be conditional (e.g. fully or partiallypaid in case of profitable organization). Information maintained about DSA must include how it is accessible(online or offline), access rights and cost (as defined in the Contract/Business Model).
Data Mining Tools.
Data mining tools are an optional component of RAVO. They are a must foranalytical and scientific research based VOs. Interface for data mining tools include tool description , accessrights and manul/help. 11 .5.3 PaaS Layer
PaaS layer is composed of two layers, namely 3-VO Layer and 2-Abstract Layer. Component Specificationis detailed below.
VO Trust.
VO Layer consists of two main mandatory components. VO Trust is the most important of allcomponents. It is formed by combining different modules and performs multiple tasks. It is responsible for
Authentication and
Authorization of VO members. Authorization is done on the basis of
Roles defined in the
Contract/Business Model . VO Trust have a mandatory emphContract which consists of policies to achievethe goals of VO. In profitable or partially profitable VOs Business Model is also mandatory componentof VO trust. In RAVO Business Model is optional and depends on the type of VO, however Contract ismandatory. Access rights are defined in contract or Business Model. Different methods are available todefine the access rights. Organization models and access rights are comprehended in [31]. According to theauthors access rights might be subjected to
Organizational and
Direct change [31]. All components of VOTrust are synchronized to maintain the VO. Each component is assigned a specific task and output of onecomponent provides input to the other component. VO Trust has a
Resource Information component thatacts like a
Registry . It keeps necessary details about all the resources available in VO.
User Interface.
User Interface is a mandatory component of VO Layer. It provides access to the platformservices offered by VO. User is authenticated and authorized using Login option. After authorization, usercan formulate different queries and perform actions. These facilities are realized using a Web portal.
Workflow Tools.
Abstract Layer is a sub layer of PaaS layer. It includes different components. Workflowtools is a mandatory component of this layer. Workflow management is a critical aspect of a VO in anydomain. It supports Provenance management which plays vital role in monitoring and maintaining a VO.Workflow can be interpreted in different forms (e.g. graphical, textual, source code). Interpretation modeis chosen on the level of audience a VO possess. Workflow tools keep track of all the processes active inVO. Process management can be included as a sub component of a Workflow Tools. Dynamic adaption ofin-process workflow is an essential part of any workflow management system. Classification of approachesalong their strength and limitations used for dynamic adaption in workflow systems are detailed in [32].Flexibility criteria in process management to handle the foreseen and unforeseen behaviors are categorizedin [33].Workflow tools allow user to define workflows for a problem solving activity. The participants responsibleat each stage of this activity are notified and are responsible for delivering the promised results. Workflows arereusable and reduce redundancy and time for similar problems. Information maintained consist of workflowID, type, status, access rights, how it interprets the results and process management. workflows are used byProvenance management to track the problem solving activity on user demand.
Provenance Tools.
With the advent of financial computing systems, as well as of data-intensive scientificcollaborations, the source of data items, and the computations performed during the incident processingworkflows have gained increasing importance [34]. Provenance of a resource is a record that describesentities and processes involved in producing and delivering or otherwise influencing that resource In aVO, provenance forms a critical foundation for enabling trust, reproduction and autentication. Provenanceassertions are a form of contextual metadata and can themselves become important records with theirown provenance. Provenance Tools are mandatory and included in Abstract Layer of RAVO. Provenancemanagement is dependent on authorization, query management and workflow management.
Graphical Interface.
Graphical Interface is a mandatory component of Abstract Layer. It facilitatesusers to perform different task in VO Web portal. It provides an understandable interface to interact withthe VO. . esource Management. Resource Management is a mandatory component of Abstract Layer. It pro-vides a mechanism to select and aggregate resources for a problem solving activity. Depending upon theunderlying technology, VO developers can deploy different resource management tools. Necessary infor-mation maintained depends on the resource type and interest of participating entities. Basic informationincludes resource’s unique identification, categorization as logical or physical, owner information, accessrights and costs etc.
IaaS layer is composed of Infrastructure Enabler Layer and Factory Layer. This layer from the fabric ofRAVO. All the resources are avaialble in Factory Layer and are exploited through Infrastructure EnablerLayer.
Infrastructure Enabler.
This module is depending on the underlying technology . QoS, Service LevelAgreement (SLA), Security, Fault tolerance and Disaster management are most important issues specificallyin clouds [35, 36, 37, 38, 39, 40]. These aspects have to be implemented on the bases of terms and conditionspresented by participating entities. Financial aspect is another limitation for the implementation of thesemodules. Any other desired aspects can be added to extend the Infrastructure enabler layer. Componentsare dependent on the decision of the developers. RAVO identifies least basic and gives developers an openend to use them as mandatory or optional in their target VO.
Resource Catalogue.
This module is part of Factory Layer but not explicitly shown in RAVO. It acts likea database for the resources. VO developers can include it at any layer according to their needs. RAVO keepsit at the Factory Layer as a mandatory component. It contains information about resource management.
Expert.
Expert represents the logical resource in RAVO Factory Layer. An Expert plays important rolein problem solving activity. Expert can be contacted online during the problem solving process or she canbe accessed offline. VO must maintain detailed information about Expert so that this feature can be fullyexploited.
Data Service.
Data Services is a mandatory component of Factory Layer. It represents the physicalresource in RAVO. Data stores are important scientific and research based VOs.
Computational Services.
Computational Services are mandatory component of Factory Layer. Theyalso form the physical resources offered by a VO.
As proof-of-concept of our approach we used RAVO as a design blueprint for implementing a cloud based VOfor Neural Network Research, namely, N2Sky. We based the development of N2Sky on the blueprint providedby RAVO and produced a concrete instance out of our proposed standard [41]. This section compares N2Skywith RAVO to reveal the process of creation of N2Sky. The comparison justifies and proves how RAVOsupported different development phases of N2Sky. We explain N2Sky as an instantiation of RAVO butwith concrete components. We divide this comparison in 3 levels. First,
Requirement Analysis Phase thatdefined boundaries of N2Sky. Second,
Component Identification Phase which made it easy to identify thecomponents of N2Sky and also choose between optional and mandatory components. Third,
ImplementationPhase that reveals how technology independence, XaaS and layered distribution of components made ithelpful to implement the system. The stakeholders envisioned in RAVO are also implemented as part ofN2Sky. 13 .1 Requirement Analysis in terms of RAVO
In the previous section we detailed a series of questions which must be answered by the responsible authoritiesfor creating a VO. N2Sky utilizes this pattern for defining the requirements boundary of the system. Thesequestions are answered in detail in an interview by engaged software engineering experts, whic are presentedin section 5.3.4.
N2Sky is a layered architecture instantiated from RAVO. The N2Sky is shown in Figure 3. N2Sky is alsopresented as an XaaS, based on Cloud SPI model. It consists of 3 layers, namely SaaS, PaaS and IaaS.These layers have sublayers similar to RAVO. Each layer has some components which are either mandatoryor optional depending upon their participation in VO. Figure 1 shows RAVO framework. A detailed, tabularcomparison of RAVO and N2Sky components is given in Figure 4.
Section 4 presented interface specification for components. Here, we analyze how these interface specificationswere used in N2Sky. We compare the underlying framework RAVO with its instantiation as N2Sky, in atop-down fashion. We start with SaaS layer.
SaaS layer of RAVO consists of optional and mandatory components. Choice of components and decision ontheir status (mandatory and optional) is open for the developers. The inclusion of components is dependenton the requirement definition by the stakeholders.SaaS Layer has one layer, named Service layer. Here tables are included for the sake of comparison. • Query Interface: RAVO proposes Query Interface as a mandatory component at Service Layer. InN2Sky, Query Interface is also included as a mandatory component. • Domain Specific Application (DSA): DSA is a mandatory component. N2Sky has a simulation servicebut at Neural Network layer (sub layer of PaaS). N2Sky includes DSA as NN specific applications.N2Sky is planned to include NN specific applications. The Simulation Service provides the creation,training and simulation of neural objects which in turn are instances of NN paradigms. Currently,Simulation Services are provided at NN Layer of N2Sky. • Data Mining Tools: Data mining tools are an optional component of RAVO. N2Sky has not includedthis option.N2Sky also has one layer, named Service Layer (similar to RAVO). Extended components included atService Layer in N2Sky are: • Web Portal: N2Sky Web Portal is a mandatory component. • Smaprtphone APP. • Hosted UI.
PaaS layer is composed of two layers, namely VO Layer and 2-Abstract Layer. Component Specification isdetailed below. In N2Sky PaaS consists of 3-Neural Network Layer and 2-Abstract Layer.14igure 3: N2Sky15igure 4: Comparison: RAVO vs N2Sky16
O Layer comparison with 3-Neural Network Layer.
In RAVO VO layer has the following compo-nents: • VO Trust: Mandatory component of VO, which is responsible for enabling resources, defining policiesto achieve a goal. It has several components and is extendable according to the need and requirementof stakeholders. N2Sky has distributed Trust component in to different modules. In N2Sky, NeuralNetwork Layer has a Management Service component to serve the purpose. Other components areavailable at Abstract layer namely, Business Model with SLAs and Accounting. • User Interface: User Interface is a mandatory component for solving problem utilizing VO PaaS utility.It provides an interface to interact with the VO. N2Sky also realizes this component as a part of WebPortal.Extended Component of N2Sky: • Hosted Component: Provides and interface for components hosting platform. • Simulation Service: Already described in Service Layer comparison. It is a mandatory component thatis part of Neural Network Layer of N2Sky.
Abstract Layer Comparison.
RAVO and N2Sky both have this sub layer named 2-Abstract Layer.Components of these layer in RAVO and N2Sky are compared. • Resource Management: Resource Management is a mandatory component of Abstract Layer. It pro-vides a mechanism to select and aggregate resources for a problem solving activity. Depending uponthe underlying technology, VO developers can deploy different resource management tools. In N2Skyresource management is achieved via mandatory Registry component. • Workflow Tools: N2Sky also has a Workflow System under development. • Provenance Tools: Provenance Tools are proposed in RAVO but they are not included in N2Sky. • Graphical Interface: A mandatory components which facilitates interaction with VO easier and helpsuser to get results in an understandable format. It also assists user in formulating queries and browsingin VO environment. In N2Sky Graphical Interface is implemented as a Web portal described earlier.Extended Components supporting VO Trust (as proposed in RAVO) Functionality: • Controlling and Accounting: This component along with SLA component serves as a Business Model.In RAVO Business Model is optional. • Usermanagement. • Access Control. • SLA. • Annotation Service. • Knowledge Management: It refers to Expert’s Knowledge of RAVO defined at Factory level. • Component Hosting Platform. 17 .3.3 IaaS Layer Comparison
IaaS layer is composed of 1-Infrastructure Enabler Layer and 0-Factory Layer. This layer froms the fabricof RAVO. All the resources are available in Factory Layer and are exploited through Infrastructure EnablerLayer.Infrastructure Enabler Layer in RAVO brings an open choice for the developers for underlying technology.QoS, Service Level Agreement (SLA), Security, Fault tolerance and Disaster management are aspects to beconsidered in particular. Further extension can be done by developers.N2Sky also have an Infrastructure Enabler Layer. It contains following components. • Data Archive: Implemented as a mandatory component of N2Sky. • Component Replication Service.Factory Level of RAVO is also instantiated in N2Sky. It has following components in RAVO • Resource Catalogue: Resource Catalogue module is an extension of Resource Management Component.It is a mandatory components. It keeps information about resources which is of interest to VO. InN2Sky this task is achieved by Registry component. • Computational Services: RAVO offers Computational Services as a mandatory component. In N2Skythis component is realized by Component Replication Service. It is a mandatory component which actas N2Sky Paradigm Archive Service. • Data Services: This component of RAVO is realized by N2Sky as a part of Infrastructure EnablerLayer. • Expert’s Knowledge: N2Sky implements this component of RAVO as Knowledge Management as asubcomponent of Abstract Layer.
Based on the experiences drawn from development of N2Sky we could derive the following list of findings: • RAVO provides strong theoretical grounds to clear the vision of VO developers and participants beforethey start building a community. • Requirement Analysis and Component Identification phases enable developers to list mandatory andoptional components. The purpose is twofold. First, must parts of the VO are confirmed. Second,optional parts leave room for future requirements and upgrades. • RAVO framework is flexible and generic. Components at different layers are moved or integrated withother parts as it eases the developing process. • RAVO is technology independent and it gives freedom of choosing any suitable tools and programminglanguages. • RAVO emphasis on providing graphical interface to ease the end user so that they can communicateand formulate their queries easily. The interface should not be complicated that only professionals caninteract. • Stakeholders and their roles are important to understand. Pattern developed for RAVO are used hereextensively to design a Business Model for N2Sky.18or further justification of our approach also an informal evaluation was conducted. hereby two softwaredevelopers (which we name A and B), who were involved in the final development of VOCI, were interviewed.Interview partner A is a senior researcher at our research group. His expertise include SOAs (including workon mobile devices), with a specific focus on process aware information systems. He developed a light-weightmodular process engine to fully support external monitoring and intervention. He further published in thefield of RESTful service description, composition and evolution. He was interviewed regarding RAVO as astaring point for developers in NN domain.Interview partner B was a master student at University of Vienna, chose RAVO as the template to developa cloud-based virtual organization for NNs called N2Sky. Mr. Erwin Mann has experience in implementingservice-oriented architectures (SOAs), service orchestration, to create workflows and in porting such systemsto cloud-based environment. N2Sky brings together both NN paradigm developers and users who deal withproblems that are beyond conventional computing possibilities. N2Sky provides a standardized descriptionlanguage for describing neural objects (instances of neural paradigms) called VINNSL. Furthermore N2Skyprovides a business model for researchers and students but also for any interested customer. N2Sky’s coreprocess is the Simulation Service including creation, training and evaluating of neural objects in a distributedmanner in the cloud.Both researcher gave their opinion after critical analysis of RAVO. Researcher A’s abstraction of RAVOin terms of “Q&A” is helpful for the developers of VO in any domain. Researcher B has applied RAVO anddeveloping an instance in the domain of NN. We deduce the following statements from this evaluation. • RAVO best fits needs of community for developing a VO from scratch. • RAVO supports evolution of existing systems in to a VO. N2Sky is an example of such evolution. • RAVO is presented in a layered fashion, with a choice of mandatory and optional components. Layeredapproach make it easy to distribute the components in different layers and also developers are not boundto choose the exact distribution. RAVO is a flexible and extendable framework. Developer can changethe components and move them to any desired layer. For example in N2Sky, components have beenmoved to different layer as compared to RAVO. • RAVO is not technology dependent. Both the researchers described their alternative choices whichestablishes the technological independence of RAVO. • Categorization of resources into logical and physical is a new dimension for VO developers. Inclusionof human expertise as a resource supports the demanding nature of problem solving ability, therebyincreasing the level of trust in users. • RAVO presented a new concept of stakeholder,
Subject . A unique idea of how a stakeholder can becomea resource in a VO. Being consumer and producer at the same time is difficult to implement. RAVOmake it easier by introducing the stakeholder categorization. • RAVO foresees a Business Model which is introduced in N2Sky as a mandatory component. Stake-holder’s roles are integrated in Business Model to set the usage and cost policy.The interviews and the derived results are detailed in [42].
The strong response from research community, motivated us to design a Reference Architecture for VirtualOrganization (RAVO). Reference architectures are system specific and provide a level of detail required totranslate the required capabilities as derived from missions, operational concepts, and operational architec-ture views, into projects within a capable package, which will increase system quality and decrease systemdevelopment costs. 19e developed a service-stack pattern to start a Virtual Organization from scratch and also presented adesign blueprint for collaborative environments. Emphasis is on flexible and simple interface for interactionfrom the user perspective. It supports addition of tools and application to the Virtual Organization environ-ment. We give guidelines for building a domain specific Virtual Organization for Computational Intelligencecommunity and can extend it according to our requirements.
References [1] T. Weish¨aupl, F. Donno, E. Schikuta, H. Stockinger, and H. Wanek, “Business in the grid: BIG project,”in
Grid Economics & Business Models (GECON 2005) of Global Grid Forum , vol. 13, (Seoul, Korea),GGF, 2005.[2] E. Schikuta, F. Donno, H. Stockinger, H. Wanek, T. Weish¨aupl, E. Vinek, and C. Witzany, “Businessin the grid: Project results,” in , (Hagenberg, Austria), OCG, 2005.[3] T. Weish¨aupl and E. Schikuta, “Towards the merger of grid and economy,” in
International Workshopon Agents and Autonomic Computing and Grid Enabled Virtual Organizations (AAC-GEVO04) at the3rd International Conference on Grid and Cooperative Computing (GCC04) , vol. 3252/2004 of
LectureNotes in Computer Science , (Wuhan, China), p. 563–570, Springer Berlin / Heidelberg, 2004.[4] T. Weish¨aupl, C. Witzany, and E. Schikuta, “gSET: trust management and secure accounting forbusiness in the grid,” in , (Singapore), p. 349–356, IEEE Computer Society, 2006.[5] W. Mach, B. Pittl, and E. Schikuta, “A business rules driven framework for consumer provider con-tracting of web services,” in , December 2013.[6] R. Vigne, W. Mach, and E. Schikuta, “Towards a smart webservice marketplace,” in
IEEE Conferenceon Business Informatics , (USA), IEEE, 2013.[7] W. Mach and E. Schikuta, “A generic negotiation and re-negotiation framework for consumer-providercontracting of web services,” in , (Bali, Indonesia), ACM, Dec. 2012.[8] P. F. Drucker,
Post-Capitalist Society . HarperCollins, Nov. 2009.[9] C. Kesselman, I. Foster, J. Cummings, K. A. Lawrence, and T. Finholt, “Beyond being there: Ablueprint for advancing the design, development, and evaluation of virtual organizations.,” tech. rep.,May 2008.[10] W. Wulf, “The collaboratory opportunity,”
Science , vol. 261, no. 5123, pp. 854–855, 1993.[11] T. Hey and A. E. Trefethen, “E-science, cyberinfrastructure and grid middleware services,”
Science ,vol. 308, pp. 817–812, 2005.[12] M. O’Leary and J. Cummings, “The spatial, temporal, and configurational characteristics of geographicdispersion in teams,”
MIS Quarterly , vol. 31, pp. 433–452, March 2007.[13] B. Katzy, C. Zhang, and H. Lh, “Reference models for virtual organisations,” in
Virtual Organizations (L. M. Camarinha-Matos, H. Afsarmanesh, and M. Ollus, eds.), pp. 45–58, Springer US, 2005.[14] P. Jennifer,
Online communities: Designing usability and supporting sociability . Chichester, England:John Wiley & Sons Ltd, 2000. 2015] D. Plummer, T. Bittman, T. Austin, D. Cearley, and D. Smith, “Cloud computing: Defining anddescribing an emerging phenomenon,”
Gartner, June , vol. 17, 2008.[16] E. Schikuta and T. F¨urle, “ViPIOS islands: Utilizing I/O resources on distributed clusters,” in , (Louisville, KY,USA), ISCA, 2002.[17] E. Schikuta, T. F¨urle, and H. Wanek, “ViPIOS: the vienna parallel Input/Output system,” in , vol. 1470/1998 of
Lecture Notes in Computer Science , (Southampton,UK), p. 953–958, Springer Berlin / Heidelberg, 1998.[18] P. Brezany, T. M¨uck, and E. Schikuta, “A software architecture for massively parallel input-output,”in
Third International Workshop Applied Parallel Computing Industrial Computation and Optimization(PARA’96) (J. Wasniewski, J. Dongarra, K. Madsen, and D. Olesen, eds.), vol. 1184 of
Lecture Notesin Computer Science , (Lyngby, Denmark), p. 85–96, Springer Berlin / Heidelberg, 1996. 10.1007/3-540-62095-8 10.[19] I. Foster and C. Kesselman,
The grid: blueprint for a new computing infrastructure . Morgan Kaufmann,2004.[20] Accessible at : http://portal.leadproject.org/gridsphere/gridsphere.[21] G. Klimeck, M. McLennan, M. Mannino, M. Korkusinski, C. Heitzinger, R. Kennell, and S. Clark,“NEMO 3-D and nanoHUB: Bridging Research and Education,” in
Nanotechnology, 2006. IEEE-NANO2006. Sixth IEEE Conference on , vol. 2, pp. 441–444, IEEE, 2006.[22] A. C. von Eschenbach and K. Buetow, “Cancer Informatics Vision: caBIG,”
Cancer informatics , vol. 2,p. 22, 2006.[23] C. Catlett, W. Allcock, P. Andrews, R. Aydt, R. Bair, N. Balac, B. Banister, T. Barker, M. Bartelt,P. Beckman, et al. , “Teragrid: Analysis of organization, system architecture, and middleware enablingnew types of applications,”
HPC and Grids in Action, Amsterdam , 2007.[24] U. Nambiar, B. Ludaescher, K. Lin, and C. Baru, “The GEON portal: accelerating knowledge discoveryin the geosciences,” in
Proceedings of the 8th annual ACM international workshop on Web informationand data management , pp. 83–90, ACM, 2006.[25] I. Foster, “Service-oriented science: Scaling escience impact,” in
IAT ’06: Proceedings of theIEEE/WIC/ACM international conference on Intelligent Agent Technology , (Washington, DC, USA),pp. 9–10, IEEE Computer Society, 2006.[26] D. Gannon, “Building virtual organizations around super computing grids and clouds.” Indiana Uni-versity and Tera Grid Infrastructure Group, 2008.[27] G. Muller, “A Reference Architecture Primer,”
Eindhoven Univ. of Techn., Eindhoven, White paper
In Proceedings of the International Joint Conference on Neural Networks 2010 (WCCI 2010),Barcelona, Spain , 2010.[30] L. Jen and Y. Lee, “Working group. ieee recommended practice for architectural description of software-intensive systems,” in
IEEE Architecture , Citeseer, 2000.2131] S. Rinderle-Ma and M. Reichert, “Managing the life cycle of access rules in ceosis,” in
Enterprise Dis-tributed Object Computing Conference, 2008. EDOC’08. 12th International IEEE , pp. 257–266, IEEE,2008.[32] S. Rinderle, M. Reichert, and P. Dadam, “Correctness criteria for dynamic changes in workflow systems–a survey,”
Data & Knowledge Engineering , vol. 50, no. 1, pp. 9–34, 2004.[33] H. Schonenberg, R. Mans, N. Russell, N. Mulyar, and W. Aalst, “Process flexibility: A survey ofcontemporary approaches,”
Advances in Enterprise Engineering I , pp. 16–30, 2008.[34] R. Hasan, R. Sion, and M. Winslett, “Introducing secure provenance: problems and challenges,” in
Proceedings of the 2007 ACM workshop on Storage security and survivability , StorageSS ’07, (NewYork, NY, USA), pp. 13–18, ACM, 2007.[35] I. U. Haq, E. Schikuta, I. Brandic, A. Paschke, and H. Boley, “SLA validation of service value chains,”in , (Nanjing, Jiangsu, China),p. 308–313, IEEE Computer Society, 2010.[36] I. U. Haq and E. Schikuta, “Aggregation patterns of service level agreements,” in
Frontiers of Informa-tion Technology (FIT’10) , (Islamabad, Pakistan), ACM, 2010.[37] I. U. Haq, I. Brandic, and E. Schikuta, “SLA validation in layered cloud infrastructures,” in
Economicsof Grids, Clouds, Systems, and Services, 7th International Workshop, GECON’10 , vol. 6296 of
LectureNotes in Computer Science , (Ischia, Italy), p. 153–164, Springer Berlin / Heidelberg, 2010.[38] I. U. Haq, A. A. Huqqani, and E. Schikuta, “A conceptual model for aggregation and validation ofSLAs in business value networks,” in , (Leipzig, Germany), Mar. 2009.[39] I. U. U. Haq, A. Paschke, E. Schikuta, and H. Boley, “Rule-Based workflow validation of hierarchicalservice level agreements,” in
Workshops at the Grid and Pervasive Computing Conference (GPC’09) ,p. 96–103, IEEE Computer Society, 2009.[40] I. U. Haq, A. Huqqani, and E. Schikuta, “Aggregating hierarchical service level agreements in businessvalue networks,” in , (Ulm,Germany), p. 176–192, Springer-Verlag, 2009.[41] E. Mann, “N2sky - a cloud-based artificial neural network resource,” master thesis, Faculty of ComputerScience, university of Vienna, A-1090 Vienna, Austria, 2013.[42] W. Khalil,