B2 Content List

B2 Content List......................................................................................................................... 1

B3 Objectives............................................................................................................................ 2

B4 Contribution to programme and key action objectives....................................................... 4

B5 Innovation............................................................................................................................. 5

B5.1 SLA specification, Service Composition and Analysis Techniques.............................. 5

B5.2 Trusted and QoS-aware Services for Application Hosting........................................... 6

B5.3 Assessment.................................................................................................................... 7

B6 Project Workplan................................................................................................................. 8

B6.1 Introduction and overall methodology.......................................................................... 8

B6.1.1 Application Service Requirements and Specification (WP1)................................. 8

B6.1.2 Design of QoS-aware Infrastructure for Application Hosting (WP2)................... 11

B6.1.3 Implementation of QoS-aware Core Services (WP3)........................................... 12

B6.1.4 Case Studies and Evaluation (WP4)..................................................................... 14

B6.1.5 Project Management and Coordination (WP5).................................................... 16

B6.2 Project Plan.................................................................................................................. 17

B6.3 Graphical presentation of the project’s components.................................................. 17

B6.4 Detailed project description........................................................................................ 17

B6.4.1 Resources............................................................................................................. 17

B6.4.2 Workpackage List................................................................................................. 18

B6.4.3 Deliverable list...................................................................................................... 19

B6.4.4 Workpackage descriptions................................................................................... 19

 


B3 Objectives

It is well known that organisations are increasingly focusing on their core businesses and streamlining their operations by ‘outsourcing’ non-core businesses to external organisations. In particular, many organisations find it cost effective to outsource their IT applications to Application Service Providers (ASPs). An ASP typically uses middleware and component technologies for deploying, hosting and managing applications of an organization from a centrally managed facility. However, as organisations become global and distributed, such centrally managed hosting solutions will need to be replaced by multi-site, distributed hosting solutions. As we argue below, many research problems in enterprise distributed computing will need to be solved before such hosting solutions can be realised.

The TAPAS partners believe that an ASP will increasingly be called upon to host distributed applications that make use of a wide variety of Internet services provided by different organisations. This naturally leads to the ASP acting as an intermediary for interactions for information sharing that cross organisational boundaries. However, despite the requirement to share information and services, autonomy and privacy requirements of organisations must not be compromised. Organisation will therefore require their interactions with other organisations to be strictly controlled and policed. This creates two major challenges. Firstly, contractual relationships between multiple organisations for information access and sharing will need to be governed by service level agreements (SLAs), which will need to be defined and agreed between the organisations and then enforced and monitored by the ASP. Secondly, the ASP will have to establish appropriate trust relationships with the organisations and implement corresponding security policies before organisations will permit the ASP to act as an intermediary for inter-organisational service invocations. Unfortunately, middleware services for inter-organisational interactions as outlined above do not yet exist; indeed, development of such services is very much a research problem. Thus ASPs currently lack tools and techniques for offering hosting facilities for advanced Internet based applications. We use a simple example to focus on application hosting issues and limitations of current technologies.

Our example considers the hosting of a Marketplace application that matches buyers and vendors. We might imagine that the Marketplace provides services through a component that manages requests for proposals (RFP). This component might use a service from a credit rating agency in order to obtain a credit rating of the buyer that is then forwarded alongside the RFP to vendors. The credit rating agency itself may implement its services using data obtained from account history services provided by retail banks. The Marketplace may need the services of one or more trusted third parties (TTPs) to meet the security requirements of buyers and vendors. We assume that the ASP hosting the Marketplace is obtaining its communication and storage resources from an ISP (Internet Service Provider) and an SSP (Storage Service Provider) respectively. The figure below shows the various organisations and the corresponding SLAs involved. The company providing the Marketplace has set up SLAs with buyers and vendors  etc. and to meet the obligations implied by these SLAs, it will have a comprehensive SLA with the ASP specifying overall processing, storage and communication requirements, as well as availability responsiveness  and security requirements. 

 

In effect, to host the Marketplace, the ASP will require a distributed execution environment with a number of core services capable of meeting specific non-functional requirements of fault tolerance, availability, security, and timeliness; we will refer to these as QoS enabled services (QoS: Quality of Service). State-of-the-art application services are developed using component-based technologies, such as those provided by the Java 2 Enterprise Edition (J2EE), Microsoft’s .NET or the Object Management Group’s CORBA Component Model. These technologies support the cost effective creation of services by composing and integrating existing components. To date components can be obtained from component vendors through component catalogues and be deployed in-house. In the future, as our example illustrates, components that implement services will be hosted by vendors or dedicated service providers in application servers and will be invoked from components from other organisations across public networks. Current component technologies support the specification of functional component interfaces. They, however, do not adequately support the definition of the non-functional characteristics of component execution.

With the above observations in mind, the overall objective of the TAPAS project is to develop novel methods, tools, algorithms and protocols that support the construction and provisioning of Internet application services. We will achieve the overall objective by developing QoS enabled middleware services that  will enable components to be deployed and interact across organisational boundaries. We have divided the overall objective into three broad categories which we describe below together with our approach to achieving them.

Objectives related to SLA specification, Service Composition and Analysis Techniques: The TAPAS project will develop notations for expressing SLAs to enable specification of QoS, such as the availability, performance and scalability characteristics of components, as well as trust relationships. Model checking capabilities will be developed to support reasoning about QoS characteristics of components and their composition. This will support the ASP in assessing the qualities of service perceived by end-users prior to developing and deploying an application service. In our example, the composition of complex application services from more elementary services provided by different organizations will thus be governed by multiple SLAs. The project intends to adopt UML as the language for the description, modelling and analysis and extend it with formally defined stereotypes and properties. This approach is motivated by the large number of users of the UML in industry, who will find it easier to adopt a small UML extension than an entirely new specification language.

Objectives related to Trusted and QoS-aware Services for Application Hosting: Component oriented middleware promotes the use of containers to host component instances. Containers are responsible for using the underlying middleware services for communication, persistence, transactions, security and so forth. TAPAS will develop support architectures that provide QoS negotiation, establishment, and adaptation facilities to such services; these will be used by containers to make them QoS enabled. Particular attention will be placed on the development of QoS enabled multi-party communication (e.g., for supporting publish/subscribe communication, dynamic load balancing between replicated containers) that cross organisational boundaries. To this end, SLA trust specifications will be used for deriving service invocation primitives enriched with authentication, non-repudiation mechanisms, with or without the involvement of  TTPs.

Objectives related to assessment: The results from the TAPAS projects, in the form of methods, tools and techniques for design and development of component oriented middleware for provisioning of Internet application services will be evaluated by comparing the results with current state-of-the-practice (e.g. an off-the-shelf CORBA or J2EE application server). The TAPAS consortium includes an ASP, who will provide requirements for QoS enabled application service provision, and case studies. Partners will build demonstrator applications, such as hosting of an auction service to demonstrate the effectiveness of TAPAS results.

