Reference Architecture. The main task of the BM is the selection of the most suitable set of gHNs to deploy a specified set of packages. The matching process, implemented by the BM-Algorithm component, is based on the matchmaking algorithm described in section 5.5. 1.1. The process returns an association between packages to be deployed and gHNs, named deployment schema, trying to minimize the number of gHN used. The deployment schema can then be used by the client (namely, the VREManager) to drive the deployment process. The matching process takes into account the current status of the infrastructure, i.e. the set of services already deployed on gHNs. The DIS-Connector component queries the gCube Information Service (IS) to obtain the current deployment status, as well as dependencies and requirements of packages to be deployed (contained in Service Profiles and stored in the IS). Broker and Matchmaker functionalities can be invoked by clients through the BM- Service. This WSRF-enabled web service, described in detail in Section 5.5.1.1, provides operations request a matching process and to notify the matchmaker of a failure in the deployment process. When a deployment process fails, the BM can be notified about the gHN originating the failure, and the client can ask for an alternative deployment schema excluding the notified gHN. The BM-API and BM-Connector components provide a local interface to the remote BM-Service. Particularly these components enable clients to perform asynchronous matchmaking requests. The asynchronous calling mechanism is particularly useful as the time needed to find a valid deployment schema may widely vary, depending on the status of the infrastructure (number of available gHN, number of services already deployed) and on the packages to be deployed. A deployment diagram of BM components is shown in Figure 16.
Appears in 2 contracts
Sources: D4science System High Level Design, D4science System High Level Design