A Unified Architecture for Utility Service in Cloud

A Unified Architecture for Utility Service in Cloud Mansura Habiba

Md. Rafiqul Islam

IBM in Ireland, Dublin, Ireland e-mail: [email protected]

Department of Computer Science, American International UniversityBangladesh, Dhaka, Bangladesh e-mail: [email protected]

Abstract—Today our world is ready to make the maximum use of cloud computing facility as like other daily most common utilities such as electricity, gas and water. However, currently the cloud is showing its limited effect in case of utility service system. The main lacking in cloud is the absence of unified architecture for deploying service and use of application in an optimum way to make the maximum availability of service within the limited time frame duration and minimum configuration overhead. In this research a cloud based unified architecture has been proposed for utility service system. In addition, the working procedure of proposed architecture with performance description is also added in this paper. Keywords: Unified Architecture, Utility Computing, Cloud.

I.

INTRODUCTION

Recent change in cloud landscape due to the immense use of social networking and the establishment of social cloud it is inevitable that social networking system is going to become one of the mandatory subsystems of utility system. However, in typical utility system the main challenge is to design service specific cloud architecture. Each different utility service has different design as well as goal specification. For example, sometimes service providers emphasize on Service Level Agreement (SLA), other times they emphasize on availability or scalability. As a result the architecture needs to be designed either SLA–driven or Scalability-driven. Every case requires redundant and additional effort, which ultimately turns the system expensive and complex. . In order to overcome all the limitations and challenges of existing architectures, utility computing needs a cloud platform which can increase the velocity of applications deployment and configuration within the lower cost and higher business agility. Therefore, utility service system needs a unified architecture that could be configured heterogeneously. The goal of this work is to design an architecture based on cloud platform for utility services which is capable to protect utility service and corresponding resources from external threats and maximize the interoperability. In this paper unified cloud based architecture for utility computing is proposed. Some limitations of existing architecture are discussed in the state of art section. The main focus of our research is on dynamic configuration and secured data delegation.

A B M Shawkat Ali Department of Computer Science and Information Technology School of Science and Technology The University of Fiji Lautoka, Fiji. e-mail: [email protected] II.

STATE OF ART

Huang et al. [7] has proposed a cloud based architecture for E-learning, which enables teacher and students to access education system from anywhere at any time. The proposed system ensures high availability, security, and powerful data storage system with easy access. However this architecture is developed for a specific domain, education. Now-a-days with the rapid and immense growth of cloud computing the world needs unified cloud based architecture for utility services which can be easily configurable as well. Wu et al. [8] describes a typical utility that focuses on SLA that includes service discovery, pricing, negotiation, SLA enforcement, monitoring and scheduling. The main limitation of this proposed system is that it differs from system to system. As a result, most of the time it becomes costly for the utility service provider to set up their own utility system and define their own metrics in cloud. That is why, in this paper we have proposed a utility system that can be used by any utility service provider and also help them to define related metrics. In typical utility system [8] auditing and monitoring can be done only in SaaS layer of cloud and basically for service discovery and execution. However this trend is too vulnerable for the current cloud system. It is also mandatory to monitor the application layer and vendor layer. In this proposed architecture an audit and security layer have been proposed for all other layers. These two layers also perform risk management and continuous monitoring. However, this proposed architecture is still not exactly on the fly configurable and also not dynamic. On the other hand, recent researches [12, 13 and 14] mainly emphasize on the dynamic behavior and the fly configuration management procedure which ultimately reaches the main goal to have a unified architecture for utility service. Therefore in this paper we have designed unified system architecture for utility service in cloud. The proposed architecture could consider an initial step to initiate drawing the bridge between utility and ubiquitous computing based on the cloud’s environment. III.

CHALLENGES OF EXISTING ARCHITECTURE

A number of researchers all over the world are working on the basic limitations of existing cloud system architecture for utility service. Wei et al. [1] discusses on several open challenges in service oriented cloud and cloud computing in order to use it for utility services, such as service discovery, scalability, maintaining high service availability, rapid