Deliverables and exploitation: The deliverables of the project by means of which we provide measurable evidences of the extent to which we succeed in meeting the above stated very challenging objectives will include prototype implementations using open source application servers and demonstrators as well as technical reports and papers. The inclusion of an ASP in the consortium will speed up the migration of TAPAS results and technologies to industry. In addition, the project will form an Industry Advisory Board, whose membership will represent a cross-section of technology providers and end-users; the Board will help us in revising, where necessary, the objectives of the project. Thus, even though the TAPAS project has been formed to address the needs of ASPs, the results of the project will be of interest to much wider scientific and industrial communities.

The TAPAS consortium brings together academic researchers from software engineering, middleware and Internet communities to work with an ASP. Success in this endeavour will substantially ease the development of domain specific application services; for example, services for computational grid (enabling  scientists to move large amounts of data globally and perform long lasting parallel scientific computations), electronic markets (enabling art dealers to conduct real-time auctions on a world-wide scale), collaborative applications (enabling globally scalable multi-person games) and a variety of other Web Services.


B4 Contribution to programme and key action objectives

The TAPAS project is specifically addressing most of the main objectives of V.1.12 CPA 12, the Cross-Programme Action on Application Services provision: to develop and validate open architectures, technologies and tools to allow for the provision of a variety of applications as networked services, with focus on development of middleware services and development of service management frameworks.

Organisations, particularly, small and medium scale enterprises (SMEs) are increasingly finding it difficult to develop, maintain and manage their IT applications largely due to difficulties in retaining and attracting trained IT staff. ASPs hold the promise of providing an attractive solution by making available application hosting facilities on remotely managed servers. However, to work effectively, ASPs must guarantee security, provide resilience and SLAs over commonly available infrastructures. Furthermore, ASPs need to ensure that hosted applications are capable of accessing a wide variety of services irrespective of the platform or the organisation through which they are provided. As we have argued, ASP will have to establish appropriate trust relationships with the organisations and implement corresponding security policies to enable inter-organisational service usage.

The TAPAS project will develop QoS enabled middleware services capable of meeting SLAs agreed between application services, and will enhance component based middleware technologies such that components can be deployed and interact across organisational boundaries. Middleware services and architectures will be developed using open source application servers  and widely used component technologies such as CORBA and Java.

Broadly speaking, the TAPAS project is addressing two priority areas identified in section 2.3 of the 2001 Work Programme, namely:

·         To develop middleware, distributed systems, multi-layered architectures and agents-based systems to enable interoperability, inter-working, openness and integration of application and services across platforms.

·         To emphasise trust and security, including information security, privacy, suppliers and users rights and dependability of systems and infrastructures, as a general requirement for all technologies, applications and services.

The above priority areas map onto the following main action lines that are related to TAPAS:

·         II.2.2 Smart Organisations, with focus on “development and validation of novel architectures, software platforms and pre-standards to support interoperability, seamless integration and knowledge sharing between heterogeneous enterprise applications and services”.

·         II.4.1 Trust in information infrastructures, with focus on “development, integration and validation of trust and security technologies in information infrastructures”

·         IV.2.1 Real time distributed systems, with the objectives “to develop and assess models, technologies and tools for sharing and interactive use in real time of applications and resources in geographically dispersed locations…”, with focus on “development environments to support real time, distributed applications”.

·         IV.3.1 Software architectures, with focus on “models and notations for describing systems architectures and being able to reason about them. The main concern is to guarantee required quality attributes (for instance on scalability, performance and reliability) of systems.”

·         IV.6.2 Interfaces and buffers for seamless end to end services, with focus on “network programming interfaces”.

 


B5 Innovation

We restate the two observations that underpin the TAPAS project objectives for application service provisioning, namely: (i) contractual relationships between multiple organisations for information access and sharing will need to be governed by SLAs, which will need to be defined and agreed between the organisations and then enforced and monitored by the ASP; and (ii) the ASP will have to establish appropriate trust relationships with the organisations and implement corresponding security policies before organisations will permit the ASP to act as an intermediary for inter-organisational service invocations. The TAPAS aim of developing QoS enabled middleware services capable of meeting SLAs and supporting components that can be deployed and interact across organisational boundaries poses significant technical challenges. We expect that the project will introduce several research innovations in the areas of architecture, system design and validation. We begin by highlighting the innovative features of the project:

B5.1 SLA specification, Service Composition and Analysis Techniques

Ideally, an ASP should have at his disposal a toolkit that enables him to describe the configuration of the application to be hosted in terms of building block services, and then use the toolkit to confirm that the various SLA commitments can be honoured for a variety of physical configurations and load conditions. This should enable the ASP to make an informed choice between various design options before commencing the actual deployment of the application. Current system development practices fail to live up to this ideal; rather, systems are frequently built without any precise idea about how the system will actually perform. The reason being that there is no rigorous methodology available to system designers that allows them to express their design in sufficient detail, and predict what the system behaviour will be with respect to, say, timeliness under a given load. The TAPAS project aims to overcome this deficiency by defining a language for SLAs. Alongside functional components interfaces, these SLAs specify the non-functional qualities of service, such as the availability, performance and scalability characteristics of components. The project intends to adopt UML [1] as the language for the description, modelling and analysis and extend it with formally defined stereotypes and properties. TAPAS will define the semantics of SLAs using stochastic process algebras [2-6]. Model checking capabilities developed for stochastic process algebras will then support reasoning about the performance and scalability characteristics of components and their composition. This will support the application service provider in assessing the qualities of service perceived by end-users prior to developing and deploying an application service. currently SLAs are used mainly within the rather narrow confines of network service performance, TAPAS will extend SLAs to application level services.

B5.2 Trusted and QoS-aware Services for Application Hosting

QoS-aware services: SLAs are only useful if their compliance is enforced and monitored. To achieve this aim, TAPAS will use SLAs not only as an inter-organizational contractual feature but also to govern component execution that adheres to specific QoS requirements as implied by the SLA (commonly referred to as QoS policy of the application). In order to provide QoS-aware execution of components, application servers themselves need to rely on a number of basic middleware services. The TAPAS project will aim to define the distributed algorithms (QoS signalling protocols) and implement the middleware services that are necessary for QoS enabled deployment and execution of components. To achieve this aim, TAPAS will extend open source application servers (such as Jboss [7] or Jonas [8]) to enforce and monitor adherence to SLAs.

 So far, issues of QoS have been addressed principally in the design of communication protocols. In this context, the principal design concern has been that of providing mechanisms that allow one to master and control quantitative communication parameters, such as network throughput, delay, delay jitter, and packet loss. These parameters indeed affect the quality of the service perceived at the application level. However, it is at this very level that further QoS application requirements emerge; these may include performance oriented requirements (e.g. timeliness of execution and relative processing speed requirements), reliability oriented requirements (e.g. high availability and relative failure recovery requirements), and security oriented requirements (e.g. authentication, privacy). There is thus a need for research on QoS enabled middleware services that takes a broader view of QoS than has been done so far. TAPAS will develop techniques for translating the QoS policy of an application into low level resource requirements as required by QoS signalling protocols. This is a relatively new area of research, particularly for multi-party applications (see next).

