NoMISHAP Architecture
 


 

The NoMISHAP adopts a two layer architecture.The top coordination and high availability layer aims at providing all support functions for the brokering and monitoring of services and CHA provisioning:

  • it keeps track of currently available Cloud service Instances on target PaaS providers by routing client requests towards them;
  • it handles request failures and retries ;
  • it realizes all needed coordination protocols to grant high availability of the support components.
The main middleware component at this layer is the Service Registry/Broker (SRB) that acts as LBC stub and plays the role of:
  • service registry that provides service discovery features to service clients, no matter the available CSIs (and cloud PaaS providers);
  • service broker to physically route requests from client applications to the specific CSI, via Service Adapters (SAs).
Moreover, this layer includes a pool of SRBs that are inherently distributed, loosely replicated components that coordinate with each other in a peer-to-peer fashion to grant CHA of the middleware support itself.

 
NoMISHAP Architecture
NoMISHAP Architecture
 

The bottom service/cloud abstraction and decoupling layer, instead, implements a standardized interface for each LBC that hides both service-specific and cloud-specific CSI implementation details.
The main middleware component at this level is the Service Adapter(SA) that depends from the PaaS provider with manifold purposes.

  • SA acts as LBC service interface/logic adaptor to mediate and glue any CSI-specific detail, by presenting a uniform interface to SRB.
  • SA realizes identity/access management functions by taking care of client identification and authorization, and thus freeing clients from the burden of authenticating themselves against each CSI.
  • SA enhances service lifecycle/health status management since cloud providers typically provide limited information support about current service status and availability.
 
10-set-10