service deployment, inefficient business model, lack of flexible, rapid deployment system and so on. We have found that there are several types of challenges available in the existing cloud system. In order to use cloud for daily utility service, at first, these challenges are to be diminished. Several challenges are enlisted as follows. A. Platform related challenges The nature of Cloud infrastructure and platform causes several challenges as following: 1) Deployment system is neither easily configurable nor unique for separate system. However in order to provide smooth and efficient utility service through cloud, it is mandatory to have a deployment system which is rapid, easily configurable with minimum changes in the system independently. 2) Security is still the major concern of consumers, therefore, cloud system architecture must be secured, protected from malware attacks and should possess self healing nature to overcome the loss and stand against different vulnerable attacks. This system needs to act as two different security systems; one for cloud oriented information or data, another for service oriented data. 3) A complete and efficient audit system should be incorporated with cloud system. So that the status of system can be monitored very efficiently. At the same time, the audit subsystem should be capable to generate information regarding the service reputation and any malfunction including security breach or service level degradation. 4) Utility service in cloud system must be scalable automatically. As a result, it is also important to have automatic load balancing system along with cloud system. 5) Time scheduling and proper algorithm to optimize the time among different services within the same cloud system is a challenging job. It is very essential to build a subsystem in order to optimize the performance of the total system. 6) Maintaining heterogeneous communication protocol used by users e.g. Bluetooth, WiFi, WiFi Direct etc. should be handled efficiently within the system. In this case bandwidth balancing and load balancing also needs to be addressed. 7) User interface are very complex [2] for existing systems like HP [4] or EC2 [5]. Therefore the user interface for configuration system should be user friendly and flexible. 8) A common platform independent application development kit needs to be defined. So that it would be very easy for SOA based service provider to develop different applications according to the requirement. Also it would save a lot of time and reusability of applications and coding should be easier. 9) Cloud Service Provider (CSP) independency is another important necessity. 10) Inter system communication is also very necessary for modern cloud based utility service system [3]. There must be an established efficient inter system communication channel. This channel should be system independent and configurable for any system in cloud.

11) There must be a concrete risk management system along with efficient backup system in order to handle unexpected disaster. B. Service Related Challenges Service in utility computing is one of the driving factors for architecture design. It provides challenges due to their heterogeneity, organization, user domain, user interaction procedure and so many other features [17]. Some of the most significant challenges are as following: 1) In case of utility service, service level agreement (SLA) plays an important role.So, it is also important issue to define the rules and regulations of SLA for the system. 2) A separate billing system needs to be incorporated which should be independent from any particular service. Moreover, this service should be configurable for different services according to the SLA. 3) Proper algorithm should be incorporated to discover service. Algorithm should be suitable enough to increase the maximum service availability. 4) Another advance technological component which needs to be added to the existing system is theagent based ontology generation system. Now-a-days, context aware service delivery and ontology based service report is an ultimate requirement from user.Therefore, this component needs to be addressed for better service. 5) Another significant thing is services must be available on demand. Moreover,service reputation is also an inevitable part of modern system. It is necessary to publish service reputation periodically and to forecast future situation based on all information. IV.

PROPOSED CLOUD BASED UTILITY SERVICE SYSTEM ARCHITECTURE

In this paper, cloud based architecture is proposed for utility service. The main goal of this proposed architecture is to improve dynamicity of configuration for the security, availability of service and context awareness of system. In addition, this proposed architecture will also ensure to make ontological decision using reasoning and incorporation with different social networks in a balanced workload environment for different types of utility services. The main challenges for the proposed architecture is to provide a unified architecture regardless cloud service provider (CSP), different services and heterogeneous network topology. The proposed architecture is depicted in Fig.[1]. A. Application Layer The main component of this layer is the User Interface (UI) configuration which is designed to deal with heterogeneous CSP, applications, user interface middleware and services. In this layer, a number of applications can run together. In order to adopt a general and easier way to configure those applications, simple XML or XHTML based specification files are available for different types of services and applications. User needs to change particular simple XML or XHTML file and in order to reflect the change in user interface of application configuration console