Network level QoS  for multi-party applications: The Internet community has made two efforts to develop standards for Internet Protocol (IP) with QoS capabilities: the integrated services architecture (IntServ) and the differentiated services architecture (DiffServ). There is much ongoing debate concerning strengths and weaknesses of these two architectures which we will not discuss here, but both expose the need for sophisticated mechanisms for accessing network resources [9,10]. In addition, because of the large impact that multicast can have on a network, the design of multicast management middleware (for services such as creation and joining of multicast groups, multicast address management, and providing various forms of reliability guarantees) is quite complicated and design issues not properly understood. Distributed applications with multiple senders pose several additional problems for Network QoS. Traffic engineering techniques currently used by network service providers for route balancing and prioritising traffic need to be extended to the situation involving multiple senders; this will require studying traffic patterns from these applications (looking for correlation in the traffic from different sources that make up an application). An important question for the network QoS API is ‘how to encode efficiently a multi-party traffic specification’; clearly, specifying the full matrix of source models is not going to be viable, but the alternatives are not obvious. The other side of this coin is that a multi-party application can have a partial QoS contract failure. This needs to be signalled efficiently to the relevant parties in the application by the network; multicasting techniques for such signalling needs investigation.

Trusted coordination: To enable inter-organisation interactions, SLAs on service usage, defining what is to be shared, who is allowed to share, costs etc will need formalising. The organisations involved might not trust each other, so an important part of our research will be concerned with developing infrastructure support for interactions between two or more mutually distrusting organisations. This is a relatively new area of research [10-14]. The relationship between parties may be asymmetric (customer-supplier) or symmetric (peer-to-peer). Parties may be strangers to each other or there may be a pre-existing basis for trust. Trust between parties may develop as a  result of the interaction. Trust relationships may be symmetric - mutually trusting or distrusting - or asymmetric, when trust (or distrust) is not reciprocated. Parties engaged in an interaction require an infrastructure that both facilitates the interaction (for example, to share and coordinate application state) and provides guarantees with respect to protection of their individual and collective interests, given the trust relationships. So, if neither p or q trust each other then interaction between them will need to be coordinated via one or more mutually trusted third parties. For trust management, TAPAS will develop non-repudiation and authentication services as well as robust fair exchange protocols [15-19]. We will also need to develop notations for specifying trust relationships, so that from that specification, ‘right’ kinds of infrastructure components can be derived.

B5.3 Assessment

The TAPAS project will evaluate the methods, application servers and network protocols that it will develop by comparing it to current state-of-the-practice (e.g. an off-the-shelf CORBA or J2EE application server). Partners will develop demonstrator applications, including a particularly demanding multiparty application service, hosting of real time auctions, using the facilities of the ASP partner. The project will port the components of these applications to the TAPAS platform and compare their execution characteristics to those developed with off-the-shelf products.


B6 Project Workplan

B6.1 Introduction and overall methodology

The work of TAPAS will be structured into four technical workpackages according to the three classes of objectives introduced in Section B.3:

·         WP1 (Application Service Requirements and Specification) will meet the objectives related to SLA specification, Service Composition and Analysis Techniques;

·         WP2 (Design of QoS-aware Infrastructure for Application Hosting) and WP3 (Implementation of QoS-aware Core Services) together will meet the objectives related to Trusted and QoS-aware Services for Application Hosting; and

·         WP4 (Case Studies and Evaluation) will meet the objectives related to assessment.

A fifth work package (described in Part C) will deal specifically with project management, coordination, dissemination and exploitation.

Basically, within WP1 we will work towards acquiring an understanding of the requirements and then develop SLA specification and its QoS analysis tools and techniques; WP2 will be devoted to the development of trusted and QoS-aware middleware architecture based on the requirements generated from WP1. WP3 will implement the architecture developed in WP2, and WP4 will perform assessment of the architecture and its implementation through demonstrator application building exercises. Each technical workpackage has a workpackage leader (lead contractor) responsible for overall direction and production of the deliverables. Furthermore, each workpackage has been divided into a number of related tasks,  with a partner with specialist expertise acting as the task leader, We will collaborate with related IST projects on topics of mutual interests; some of these projects include MAFTIA (fair exchange protocols, dependable trusted third parties), DSOS (system integration), CORTEX (realtime distributed systems).

An innovative aspect of this project is its emphasis on hosting of important class of large scale networked multi-party applications that are characterised by a group of entities requiring many-to-many interactions; examples include collaborative applications (e.g., multimedia conferencing, multi-person interactive games), electronic share dealing and auctions, and ‘information supply chain’ applications typically based on publish-subscribe paradigm. Currently, strict separation exists between the middleware that executes application services and the network, so providing services that go beyond ‘the best effort’ is difficult. The next generation Internet is expected to offer services to users to enable them to request and reserve network resources that their applications require. However, application developers will have to deal with the complexities of interacting with communication services for QoS allocation. It is not entirely clear how this interaction should take place, and research work is required on specification and enforcement of QoS at the network level. TAPAS will examine ways of ‘opening the network cloud’ and develop network QoS API for multi-party traffic control. For this reason, TAPAS workpackages contain specific tasks that relate to network level QOS issues.

B6.1.1 Application Service Requirements and Specification (WP1)

This workpackage, led by partner CR4, has been divided into four tasks. The first two tasks study, respectively application hosting requirements and networking requirements for many-to-many communications. A common deliverable report (D1) will document the results from the study. These results will feed into WP2 and WP3. The remaining two tasks concern SLA specification and analysis: alongside functional components interfaces, these SLAs specify the non-functional qualities of service, such as the availability, performance and scalability characteristics of components; analysis tools will be developed for reasoning about the performance and scalability characteristics of components and their composition. Deliverable report D2 will document the SLA specification method, report D3 will describe service composition and analysis method developed within the project and D4 will be the corresponding toolkit. The toolkit can be used to confirm that the various SLA commitments can be honoured for a variety of physical configurations and load conditions before commencing the actual deployment of the application. The results from D1-D4 will be used for the development of applications in WP4.

1.1 Application Hosting Requirements

Industrial partner CR2 will lead this task. The basis for defining requirements will be the analysis of the needs of the different parties in application hosting, and limitations of current application hosting from the views of the different parties. Such limitations typically arise from core problems of the ASP approach such as the risk for a client to loose control over an application [1]. In order to keep the requirements discussion close to industrial needs we will develop scenarios for QoS aware applications. Such applications shall not only overcome existing problems, but will provide new features, which might in the end lead to new unique selling propositions of QoS-aware ASP and thereby to an increasing ASP market.

Electronic marketplaces introduce a huge number of different aspects regarding QoS. While customers usually wish to have control on their private data, the providers are interested in secure transactions together with data protection, as competitors should not be able see offers. Furthermore the company running the marketplace as a business might be interested in integrating many different providers, secure transactions and as well in anonymity of customer and provider during the ordering process in order not to be bypassed. In a QoS aware application scenario such a company could even supervise the ASPs fulfilment of the SLAs by technical means. However, the ASP will be interested in using services like storage area networks from other service providers, to monitor the behaviour of the applications etc. A condensed scenario containing the marketplace’s QoS issues are online auctions, because the same participants as in the general marketplace scenario are involved and even more requirements like delivery time constraints for offers and bids will come up. Especially on a B2B background a QoS-aware application for auctions may even become a part of a real client’s marketplace, if it proves to be valuable.

