Model Driven Engineering and Verification of Composite Cloud Services in MetaMORP(h)OSY Francesco Moscato Dep. of Political Sciences Jean Monnet Second University of Naples Italy Email:
[email protected]
Abstract—Service Oriented Architectures and service-centric models arose in the last years as a standard de-facto in IT enterprises for offering practically any kind of services to users world-wide. In particular Cloud-based models provide means for realizing and distributing everything-as-a-service, including infrastructures, hardware and software platforms and services. Even if at the moment Service-centric models and technologies are mature in the IT scenario, composition, analysis and validation of Cloud services are open research challenges. In this work we describe a methodology based on Multi-Agent Models which allows for description, composition and verification of requirements of Cloud-based services. The methodology uses a modeling profile able to describe services as agents in a multiagent environment and it is based on Model Driven Engineering (MDE) techniques. The proposed methodology includes a verification process for requirements that exploits formal methods during the whole life cycle of services.
I. I NTRODUCTION Nowadays, researches on service-centric system engineering mainly focuses on Cloud Services, since they have Cloud Computing has recently emerged as a new paradigm for hosting and delivering services. Users demand more and more complex services, requesting some properties on services execution (Qualities Of services - QoS): providers must build and configure services in order to verify required QoS. In addition they have to enact proper monitoring actions able to assure that services are provided with promised QoS also at run time. A methodology to analyze reachability of goal services with given QoS is appealing if it can be used to build automatically the target service [1], [2]. In this scenario Models based on Multi-Agent Systems[3] (MAS) Models are promising formalisms for the analysis of composite Cloud services. MetaMORP(h)OSY framework is based on Papyrus [4] and defines profiles for the definition of a modelling language for real-time MAS description. Verification at every life-cycle step is performed by implementing translation algorithms which translate design, simulation and run-time description into formal models [5], [6], [7], [2]. This paper shows how it is possible to use MDE and MAS models in order to describe composition of cloud services meeting given availability QoS and how it is possible to verify requirements at design phase while configuring (existing)
services to offer a VAS. A simple example will be reported in order to show the application of the presented approach. This paper is organized as follows: section II contains an analysis of the state-of-the-art in Model Driven Engineering methodologies and tools applied to Cloud systems development and validation; the MetaMORP(h)OSY overall architecture is described in section III. SectionIV shows how it is possible to use MetaMORP(h)OSY methodology to describe and validate cloud services composition. The methodology is applied to a simple example in section V. Finally section VI contains some concluding remarks. II. S TATE O F T HE A RT Combining Cloud services to build VAS in Cloud environments is a recent problem and an open research challenge. Interoperability is still a problem for Cloud services of different providers, and composition is usually approached with the standard methods (i.e. Orchestration) used in Web Services and Service Oriented Architectures [8]. Anyway, Agent-Based paradigm in defining and implementing cloud services is arising because it copes well with characteristics of Cloud systems[9]. In this scenario an increasing number of cloud platforms are trying to provide services by using autonomous, self-organizing MAS. For example, Authors in [10] use a MAS system to provide cloud services. The need for Choreography in composition in this work is clear, but a methodology and a language have not been yet defined for modeling composition of services,. In addition, the other problem in modeling and providing Cloud services is that users request given level of services in terms of Service Level Agreements (SLA), but existing public clouds provide very few guarantees in terms of performance and dependability [11]. Several approaches have been proposed in the last years in order to manage performance and dependability in terms by signing SLA between providers and users. A similar approach for SLA enforcement, based on classes of clients with different priorities, is presented in [12]. The need for a managing guaranteed Service Level Agreement becomes larger in the last years. Authors in [13] proposes a new Cloud Model, entirely based on the provision of Cloud services which fulfill measured properties at run-time. Model Driven Engineering (MDE) Techniques sounds good to reach
the goal of SLA verification and monitoring since they cover all the life cycle of the services (from design to run-time). There have been several attempts to apply MDE techniques to the study and development of Cloud systems and services. In [14] authors propose to implement Model Driven Engineering environments as a Service to use on the Cloud. Although it is only a proposal, the idea of providing services which are build based on Design requirements and not already deployed by providers is appealing. The need for verification of requirements by using formal methods at design phase is reported in [15]. What is missing in this work is the enactment of the optimization based on users requests and SLA managements. Furthermore, once the services are optimized at design phase, there is no way to reconfigure the system monitoring services execution. The need of MDE techniques for defining Cloud Systems and services is reported in [16], where are outlined the lack of support for heterogeneous Cloud providers, the limited matchmaking between application requirements and Cloud capabilities, the lack of meaningful cross-platform Cloud resource descriptions, the lack of lifecycle management of Cloud applications, the inadequate cross-layer monitoring and adaptation based on event correlation. In this context MetaMORP(h)OSY tries to overcome all the reported limitations in applying MDE techniques to the management of Cloud Systems and Services. First of all, MetaMORP(h)OSY is able to address different kind of requirements (reliability, availability, performances, security etc.). Requirements verification is enacted in all the life cycle of services, hence it is not limited only at design phase. MetaMORP(h)OSY components can be embedded at run-time in order to allow for requirement verification also during services execution, acting not only as a development tool, but also providing a mean for produce run-time monitors of services depending on users requests. The use of MetaMORP(h)OSY methodology, it is possible to build and configure services depending on users requirements (i.e. SLA) and not only to choose the “best-coping” service for user. III. M ETA MORP( H )OSY In the following both the Architecture of the MetaMORP(h)OSY framework and the MDE methodology on which the Architecture is based will be described. A. MetaMORP(h)OSY Modelling Methodology The MetaMORP(h)OSY Modeling Methodology (MMM) is based on Beliefs, Desires, Intentions (BDI[3]) methodology. A UML modeling profile that implements a modeling language (RT-AML) for real-time BDI MAS is used in order to describe design models. Requirements are verified at design phase by using formal methods following a MDE approach. Vertical model transformation [17] can be enacted to specialize design models onto simulation or run-time ones . Notice that verification of properties in a given phase can also be enacted applying abstraction techniques in the case verification cannot be applied because of model (or system) complexity or even because of decidability problems.
A way to associate a request for verification to a proper analysis, simulation or monitoring process (at run-time) has to be provided. The association is realized by the definition of components that in MetaMORP(h)OSY are called Observers. MetaMORP(h)OSY profile allows for definition of new Observers if users want to define new verification processes. Since verification is driven by model transformation, new observers have eventually to be coupled with proper translation algorithms. Vertical transformation allows for refinement and abstraction of models. They strongly depend on the application and on systems to model, analyze and implement. In MetaMORP(h)OSY vertical transformation algorithms are embedded as plug-ins and are activated depending on the profile used by the users. Plug-ins for analysis, generation and monitoring of Cloud Systems and FPGA-embedded systems are provided at the moment in the MetaMORP(h)OSY. In MetaMORP(h)OSY, the definition of properties is also assured by the definition of a common ontology which describes formally cloud components and services and a taxonomy of properties which is possible to analyze on different MAS models components[18], [19]. Proper annotation techniques and models (like the one discussed in [20], [21], [22], [23]) have to be coped with services definition in order to be exploited in mOSAIC. IV. M ODELLING P ROFILE IN M ETA MORP( H )OSY The Modeling Methodology in MetaMORP(h)OSY (MMM) is based on AML[24], that describes MAS by using a UMLbased language. As described in[25], the original support for describing timed behaviors of agents in AML is poor. Agents behaviors are defined by using Beliefs, Desires, Intentions (BDI) logic. Agents structures are defined in terms of beliefs of agents, goals they want to achieve and the available plans to reach the goals. The language defined in MMM for Agent description is called RT-AML (RealTime AML) since it was originally intended for describing real-time agent. As described before, RT-AML is a UML-based language. The UML profile on which the RT-AML metamodel is based is described in the following. RT-AML useses four diagrams for MAS behaviours description: the Class diagrams, the same of UML diagrams. They are used when it is not useful to describe objects as agents (for example, for passive entities); the RTAgent diagrams, the core of the RT-AML profile, are used to describe agents structures, goals and beliefs, their inner states and to declare which actions and plans they can execute; the RT-Activity diagrams that allows for the description of agents plans; and the RT-Sequence diagrams that are used in order to describe agents collaborations (and/or competitions). Their main goal is to define how messages and events (real-time stimula) are exchanged during agents plans executions. Main Elements in RT-Agent diagram are: AgentRT, PlanRT, DgoalRT and BeliefRT. AgentRT stereotype is used to define agents structures. They are managed as classes hence they have to be related
to Class and Classifier UML base classes. In addition relationships with ObjectNode and ObjectFlow have to be defined in order to apply the stereotype to classes and objects in the RT-Activity and RT-sequence diagrams. RT-Agent inner state and other resources (like sensors etc.) are modelled as MARTE Resources. In addition, an AgentRT is composed by BeliefRT, PlanRT and DgoalRT. AgentRT stereotype properties include: PlanningSwitchTime, the time needed for an agent to replan actions (if needed); Thinking Time, the time usually spent by agents when a choice must be taken; Action Time, the time used to begin actions executions; Reaction Time, the time elapsed between thinking and action time; Start and Finishing Times, the times (if defined) when agents are started and terminated; Priority, the priority of agents. PlanRT allows for the modelling of plans as Steps(i.e. actions) composition as it was introduced before. Plans are associated to goals: each plan is intended as a composition of actions aiming at reaching a goal state. Some properties for this stereotype are: Arrival Time, the time when the Plan is activated; Execution Time: the time needed to execute a plan; Start and Finish Time, the times at which the plan is started and finished; the Deadline, the deadline for the plan execution; PlanType, used to specify hard or soft real time behaviour. DgloalRT stereotype is used to define decidable goals for AgentRT, where a decidable goal is a goal whose reachability can be determined under real-time constraints. Some DgoalRT properties are the following: MantainingGoal Time, the time the goal has to be maintained active; Deadline, the deadline for the reaching the goal; GoalType, that is used to specify hard or soft real time constraints for goal reachability. RT-Activity diagrams inherits all elements from UML activity diagrams, and re-define states and transitions to enable realtime constraint specification. In particular, ActionStateRT, InitialState, FinalState, TransitionRT, SendObjectRT and ReceiveObjectRT are the new stereotypes for this diagram. InitialState and FinalState are the initial and the final states for the Activity Diagram. Usually FinalState refers to a DgoalRT, since usually agents actions are enacted in order to reach their goals. When starting a new plan, an agent has some Beliefs of its environment. Beliefs also composes its initial state and are specified as properties of InitialState stereotype. The usual time-related properties are instead related to the final (goal) state. ActionStateRT is a step that composes the whole agent plan. It inherits the classic UML Activity State, but also GaStep from MARTE profile. An Action State is basically an activity State which is subject to real-time constraints. In fact, this stereotype is characterized by the following properties: the ExecActionTime, the time needed for the execution of the action; the TimeOut. Two particular types of ActionStateRT are the SendObjectRT and ReceiveObjectRT, which are used when messages and events are sent and received to and from other agents. TransitionRT is a stereotype used to define transitions in activity diagrams with timing constraints. Time-related
properties are defined also for this stereotype. Finally, the main elements for Sequence Diagrams are: StimulusRT and SyncType. The StimulusRT stereotype is used to define stimula with real time constraints in Sequence diagrams. The main properties for this element are: the StartTime, the time when the decision of sending a message is taken by an agent during the execution of a plan; the SendTime, the time when the message is sent; the TransmissionTime, the time needed for messages transmission; the StartReceiveTime, the time when the receiver begins to receive the message; the StartEndTime, the time when the receiver ends to receive the message; the Deadline, the deadline for transmission; the MessageSync, it is used to specify if the message is synchronous or not (SyncType). V. E XAMPLE Let us suppose a user needs to implement an highavailability storage service. In order to improve availability services can be hosted and replicated to multiple providers, on multiple locations, reducing chances of failure. To this purpose, let us assume that a Composed Cloud Services will be build. Replicas or different storage services will be used in the composed service in order to increase availability. Services used in composition are: (a) SimpleStorage: it has the goals (SimpleReadOK and SimpleWriteOK9 of completing a read or a write operations (SimpleRead and Simple Write). (b) MultipleStorage which has the goals of performing a Read or Write operation (ReadOk and WriteOk Goals respectively) in a redundant configuration of storage; (3)Connection: this agent models the link connection among services. Fig.1 shows Agent Diagram of Services Here we show how MetaMORP(h)OSY can be used for describing and analyzing this Composite Service. In this scenario a storage service with given availability is built. Let us assume that no available vendor can meet requirements and that a Composed Cloud Service is built by using available storage services. In order to increase availability, in this example, data are replicated on different storage services. In a redundant configuration, data are collected from multiple sources (SimpleStorage) and MultipleStorage service reaches its goal if a majority voting is completed on source storage. In order to model these agents and their interactions in MetaMORP(h)OSY, three kinds of diagrams have to be provided: the Agent Diagram, the Activity Diagrams for agents plans, and a Sequence Diagrams for describing interactions among agents. In the Agent Diagram the MAS system structure is described. Here classes with proper stereotype represent Agents, their Plans, their Beliefs and relations among them. The Agent Diagram with SimpleStorage, MultipleStorage and Connection agents is shown in Fig.1. The Agent Diagram in Fig.1 describes agents structures, listing their plans, beliefs and goals related to each plan. In order to complete the model a dynamic description of agents behaviors has to be provided. In MetaMORP(h)OSY this is done by mean of particular activity and sequence diagrams.
Fig. 1.
Agent Diagram
The MetaMORP(h)OSY profile defines several stereotypes for messages and timed activities in the activity diagrams. This allows for the analysis of timed behavior and interaction of agents. At the state, each PlanRT in the AgentDiagram is associated to an Activity Diagram which describes the action enacted during plan execution. Each action is described in terms of expected execution time, messages awaited from and sent to other agents, resources and beliefs involved in the action. Activity diagrams describe agents behaviors in regard to their plans, but different execution paths are possible depending on different use cases. In order to define which events and messages are involved in a particular use case, a Sequence Diagram is reported in MetaMORP(h)OSY. The main purpose of this diagram is the definition of agents interactions in a use case. In Fig.2 the Activity related to the plan MultiRead is reported. This is the first plan enacted by a MultiStorage agent in the use case described in this paper. it first sends three parallel requests to three SimpleStorage services in order to retrieve date requested by the user (RequestData[i], i ∈ {0, 2}). Each following ActionStateRT has a deadline associated: a retrieval fail if deadline expires. Retrieved Data are then compared by a Vote procedure. If at least 2 retrieved data are identical, the DataRetrieved action state (and the related DgoalRT reported in Fig.2) is reached. It is clear that Plans require communication among agents. Agent Collaborations are modeled by using RT-AML Sequence diagram. For example, interactions among Voter service and Storage
Fig. 2.
RetrieveData Plan
agents (which have not been described for brevity) are reported in Fig.3. All messages in the sequence are StimulusRT which is a MetaMORP(h)OSY stereotype able to represent the timed behavior of messages exchanged during the execution of the use case with three SimpleSotage Services. StimulusRT messages are related to messages sent and received in the actions of the activity diagrams; they represent the messages that are actually sent considering the use case in analysis. Filled Lifeline under the MultipleService agent indicates that not all the messages from Storage services have to reach the MultipleServices. If
Fig. 3.
Sequence Diagram
for some reason (deadlines expiration, broken communication links etc.) it does not receive all messages, the Vote action is executed (probably leading to an operation failure). Once the whole model has been defined in MetaMORP(h)OSY, it provides a way to chose the property to analyze and the type of analysis to perform. To this purpose, the MetaMORP(h)OSY modeling profile provides a set of stereotypes which are able to define properties to analyze on the system. They include functional and non functional properties, like state reachability, schedulability, availability, performance, fault tolerance etc. In addition, the type of the analysis to perform on the model is defined by mean of Observers. Depending on the property and on the observer, proper model transformation algorithm is executed in order to translate the RT-AML model into a model that can be exploited for analysis. For example, for what Availability concerns, in the example an Observer is used to translate the model into Fault Trees and the SHARPE[26] framework is used in order to analyze the property. The produced Fault Tree is depicted in Fig.4.
TABLE I AVAILABILITY SimpleStorage Replicas 1 2 3 4 5 1 2 3 4 5
StorageAvail. 0.95 0.95 0.95 0.95 0.95 0.98 0.98 0.98 0.98 0.98
Multiple Storage Avail. 0.9999 0.9999 0.9999 0.9999 0.9999 0.9999 0.9999 0.9999 0.9999 0.9999
Tot.Avail. Tot.Avail. 0.95 0.9975 0.999875 0.9999 0.9999 0.98 0.9996 0.9999 0.9999 0.9999
Some results about the analysis of the availability of the replicated service is reported in Tab.I Notice that the Availability of Broker and Voter in this simple example polarized results since they are a single point of failure in the system. VI. C ONCLUSIONS AND F UTURE W ORK In this paper the MetaMORP(h)OSY methodology and framework have been introduced and applied to the design and the analysis of a simple Coposite Cloud Service. It has been shown how MetaMORP(h)OSY suites well the MAS nature of cloud components and it is possible to define Observers on models for system analysis. Future works include the design and the analyses of high available and fault tolerant scenarios of complex systems. R EFERENCES
Fig. 4.
System Fault Tree
[1] F. Moscato, B. D. Martino, and R. Aversa, “Enabling model driven engineering of cloud services by using mosaic ontology,” Scalable Computing: Practice and Experience, vol. 13, no. 1, 2012. [2] F. Moscato, V. Vittorini, F. Amato, A. Mazzeo, and N. Mazzocca, “Solution workflows for model-based analysis of complex systems.” IEEE T. Automation Science and Engineering, vol. 9, no. 1, pp. 83– 95, 2012.
[3] M. Wooldridge, “Agent-based software engineering,” in IEE Proceedings on Software Engineering, 1997, pp. 26–37. [4] “Papyrus uml: http://www.papyrusuml.org.” [5] G. Franceschinis, M. Gribaudo, M. Iacono, S. Marrone, F. Moscato, and V. Vittorini, “Interfaces and binding in component based development of formal models,” in IEEE proc. of VALUETOOLS 09 conference, 2009, p. 44. [6] G. D. Lorenzo, N. Mazzocca, F. Moscato, and V. Vittorini, “Towards semantics driven generation of executable web services compositions,” International Journal of Software, JSW, vol. 2, no. 5, pp. 1–15, 2007. [7] G. D. Lorenzo, F. Moscato, N. Mazzocca, and V. Vittorini, “Automatic analysis of control flow in web services composition processes,” in PDP, 2007, pp. 299–306. [8] T. Dillon, C. Wu, and E. Chang, “Cloud computing: Issues and challenges,” in Advanced Information Networking and Applications (AINA), 2010 24th IEEE International Conference on. Ieee, 2010, pp. 27–33. [9] D. Talia, “Clouds meet agents: Toward intelligent cloud services,” Internet Computing, IEEE, vol. 16, no. 2, pp. 78–81, 2012. [10] J. O. Gutierrez-Garcia and K.-M. Sim, “Self-organizing agents for service composition in cloud computing,” in Cloud Computing Technology and Science (CloudCom), 2010 IEEE Second International Conference on. IEEE, 2010, pp. 59–66. [11] S. A. Baset, “Cloud slas: present and future,” ACM SIGOPS Operating Systems Review, vol. 46, no. 2, pp. 57–66, 2012. [12] M. Macias and J. Guitart, “Client classification policies for sla enforcement in shared cloud datacenters,” in Proceedings of the 2012 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (ccgrid 2012). IEEE Computer Society, 2012, pp. 156–163. [13] D. Serrano, S. Bouchenak, Y. Kouki, T. Ledoux, J. Lejeune, J. Sopena, L. Arantes, P. Sens et al., “Towards qos-oriented sla guarantees for online cloud services,” in IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, CCGrid 2013, 2013, pp. 0–0. [14] H. Bruneliere, J. Cabot, F. Jouault et al., “Combining model-driven engineering and cloud computing,” in Modeling, Design, and Analysis for the Service Cloud-MDA4ServiceCloud’10: Workshop’s 4th edition (co-located with the 6th European Conference on Modelling Foundations and Applications-ECMFA 2010), 2010. [15] J. Li, J. Chinneck, M. Woodside, M. Litoiu, and G. Iszlai, “Performance model driven qos guarantees and optimization in clouds,” in Software Engineering Challenges of Cloud Computing, 2009. CLOUD’09. ICSE Workshop on. IEEE, 2009, pp. 15–22. [16] G. Baryannis, P. Garefalakis, K. Kritikos, K. Magoutis, A. Papaioannou, D. Plexousakis, and C. Zeginis, “Lifecycle management of service-based applications on multi-clouds: a research roadmap,” in Proceedings of the 2013 international workshop on Multi-cloud applications and federated clouds. ACM, 2013, pp. 13–20. [17] T. Mens and P. V. Gorp, “A taxonomy of model transformation,” Electronic Notes in Theoretical Computer Science, vol. 152, no. 0, pp. 125 – 142, 2006, proceedings of the International Workshop on Graph and Model Transformation (GraMoT 2005), Graph and Model Transformation 2005. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1571066106001435 [18] F. Moscato, R. Aversa, and A. Amato, “Describing cloud use case in metamorp(h)osy,” in IEEE Proc. of CISIS 2012 conference, 2012, pp. 793–798. [19] F. Moscato, R. Aversa, B. D. Martino, T.-F. Fortis, and V. I. Munteanu, “An analysis of mosaic ontology for cloud resources annotation,” in IEEE Proc. of FedCSIS 2011 Conference, 2011, pp. 973–980. [20] F. Moscato, B. D. Martino, S. Venticinque, and A. Martone, “Overfa: a collaborative framework for the semantic annotation of documents and websites,” International Journal of Web and Grid Services, IJWGS, vol. 5, no. 1, pp. 30–45, 2009. [21] ——, “Overfa: a collaborative framework for the semantic annotation of documents and websites,” Int. J. Web Grid Serv., vol. 5, pp. 30–45, March 2009. [Online]. Available: http://portal.acm.org/citation.cfm?id=1516644.1516647 [22] F. Amato, V. Casola, A. Mazzeo, and S. Romano, “A semantic based methodology to classify and protect sensitive data in medical records,” in Information Assurance and Security (IAS), 2010 Sixth International Conference on. IEEE, 2010, pp. 240–246. [23] F. Amato, A. Mazzeo, V. Moscato, and A. Picariello, “A system for semantic retrieval and long-term preservation of multimedia documents in the e-government domain,” International Journal of Web and Grid Services, vol. 5, no. 4, pp. 323–338, 2009.
ˇ [24] R. Cervenka, I. Trenˇcansk`y, M. Calisti, and D. Greenwood, “Aml: Agent modeling language toward industry-grade agent-based modeling,” in Agent-Oriented Software Engineering V. Springer, 2005, pp. 31–46. [25] F. Moscato, S. Venticinque, R. Aversa, and B. Di Martino, “Formal modeling and verification of real-time multi-agent systems: The remm framework,” in Intelligent Distributed Computing, Systems and Applications, ser. Studies in Computational Intelligence, C. Badica, G. Mangioni, V. Carchiolo, and D. Burdescu, Eds. Springer Berlin / Heidelberg, 2008, vol. 162, pp. 187–196. [26] C. Hirel, R. Sahner, X. Zang, and K. Trivedi, “Reliability and performability modeling using sharpe 2000,” in Computer Performance Evaluation.Modelling Techniques and Tools, ser. Lecture Notes in Computer Science, B. Haverkort, H. Bohnenkamp, and C. Smith, Eds. Springer Berlin Heidelberg, 2000, vol. 1786, pp. 345–349. [27] S. Luke, C. Cioffi-Revilla, L. Panait, K. Sullivan, and G. C. Balan, “Mason: A multi-agent simulation environment,” Simulation, vol. 81, no. 7, pp. 517–527, 2005.