of all kinds of cloud broker, social networks e.g. Facebook, LinkedIn, twitter, cloud vendors like HP and Amazon as well. In this layer all policies and d social media usage of utility service defined by social neetwork, cloud broker and vendor must be defined and deployeed. Audit and Monitoring layers will audit and monitor the im mplementation policies by each application and service. For F implementation, the proposed architecture uses web serrvice based API for each vendor, social network or cloud broker. b All web service based APIs are connected to the data d storage and another stand alone web service for service registry. r

Fig. 1. Architecture of Proposed Cloud based utiliity service system architecture

redesigned and deployed as well. The appliccation can be web application, mobile application or even dessktop application. Deployment configuration component is a common component for each and every layer. For this layer (application layer), this component is in chaarge of deploying application in different process. The deployyment process for different applications can be of three types [66] as following: • Multiple instances of same applicaation are running together with single instance of service. • Single instance of an application is running with single instance of service. • Single instance of an application is running with multiple instances of same service. Another responsibility of deploymennt configuration component is to register each available servvice in the service registry and also update the application map that stores references for all allowed services for each aapplication. Load balancing component is also aanother common component for each layer in the proposed architecture. However, the major percentage of work of tthis component is mainly done for application layer, SOA layeer and SaaS layer. Once deployment configuration componentt deploys several application instances, the load balancing com mponent come in to account to manage the load among differrent applications. This component is also responsible to publiish a status report to audit component periodically. B. Vendor Layer Recently social network is becoming vvery popular for cloud based utility service. For instance, Faacebook is being used to buy garments items through severaal fashion houses. Sooner the world is going to approach unifieed electronic cash [6]. As a result, we have introduced this layer which consists

C. CSP layer This layer mainly consists of following important components. nent: This component 1) Service discovery Compon receives requests from applicatiion layer and runs a discovery algorithm to find out the appropriate service with t period. Optimizing best performance within shortest time maximum availability within short time and minimum cost mponent. Sometime the is the ultimate goal for this com service discovery algorithm is dessigned only to fulfill the vendor’s requirement and does no ot focus on performance only. c is responsible 2) Helpdesk Component: This component for customer service. All kind of negotiation and communication with customer are managed by this component. This component musst have mailing service, social network community, audit and report system for efficient communication. 3) Access Control Componentt: This component deal with the access management overr the entire system in a trusty fashion. For access control management system the proposed architecture establishes the same architecture proposed by Habiba et al. [11]. 4) Security and Trust Componeent: No architecture will be successful if security and trrust is not maintained properly. For this proposed unified d architecture we plan to integrate the collective swarm inttelligence based security system architecture proposed by Islaam et al. [16]. 5) Service Oriented Feature (SO OF) Layer: This layer of the proposed architecture mainly deals with the service configuration, management, mainteenance and deployment. Following are the components of SO OF layer. 6) SLA Settlement Component: Service level agreement (SLA) is one of the mandatory feaatures for utility service. Wu et al. [8] describes SLA manaagement system for their proposed utility computing architecture as shown in Fig. [2].

Fig. 2.SLA Component proposed p [8].