SLAs define probably in most cases a relationship between a service client and a service provider. However, some clients like insurance companies or small financial institutes may not be not able to supervise the fulfilment of the SLAs due to lack of technical knowledge and staff. This can lead to severe acceptance problems, especially in the area of trust delegation and management. An insurance company could for instance state in a SLA that data has to be stored encrypted in a storage area network or data centre. Without provider-independent means to supervise this feature the company would most likely not choose the ASP solution due to an obvious and understandable lack of trust. In order to solve problems of trust management and fulfilment of SLAs the discussion of the scenarios might identify the need for additional participants, who will mediate between service user and provider, hence having a kind of referee or notary role. While the main goals of the TAPAS project aim on technology-related improvements the introduction of a new role into the ASP world has to be investigated carefully, because the applicability of the scenario could be based on a role, which must be brought to the markets.

1.2 QoS Networking Requirements

Partner CR5, a member of the Internet Architecture Board and with expertise on reliable multicast protocols for the Internet will lead this task. This task will study network QoS requirements for supporting multi-party applications that are characterised by a group of entities requiring many-to-many interactions. The ‘best effort’ service model of the Internet makes no guarantee about the QoS. The Internet community has made two efforts to develop standards for Internet Protocol (IP) with QoS capabilities: the integrated services architecture (IntServ) and the differentiated services architecture (DiffServ). In the absence of router implementations as required by IntServ, the community has moved on to DiffServ, where there is only a per-class scheduling problem. However, in this arena, people have struggled, even with complex "edge" traffic conditioning, to find a scheduler and allocation and service specification that can achieve a delay bound.

The network provider usually carries out long term provisioning of their network (Sprint, Worldcom and AT&T claim they upgrade their Internet capacity by 100% every 6-9 months). This is based on measurement of service use and service violations. Due to the rapid evolution of applications in the Internet, short term provisioning is also carried out - this is known as Traffic Engineering, and often takes the form of re-balancing routes, and of re-prioritising different less important applications (e.g. downgrading mp3 music download traffic for example).

Multi-party applications (trading, games, online debating systems), with QoS requirements represent another stage in the evolution of Internet traffic patterns, in that we would expect a high degree of correlation in the traffic from different sources that make up the applications. To this end, the resource allocation that is normally made on the timescales of traffic engineering now has to be carried out on the timescales of application sessions. Of course it is possible that these applications will be long-lived (although evidence from game data is against this).

 This part of the research will study the traffic patterns from these applications, so that the information could be applied for developing algorithms and signalling API for traffic engineering that can operate at the appropriate time scales; this will be addressed in task 3.2

1.3 Specification of Service Level Agreement

Partner CR4 with expertise in system specification, analysis and modelling will lead this task. Rather than defining yet another modelling language for application services, the TAPAS partners intend to adopt the UML as the baseline for the description, modelling and analysis of application services and extend the UML with formally defined stereotypes and properties that support the modelling of distributed interaction primitives and QoS characteristics. This approach is motivated by the large number of users of the UML in industry, who will find it easier to adopt a small UML extension than an entirely new modelling approach. Moreover, there are various very good UML tools available as open source products and we plan to use the Argo/UML tool as a baseline for the tool development of TAPAS.

The different diagrams provided by the UML are sufficient to model the functionality of application services, but the lack of a formal UML semantics inhibits reasoning about qualitative properties of the design of distributed application services, such as absence of livelocks, deadlocks or safety properties. Moreover, the UML does not support the modelling of QoS characteristics, such as the performance, scalability and availability of distributed application services. In [22], we have identified that there is only a limited set of interaction and threading primitives available for distributed objects and we have expressed them as stereotypes of UML models. In particular, we have defined synchronization stereotypes to be used in state diagrams for synchronous, oneway, deferred synchronous and asynchronous communication that is available in distributed object middleware (e.g. CORBA, COM and Java/RMI) and class diagram stereotypes for the different threading policies supported by middleware object adapters (such as CORBA’s POA). We propose to use the same idea to the component-based middleware standard that TAPAS will adopt and define suitable stereotypes and properties.

1.4 Service Description, Composition and Analysis Techniques

Partner CR4 will lead this task. The semantics and properties of the stereotypes will be defined by mapping stereotyped UML diagrams to process algebra, such as CSP [23], CCS [24] and FSP [25]. The choice of a process algebra is motivated by its algebraic properties, most notably composition, its precise operational semantics based on labelled transition systems and the availability of powerful model checkers, such as the FDR tool for CSP [26], and the LTSA for FSP [25]. These model checkers apply compositional reachability analysis in order to analyse qualitative properties of application service provision, such as adherence to safety properties and absence of deadlocks and livelocks. In [27], we have used this technique successfully to model check labelled transition systems that were derived from stereotyped UML class and state diagrams for the design of distributed objects against absence of deadlocks. In TAPAS we plan to extend this technique of generating an equivalent process algebra specification for a UML design to model and verify general liveness and safety properties of the design of distributed application service components.

In addition to the analysis of the qualitative properties discussed thus far, we would also like to be able to reason about the quantitative properties of application service design, such as performance, scalability and dependability prior to building a new or modifying an existing service. For these quantitative properties we will take a similar approach of expressing them as annotations to UML diagrams and then derive a formal representation from these annotated design diagrams that is amenable to quantitative analysis. We propose to use Markovian stochastic process algebra, such as MPA [2], PEPA [4] or TIPP [5]. The choice of stochastic process algebra is motivated by the fact that they are direct extensions of the approach that we used for qualitative properties and possess the same algebraic property of compositionality, they can formally express the timed and stochastic behaviour that we would like to model and finally there are analysis tools available, such as the PEPA Workbench [3] and the TIPP tool [6] that use continuous timed Markov chains as the underlying formalism for reasoning about utilization, response time, scalability and dependability.

 

B6.1.2 Design of QoS-aware Infrastructure for Application Hosting (WP2)

TAPAS architecture will use SLAs not only as an inter-organizational contractual feature but also to govern component execution. To this end, QoS negotiation, establishment, and adaptation facilities will be added to the TAPAS middleware and these will be used by component containers to make them QoS aware. This workpackage, led by partner CO1 has four tasks: middleware architecture, trust management, network control architecture and component execution environment. These will be initiated after the first six months of the project, by which time results from WP1 (requirements deliverable report, D1) will be available to guide us. These tasks will last for six months each; the result will be the deliverable report D5, available by the end of the first year of the project, that will describe the interim TAPAS architecture for application hosting. Work on D5 will influence the implementation work of WP3 that will run concurrent to WP2. We expect that case studies and evaluation work (WP4) will provide us with valuable feedback on the effectiveness of the TAPAS architecture of D5, suggesting improvements and modifications. For this reason, the middleware architecture task will be resumed during the last six months of the project, and a revised architecture report will be produced (deliverable report D6). 

2.1 Middleware Architecture

