System Architecture Design

More documents

Recommendations

Info

pSHIELDSystem Architecture DesignPU• secure service discovery• service composition• service orchestrationSecure service discovery allows any pSHIELD Middleware Adapter to discover in a secure manner theavailable SPD functionalities and services over heterogeneous environment, networks and technologiesthat are achievable by the pSHIELD Embedded System Device (pS-ESD) where it is running. Indeed thepSHIELD secure service discovery uses a variety of discovery protocols (such as SLP 1 , SSDP 2 , NDP 3 ,DNS 4 , SDP 5 , UDDI 6 ) to harvest over the interconnected Embedded System Devices (ESDs) all theavailable SPD services, functionalities, resources and information that can be composed to improve theSPD level of the whole system. In order to properly work, a discovery process must tackle also a secureand dependable service registration, service description and service filtering. The service registrationconsists in advertising in a secure and trusted manner the available SPD services. The advertisement ofeach service is represented by its formal description and it is known in literature as service description.The registered services are discovered whenever their description matches with the query associated tothe discovery process, the matching process is also known in literature as service filtering. On the light ofthe above an SPD services discovery framework is needed as a core SPD functionality of a pSHIELDMiddleware Adapter. Once the available SPD services have been discovered, they must be prepared tobe executed, assuring that the dependencies and all the services preconditions are validated. In order tomanage this phase, a service composition process is needed.Service composition is in charge to select those atomic SPD services that, once composed, provide acomplex and integrated SPD functionality that is essential to guarantee the required SPD level. Theservice composition is a pSHIELD Middleware Adapter functionality that cooperates with the pSHIELDOverlay in order to apply the configuration strategy decided by the Control Algorithms residing in thepSHIELD Security Agent. While the Overlay works on a technology independent fashion composing thebest configuration of aggregated SPD functionalities, the service composition takes into account moretechnology dependent SPD functionalities at Node, Network and Middleware layers. If the Overlaydecides that a specific SPD configuration of the SPD services must be executed, on the basis of theservices’ description, capabilities and requirements, the service composition process ensures that all thedependencies, configuration and pre-conditions associated to that service are validated in order to makeall the atomic SPD services to work properly once composed.When the SPD services have been discovered and a feasible service composition has been identified,those services must be deployed, executed and continuously monitored. This is part of the serviceorchestration pSHIELD Middleware Adapter functionality. While service composition works “off-line”triggered by an event or by the pSHIELD Overlay, service orchestration works “on-line” and iscontinuously operating in background to monitor the SPD status of the running services.1IETF Service Location Protocol V2 - http://www.ietf.org/rfc/rfc2608.txt2UPnP Simple Service Discovery Protocol - http://upnp.org/sdcps-and-certification/standards/3IETF Neighbour Discovery Protocol - http://tools.ietf.org/html/rfc48614IETF Domain Name Specification - http://www.ietf.org/rfc/rfc1035.txt5Bluetooth Service Discovery Protocol6OASIS Universal Description Discovery and Integration - http://www.uddi.org/pubs/uddi_v3.htmPUD2.3.2Issue 5 Page 44 of 122
pSHIELDSystem Architecture DesignPUSecure service discovery, service composition and service orchestration operate at pSHIELD MiddlewareLayer and have access to the information coming from the Middleware, Network and Node layers as wellas from the Overlay. These core SPD functionalities can take advantage from the information provided bythe running services to “sense” the context or the situation in which the system is operating. Such acapability allows introducing an additional pSHIELD Middleware Adapter functionality that is contextawareness. The context awareness is a pervasive functionality that is embedded in the discovery,composition and orchestration processes, thus it does not represent an individual core SPD functionalitybut an additional characteristic of the pSHIELD Middlware Adapter functionalities. In pSHIELD weintroduce the context awareness of the pSHIELD Middleware Adapter core SPD services with a semanticapproach, extending the service description model with context aware requirements 7 .3.4.3 Policy-based ManagementA typical Policy Based Management (PBM) architecture is defined by the IETF policy framework [21]. Thearchitecture constitutes several points and elements, i.e. Policy Management Tool (including the requiredtools and a policy repository), Policy Decision Point and a Policy Enforcement Point. The following figurepresents an illustration of the main points in a typical PBM.Figure 12 – Typical IETF PBM Architecture.7V. Suraci, S. Mignanti, “Context-aware Semantic Service Discovery”, 16th IST Mobile & Wireless Communications SummitBudapest, Hungary 1-7 July 2007. Proceedings. #273.PUD2.3.2Issue 5 Page 45 of 122
Page 1 and 2: Project no: 100204pSHIELDpilot embe
Page 3 and 4: Contents1 Executive Summary .......
Page 5 and 6: FiguresFigure 1 - A generic embedde
Page 7 and 8: Figure 45 - pSHIELD Security Agent
Page 9 and 10: MGFMIPSMLNeLNFMRFPNMPNMPSNoLNVMOLOS
Page 11 and 12: Issue 5Page xi
Page 13 and 14: pSHIELDSystem Architecture DesignPU
Page 19 and 20: pSHIELDSystem Architecture Design3.
Page 31 and 32: pSHIELDSystem Architecture Design
Page 39 and 40: pSHIELDSystem Architecture Design
Page 43: pSHIELDSystem Architecture DesignPU
Page 47 and 48: pSHIELDSystem Architecture Designen
Page 94 and 95:
pSHIELDSystem Architecture DesignPU
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
show all

System Architecture Design

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?