The broker meta-model for describing resource brokers, offered services , resource providers, offered resources and scenarios

Figure 1

Figure 1 displays resource providers forming a federation where a resource broker is capable of exposing resources R to end-users in a uniform manner to create richer infrastructures. Resource providers must have an API that exposes resources and enables brokers to browse and manage them. The figure displays also that it’s possible to create a federation of federations for even richer environments. The end-user can create scenarios involving resources in three different ways: by directly going to a resource provider, by going to a resource broker of a federation or finally to a large resource broker of the upper federation.

FSToolkit adopted practices of Domain Specific Modeling (DSM), where the systematic use of textual or graphical Domain Specific Language (DSL) is involved. A DSL is defined as a specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain. For the language definition an abstract syntax (the meta-model), a concrete syntax and semantics are needed. All of these are captured in a solution workbench, which in this case is Eclipse, used both as a development but also as a deployment environment.

In this page, we present the meta-model for defining a resource broker, its services, providers and their resources and how Domain Specific Modeling (DSM) is used to define Federation Scenarios. We implemented a meta-model that describes resource brokers offering (representing) services later mapped to resource providers. The meta-model is also used to define a family of Domain Specific Languages (DSLs), used by resource brokers, resource providers and experimenters, that have the proposed meta-model as an abstract syntax. The meta-model is also capable to support a federation of federations. This means that the model and therefore the DSLs are capable to describe federation scenarios involving resources even from a pool of resource brokers.

The following DSLs are used by resource brokers or resource providers to describe themselves: i) the BrokerDSL is used to define a resource broker or a resource provider, ii) the Service Description Language(SDL) defines offered services of a broker to the customer, iii) the Resource Description Language (RDL) defines a provider’s offered resources implementing services. The end-user (an experimenter or customer) uses the Federation Scenario Description Language (FSDL). FSDL is a DSL to describe the needed services of an experiment over a federated infrastructure. Model-to-Model transformation is also used between resource brokers to import in the language heterogeneous resources by other resource brokers or resource providers expressed with other models. Model-to-Text transformations were used to generate wrapper code for exposing resources and for targeting different provisioning engines.

Levels view

A Federation Scenario describes customer needs for services over a federated infrastructure. To support this, we needed first to define a resource broker. Thus, we defined a meta-model the Broker meta-model (figure 2, level M2) that helps to describe resource broker models (in M1) and eventually instantiations of them in Federation Scenario definitions (M0). In the Broker meta-model the core entity Broker is defined. A Broker is a resource broker offering services and matching services and resources, maintains users, and in general support federation scenarios.

Figure 2

The meta-model

The concepts of Offered Services and Offered Resources in Broker meta-model are as follows:

  • An Offered Service is an abstract entity and it describes an offering along with its configuration attributes, e.g. Computing Resource with memory, disk space, etc.
  • An Offered Resource is an entity that implements an Offered Service. e.g. Resource Acme.Comp1234 is a resource of the provider Acme capable of implementing a service of Computing Resource (creating Virtual Machines). An Offered Resource is supposed to be managed by Create-Read-Update-Delete operations. So an Offered Resource is currently a really simple entity with a few attributes exposed to the end-user. The same is also true for an Offered Service.

The Broker meta-model, is defined in Ecore: a variant of OMG’s MOF that has been developed in the Eclipse Modeling Framework and is more or less aligned on OMG's Essential MOF (EMOF).

Figure 3

The Broker meta-model defines related entities and their relationships, what an Offered Service is, what an Offered Resource is, how an Offered Service is supported by a resource of the federation, taxonomies, service compositions, SLAs, users, etc. Part of the meta-model is illustrated in figure 3, where it displays that a Broker is an aggregation of Offered Services, Users and Requested Federation Scenarios. The Broker aggregates Requested Federation Scenarios where an SLA (not shown) is created for each one of them. Since the entity Broker describes actually a resource broker, it has an aggregation of providers offering resources. A Resource Provider is viewed as a user of the Broker. A Resource Provider has an aggregation of Sites and eventually a Site contains the Offered Resources.

Figure 4

A Broker matches Offered Services and Offered Resources. Having this, the Broker maintains some contracts the ResourceServiceContracts? (see Figure 4). A contract helps the broker to match a service to a resource. From figure 4, one can see that a ResourceServiceContract? is between an Offered Service and an Offered Resource. Some extra characteristics of the contract are described in the Availability of the Resource and potential Cost.

A Federation Scenario is an instance of the RequestedFederationScenario? entity. Figure 5 displays the relationships with the rest of the classes.

Figure 5

Download the meta-model

To download the meta-model go to . You can use git in eclipse to download it as a plugin project.

Last modified 11 years ago Last modified on Oct 22, 2012, 3:09:47 PM

Attachments (5)

Download all attachments as: .zip