Partner CO1, with expertise on dependable middleware services and architectures will lead this task. As we stated in section B3, component oriented technologies (such as CORBA components, EJBs) support the cost effective creation of services by composing and integrating existing components [28, 29]. Current component technologies support the specification of functional component interfaces. They, however, do not adequately support the definition of the non-functional characteristics -QoS- of component execution [30, 31]. How to incorporate performance oriented requirements (e.g. timeliness of execution and relative processing speed requirements), reliability oriented requirements (e.g. high availability and relative failure recovery requirements), and security oriented requirements (e.g. authentication, privacy) in the middleware?

Component oriented middleware promotes the use of containers to host component instances [32-34]. A container is a runtime environment for component instances and their homes. Several containers could be hosted by a same component server. A container is more than a simple execution environment. Containers hide the complexity of most of the system services like transaction, security, persistence, and notification services. Thus, containers take part in the management of non-functional aspects of a component. To this end, QoS negotiation, establishment, and adaptation facilities will be added to the underlying services (see WP3) and these will be used by component containers to make them QoS aware. That is to say, a container will have a QoS contract with the underlying service, that the component execution environment will (try to) honour. Specification of these contracts will be derived from the application level SLAs using the techniques developed in WP1. This task will examine overall architectural issues in the development of such containers and their execution environment. Given the emphasis of the project, particular attention will be placed on issues of trust and how it impacts inter-organisation interactions and multi-party communications.

2.2 Trust Management

[wje1]

 Partner CO1 will lead this task. We are assuming that the organisations involved might not trust each other, so an important part of our work will be concerned with developing infrastructure support for interactions between two or more mutually distrusting organisations. A fundamental approach is to use mutually trusted third party (TTP) to create a context in which multi-party interactions can be carried out. An interaction is assumed to involve the electronic exchange of items of value (information, goods, services). Governed by agreed rules, these exchanges involve coordinated changes to the state of shared data and the imposition of related obligations (and restraints)on the parties to the exchange. Few assumptions should be made about the nature of the interaction or about the relationship between parties. For example:

·         an interaction may be short- or long-lived: from fulfilment of an order to provision of a complex, evolving service;

·         interactions may be composed from sub-interactions: service delivery may involve the sub-contracting of obligations to other parties whilst ensuring compliance with the obligations imposed by the "parent" interaction;

·         interactions may be dynamic: the rules governing the interaction may be subject to re-negotiation and the parties to the interaction may change;

·         the relationship between parties may be asymmetric (customer-supplier) or symmetric (peer-to-peer)

·         parties may be strangers to each other or there may be a pre-existing basis for trust. Trust between parties may develop as a result of the interaction. Trust relationships may be symmetric - mutually trusting or distrusting - or asymmetric, when trust (or distrust) is not reciprocated.

·         an interaction may be subject to both global constraints and to local constraints with a requirement to resolve conflicts between the two.

Parties engaged in an interaction require an infrastructure that both facilitates the interaction (for example, to share and coordinate application state) and provides guarantees with respect to protection of their individual and collective interests. The infrastructure should support interaction in a hostile environment: interaction, between strangers over open networks. These are very demanding requirements and the subject of trust management is a relatively new area of research [10-14, 36]. In this task we will investigate various design options, such as those discussed in [15-19,35] for developing the basic building block of non-repudiateable update of and access to shared objects; we have done some preliminary work in this area [16].

2.3 Network Control Architecture

 Partner CR5 will lead this task. From an application’s perspective, the network is just another type of resource that needs to be managed. The goal here is to work bottom up from the network layer looking at fault tolerance and performance management mechanisms, up to the level of service interface and behavioural description that matches the work done in the other work packages; the intention is to make the network services for multi-party communication all available at the object level as first class objects in the system, so that overall distributed services  can be built out of components as needed, and with no special different treatment of networking entities from other forms of distributed object engineering.

This task will build on the work of CR5 [37, 38] and will look at existing control and signalling protocols including recent work on RSVP/IntServ/Cops subscribe and broker protocols for DiffServ and others in the IETF siglite work. As stated earlier, results from task 1.3 will be applied for developing algorithms and signalling API for traffic engineering, collectively referred to here as the network control architecture. The architecture will include feedback mechanisms for notifying applications when performance is below the SLA level, or when an application violates the SLA.

2.4 Component Execution Environment

Partner CR3 with expertise on QoS middleware will lead this task. As indicated earlier, component containers will have QoS contracts with the underlying services, that the component execution environment will (try to) honour. Our aim is to ensure that a developer only has to write the functional code in order to complete the component implementation, all the non-functional properties will be derived from the SLAs and used to configure the execution environment at the time of component deployment. This will require operations to discover component ports in a generic manner (same operations for any component type), or in a specific one (operations generated according to the component type); these operations will be used by the execution environment to introspect and interconnect component instances at runtime [34]. Thus our environment will require reflective capabilities [39,40].

In existing component oriented middleware systems, Component Descriptors are used for recording information about the component implementation. We will examine what additions are required for extending these descriptors with QoS and trust relationship policy descriptions (borrowing ideas from [41]) to enable run time generation of configuration information. 

B6.1.3 Implementation of QoS-aware Core Services (WP3)

Partner CR3 will lead this workpackage. This workpackage will implement a collection of QoS enabled services as required by the architecture developed by WP2. The overall implementation framework will be defined by the first task 3.1, QoS-aware containers, that will run concurrently with WP2 and will run initially for six months. The deliverable report, D7 will define the APIs. Three main implementation tasks, on group communication, trusted coordination and QoS monitoring will last for 18 months and will implement containers enriched with a particular functionality (group communication, trusted coordination and monitoring respectively). The deliverables, available by the end of the second year of the project will be working prototypes, deliverables D8, D9 and D10. The first task will be resumed during the last six months of the project and will produce the revised version of D7 (report D11), that will take into account the prototype design and implementation work. TAPAS will make use of open source application servers (such as Jboss [7] or Jonas [8]) for this workpackage.

3.1 QoS-aware Containers

Partner CR3 will lead this task. Applications require the ability to request resources based on their immediate usage needs. Fulfilment of a given resource request will usually require several interactions with the underlying service, and each service may well have its own specific signalling methods and protocols (for end to end QoS negotiation) for resource reservation and feedback and adaptation, using advance exception handling techniques [42].

Adaptation based approach requires implementing mechanisms that periodically monitor the resources availability of the execution environment, and provide the applications with appropriate adaptation and reconfiguration properties. Relevant instances of the adaptation based approach are the QuO [43], TAO [44], and DaCapo++ [45] and Agilos [46] projects. In these projects, the adaptation middleware reconfigures itself to provide the application with a transparent and stable execution environment. In summary, it is worth pointing out that adaptation based middleware architectures demand the following three principal stages of run time support: (i) probing the performance of QoS parameters, (ii) instantiating the initial middleware configuration, and (iii) adapting to on-the-fly variations.

This task will develop APIs for QoS -aware group communication. A different style of API is required for interacting with the trusted coordination service, where negotiations and instantiation will be for establishing appropriate bindings with TTPs , as discussed in section 3.3.

3.2 QoS-enabled Group Communication