Their SLA component is missing quuality of service (QoS), compensation mechanism for poor service, auditing, configuration module, specification databaase, specification parser, common SLA format components. Therefore in our proposed SLA component we have incorpoorated all missing components. Our proposed SLA componennt is inspired by the definition of SLA component proposeed by Jin et alto some extent [13] who describes a typical SLA component with different subcomponents that describbe different roles such as purpose, restrict, validation, scope,, parties, penalty, optional service, SLAs and admin. Therefo fore the total sub components for our proposed SLA component are Discovery, Specification Parser, Pricing, Configuration, Scheduling, Re/Negotiation, Monitorinng, Accounting, Dispatching, QoS Maintenance, Validatorr, Compensation Management, SLA Enforcement, Specificatiion Database and Auditing. 7) Billing Settlement Component: Acccording to the system of service context, different kinds oof billing systems need to be deployed. For instance,First time purchase, Subscription for regular payment (Prepaidd or Post Paid), Meter based (Meter based and Prepaid or Meter based and post paid), Hybrid which can be configuredd dynamically to any of the above mentioned billing systems.. 8) Reasoning Component: This compponent acts as a resonance knowledge domain for impposing artificial intelligence. This component generates the input for ontology generation component and ddecision making component. Finally it collects resonance knnowledge domain and stores them for future use. 9) Business Model Settlement Component: Rappa [6] model for utility has described the taxonomy for business m computing system in cloud. He has ideentified different classifications and types of utility system. 10) Deployment Configuration Coomponent: This component is basically responsible to deeploy the system specification for different services and customer in to different types of cloud such as private, ppublic or hybrid. Fig. 3 shows the sub-components of deployment configuration component. Spec from different service providers oor customers are queued in a scheduler. There is predeffined scheduling algorithm run inside the scheduler that hhelps deployment configuration component to schedule all the specs within due time and budget. Wu et al. has conducteed a comparative analysis of three meta-heuristic based schedduling algorithms including genetic algorithm (GA), ant coloony optimization (ACO) and particle swarm optimization (P PSO) scheduling algorithms in their paper [14]. In this com mparative analysis they have represented PSO based schedduling algorithm performs best in a time and cost constrainned environment. For a dynamic cloud environment where tiime and cost are two contradictory parameters, we have seleected PSO based scheduling algorithm for its better perforrmance and less memory requirement [18]. Therefore in this work, the scheduler is cost effective. Once any spec passes the scheduler it reaches the deployment enginne which already has some common specs and a filter. The deeployment engine then prepares the final spec that is to be deployed in any

Fig. 3. Sub-Components of Deplo oyment Configuration Component.

cloud based on the specification. Filter helps deployment g type and other decision. engine to choose cloud type, pricing Here the filter gets it input from other components such as ng settlement component, decision making component, billin SLA settlement component, bussiness model settlement component and finally prepare an appropriate filter criteria d. for any spec which is to be deployed 11) Context Aware Management Component: One of c is to enable the main goals of the utility computing automated service integration. In th his regard, location is not only the context [4], along with h location, information, sensors, time and so many other objects are considered. Although context aware computing is still limited to mobile computing, however, recently con ntext awareness is being considered as one of the block module for ubiquitous computing. mponent: This component 12) Ontology Generation Com is directly related to two other com mponents such as Context Aware Management (CAM) and Decision D Making (DM). Fig. 4 explains the architectural structure of Ontology GC consists of reasoning Generation Component (OGC). OG engine, filter engine, formatter and a a database. Sample context aware based information in nformation e.g S1, S2 are collected from surrounding conteext and are saved in a generic context aware database. Later, L reasoning Engine runs several reasoning algorithm on o different category of parsed context aware information such s as C1, C2 in Fig. 4. Once all categorized context aware (CA) data are f criteria to filtered resonances, filter engine runs filter required data and information fro om the vast number of categories of CA data. ponent:Both Ontology 13) Decision Making Comp Generation and Decision Making component take part in decision making for this compo onent. This component gathers knowledge storage in other two components and generates decision based on thosee stimuli generated from other two components.

Fig. 4: Sub Components of OG Compoonent.

D. SaaS layer This layer consists of four different compoonents which are described below: 1) Configuration Component: This component is the most dynamic component of proposeed architecture. Different configuration process or mechaanisms will run inside this component for different purposees. The main goal of each configuration mechanism is to perform a unit functionality configuration to keep it simpple and flexible. Therefore this component consists of a number of configuration mechanisms which are ussed o configure service deployment, security, billing, Servvice maintenance, customer ecosystem, logging and reportingg, cloud system, scheduling, scalability and automation.

Fig.5.Architecture of Configuration Com mponent

The mechanism to deploy configuration follows the steps given below: a. Filter picks the correct resource discovvery algorithm to choose the correct configuration specificcation; therefore, here the resource for resource discovery algorithm is the configuration specification. There must bee filter to choose the correct specification or process for corrrect service and correct functionality. All the algorithms for discovering mented inside the configuration specification must be implem filter component. There can be different reesource discovery algorithms based on the nature of service. For example, for SLA driven services, the resource disccovery algorithm presented by Dasjerti et al. [14] is a suitabble one. Similarly for market oriented cost and time constrainned environment,

