Engineering and Design (KM-ED)
WP-JRA-1.1: Engineering and Design
Engineering Service-Based Applications (SBAs) is quite different from any other software engineering activity. These applications are built by gluing together some possibly already existing services that can be built and operated by third parties with which we may decide to establish a Service Level Agreement.
The possibility to reuse in SBAs existing services without even caring about the details needed to operate them is very attractive in principle. However, it changes the way applications are built and are operated. All services used to compose an application are not anymore under the direct control of the application developer and provider. This means that they could be modified or even temporarily or permanently dismissed without notice. Even what a service provider could perceive as an improvement of the service functionality could result in the impossibility for an SBA of using this service anymore. Think for instance at a service that is offering images at a certain resolution. Increasing the resolution is not necessarily a plus if the application that is using this service has to display the images on a PDA. This fact leads to the need for being able to replace a service with another at runtime in order to make the application resilient to any change happening on the side of the service.
Another interesting and promising aspect of Service-Based Applications is their ability to adapt to different execution contexts (we call these Adaptable Service-Based Applications). Again, this requires the selection and possibly (re)placement of services at runtime.
While a number of specific techniques have been developed to support dynamic service discovery, selection, and service binding, a set of engineering methods aiming at developing service-based applications ready to perform self-adaptation at runtime is still missing. A method of this kind should support the designer in the definition of the application-dependent logic of a service composition as well as of the policies that are actuated when runtime changes are needed. Such policies aim at supporting the evolution of Service-Based Applications still keeping them under control. More in detail, a design for adaptation approach should address the following problems:
How to identify and represent relevant changes or situations that the target system should adapt to. This amounts to the classification and description of the dynamic aspects of the target system (such as context-related aspects, available services and their metrics, classes and parameters of failures), and the relevant values and ranges (e.g., acceptable bounds of QoS parameters, values of context parameters, etc).
How to drive the modification of the application when the necessity to adapt is detected. In this case the specification of adaptation requirements and objectives and adaptation strategies should be addressed. The corresponding notations and languages should enable the integrator to describe the desired situations (e.g., “good” state of the system in case of self-healing systems) or even adaptation actions (e.g., re-execution or re-binding command) at high level of abstraction.
Services and SBAs can require interaction with human users taking part in the business process enabled by the service, or imparting human intelligence to the relevant services (e.g. the Amazon Mechanical Turk Web service). This interaction is currently supported in initiatives such as BPEL4People, an extension to the BPEL language that defines human tasks through Web Service Human Task (WS-Human Task) and describes them as activities with WS-BPEL Extension for People. We explore whether the Human-Computer Interaction (HCI) literature can further contribute to the integration of human actors in SBAs by providing richer, more contextual descriptions and models than those currently available. We further examine whether an explicit integration of current HCI knowledge into approaches to the engineering of SBAs would support their development.
Engineering and Design shows many relationships with the other S-Cube work packages since it gathers techniques and approaches from them and tries to harmonize them into an engineering method. More specifically:
Quality Definition, Negotiation, and Assurance offers support for the quality assurance aspects. These are of paramount importance for any software engineering method and are particularly critical when we consider the development of SBAs where component services are out of our control and therefore require the definition of SLAs as well as of mechanisms that support both their pre-execution evaluation and their runtime monitoring.
Business Process Management, Service Composition, and Service Infrastructure domains offer features and approaches at the various layers of the SBA stack, ranging from BPM to the execution infrastructure. All of these will have to be considered in the definition of the engineering method for adaptable SBAs. Moreover, the HCI findings, as well as the methodological aspects that will be identified in this domain will provide hints and suggestions to the other work packages for the selection of the approaches that best suit the S-Cube engineering vision.