This task will be led jointly by partners CO1 and CR5. Group communication protocols play an important part in the construction of services that need to be replicated for fault tolerance and/or load balancing reasons [47-50]. Group communication protocols enhance multicast by providing guaranteed message delivery, atomicity and total ordering (ensuring all intended recipients receive the same messages in the same order); existing systems do not support QoS enabled communication (properties of timely delivery to all participants, large group size) over wide-area networks. Another class of group communication protocols use publish/subscribe model for handling event based communication as required in say share dealing. Existing publish/subscribe middleware services, such as CORBA event service [51], Java Message Service, JMS, [52] do not adequately support the notion of QoS, neither do the research systems developed so far [53,54]. This is because, these systems assume a ‘best effort’ transport layer. In this task we will develop a QoS enabled transport protocol for the Internet and use it to support group communication systems for the Internet such as the one developed by partner CO1 [55-57]. The work will be extended to support a suitable JMS implementation. We will examine work being done in this area by IST projects such as CORTEX.

Turning our attention to the development of a QoS enabled Internet transport service itself, we note that the protocol PGM [58] implements explicit "due date delivery" semantics. We thus have the beginnings of one-to-many protocol support for homogeneous and heterogeneous rate controlled, reliable delivery of data, with control over the timelines with which a specific item of data is delivered. Coupled with feedforward information signalled to a QoS sensitive network, and feedback from the network, a framework can be constructed that provides efficient communication; preliminary work in this area has been performed by partner CR5 [37,38]. An important question for the network API designer is "how to encode efficiently a multiparty traffic specification" - clearly specifying the full matrix of source models is not going to be viable, but assuming all sources are homogeneous is also unlikely to meet the requirements found in WP1. The other side of this coin is that a multi-party application can have a partial QoS contract failure. This needs to be signalled efficiently to the relevant parties in the application by the network, and again we will investigate appropriate mechanisms.

3.3 Trusted Coordination

This task will be led by partner CO1. The infrastructure for trusted coordination should support the life-cycle of an interaction, which may include some or all of the following steps (repeated as necessary and, possibly, recursively during an interaction):

·         introduction: the exchange of credentials to establish sufficient trust to pursue an interaction. This could range from the exchange of public keys to assertions of credit-worthiness, organisational membership etc.

·         negotiation: reaching binding agreement on the rules that will govern the interaction (the contract) and deriving sufficient information from the agreement to be able to instantiate an infrastructure to support the interaction

·         instantiation: the expression of the contract governing the interaction as a configured and instantiated infrastructure

·         activation: execution of the activity governed by the negotiated agreement and facilitated by the instantiated infrastructure

·         assimilation: the processing of interaction history to enable decision support to future interactions. For example, "reputation tokens" might be generated so that they can be used to establish trust in subsequent introduction phases.

We will begin by implementing two party client-server interaction with non-repudiation and authentication, based on the work performed by CO1 [16] and extend it to include TTPs. This framework will be further extended to support fair exchange protocols and multi-party communications. Interactions with the IST project MAFTIA will be relevant here.

3.4 QoS Monitoring

Once a design has been achieved and been proven to have the desirable qualitative and quantitative properties, it can inform not only the implementation in terms of an appropriate component framework, but also its deployment. In particular, the performance parameters that have been modelled and been established to meet the quantitative performance and scalability requirements will then be used to inform the definition of SLA that govern the execution of components across organizational boundaries. The TAPAS component execution middleware API developed in task 3.1 will be used to monitor conformance of component execution with these SLAs.

It is our intention to use the data gathered during SLA monitoring to inform the refinement of model parameters. In particular, it will be useful to validate the assumptions that have been made during the initial design about the performance of operation executions and the load characteristics against data gathered during the performance. Already to date, application services are designed in an incremental and iterative manner. The SLA monitoring data gathered after the first version has been deployed will provide very valuable data for the tuning of quantitative design parameters in the UML model during future iterations.

B6.1.4 Case Studies and Evaluation (WP4)

This workpackage will be led by the industrial partner CR2. We intend to build a particularly demanding application (in terms of QoS) that ASPs are currently unable to host using present day middleware platforms. The application we have chosen is that of electronic auctions. TAPAS partners CO1 and CR3 have worked jointly on large scale, dependable auctions on the Internet [59,60], so this provides a good starting point. We will be able to demonstrate features such as the use of QoS enabled group communication for supporting timely delivery of notifications from the auctioneer to bidders, and supporting replication of auction servers for availability and so forth. These aspects are covered in tasks 4.1. The second task (task 4.2) will use the experience of building the auction application as a basis for evaluating the results of the TAPAS project. Deliverables will be prototype auction implementation D12, and the TAPAS evaluation report D13.

4.1 Internet Auctions

The solutions developed by the TAPAS project will overcome limitations in current application hosting, not only for application service providers but as well for software developers and of course for the users of such applications. In a B2B marketplace scenario an auction application will provide a broad variety of quality and trust related aspects, because many different groups of participants are involved:

All these different groups have different requirements regarding the quality of the application’s services. The variety of requirements will be available from the requirements analysis performed in WP1 and will cover some basic topics such as (i) Trust management, (ii) Security policies, (iii) Privacy, and (iv) Measurable quality of the underlying network such as bandwidth, response time etc.

A vendor might, for instance, be interested in staying anonymous during the auction until the deal is settled, while the company running the marketplace will be interested in features such as availability and performance of the application. Currently SLAs are specified as contracts between two parties, i.e. in a non technical way. In order to increase the reliability of the SLA fulfilment and hence the acceptance of outsourcing even core parts of enterprise-relevant applications, SLAs clearly have to be specified on a technical level. The actual construction of the SLAs is part of the case study and will make use of the specification techniques and tools developed in WP1. We will  identify use-cases from the perspectives of the different participants. Some coarse-grain use-cases are already deductible from the description of the participants above:

These use-cases have to be refined in order to cover different behaviour of the system appropriately. The first result of the case study is an application, deployed and hosted on dedicated servers, which will be usable for a group of testers. The installation should sufficiently demonstrate the results from the perspectives of the different participants such as end-users, service providers etc. Furthermore, as a base for the following evaluation, the development artefacts such as use-cases and design models are available. Last but not the least, a summary of the development experiences will provide valuable input to the subsequent task of compiling an evaluation study and refinement of the TAPAS architecture, WP2.

4.2 Evaluation

The goal of the evaluation study is to inspect the TAPAS methods, techniques and components from an industry point of view. The evaluation will utilise the results of the case study as a starting point. Part of the results is the application itself, i.e. the software that can be deployed and hosted. While the case study focuses on the actual realisation of an QoS-aware scenario, the evaluation has to investigate as well quality aspects of the rest of the life cycle. For instance the SLA modelling techniques and tools have to be considered as well. Again it is reasonable to start with the experiences from the case study, for which these techniques and tools will have been used during the construction. However, the case study cannot cover all aspects of a broadly usable technique. Therefore further effort has to be taken to explore uncovered aspects. This must start with identifying the methods, tools, techniques and components developed by TAPAS. We will scan the use-cases of the case study for test cases that involve QoS features and can then construct test cases.

In an auction scenario, which is embedded into a marketplace scenario, the set of QoS-related test cases might base on some of these cases:

The test cases then have to inspect the behaviour of the application and the middleware and network components. Therefore it is necessary to test the fulfilment of the requirements under normal conditions as well as under stress situations. Due to the variety of requirements such as guaranteed bandwidth, simultaneous arrivals, transaction safety including different systems etc. constructing stress situations will lead to a variety of possibilities: (i) limiting the network bandwidth, (ii) causing significant delays of messages, (iii) trying to access protected data, (iv) stopping features like encryption in underlying services, (v) accessing services beyond the asserted limitations of data amount or accesses. Thereby constructed test cases cover the fulfilment of the requirements. Furthermore the behaviour of the QoS monitoring components must be inspected, because the escalation of QoS failures is important to build confidence between the users of SLAs. Beside the test cases derived from the use-cases, some effort will be taken to attack the core features of the TAPAS components such as trust, security, privacy, network multicast etc. to find weaknesses and strengths, that have not been highlighted by the test cases.

B6.1.5 Project Management and Coordination (WP5)

The TAPAS Executive Board will be responsible for the overall conduct of the project, setting overall technical goals, co-ordinating and reviewing technical progress, revising the project plan as necessary, ensuring the timeliness and quality of the deliverables, and developing an exploitation plan. It will be assisted by an Administrative Coordinator. Membership of the Executive Board will consist of one representative of each Partner, though other individuals may be co-opted as appropriate.

The Executive Board will meet at least twice a year, normally in connection with Project workshops, and will also have regular meetings with the Advisory Board. Additional meetings will be called as and when necessary. Detailed responsibility for the different workpackages has been divided among the Partners - who nominate particular individuals to have detailed responsibility for the completion of the work and the timely production of the deliverables.

The Administrative Coordinator is, from the point of view of the Commission, the contract manager responsible for maintaining contact with the Commission on all aspects of the Project, and has primary responsibility for managing the budget, maintaining an information service, etc.

The project's infrastructure will use the Internet, and will consist of an internal and public web server, and an internal servers for documents, code and documentation, version control and archived mailing lists.

Full details can be found in Part C of this proposal.


B6.2 Project Plan

B6.3 Graphical presentation of the project’s components

For the sake of simplicity, the Plan below assumes 1st January 2001 as the start date.

B6.4 Detailed project description

B6.4.1 Resources

Throughout this proposal, resources per partner and work packages relate to the effort for which we are requesting funding from the Commission. However, the actual effort on the project will include significant additional resources to augment the resources we hope the Commission will agree to fund. For example, partner CO1 is seeking funding for 117 person-months directly from the project whilst estimated total effort on the project, including that of senior researchers, is approximately 150 person months. The other costs attributed directly to the project, e.g., the costs of travel to enable participation in project workshops, therefore reflect the participation of staff over and above those directly funded by the project. The project will be undertaking significant amount of experimental work, so the requested budget includes funding for equipment. Finally, it should be noted that the coordinator's costs include provision for the participation of members of the TAPAS Industrial Advisory Board in project meetings.

 

 

CO1

CR2

CR3

CR4

CR5

Totals

% of res

% of total

WP1

12

11

14

24

7

68

23%

19%

WP2

24

11

14

12

7

68

23%

19%

WP3

24

12

27

20

12

95

32%

26%

WP4

12

24

13

12

7

68

23%

19%

Subtotal

72

58

68

68

33

299

100%

83%

WP5

45

4

4

4

3

60

 

17%

Total

117

62

72

72

36

359

 

100%

Resources Per Partner and Workpackages

B6.4.2 Workpackage List

 

 

Workpackage list

 

 

 

 

 

 

 

 

Work-package
No

Workpackage title

Lead
contractor
No

Person-months

Start
month

End
month

Phase

Deliv-erable
No

WP 1

Application Service Requirements and Specification

CR4

68

0

29

R

D1,  D2, D3, D4

WP 2

Design of QoS-aware Infrastructure for Application Hosting

CO1

68

6

          35

R

D5, D6

WP 3

Implementation of QoS-aware Core Services

CR3

95

6

35

R

D7,D8, D9, D10, D11

WP 4

Case Studies and Evaluation

CR2

68

18

35

R

D12, D13

WP 5

Project Management and Coordination

CO1

60

0

35

R

N/A

 

TOTAL

 

359

 

 

 

 

 


B6.4.3 Deliverable list

 


Deliverables list

 

Deliverable
No

Deliverable title

Delivery
date

Nature

Dissemination
level

D1

Application Hosting and Networking Requirements Document

5

R

PU

D2

Specification Language for SLAs

11

R

PU

D3

Method for Service Composition and Analysis

17

R

PU

D4

Service Composition & Analysis Tool

29

P

PU

D5

Architectural Design Document

11

R

PU

D6

Revised Architectural Design Document

35

R

PU

D7

QoS Container Interface Specification

11

R

PU

D8

Container for Group Communication

23

P

PU

D9

Container for Trusted Coordination

23

P

PU

D10

Container for QoS Monitoring

23

P

PU

D11

Revised Container Interface Specification

35

R

PU

D12

QoS-aware and trusted ASP for Auctions

29

D

PU

D13

TAPAS Evaluation Report

35

R

PU

 

B6.4.4 Workpackage descriptions

Note: Project start month is M0.

 

Workpackage description

 

Workpackage number :

WP1- Application Service Requirements and Specification

Start date or starting event:

Month 0

Participant number:

CO1

CR2

CR3

CR4

CR5

Total

 

Person-months per participant:

12

11

14

24

7

68

 

 

Objectives:

To develop notations for expressing SLAs to enable specification of QoS, such as the availability, performance and scalability characteristics of components, as well as trust relationships. Model checking capabilities will be developed to support reasoning about QoS characteristics of components and their composition. This will support the ASP in assessing the qualities of service perceived by end-users prior to developing and deploying an application service.

 

 

 

Description of work:  

This workpackage has been divided into four tasks. The first two tasks study, respectively application hosting requirements and networking requirements for many-to-many communications. These results will feed into WP2 and WP3. The remaining two tasks concern SLA specification and analysis: alongside functional components interfaces, these SLAs specify the non-functional qualities of service, such as the availability, performance and scalability characteristics of components; analysis tools will be developed for reasoning about the performance and scalability characteristics of components and their composition. TAPAS will adapt the UML as the baseline for the description, modelling and analysis of application services and extend the UML with formally defined stereotypes and properties that support the modelling of distributed interaction primitives and QoS characteristics. The semantics and properties of the stereotypes will be defined by mapping stereotyped UML diagrams to process algebra; in addition, we propose to use Markovian stochastic process algebra for use in performance analysis.

 

 

 

Deliverables:

Report D1 describing application hosting requirements and networking requirements

Report D2 will document the SLA specification method

Report D3 will describe service composition and analysis method

D4 will be the toolkit for service composition and analysis

The results from D2-D4 will be used for the development of applications in WP4.

 

 

Milestones and expected result:

Application hosting and network QoS requirements; service composition and analysis techniques.

Results from D1 will feed into WP2 and WP3

The results from D2-D4 will be used for the development of applications in WP4.

Preliminary version of the toolkit available when WP4 starts (month 18)

 


 


Workpackage description

 

Workpackage number :

WP2- Design of QoS-aware Infrastructure for Application Hosting