the market oriented resource discovery algorithm proposed by Wright et al. [18] is considered in this work for its better performance and dynamic scalability y. b. Once the correct specification is selected, Parser parses the spec into a process specificaation and delegates the process specification to Configurration Process Manager (CPM). Process will be stored there for execution. CPM actually identifies the action from the parsed process and t actual unit task. informs configuration engine about the c. Filter selects the exact filtering g algorithm based on the nature of environment as already y mentioned in order to refine the process specification and once the process specification is filtered and validateed by valuator that is sent to configuration engine. d. Configuration Engine is responsible to check whether all resources are available for the deplloyment. Once it gets all resources ready, it executes the con nfiguration and deploy in cloud. 2) Load Balancing Componeent: The task for this component is really simple to baalance the load for the system and keep it scalable. For doiing this job there must be a priority driven and scheduler. Once O the scheduler can schedule the load balancing actio on to be executed, we propose the load balancing algorithm a proposed by Daryapurkar et al. [9]. However, we w have planed to develop another load balancing algorithm in nspired by the algorithm based on honey bee behavior propo osed by Babu, et al. [10]. Using swarm intelligence can impro ove the performance to a great extent [10] and also this existiing algorithm needs to be modified to run in for a dynamic on the fly environment. This will be described in our future work in details. ponent: This component 3) Workflow Deployment Comp is for future scalability and automaation. As the architecture is used and run over different deplo oyment environment and the reasoning as well as the ontolog gy component, it will get mature more and more. At that mo oment a single workflow can be designed and that will initiatte to run all the activities for different components and in nitiate the configuration process. nent : SaaS layer also has 4) Third party Service Compon another important component to utilize u several third party services. For instance, we have useed an E-learning program supported by a library system as a utility service. For this onent in SaaS layer there system, in third party service compo could be several third party services to buy books such as eBay, Amazon. There could be Goo ogle Map as another third party service to define the locatiion of students and the nearby library where the required bo ook will be available. E. PaaS Layer This layer deals with the platforrm related characteristics of the proposed unified architectu ure. It has the following components. T is the module which 1) Configuration Component: This one is responsible for deploying PaaS system for utility a described in service. This module has similar architecture earlier section. 2) Network discovery component: This component runs hm to discover all a resource discovery algorith

requirednetwork component from cloud to complete any service delivery or discovery life cycle. 3) Network topology management: All information retrieval and maintenance are done by this component. 4) Virtualization Component: This component is used inspired by existing cloud environment where virtualization is a very important feature [15]. V.

WORKING PROCESS AND COMMUNICATION AMONG COMPONENTS

The working procedures of different layers are described in this section. A periodic monitoring and audit runs simultaneously to monitor the complete system and its stability. A. Application Layer For every application deployment in application layer the following activities are performed: a. UI component designs the UI for application deployment and service registration console. b. Deployment component decides the deployment mode for particular application from any of the three modes described earlier. c. Service registry registers each available service against each application. d. Deployment component communicates data storage to define the service definition. e. Security console validates and authenticates the application each time it is deployed. f. Deployment component also publishes a periodic status report to audit component regarding the status of all deployed applications. g. Once any application crashes or any runtime error occurs, risk management needs to store back up for certain action point periodically to store the status of application and its deployment environment for uncertain damage. h. Monitoring component continuously monitors the state of different applications. Internal communication component is used for communication among different applications or different instances of same application for internal communication among them. B. Vendor layer Vendors (social network, broke, vendor) are usually the request generators for any service using application on behalf of the users. The following activities take place in this layer: a. Vendors generate the request and submit that in the request queue situated in vendor layer. b. Each vendor is register to a vendor registration system. c. Security component validates and authenticates the vendor, if any invalid or unregistered vendor generates any request that request is rejected immediately and deleted from the request queue. Security component sends the identity of invalid vendor to IaaS layer and the corresponding vendor is also blocked from the network through IaaS Layer. d. Security component validates the request also. Request validation includes the format validation for the request.

