BM-Service. This stateful web service is based on the Xxxxxxxxx resource pattern. The BrokerResource resource, that does not publish any Resource Property, orchestrates the matching request received through the matchOperation() operation exposed by the service. When a request is received the BM-Service is in charge to contact the gCube IS, through the DIS-Connector, and enrich the request with: a) the current status of GHN and, b) the set of dependencies and requirements extracted from Service Profiles. Then the request is passed to the BM-Algorithm to be processed. When a response is received from the BM-Algorithm the BM-Service is in charge to format it and send back to the client. The BrokerResource is not persistent, and its status is never stored on the local file system. As a consequence of a deployment operation, the status of the infrastructure will be modified, and the deployment scheme resulting from a subsequent matching request could be different. To avoid race conditions among concurrent matching processes the BM-Service has a sequential matching behaviour preventing two matching requests to run in parallel. When a deployment process originated from a deployment scheme has been completed, the BM-service must be notified invoking the notifyDeployment() operation to start the processing of pending requests, if any. The status of the BM- Service can be queried through the getTerminated() operation, also exposed by the service interface. From the security point of view the BM-Service can be invoked using the GSI Secure Conversation mechanism, and runs with the identity of the caller (credentials of the caller are delegated to the BM-service). This allows the BM-Service to impersonate the caller when querying the IS, thus obtaining just the set of GHN where the caller is authorized to deploy.