Start date or starting event:

Month 6

Participant number:

CO1

CR2

CR3

CR4

CR5

Total

 

Person-months per participant:

24

11

14

12

7

68

 

 

Objectives

To develop QoS enabled middleware services capable of meeting SLAs agreed between application services, and to enhance component based middleware technologies such that components can be deployed and interact across organisational boundaries. To consider hosting of important class of large scale networked multi-party applications that are characterised by a group of entities requiring many-to-many interactions; examples include collaborative applications (e.g., multimedia conferencing, multi-person interactive games), electronic share dealing and auctions, and ‘information supply chain’ applications typically based on publish-subscribe paradigm.

 

 

Description of work

Component oriented middleware promotes the use of containers to host component instances. Containers are responsible for using the underlying middleware services for communication, persistence, transactions, security and so forth. TAPAS architecture will use SLAs not only as an inter-organizational contractual feature but also to govern component execution. To this end, QoS negotiation, establishment, and adaptation facilities will be added to the middleware and these will be used by component containers to make them QoS aware. The workpackage will have four tasks: middleware architecture, trust management, network control architecture and component execution environment. We are assuming that the organisations involved might not trust each other, so an important part of our work will be concerned with developing infrastructure support for interactions between two or more mutually distrusting organisations. Our aim is to ensure that a developer only has to write the functional code in order to complete the component implementation, all the non-functional properties will be derived from the SLAs and used to configure the execution environment at the time of component deployment.

 

Deliverables

Report D5, available by the end of the first year of the project, that will describe the interim TAPAS architecture for application hosting

Final architecture report, D6, describing the TAPAS architecture for application hosting

 

Milestones and expected result

Techniques for building QoS-aware containers

M08:Preliminary methods for governing QoS contracts between containers and underlying services

M08:Understanding of the use of TTPs in inter-organisation interactions

M08:Signalling protocols for multi-party communications

M30:Feedback from case studies and evaluation work (WP4) available for D6

 


Workpackage description

 

Workpackage number :

WP 3- Implementation of QoS-aware Core Services

Start date or starting event:

Month 6

Participant number:

CO1

CR2

CR3

CR4

CR5

Total

 

Person-months per participant:

24

12

27

20

12

95

 

 

Objectives

Implement the architecture developed in WP2. Implement QoS-aware containers and support services of QoS-aware group communication, trusted coordination and QoS monitoring.

 

 

Description of work

Applications require the ability to request resources based on their immediate usage needs. Fulfilment of a given resource request requires several interactions with the underlying service, for which specific signalling methods and protocols (for end to end QoS negotiation) for resource reservation and feedback and adaptation will be implemented. QoS enabled Internet transport service based on PGM protocol will be developed. This will be used for supporting group communication and publish-subscribe protocols. For trusted coordination, implementation of two party client-server interaction with non-repudiation will be performed and extended to include TTPs. This framework will be further extended to support fair exchange protocols and multi-party communications. Component execution middleware API developed will be used to monitor conformance of component execution with the SLAs. TAPAS will make use of open source application servers (such as Jboss or Jonas) for this workpackage.

 

Deliverables

Deliverable report, D7 will define preliminary APIs for QoS-aware component containers

D8: prototype QoS-aware group communication system

D9: prototype trusted coordination software

D10: prototype QoS monitoring software

D11: Final APIs for QoS-aware component containers

 

 

Milestones and expected result

Open source application server software with QoS aware containers and services, permitting inter-organisation component deployment

M15: Preliminary method for implementing QoS contracts between containers and underlying services

M15: Preliminary version of enhanced PGM transport layer

M20: Preliminary versions of QoS-aware group communication, trusted coordination and monitoring software

 

 


 


Workpackage description

 

Workpackage number :

WP 4- Case Studies and Evaluation

Start date or starting event:

Month 18

Participant number:

CO1

CR2

CR3

CR4

CR5

Total

 

Person-months per participant:

12

24

13

12

7

68

 

 

Objectives

To build a particularly demanding application (in terms of QoS) that ASPs are currently unable to host using present day middleware platforms. The application we have chosen is that of electronic auctions. To demonstrate features such as the use of QoS enabled group communication for supporting timely delivery of notifications from the auctioneer to bidders, and supporting replication of auction servers for availability and so forth. To use the experience of building the auction application as a basis for evaluating the results of the TAPAS project.

 

Description of work

The variety of requirements for the application will be available from the requirements analysis performed in WP1 and will cover some basic topics such as (i) Trust management, (ii) Security policies, (iii) Privacy, and (iv) Measurable quality of the underlying network such as bandwidth, response time etc. The application, deployed and hosted on dedicated servers, will be usable for a group of testers. The installation should sufficiently demonstrate the results from the perspectives of the different participants such as end-users, service providers etc.

For evaluation,  it is necessary to test the fulfilment of the requirements under normal conditions as well as under stress situations. Due to the variety of requirements such as guaranteed bandwidth, simultaneous arrivals, transaction safety including different systems etc. constructing stress situations will lead to a variety of possibilities: (i) limiting the network bandwidth, (ii) causing significant delays of messages, (iii) trying to access protected data, (iv) stopping features like encryption in underlying services, (v) accessing services beyond the asserted limitations of data amount or accesses.

 

Deliverables

D12: Prototype auction demonstrator application

D13: TAPAS evaluation report

 

 

Milestones and expected result

M23: preliminary version of auction system working

M30: preliminary evaluation results available

Results will provide inputs to TAPAS Architecture revision work

 


 


Workpackage description

 

Workpackage number :

WP 5- Project Management and Coordination

Start date or starting event:

Month 0

Participant number:

CO1

CR2

CR3

CR4

CR5

Total

 

Person-months per participant:

45

4

4

4

3

60

 

 

Objectives

·         To initialise, manage, and administer the project.

     To ensure the desired high quality and timely production of results.

     To set-up and maintain a communication infrastructure for the project.

     To provide administrative support for, and ensure that full benefit is gained from, the Industrial Advisory Board

 

Description of work

This work package is concerned with management at a project, activity, and partner level. The Executive Board, consisting of one representative of each partner, with other individuals co-opted as appropriate, is responsible for the overall conduct of the project, including setting overall technical goals, co-ordinating and reviewing technical progress, revising the project plan as necessary, and ensuring the timeliness and quality of the deliverables. The Executive Board will be supported in this work by the Administrative Co-ordinator who will act as contract manager responsible for maintaining contact with the Commission, managing the budget, supporting the activities of the Industrial Advisory Board, ensuring proper dissemination of reports, etc.

The project’s communication infrastructure will be based on the Internet, and will consist of an internal and public web server, and of internal servers for documents, code and documentation, version control and archived mailing lists. The infrastructure of a previous project will be (re)used, as far as possible.

 

Deliverables

WP5 will co-ordinate the production of the four technical Workpackage Reports and software development work. The technical contents of these reports will be provided by the other workpackages

 

Milestones and expected result

Production of regular control and audit reports, according to the scheme to be set up by the IST project office

Realisation of regular technical and management project meetings per year

 

 


References Attached in Part C

 

 

 

 


 [wje1]write also something about NAT to get around firewalls