The Changing Nature of Feature Interaction Ken Turner University of Stirling Lydie du Bousquet IMAG Glenn Bruns Bell Labs, Lucent Technologies Luigi Logrippo Université du Québec Mark Ryan University of Birmingham 29th June 2005 Is FI Dead?

Panel Questions

FI - An Outdated Problem? FI research and the FIW conference arose from an immediate and specific technological need: dealing with FI in a very specific telephony architecture (IN) Much FI work was targeted to this need However researchers have been saying all along that this is a general problem

The Death of FI? Is feature interaction dead, rendered obsolete by new kinds of services? Does FI exist in VoIP, IVR, Web, Grid? Is feature interaction meaningful in modern communications systems? Are features an old-fashioned IN concept? Will feature interaction be replaced by new concepts such as policy conflict? Are policies replacing features?

The New Face of FI Is service creation/analysis of greater interest to industry? Create effective services, forget analysis? How can non-functional feature interactions be considered? Are known interactions all just behavioural? Will feature interaction become an issue for endpoints, not the core network? Will networks become simple carriers? Will new techniques alter the nature of FI? What about model-driven architecture, AOP?

Lydie du Bousquet IMAG

FI - A Problem in Telephony Telephone - a safety critical system Widely used POTS + additional features: Developed independently Competitive context Types of interaction: Functional (specification vs. software) Time delay Ergonomics (user vs. software/spec)

FI Meaningful Elsewhere ? FI with car/plane embedded control systems ? Yes maybe (Renault?) FI in classical software development? “Service” is not traditional Components (COTS), Aspects, … FI in web services? Becoming critical/commercial Is there a “basic service” and additional features? FI in ubiquitous software systems? Too soon: not much used and no “basic service” FI in augmented reality ? Too soon: not much used and no “basic service”

Glenn Bruns Bell Labs, Lucent Technologies

Features Understanding “features” as “call processing features in telecommunication systems” is much too narrow Work in Aspect-Oriented Programming should open our eyes to the broad scope that is possible for this field The challenge is to find the fundamental concepts and to see how they are instantiated in different kinds of systems

Economics At Lucent, “fast” trumps “better” This attitude probably makes sense from a business point of view How much does a undesired feature interaction cost?

Culture System DevelopmentComputer Science design analyze hard soft architect systems engineer software developer tester theory, analysis design, application

Answers to the Questions Feature Interaction is not dead – it is being resuscitated Policy Conflict provides a new application area for FI “Traditional” FIs will remain an issue Service Creation has always been of more interest to industry than FI New approaches such as self-provisioning will make things interesting

Luigi Logrippo Université du Québec en Outaouais

Will there still be FI in VoIP? Consider the following situations: a phone can be simultaneously free and busy you can dial a new call when hearing busy you can connect to someone in a blacklist anyone can dial in to an existing conversation an event under the same preconditions can yield different results If all this and more should be tolerated in VoIP, then there is no point looking for FI

The New Importance of Intention Since features are freely programmable in VoIP, there is no technological reason to worry about any of these situations some users may want it that way; who knows... FI must be taken to be the undesirable effects of feature composition What is undesirable depends on user intentions

Intentions, Policies and Their Inconsistencies Some intentions are explicitly stated: these are the policies Some are implicit: expectations about system behavior FIs are inconsistencies that can occur in specific situations among: user policies user intentions

Resolution in context (Tom Gray) Application will be 'embedded' in the larger enterprise or social context. Resolution must be done within the rules or expectations of that context a call from a boss is important a cold call from a salesman is not for a lawyer, a call from a judge's office requires immediate attention The designer must be aware of the sociological expectations that surround the human activity that application is supporting This requires much customization

The World of Web Services: FIs Galore with A Vengeance! A phone can ring wrongly without much harm, but the purchase of an expensive item can’t be cancelled as easily! Forwarding loops: much worse in effects and prevention, e.g. loops of subcontracts can lead to disastrous economic effects Contract interactions: policies of different users clash, making certain contracts impossible, perhaps for futile reasons How to keep user in the loop for meaningful resolution Security gaps in access control

Infinite loops FIs Companies A, B and C have policies where each of them uses the next in a loop as suppliers of parts in excess of inventory This can start a chain reaction with potentially disastrous effects! Send 1000 hockey pucks Send 800 pucks Send 600 pucks Send 400 pucks Send 400 Examples by Tom Gray

Mark Ryan University of Birmingham