Ensembles Level Modeling with Xxxxxx Sample Clauses

Ensembles Level Modeling with Xxxxxx. ‌ Modeling the behavior of the individual components and the ensembles which implement the cloud functionality is challenging due to the complexity and dynamics of the participating ensembles. In ASCENS, existing techniques such as component-based software engineering ([Szy02, RRMP08]) have thus been augmented with features that focus on the particular characteristics of ensembles. Among these are the fact that ensembles are dynamically formed on demand, realizing collective, goal- oriented behavior through communication between the individual participants; furthermore, multiple ensembles may run concurrently using the same basic resources, but dealing with different tasks on a higher level. To be able to model these issues on a first-class basis, the Helena approach [HK14] has been developed, which uses a UML-like notation for collaborations founded on a rigorous formal semantics. This work may be used in the modeling section of the EDLC. A particular property of ensembles is the fact that although the platform on which ensembles run may itself be plain component-based, each component can take part in different ensembles and in the course of doing so take up different, ensemble-specific roles [GSR96]. A service component may play different roles at the same time, both in one ensemble and in different, concurrently running ensembles; it may also dynamically change its role(s) in order to adapt to new situations. The Helena approach is centered on this notion of roles and the collaboration of roles in ensembles for pursuing the ensemble goal. In the present case study, there may be multiple such ensembles; one for each of the applications which are executed within the cloud. Each ensemble has the goal of deploying the application, finding an execution target node, executing, and finally monitoring the application execution. This is illustrated in Figure 4. Figure 4: Ensembles in the Helena approach The first or basic level (on the bottom of the figure) shows the pool of all SCPi nodes which are, in principle, able to provide resources to the cloud. In the figure, these are the four nodes labeled i1 to i4, which may be physical or virtual machines on which instances of the science cloud platform (SCPis) are running. Each of these may participate in ensembles for executing an application. As indicated in the figure, executing an application requires different responsibilities taken up by different roles in the ensemble. These are the deployer (node from which...