e. All valid requests are parsed to SOF layer. C. SOF Layer All the service related tasks are mainly performed in this layer. This layer can also be considered as the middleware layer between cloud and utility service. Time scheduling component schedules the request queue in order to optimize the execution time and system workload. Parse component parses a request and differentiates the requested service, billing metadata, SLA for request, requested service provider preference, required time for engaging to service, execution time, and validation and identification information regarding the request. Service related information are extracted from there, parsed request specification of the service definition is prepared accordingly. Then service discovery component searches for the requested service. If requested service is found, required resources and infrastructure elements are discovered. For this a discovery web service API runs. The next stage confirms the SLA, if SLA discontinues or SLA agreement is not taken care of, the request is blocked and all other layers are notified by notification component. If SLA is confirmed for requested service, the next step is to confirm the billing agreement. This billing settlement also get approved only if the required amount is available, if the amount is available and all other policies for billing are satisfied the request is passed to Business Model Component (BMC).BMC is responsible to validate whether the task, request itself and the requested service are following the appropriate business model. And also the running business model is valid according to the policies and specifications. Ontology and reasoning components gather required information from the request in order to make input for decision making component. If any alert arises from decision making component that is immediately imposed by supporting activity component. There can be different kinds of alerts such as update stimuli for current request, change in system and/or in request, stop/pause/resume/restart the current request only store data, backup the system and update decision making component. Context aware component also gathers information for system learning and is also responsible to generate alerts which are aware of the surrounding context. Similarly for the alert of decision making component those alerts are also immediately imposed by supporting activity component. Along with the alarms described for decision making component, context aware component also generate some special alarms such as update context aware (CA) database, add new data and refine CA based data. D. SaaS layer After requested are passed to SaaS layer, the complete task is defined for running the whole process. Once all unit tasks are prepared, all tasks are put into a single workflow. Each task is registered against a workflow and each workflow running in this layer is registered. Workflow initiates the requested service execution. If internal communication is required among requests, it is done by internal communication system component. Load balancing

component is again busy in this layer to balance workload among different workflows. E. Pass Layer First of all requested or already fixed network topology is deployed in this layer after that the following activities are performed sequentially: a. Network discovery service helps to select the optimum network solutions. b. Once network is established, the protocol agreement is settled, protocol agreement component establish all communication and cloud platform related protocols. c. Requests are passed an OK status for current request to SaaS layer. d. Audit component audits and monitoring component monitors this layer continuously. e. Security component is responsible to validated and secure network topology. F. IaaS Layer Infrastructure validation and authentication is done by security component of this layer. This component is also responsible to validated and secure network topology. Audit component audits and monitoring component monitors this layer continuously. Selecting optimum communication protocol and validating that is another important responsibility of this layer. For selecting this optimum communication protocol, Eq. (1) is used.

CM = f ( d p , c p , c m , m , o p , ξ )

(1) Here f is a function, which is implemented and defined according to the policies and agreements set by CSP. The value of CM for any communication protocol needs to be less than threshold value in order to be selected. Other parameters are device configuration (dp), critical parameters (cp) such as energy, time duration, number of simultaneously running applications etc. It also selects optimum communication protocol (cm) among Bluetooth, NFC, WiFi based on network components of devices., an optimum set, ξ of SLA, a set of mandatory ( m) as well as optional ( o ) p policy. VI.

METRICS FOR DIFFERENT LAYER

In this section different metrics those are mandatory to be defined regardless utility service provider are discussed. θ: If the service execution time is less than the threshold value θ defined by CSP for each service, the corresponding service in current hour which could be either off-pick or onpick, will be put in to request queue. Otherwise it would be rescheduled. The value for θ is defined by CSP. δ: It is a Boolean value which could be either true or false. If the service can be performed within negotiated cost, it has a positive value; otherwise it has negative value. Negative value of δ indicates the service execution failure. ∆ : This defines the scope for renegotiation for cost and time of service execution. This defines the deadline, d to complete the task. The costs limit (c) that could be possible to readjust. The SLA limit must be maintained and defined by p.

