TAPAS Deliverables for March 04 (Trusted and QoS-Aware Provision of Application Services)

1. TAPASDeliverables for March 04(Trusted and QoS-Aware Provision of Application Services) Santosh Shrivastava Newcastle University

2. Structure of the talk • Deliverable list • TAPAS Architecture • Based on D5 extended report • How the deliverables meet the requirements of the Architecture

3. March 04 Deliverables • D3: Service composition and analysis (report) • UCL: done (Sept 03 was the deadline) • D8: Container for group communication • Really about QoS enabled group communication (Camb, Ncl) • Software deliverable (open source) • D9: Container for trusted coordination • Really about regulating interactions between organisations (Ncl) • Software deliverable (open source) • D10: Container for QoS monitoring • Really about QoS control within application servers plus SLA compliance monitoring (Bologna, Ncl) • Software deliverable (open source)

4. March 04 Deliverables (contd.) • D13: Second year evaluation and assessment report • Needs feedback from our IAB • Work towards auction system hosting needs to be reported • Adesso • D17: Updated dissemination and use plan • updated version of D16, produced in Sept 02 • Adesso • PPR2: Periodic progress report • All of us

5. TAPAS Architecture (D5 extended report) • ASP should be capable of hosting Virtual Enterprises (VEs) • A key problem in VE management is how enterprises can regulate access to their resources by other enterprises • Enterprises within a VE will therefore require their interactions with one another other to be strictly controlled and policed. • there will be a clear need among all parties to embark upon their business relationships underpinned by guarded trust management procedures.

6. TAPAS Architecture TAPAS Architecture: shaded entities make all the difference

7. TAPAS Architecture • The QoS management, monitoring and adaptation layer is intended to make the underlying application server QoS enabled. • Discussed in D7 • All cross-organisational interactions performed by applications are policed by the Inter-Organisation Interaction regulation subsystem • D5 describes how relevant aspects of contracts can be converted into electronic contracts and represented using state machines and role based access control (RBAC) mechanisms for run time monitoring and policing. • Application level QoS monitoring service, which must also measure various application level QoS parameters, calculate QoS levels and report any violations • QoS monitoring is occurring at two distinct levels: within an application server for controlling use of application server resources and at higher level for controlling application level QoS requirements.

8. Deliverables….. • QoS Enabled Application Server • two principal middleware services, named Configuration Service and ControllerService • QoS requirements of hosted applications as stated in SLAs will be specified using SLAng • SLAng specification will be used for initialising various QoS related configuration information required by the configuration service of the application server, through the deployment descriptors

9. Deliverables….. • D9: trusted coordination • Inter-Organisation Interaction regulation subsystem • Trust achieved through regulation • We assume that interacting entities cannot simply rely on the trust they have in one another. • To be of practical use, such trust relationships must be managed and observed • Because of this, interacting parties must resort to mechanisms that guarantee the rights and obligations that each interacting entity promises to honour. • In the worst case, violations of agreed interactions are detected and notified to all interested parties • an audit trail of all interactions will need to be maintained • Two level mechanism: • Contract management (rights and obligations) using FSMs + RBAC • Infrastructure support for non-repudiable interactions

10. Deliverables….. • D10: QoS monitoring • QoS Monitoring and Violation Detection subsystem • Several of the rights and obligations in SLAs in a contract refer to the quality of service (e.g., service availability, performance guarantees). • interacting entities cannot simply rely on the trust they have in one another and assume that QoS levels are being honoured. • a service provider must be able to demonstrate that the offered service meets the QoS levels promised to service users • hosted applications and services need to be instrumented with appropriate sensors for measuring QoS parameters • The parties involved must also agree on the QoS evaluation techniques (calculation procedures to be used)

11. Deliverables….. • These details need to be encoded in some way in the SLAng specification language. • SLAng specification can be used for configuring the monitoring and violation detection service. • Monitoring and Violation Detection subsystem could be a third party service

12. Deliverables….. • Discussion on D9, D10 and other deliverables and design and implementation of QOS enabled app server to follow this talk