ρ: This value is for pricing. Utility service provider (USP) should give the value for this metric. This value includes payment amount (pa), available payment method list (pm) and payment deadline (pd). μ: This metric defines the SLA level. This includes SLA enable (ss), which can be either true or false. If it is true SLA needs to be enforced while service is being executed, for false value SLA remains disabled. The parameter, sl is a value, which is defined by (USP) for each service for different class of user. For example sl could have any value like 1, 2,3 etc and each value defines different set of service level. Sq defines the quality of service (QoS). sq is a tuple which is consists of three different values (m,n, r) m defines the QoS for cloud service system, n defines the QoS for utility service system and r defines the QoS for resources. sp defines the priority for SLA in the system over other features. sp can be any value within the range (min, max), where min and max are defined by CSP. For a SLA driven utility system sp will be max. α: It can be any value within the range (min, max), where min and max are defined by CSP. This value define the how important of availability of services for the system. If the system mainly emphasize on the high availability of service over other feature such as SLA, then the value of α is max. β: This metric is used for defining the scalability scope. It can be any value from 0 to 10. For example for a small rigid utility system for example E-learning program for a particular university, only a definite number of users will use the system. Therefore it is not necessary for the utility service system USS to be highly scalable. For this system the value for β could be less such as 4. On the other hand, for a large scale USS, the value for β would be 8≤β ≤9. Therefore, the proposed architecture maintains an Eq.(2) to evaluate the cost using the above mentioned values. F is the value of efficiency that refers to cost, SLA, scalability and deadline. The value of F indicates the complete efficiency of the system. It considers all these parameters and gives an optimum efficacy value that should be maintained in the proposed architecture.

F=

ρ + μ ×α + (Δ × δ ) + β θ

(2)

As F is considered for execution, cost, negotiation, scalability, so the system performs best for the optimum value for F. On the other hand, for the worst value of F, the service rendering and deployment systems also perform worst. Therefore, these metrics proposed in this paper help to get minimum execution time for any service along with lowest cost. VII. PERFORMANCE DESCRIPTION In this section we describe an example for stating the implementation of proposed architecture. For this example, let’s consider an E- learning program from a library system. 1) Easily configurable: The main requirement for an up-to-date utility service system is that can be configured on the fly based on the service, customer and context. In a nutshell, the system can be configured and localized whenever necessary with limited effort. This proposed

unified architecture is a prominent solution for such requirement. 2) Unified system: Recent trend is to incorporate all kinds of utility services under cloud and govern them from same individual system. The main focus of this proposed system architecture is to provide a unified architecturewhich is configurable for different kind of utility service deployment. 3) Metric is defined already: One of the main problems of existing system architecture for utility service that in most of the cases the required metrics are not even defined. Therefore dynamic configuration of the system, pricing, deployment even maintenance become very complex and expensive [2]. In this proposed system architecture several metrics are defined and determined. These metric take part in configuration, deployment, pricing and maintenance. 4) Social Networking or Social cloud has been considered: Now-a-days one of the main concerns of utility computing is to integrate the service maintenance to the social network account of particular user. For example, a user log in to his facebook account and he will receive some alert for his utility billing such as bill payment slip for house rent, bill for internet connection, bill for gas, electricity and so on. Some of the provider who uses their own web portal for this kind of alert are planning to move this feature to social networking site like facebook, Google plus. Therefore the userdoesn’t need to manage different accounts for each of the utility service he or she is registered and at the same time the providers don’t need to manage a different web portal. This will ultimately become more flexible for user and less expensive for service providers. 5) Third party services are included: Open source is really a large community for current days and we cannot ignore them completely. Therefore if any architecture is goaled to be unified there must be scope for third party. 6) Highly secured: The first and foremost requirement for unified cloud architecture for utility service that the system must be highly secured. For security purpose in this proposed architecture we integrate our previous work on collaborative swarm intelligence based trust for cloud [10]. Therefore the system is secured and robust. 7) Continuous Audit: Another important feature for the proposed unified architecture is the continuous audit system. Every component is audited and logged separately. Finally a combined report is generated for integration testing purpose only. Therefore, if there is any malicious activities or any malfunction at any component of the total architecture, that is reported immediately and it is possible to take immediate action for system healing. VIII.

CONCLUSION

In this paper unified and easily reconfigurable cloud system architecture has been proposed for utility service system (USS). Several metrics for USS are also defined, which are responsible to define the exact value for USS. The performance description of this architecture shows that it will reduce cost and time for USS establishment and maintenance. For our future work we shall consider the implementation of this architecture in several real life utility

systems for electricity, gas and E-learning. We are also planning to focus on swarm intelligence to develop load balancing algorithm for the unified architecture for cloud environment. REFERENCE [1]

[2]

[3]

[4] [5] [6] [7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

W. Yi, and M. B. Blake, "Service-oriented computing and cloud computing: Challenges and opportunities." IEEE Internet Computing, vol.14(6), pp: 72-75, 2010. H. Christian, S. Caton, K. Chard and C. Weinhardt. "Co-operative infrastructures: An economic model for providing infrastructures for social cloud computing." (HICSS), 2013,IEEE46th Hawaii International Conference onSystem Sciences, pp. 729-738. 2013. D., Yuri, C.Ngo, C. de Laat, J. A. Garcia-Espin, S. Figuerola, J. Rodriguez, L. M. Contreras, G. Landi, and N. Ciulli. "Intercloud Architecture Framework for Heterogeneous Cloud based Infrastructure Services Provisioning On-Demand", 2013. HP public cloud, http://www.hpcloud.com/ Amazon Elastic Compute Cloud (Amazon EC2), http://aws.amazon.com/ec2/ M. A. Rappa, "The utility business model and the future of computing services." IBM Systems Journal 43(1),pp. 32-42, 2004. M. A. H. Masud, , and X. Huang. "An e-learning system architecture based on cloud computing." World Academy of Science, Engineering and Technology, , vol.62,2012. L. Wu, and R. Buyya. "Service Level Agreement (SLA) in utility computing systems." Performance and Dependability in Service Computing: Concepts, Techniques and Research Directions, pp: 125.IGI Global USA, 2011. D.Akshay, and V. M. Deshmukh. "Efficient Load Balancing Algorithm in Cloud Environment." International Journal of Computer Science and Applications, vol. 6(2), 2013. B. L. D. Dhinesh, and P. V. Krishna, “Honey bee behavior inspired load balancing of tasks in cloud computing environments”, in the proc. Applied Soft Computing, vol. 13(5), pp 2292-2303,May 2013. M. Habiba,M. R. Islam, and A. B. M. S. Ali "Access management for Cloud," In the proceedings of 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-13), Melbourne, Australia, 16-18 July, 2013, pp. 485-492. R. Buyya, C. Yeo, S. Venugopal, J. Broberg and I. Brandic, "Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility." Future Generation Computer Systems, vol. 25(6), pp: 599-616, Elsevier Science, Amsterdam, The Netherlands, June 2009. L. J. Jin, and V. A. Machiraju, Analysis on Service Level Agreement of Web Services. Technical Report HPL-2002-180, Software Technology Laboratories, HP Laboratories, June 2002. A. V. Dastjerdi, S. G. H. Tabatabaei, and R. Buyya, "A Dependency aware Ontology-based Approach for Deploying Service Level Agreement Monitoring Services in Cloud", Software: Practice and Experience vol. 42, no 4, pp. 501–518, 2012. I. Foster, Y. Zhao, I. Raicu, and S. Lu."CloudComputing, and Grid Computing. 360-Degree Compared", " IEEE Grid Computing Environments Workshop, GCE’08, 2008. R. Islam, and M. Habiba. "Collaborative swarm intelligence based Trusted Computing." IEEE International Conference on Informatics, Electronics & Vision (ICIEV), pp. 1-6. 2012. Y. Wei, and M. B. Blake. "Service-oriented computing and cloud computing: Challenges and opportunities."IEEEInternet Computing, vol. 14, pp. 72–75, 2010. P. Wright, Y.Sun, T. Harmer, A. Keenan, A. Stewart, and R. Perrott "A constraints-based resource discovery model for multi-provider cloud environments." Journal of Cloud Computing: Advances, Systems and Applications, vol. 21, pp: 1-14, June 2012.