Helen T Wagner
email: h.t.wagner@lboro.ac.uk

Susan C Morton

R J Dainty

Neil D Burns

Andrew R J; Dainty

Path Dependent Constraints on Innovation Programmes in Production and Operations Management

Keywords: Force Field Analysis, Path Dependency innovation levels, Force Field Analysis, path dependency

Innovation has been categorised into levels, ranging from incremental to radical, each of which has the potential to impact on the workforce and the organisation of a company, influenced by contextual factors. This paper investigates the barriers to innovation diffusion in companies working at these two ends of the innovation scale, in order to identify similarities and differences in how levels of innovation affect an organisation and how culture affects success. It also considers these factors in light of the Path Dependency concept. Investigations were conducted on a case study basis, using semistructured interviews. This led to the creation of Force Field Analysis diagrams to portray the findings, which show the radical innovation implementation has experienced greater resistance than the incremental program. Conclusions show that there were many similarities between the radical and incremental innovation projects. Differences were primarily based on project specific forces and those that occur as a result of path dependant forces that have shaped the current working environment. Organisational culture was found to be a significant influence, as all innovation programmes require the involvement of people. Findings of this study will contribute to theory on the differential and similar forces which shape incremental and radical innovations.

Introduction

Baumol states that "Under capitalism, innovative activity -which in other types of economy is fortuitous and optional -becomes mandatory, a life-and-death matter" [START_REF] Baumol | The free-market innovation machine: analyzing the growth miracle of capitalism[END_REF]. This makes it essential for all organisations (Arias-Aranda et.al., 2001) wishing to survive the capitalist economy that prevails in western society to embrace innovation, especially at this time of global financial uncertainty. Innovation itself can come in several forms, as "an idea, practice or object that is perceived as new by an individual or other unit of adoption" [START_REF] Rogers | Diffusion of innovations[END_REF], all of which have the potential to impact on the culture and status quo of an organisation and the individuals within it during Innovation Diffusion. Innovation has been categorised by [START_REF] Henderson | Architectural innovation: the reconfiguration of existing product technologies and the failure of established firms[END_REF] into four levels, dependent on the effects they have within an organisation: Radical, Architectural, Modular and Incremental [START_REF] Henderson | Architectural innovation: the reconfiguration of existing product technologies and the failure of established firms[END_REF][START_REF] Afuah | The hypercube of innovation[END_REF], each of which have different effects on an organisation, ranging from the minor incremental to the disruptive radical.

The process of transferring new ideas, known as innovation diffusion, causes a degree of social change, and what may appear to be a simple process is driven by the [START_REF] Steele | Creating, supporting and sustaining a culture of innovation[END_REF] as individuals project their uncertainties over the loss of stability [START_REF] Topf | Managing change[END_REF] of a situation they have often had a stake in creating [START_REF] Christensen | Something old, something new: 'the innovator's dilemma[END_REF]. The level of resistance and barriers experienced during this process comes from a variety of reasons, many of which can be linked to company specific decisions, unrelated to the current initiative [START_REF] Mazzoleni | Learning and path-dependence in the diffusion of innovations: comparative evidence on numerically controlled machine tools[END_REF]. For example, the process of innovation diffusion is affected by past events in the history of organisations, which can inhibit the ability of an organization to adopt new ideas, a concept known as 'path dependency' [START_REF] Liebowitz | Path Dependence, Lock-In, and History[END_REF][START_REF] Coombs | Knowledge management practices' and path dependency[END_REF][START_REF] David | Clio and the Economics of QWERTY[END_REF].

Having found a lack of business level implementation cases, a finding supported by [START_REF] Yu | Understanding business-level innovation technology adoption[END_REF], who noted that "Literature on business-level technology adoption is scarce compared to general literature on examining individual-level technology adoption" and Armbruster et.al (2008) who stated that "the existing literature on organizational innovation is diverse and scattered"; this paper will investigate the barriers to both the uptake and generation of innovation in organisations working at the two ends of the innovation scale; one in radical innovation, the other incremental. Offering information on how the level of innovation affects the barriers created and how culture affects success. It sets out to inform practitioners of the potential issues faced when attempting to propagate a culture more accepting of innovation and the change which this necessitates. [START_REF] Morton | Understanding and overcoming resistance to innovation[END_REF] define innovation as threefold: "the process of bringing new and improved products and processes to market; developing, adopting and adapting manufacturing processes to enhance productivity and product quality; and developing, adopting and adapting business practices to enhance the performance of the firm." All of these have the same goal: to improve efficiency and ensure the organisation remains competitive in its market. In this study, it is the organisation's innovativeness that is important, considering the propensity a firm has to adopt innovations [START_REF] Garcia | A critical look at technological innovation typology and innovativeness terminology: a literature review[END_REF]2002[START_REF] Damanpour | Organizational innovation: a meta-analysis of effects of determinants and moderators[END_REF][START_REF] Rogers | Diffusion of innovations[END_REF], both in terms of new technology and process improvements.

Literature Review

Recent publications on innovation diffusion into organisations have focused on topics from training [START_REF] Sharma | The contingent effects of training, technical complexity, and task interdependence on successful information systems implementation[END_REF], patterns of adoption [START_REF] Freitas | Sources of differences in the pattern of adoption of organizational and managerial innovations from early to late 1990s, in the UK[END_REF]Xue et.al, 2008) and effects of firm size [START_REF] Freitas | Sources of differences in the pattern of adoption of organizational and managerial innovations from early to late 1990s, in the UK[END_REF][START_REF] Battisti | The intra-firm diffusion of complementary innovations: Evidence from the adoption of management practices by British establishments[END_REF], to monitoring and measuring diffusion (Armbruster et.al 2008) and recognising its differing stages [START_REF] Freitas | Sources of differences in the pattern of adoption of organizational and managerial innovations from early to late 1990s, in the UK[END_REF][START_REF] Yu | Understanding business-level innovation technology adoption[END_REF][START_REF] Carayannis | Innovation diffusion and technology acceptance: The case of PKI technology[END_REF][START_REF] Larsen | Horses for courses: relating innovation diffusion concepts to the stages of the diffusion process[END_REF][START_REF] Lapointe | A multilevel model of resistance to information technology implementation[END_REF]. However, the majority have explored the effects of management involvement in the process (Panuwatwanich et.al, 2009;[START_REF] Peansupap | Innovation diffusion at the implementation stage of a construction project: a case study of information communication technology[END_REF][START_REF] Lapointe | A multilevel model of resistance to information technology implementation[END_REF][START_REF] Dong | Exploring the impact of top management support of enterprise systems implementations outcomes: Two cases[END_REF][START_REF] Lyytinen | The Disruptive Nature of Information Technology Innovations: The Case of Internet Computing in Systems Development Organizations[END_REF].

In their study, [START_REF] Sharma | The contingent effects of training, technical complexity, and task interdependence on successful information systems implementation[END_REF], established that although training is generally seen as an essential component in the innovation diffusion process, it is really only critical where technical complexity and task interdependence are high; which has the potential to impact on many planning innovation adoption. [START_REF] Freitas | Sources of differences in the pattern of adoption of organizational and managerial innovations from early to late 1990s, in the UK[END_REF] and [START_REF] Battisti | The intra-firm diffusion of complementary innovations: Evidence from the adoption of management practices by British establishments[END_REF], found that firm size had an impact on innovation diffusion; showing that larger firms were more likely to adopt organisational innovations [START_REF] Freitas | Sources of differences in the pattern of adoption of organizational and managerial innovations from early to late 1990s, in the UK[END_REF] and use them more intensively, than small, independent firms (Xue et.al, 2008). Armbruster et.al (2008) and divisional functions -and procedural -those that affect routines, processes and implement new procedures. This allows for a structure in a monitoring system that is clear what it is measuring, which is further broken down to identify four areas for consideration: i.e. complexity, lifecycle and quality of innovation, along with extent of use.

There are many different stages in the diffusion process, that begin before the decision to adopt, at which point information begins to become available and opinions begin to be shaped [START_REF] Yu | Understanding business-level innovation technology adoption[END_REF]; views which change as the stages progress [START_REF] Larsen | Horses for courses: relating innovation diffusion concepts to the stages of the diffusion process[END_REF]. Observations made by [START_REF] Carayannis | Innovation diffusion and technology acceptance: The case of PKI technology[END_REF] showed that many of the most successful firms have undertaken what have often been lengthy and expensive pilot studies as the first stage in their diffusion process. The work of [START_REF] Lapointe | A multilevel model of resistance to information technology implementation[END_REF], explored resistance behaviour through diffusion stages; identifying behaviour that escalated from passive individual to actively resistance coalition groups. This has led them, [START_REF] Lapointe | A multilevel model of resistance to information technology implementation[END_REF], and others [START_REF] Yu | Understanding business-level innovation technology adoption[END_REF]) to advise that, at least in the initial stages, that resistance should be looked at on an individual level and their interactions (Wagner et.al) rather than considering the group as a 'unified entity' and management responses modified accordingly. The general consensus amongst authors (Panuwatwanich et.al, 2009;[START_REF] Peansupap | Innovation diffusion at the implementation stage of a construction project: a case study of information communication technology[END_REF][START_REF] Lapointe | A multilevel model of resistance to information technology implementation[END_REF][START_REF] Dong | Exploring the impact of top management support of enterprise systems implementations outcomes: Two cases[END_REF][START_REF] Lyytinen | The Disruptive Nature of Information Technology Innovations: The Case of Internet Computing in Systems Development Organizations[END_REF], is that top level management visibility is critical to the success of an innovation initiative. [START_REF] Peansupap | Innovation diffusion at the implementation stage of a construction project: a case study of information communication technology[END_REF] noted how this should manifest at the different stages of diffusion; demonstrating commitment in the early adoptive phase by making resources available, followed by encouraging users through adaptation and rountinisation of the innovation into normal working practices and supporting with the appropriate technology and training to develop the necessary skills. [START_REF] Dong | Exploring the impact of top management support of enterprise systems implementations outcomes: Two cases[END_REF] conformed to this view, adding that senior management should be visibly supportive throughout the stages of diffusion and should not assume that staff will be aware of their support, by paying attention to change management and satisfaction of users. This will also include [START_REF] Lyytinen | The Disruptive Nature of Information Technology Innovations: The Case of Internet Computing in Systems Development Organizations[END_REF] that management recognise the demands and implications involved the change. Inspiring creativity and challenging staff to promote the development of new ideas was also considered a role of a leader in the diffusion process; a strategy that should lead to a greater propensity for supporting and facilitating the innovation initiative (Panuwatwanich et.al, 2009).

Innovation typology is a widely discussed topic, with many different scales being offered by authors [START_REF] Garcia | A critical look at technological innovation typology and innovativeness terminology: a literature review[END_REF]. [START_REF] Henderson | Architectural innovation: the reconfiguration of existing product technologies and the failure of established firms[END_REF] four level typology, developed from [START_REF] Abernathy | Innovation mapping the winds of creative destruction[END_REF], was considered to be the appropriate structure in the analysis of the two case studies, which fall at either end of the scale, when related to organisation based innovation. It is considered that the culture for radical innovation differs greatly from that of incremental innovation [START_REF] Greenwood | Understanding strategic change -the contribution of archetypes[END_REF], and must be considered by managers undertaking innovation projects [START_REF] Garcia | A critical look at technological innovation typology and innovativeness terminology: a literature review[END_REF][START_REF] Oke | Innovation types and innovation management practices in service companies[END_REF]. Management style also differs and a thorough understanding of the process must exist in order to make sense of complex and uncertain conditions [START_REF] Tidd | Innovation models: discussion paper 1, Imperial College London[END_REF]. With success resting on management creating sufficient level of enabling influence to support the process [START_REF] Sharma | The contingent effects of management support and task interdependence on successful information systems implementation[END_REF], they must obtain feedback from staff and modify their supportive actions correspondingly [START_REF] Dong | Exploring the impact of top management support of enterprise systems implementations outcomes: Two cases[END_REF].

Radical innovation, as seen in Case 1, is disruptive in nature, rendering current equipment and the connected competencies obsolete [START_REF] Garcia | A critical look at technological innovation typology and innovativeness terminology: a literature review[END_REF] [START_REF] Utterback | Mastering the dynamics of innovation[END_REF] and is characterised by a greater level of risk [START_REF] Garcia | A critical look at technological innovation typology and innovativeness terminology: a literature review[END_REF]. Although innovation is often associated with radical change [START_REF] Oke | Innovation types and innovation management practices in service companies[END_REF], it was suggested by [START_REF] Morton | Understanding and overcoming resistance to innovation[END_REF] that most successful innovations come from a programme of incremental changes, emanating from efforts of individuals in many areas not confined to research and development. Incremental innovation is based on "doing what we do, but better" [START_REF] Tidd | Innovation models: discussion paper 1, Imperial College London[END_REF], refining existing technology and processes, leading to standardisation and a position of status quo in an improved organisation [START_REF] Garcia | A critical look at technological innovation typology and innovativeness terminology: a literature review[END_REF].

Within any organisational undertaking, there are potential barriers and enablers that come from both the program being pursued and the individuals involved in the process, which is potentially different in every organisation as "innovation is a process which is intrinsically firm specific" [START_REF] Coombs | Knowledge management practices' and path dependency[END_REF]. Context has been shown to be an important factor in the understanding of innovation and its challenges, as set out by [START_REF] Afuah | The hypercube of innovation[END_REF], as the 'hypercube of innovation'. This argues that what is seen as incremental in one context may cause radical consequences in another (Harty, 2008). Issues surrounding fit with the organisational structure and top management level support exist, along with work patterns and availability of resources [START_REF] Morton | Understanding and overcoming resistance to innovation[END_REF]. Many of these issues can be resolved by the formulation of an innovation strategy [START_REF] Babbar | Computer integrated flexible manufacturing: an implantation framework[END_REF], which should then be communicated throughout the organisation to elicit buy-in [START_REF] Oke | Innovation types and innovation management practices in service companies[END_REF]. This has been shown to be important in the field of radical, technology innovation implementations, where more failures result from organisational issues than technical ones [START_REF] Voss | Managing Advanced Manufacturing Technology[END_REF][START_REF] Babbar | Computer integrated flexible manufacturing: an implantation framework[END_REF]Machuca et.al, 2004).

Human factors play a part in achieving success; barriers to which have been identified at all levels from the individual, and the team, to the organisation as a whole [START_REF] King | Innovation at work: the research literature[END_REF][START_REF] Kratzer | Informal contacts and performance in innovation teams[END_REF]. Organisational culture may have an affect on potential for success. [START_REF] Hill | Strategic management[END_REF] explain culture as "the specific collection of values and norms that are shared by people and groups in an organisation and that control the way they interact with each other and with stakeholders outside the organization". In mature organisations these can be deeply embedded and, although they initially brought about success, they can inhibit the capability to embrace new ideas [START_REF] Dougherty | Product innovation in mature firms[END_REF][START_REF] Leifer | Radical innovation how mature companies can outsmart upstarts[END_REF]. Working within rigid structures potentially has a negative effect on innovation [START_REF] Amabile | Assessing the work environment for creativity[END_REF], and a lean organisation may not allow for much 'idea time' [START_REF] Anderson | Measuring climate for work group innovation: development and validation of the team climate inventory[END_REF]. However, innovation can be nurtured by a more caring atmosphere [START_REF] Kratzer | Informal contacts and performance in innovation teams[END_REF][START_REF] Zarraga | The impact of team atmosphere on knowledge outcomes in self-managed teams[END_REF]. Initiatives to manage resistance and promote involvement may include a human resource policy [START_REF] Oke | Innovation types and innovation management practices in service companies[END_REF] and the designation of innovation champions [START_REF] Rogers | Diffusion of innovations[END_REF], especially in cases of radical innovation [START_REF] Garcia | A critical look at technological innovation typology and innovativeness terminology: a literature review[END_REF]. A further, important issue in motivating individuals to engage with the innovation programme is that of the perception of trust, both in management and in their colleagues, the establishment of which will allow the sharing of knowledge and ideas [START_REF] Morton | Understanding and overcoming resistance to innovation[END_REF].

As each organisation faces the challenges of new technology, the process they go through is different every time. One potential explanation for this difference is known as Path Dependency (PD). One term that is often associated with PD is 'history matters'. Simplistically, this explains that the decisions made, or acts of 'fate' that happen at the beginning of a venture have consequences further down the road, which may not be anticipated, and can constrain future activities [START_REF] Greener | State of the art: the potential of path dependence in political studies[END_REF]. If the notion of history means that "What we have today is in part a consequence of what we had and what we did yesterday" [START_REF] Liebowitz | Path Dependence, Lock-In, and History[END_REF], it also brings to any new venture the associated 'inherited' culture and technological skills. In many cases it can be the things that the organisation had little control over that have had an impact, such as external events; these cannot be underestimated in their influence over the process, as it is considered to be dynamic and takes on characteristics of its history [START_REF] David | Clio and the Economics of QWERTY[END_REF], and can remain affected by these events long term [START_REF] Liebowitz | The Fable of the Keys[END_REF]. The concept of path dependency has been related to many areas of study in addition to technical innovation [START_REF] Patel | The technological competencies of the world's largest firms: complex and path-dependent, but not much variety[END_REF][START_REF] Dobusch | Schumpeter vs. path dependency: innovation lessons from breaking through innovation barriers[END_REF]; including economics [START_REF] Coombs | Knowledge management practices' and path dependency[END_REF]Boas, 2008), finance [START_REF] Deeg | Institutional change and the uses and limits of path dependency: the case of German finance[END_REF], social sciences [START_REF] Greener | State of the art: the potential of path dependence in political studies[END_REF], and biology [START_REF] David | Path dependence, its critics and the quest for 'historical economics', from the 'Keynote Address' to[END_REF]. In searching for a definition of PD, authors have made several observations of the concept; that it is dynamic [START_REF] Liebowitz | The Fable of the Keys[END_REF], non-reversible and evolutionary [START_REF] David | Path dependence, its critics and the quest for 'historical economics', from the 'Keynote Address' to[END_REF].

When considering work published on innovation and PD, Coombs and Hull identified three domains in which PD is observed within an organisation, these being 'technology-as-hardware', 'knowledge base' or 'shared mental framework of fundamental design concepts' which can be seen to be connected to the technologies employed, and the 'routines' that exist to allow workers to perform effectively [START_REF] Coombs | Knowledge management practices' and path dependency[END_REF]. Whilst it is true that often small events are averaged out by history (Schwarz, 2004) this does not always happen [START_REF] David | Path dependence, its critics and the quest for 'historical economics', from the 'Keynote Address' to[END_REF], resulting in PD where small, seeming inconsequential or random events at a critical juncture can play a part; in some cases creating disproportionately large and long-lived consequences further down the path [START_REF] Liebowitz | Path Dependence, Lock-In, and History[END_REF][START_REF] Deeg | Institutional change and the uses and limits of path dependency: the case of German finance[END_REF]Schwarz, 2004).

Arthur offers examples of these types of events as "unexpected orders, chance meetings with buyers, managerial whims" [START_REF] Arthur | Competing technologies, increasing returns, and lock-in by historical events[END_REF].

The term 'lock-in' [START_REF] Greener | State of the art: the potential of path dependence in political studies[END_REF][START_REF] Liebowitz | Path Dependence, Lock-In, and History[END_REF][START_REF] Deeg | Institutional change and the uses and limits of path dependency: the case of German finance[END_REF][START_REF] David | Path dependence, its critics and the quest for 'historical economics', from the 'Keynote Address' to[END_REF][START_REF] Arthur | Competing technologies, increasing returns, and lock-in by historical events[END_REF] is often used to describe the process of moving into the reproduction phase of the path [START_REF] David | Path dependence, its critics and the quest for 'historical economics', from the 'Keynote Address' to[END_REF], after change has taken place. Within this process the organisation must find ways of sustaining the equilibrium in order to 'lock out' competing ideas [START_REF] Greener | State of the art: the potential of path dependence in political studies[END_REF]; these mechanisms are central in the concept of PD [START_REF] Deeg | Institutional change and the uses and limits of path dependency: the case of German finance[END_REF]. This locked-in state can be a positive or negative situation, as firms can also become locked-in to a situation, which is no longer the most efficient solution for them, by factors such as financing, when it is still more cost effective to continue to use inferior equipment than invest in new [START_REF] Liebowitz | Path Dependence, Lock-In, and History[END_REF].

This paper aims to bring together many areas of innovation research, comparing the barriers to innovation diffusion in companies working on radical and incremental programs, in order to identify where similarities and differences occur and how levels of innovation affect an organisation. It also considers how culture affects success in innovation programs and contemplates these factors in light of the Path Dependency construct.

Methodology

For this work to address the issues identified, the case study methodology was chosen. In an era where Open Innovation [START_REF] Perkmann | University-industry relationships and open innovation: Towards a research agenda[END_REF][START_REF] Morton | Understanding and overcoming resistance to innovation[END_REF]) is encouraged, conducting case studies in collaboration with organisations was the most appropriate research methodology. This approach allowed for the use of multiple data collection methods that created the richest picture possible. It also provides a useful example to others of practical research findings from organisations attempting change over an extended time, something that [START_REF] Yu | Understanding business-level innovation technology adoption[END_REF] and Armbruster et.al (2008) important part of explaining the nature of resistant attitudes and behaviours [START_REF] Lapointe | A multilevel model of resistance to information technology implementation[END_REF] and are especially interesting and under reported [START_REF] Perkmann | University-industry relationships and open innovation: Towards a research agenda[END_REF] Case studies are used to study complex social phenomena [START_REF] Yin | Case study research: design and methods[END_REF] and are a useful tool in studying behaviour in organisations and new or emerging behaviours. They involve research of a real situation [START_REF] Ritchie | Qualitative research practice[END_REF], with the behaviour viewed in the context of all the interactions going on around it rather than in isolation [START_REF] Cassell | Essential guide to qualitative methods in organizational research[END_REF][START_REF] Rowley | Using case studies in research[END_REF]. Qualitative cases seek to find the underlying factors, coming from perceptions and feelings of people as they undergo experiences related to the process, uncovering what lays beneath the objective evidence [START_REF] Gillham | Case study research methods, Continuum[END_REF]. Their ability to achieve this comes from the richness of data collected using the various sources of evidence [START_REF] Rowley | Using case studies in research[END_REF], which can be used to provide description, and generate new, or test existing theory [START_REF] Eisenhardt | Building theories from case study research[END_REF]. Based around a set of research questions or hypotheses, a case study is conducted over time [START_REF] Cassell | Essential guide to qualitative methods in organizational research[END_REF], using varied methods of data collection [START_REF] Yin | The case study crisis: some answers[END_REF], such as interviews, focus groups and observations, in order to create as full a picture of the situation as possible [START_REF] Ritchie | Qualitative research practice[END_REF]. This may be enhanced by the use of quantitative methods [START_REF] Bryman | Research methods and organizational studies, contemporary social research[END_REF]) in some cases.

The cases introduced in this paper were investigated as part of two larger research projects, but were brought together to show the differences and similarities experienced by organisations innovating in different ways and at different levels. Case 1: a large automotive manufacturer that has implemented highly innovative and complex technology and is encouraging staff to embrace it and be innovative in how it can be utilised. Case 2: a large automotive supplier that has undertaken a lengthy program of improvement, and wishes to promote innovative thinking and the acceptance of innovative improvements, put forward by the workforce. During the investigations, semi-structured interviews were conducted giving rise to substantial sources of qualitative data. This data was then coded into themes for further analysis.

Barriers and enablers to the innovation identified within the process at each of the case organisations were represented in visual form using the Force Field Analysis method. Force Field Analysis is a technique that was developed by Kurt Lewin in the 1940's [START_REF] Dezieck | Planning for change: the Force Field tool[END_REF][START_REF] Dhillon | Creativity for engineers[END_REF] and was published in 1951 in the work Field Theory in Social Science [START_REF] Lewin | Field theory in social science: selected theoretical papers[END_REF]. It is a 'time honoured' qualitative analysis tool [START_REF] Schwering | Focusing leadership through Force Field analysis: new variations on a venerable planning tool[END_REF], included in many organisational behaviour [START_REF] Thomas | Force Field analysis: a new way to evaluate your strategy[END_REF] and strategic management texts (Elliott et.al., 2001). Primarily utilised to inform the strategy when an organisation wishes to undertake change (Mersha, 1997;[START_REF] Thomas | Force Field analysis: a new way to evaluate your strategy[END_REF], it is used to identify and evaluate the forces at work (Thakkar et.al., 2006;[START_REF] Schwering | Focusing leadership through Force Field analysis: new variations on a venerable planning tool[END_REF]; where a force refers to any factor that has the potential to impact on an organisation, capable of changing its state [START_REF] Schwering | Focusing leadership through Force Field analysis: new variations on a venerable planning tool[END_REF]. Working on the premise that an organisation is in a state of balance [START_REF] Londeix | Deploying realistic estimation (field situation analysis)[END_REF] or, as illustrated in, "quasi-stationary equilibrium between driving (promoting) forces and restraining (hindering) forces" [START_REF] Oliver | A journey from bureaucracy to enterprise[END_REF], the technique is used to assess how great an affect the forces will have on the change process. The forces that resist change attempt to maintain the status quo [START_REF] Salaheldin | TQM implementation: the implementation of TQM strategy in Egypt: a force field analysis[END_REF][START_REF] Thomas | Force Field analysis: a new way to evaluate your strategy[END_REF], but change cannot be enacted without creating this temporary imbalance in the equilibrium (Mersha, 1997).

Strengths of this technique are its ability to create an overall picture of the situation, identifying assets as well as inhibitors (Thakkar et.al., 2006); it clearly identifies all variables, which allows for an objective evaluation of all aspects of the [START_REF] Thomas | Force Field analysis: a new way to evaluate your strategy[END_REF]. Such an approach offers the potential to 'unearth fresh options' [START_REF] Jones | Putting creativity on the map[END_REF] and not only provides a list of forces for and against, but also can identify individuals and groups that will affect, or be affected by the change, including those not part of the subsystem directly related to the change [START_REF] Thomas | Force Field analysis: a new way to evaluate your strategy[END_REF]. Using this technique allows the perception of forces to be quantified in a formalised way, which gives rigour to the decision making process making it transparent and explainable [START_REF] Swinton | s Force Field analysis: decision making made easy. Management for the Rest of Us[END_REF]. There are though, identified criticisms of the technique, based primarily on its ability to withstand bias. It can be affected by the experience, personality and style of the analyst [START_REF] Schwering | Focusing leadership through Force Field analysis: new variations on a venerable planning tool[END_REF]. However, this individual bias can be mitigated by performing the technique in a group [START_REF] Thomas | Force Field analysis: a new way to evaluate your strategy[END_REF], often in a brainstorming activity [START_REF] Jones | Putting creativity on the map[END_REF].

The process is carried out in a series of steps which begin with identifying the current position of the organisation and the required position after a change would take place [START_REF] Dezieck | Planning for change: the Force Field tool[END_REF]; this information is then used to analyse the forces at play.

Step 1: identify the driving and restraining forces that may affect the change, taking care to look at all aspects including "intangible or emotional factors" [START_REF] Oliver | A journey from bureaucracy to enterprise[END_REF].

Step 2: score each force based on its level of effect, using a rating scale, for example: 1 (weak) to 5 (strong), taking account of their limitations and constraints (Thakkar et.al., 2006). Create a Force Field diagram to depict the forces [START_REF] Schwering | Focusing leadership through Force Field analysis: new variations on a venerable planning tool[END_REF] on either side of a central divide [START_REF] Dhillon | Creativity for engineers[END_REF], assigning representatively sized arrows to driving and restraining in opposing directions [START_REF] Londeix | Deploying realistic estimation (field situation analysis)[END_REF][START_REF] Oliver | A journey from bureaucracy to enterprise[END_REF][START_REF] Swinton | s Force Field analysis: decision making made easy. Management for the Rest of Us[END_REF]Mersha, 1997;[START_REF] Thomas | Force Field analysis: a new way to evaluate your strategy[END_REF].

Step 3: total the forces driving and restraining the change to assess the potential success of the planned implementation.

This gives a picture of the current balance and offers the potential to drive the process forward by addressing and prioritising the forces working for and against the change. Where the restraining forces outweigh the drivers making change difficult, the forces should be examined to find ways to lessen their effect.

During this study factors that influenced the innovation programmes at the case study organisations became clear, from the observations and interviews carried out. Analysis was carried out in brainstorming sessions of involved researchers and results were assessed using the Force Field Analysis technique to gauge the current situation and the potential for success of the enterprise. Scored arrows were allocated based on the frequency issues were raised and the importance that the respondents placed on that factor.

Results

Case 1 explored an organisation implementing a new advanced manufacturing technology (AMT); known as Rapid manufacturing (RM). An undertaking such as this has been shown in the past to create significant disruption within an organisation and on its individual workers, meaning they must be on-board with the decision to innovate the production process. The implementation had been under way for some time at the point of study but with limited success, making progress slow. Results are shown in Figure 1. As the diagram shows, the barriers significantly outweigh the enablers, going some way to explain the lack of progress. It also illustrates just how much of the innovation depends on the attitudes of the individuals involved. In this case, however, the immaturity of the technology must also be seen as a major obstacle to exploitation.

For the organisation in Case 2, the innovation being considered was based on incremental improvements to the working practices, processes and production facilities; having previously undergone a lengthy period of business improvement to achieve Lean working conditions. In order to be successful, the program relied on the ideas of staff working in the areas of improvement, requiring them to be creative and challenge accepted practices. The results of Case 2 are shown in Figure 2.

[insert Figure 2 about here]

It can be deduced from Figure 2, that the innovation initiative has shown a degree of success, with the support for the process outweighing the resistance. However, in order to optimise the full potential there are still many areas for the organisation to address.

Barriers and enablers

Assessing the forces that exist within the two innovation initiatives, it can be seen that there are three types of forces: those that could be generally associated with innovation programmes; ones that are innovation specific; and others that relate directly to the individual organisation and are therefore path dependant.

Comparing the generic forces, it can be seen that there are some that make a significant impact on the success of the venture. It is important that the programme of innovation fits with the existing direction and objectives of the organisation. This can be seen as less aligned in Case 1 than in Case 2, as in recent years the majority of production has been outsourced, thereby building a network of external suppliers rather than increasing capabilities in-house, as would be the expected situation with radical technology implementation. Case 2 has undertaken major reorganisation in order to create a Lean working environment and as such a programme of incremental innovation fits perfectly as an ongoing direction. Strategy is an important factor and for Case 1 the innovation implementation was not planned in advance as an innovation programme. Rather, it was allowed to evolve; resulting in a lack of direction and slow, sporadic progress.

In direct contrast, the programme at Case 2 was carefully considered and planned and has shown a far greater level of success to date. This is also connected to the level of top management support shown, with Case 2 management being firmly committed to a predetermined effort rather than the unstructured, somewhat experimental approach of Case 1. In addition to this support, the nomination of change champions has had an impact on both programmes, a step more usually associated with radical innovation. Proving a significant ally in Case 1, the effects of the change champion may have actually been more fruitful in Case 2, as the individuals not only serve to influence others but in an incremental innovation programme, can begin to make initial changes that can show real results. Organisational philosophy plays a big part in the innovation process, especially in long established firms with deeply embedded routines. It also affects individuals who become invested in the status quo and, if not sufficiently convinced of its merits, can see potential innovation as change for change's sake. This is the situation at both of the organisations. At Case 1, where not all individuals can see the point of replacing equipment and processes that work perfectly well in their eyes with a new, unknown system. At Case 2 a similar, if less pronounced situation exists. Having gone through a widespread Lean Manufacturing initiative, some think the processes have already been improved and do not set out to innovate further. In both cases, this situation also links to a phenomenon that can be experienced in any type of change, especially in long established firms with little staff turnover; the legacy of initiatives past.

Both the radical and incremental programmes have come after many past innovations -some successful, some not -which causes individuals to view any new initiative with scepticism. It taints their perception and puts up barriers that have no relation to the current programme and are therefore, difficult to address. In order to counteract this, widespread acceptance of the initiative being pursued is needed. Efforts to create this level of acceptance at Case 1 have included internal 'road-show' events where key members of staff have gained access to information provided by experts in the field. Case 2 has harnessed Visual Management techniques to highlight successes in order to win-over those who are negative or disinterested. It must be recognised that, from both a technical and human resource perspective, that any new innovation initiative will take time to develop and this time must be allocated by management before measures of success are taken.

One issue that affects both the radical and incremental change is the observed changes to the job roles and the level of tasks within them. The forces termed 'blurring of job roles' and 'lack of empowerment' are connected, as one leads to the other. Perhaps by not anticipating the changes to job roles, those in authority have not allowed employees in lower level positions to become empowered to take the lead and, in some ways, to take on tasks from those above. These higher level individuals also feel the change and resist the loss of what they perceive as part of their role, which was previously above those now taking on the tasks.

For radical technology innovation there are several forces that come directly from the nature of the innovation, its potential benefits and the knowledge needed to optimise it. Advantages that come from the technology, helping to drive it forward, include the flexibility of the technology that allows for many different parts to be processed simultaneously without tooling, and leads to the potential for customisation of goods. In-house manufacturing allows for a much shortened supply chain and removes issues of confidentiality that may exist when utilising external suppliers. RM is currently immature when compared to established processing techniques and this brings with it many problems. Not only does it lead to unrepeatability and therefore unreliability, but to resolve these issues requires a level of knowledge that does not currently exist within the organisation and industry as a whole, thus holding back the technology and not just on an individual organisational basis.

The incremental innovation programme at Case 2 has brought about forces that come from the organisation itself, its culture and approach. As a well established firm with low staff turnover and high years of service, staff have become invested in the organisation and care that it is working at its best, both for their pride in the organisation and job security. There is a tremendous feeling of loyalty which is amplified by the work the union representatives do with management to ensure success and a good working environment. One element of the strategy that is proving 10 successful is the provision in the working week for idea generation, an idea not common in Lean organisations, with a designated meeting time every week. This shows staff just how important management see the initiative and gives them a forum to put forward their innovations in a supported way. However, in the past, poor communication of the response of management to innovative suggestions has led to individuals becoming disillusioned and, where credit has not been correctly attributed, some have felt aggrieved. The issue of reward has also been discussed, with some feeling the current system inadequate or inappropriate when related to effort; this must be addressed.

Radical v incremental innovation

It can be seen that many of the same forces exist in both the radical and incremental innovation programmes. Potential explanation for this relates to the size of the organisation and the ambition of the programme. As both are large and the programmes affect many staff in areas not always directly related to manufacturing, the effects of the initiative are widespread and amplified by the number of staff involved. This is not unexpected with radical innovation as it is anticipated that this will cause technology, knowledge and job roles to change. However, it is less obvious that these effects would be as widespread with incremental change. In light of the similarities experienced, it is thought that a similar management approach would be needed, contrary to suggestions in the literature. Although it can be seen that the management at Case 2 have approached the innovation with much more understanding of what will be required and what can be achieved than Case 1, who appear to have underestimated the extent to which a radical innovation can affect their organisation. In these cases it could be considered that Case 1, as a radical change in a fairly limited context, was a deep change that concentrated a narrow focus on the business, whereas Case 2, was seeking incremental change in a way that affected the whole business and so was a shallow change that had a wide effect on all of the plant, perhaps explaining why many similarities were found.

It has been said that incremental innovations tend to show more successes than radical; which at a similar stage in the two programmes has been shown to be the case. This may, however, be due to the nature of incremental innovation being broken down into stages, each of which in itself can be a success. Whereas, in order for radical innovation to achieve success, all of its elements must come together, meaning that reaching a specific stage in development does not ensure that the overall initiative will not eventually fail.

Organisational culture

Extant theory has shown that organisational culture affects the potential for innovation in organisations [START_REF] Amabile | Assessing the work environment for creativity[END_REF] and that has been seen to be the situation in these cases. Case 1 is a highly bureaucratic structure where staff know their roles and the tasks involved within them, leading to a situation where challenging the status quo has great affect on the individual, leading to resistance. The routines and work practices that are embedded are firmly set and hard to change, especially without the necessary support and influence of committed management. Case 2 has been seen to be a procedural organisation, but one that is open to change, especially having undergone a fundamental program to achieve Lean status. The overall environment is populated by staff who value their job and the role they have in Supportive management with a positive industrial relations climate creates an atmosphere that fosters innovation and aims to make every individual feel involved and valued. Although both organisations have seen a level of success, which in part is limited by the type of innovation, it is felt that the differences in organisational culture and attitudes play a significant part. [START_REF] Coombs | Knowledge management practices' and path dependency[END_REF] believe that the process of implementing an innovation is firm specific and as such path dependant. This has been shown to the case in each of the case companies of this study, as the trajectory has been different based on the initial conditions found within the organisations. Path dependency, in its most traditional form, relies on the assumption that small, somewhat insignificant events lead to the large consequences, which shape the direction of an organisation [START_REF] Schwartz | Down the wrong path: path dependence, increasing returns, and historical institutionalism[END_REF]. Others, such as [START_REF] Deeg | Institutional change and the uses and limits of path dependency: the case of German finance[END_REF] and [START_REF] Liebowitz | Path Dependence, Lock-In, and History[END_REF], accept that larger events and purposeful decisions also cause path dependent results and constrain future choices (Teece, et.al, 1997), which is a major constraint on companies' dynamic capabilities. For the case companies this is more likely the situation as, rather than the result of chance, many of the current conditions have come from decisions taken in the past. Case 1 is a long established company that has made its reputation on providing not only luxury but personalisation of their products. The technology is used primarily to tap into the market for customisation and the decision to focus on this marketing strategy makes it an appropriate technology. Other past decisions, such as the choice to outsource the majority of components and establish a tiered supplier network, have set a situation that makes RM implementation more difficult than in other organisations. At Case 2, the culture of long service means that many have been at the organisation through previous failed change initiatives that have affected their perceptions of any potential venture, causing some to be sceptical and detach from the programme.

Path Dependency

One area that has proven to be path dependent at the companies is that of routines; the importance of these routines and the role they play in an organisation was noted by [START_REF] Coombs | Knowledge management practices' and path dependency[END_REF]. These established routines go on to inhibit change as they become ingrained and become the norm after what potentially could be years of optimisation to the current situation [START_REF] Andreua | Organisational learning and core capabilities development: the role of IT[END_REF]. This has been shown to be true at the case organisations, especially Case 1, a highly procedural company, which in itself inhibits change and where even the most basic of updates must go through a formal process that takes weeks and so deters engineers from making changes in all but necessary situations. Engineers and designers have become accustomed to using techniques and materials that they know will work in a certain situation, rather than expanding their options to include new possibilities that may, in fact, meet their needs better. Routines of this kind actually form a barrier to the potential benefits of the innovations being implemented. Case 2, although procedural, has learned through previous initiatives to adapt to change and challenge procedures and set-ups that are not optimal, supported by a union established long ago; these past decisions and events actually aid in the innovation process. However, the formalised structure established at both organisations inhibits change, as staff see their roles as clearly defined and the changes begin to blur those roles, often without sufficient empowerment for them to embrace the added levels of responsibility. The process of radical innovation at Case 1, when compared to the conditions set out in the theory is undoubtedly path dependant, with many factors that are company specific working against the acceptance of the technology. Case 2 is less pronounced, but still subject to path dependant issues in many parts of the incremental innovation process.

Conclusions

This paper provides a contribution to extant literature on the barriers and enablers of innovation at different levels, highlighting the similarities and differences that exist and the effects of company size. It shows that initial perceptions of the terms radical and incremental may not be sufficient to determine the level and types of resistance that may be encountered.

Supporting the work of [START_REF] Coombs | Knowledge management practices' and path dependency[END_REF], findings show that much of the implementations have been firm specific; however, there were also generic barriers found that could affect any implementation. The barriers identified within the two case study organisations can be split into; 1) those common to both and therefore may have the potential to affect many organisations; 2) innovation specific forces, that occur as a direct result of the innovation being undertaken, especially prevalent with new technology; and 3) those that are organisation specific, derived from the individual situation and set-up that the organisation is in when it begins the innovation initiative. These organisation specific forces are highly path dependant, based on past events and decisions made, as suggested in the work of [START_REF] Liebowitz | Path Dependence, Lock-In, and History[END_REF] and [START_REF] David | Clio and the Economics of QWERTY[END_REF], who recognised the effects history has on an organisation and its characteristics.

Measuring the success and failure of innovation is difficult (Armbruster et.al 2008), especially when comparing radical and incremental programmes. For a radical innovation to be a success, it is essential that all stages are achieved, whereas for incremental innovation every step is a success in itself, which may explain why [START_REF] Morton | Understanding and overcoming resistance to innovation[END_REF] found that incremental innovations are more often successful. Culture also plays a huge part in innovation, as human factors are vital in achieving success [START_REF] King | Innovation at work: the research literature[END_REF]Kratzer et.al., 2005). It has been shown that the more open and supportive an organisation is to innovation and change in general, the greater it's potential for success; in line with the findings of Amabile et.al. (1996) and Zarrage and Bonache (2005). Results also show that those experiencing deeply entrenched routines and attitudes struggle to overcome them and encourage the level of involvement needed, corroborating the outcome of studies from [START_REF] Dougherty | Product innovation in mature firms[END_REF][START_REF] Dougherty | Product innovation in mature firms[END_REF]Liefer et.al. (2000).

Finally, as [START_REF] Garcia | A critical look at technological innovation typology and innovativeness terminology: a literature review[END_REF] and [START_REF] Oke | Innovation types and innovation management practices in service companies[END_REF] highlight, it is essential that an organisation understands the type of innovation it is embarking upon and what that potentially may involve, in order that it can plan and manage the initiative successfully. It is possible, however, that the steps involved and management style needed may not actually vary as much between the levels of innovation as would be expected, especially in large firms undertaking company-wide programmes, which forms a significant finding of this work.

Limitations and further work

Case study research has distinct advantages in the depth of knowledge that can be gained on a specific issue within an organisation; however, the findings are case specific. Although these findings have been discussed across the cases and certain commonalities found, it does not allow for automatic generalisation across the types of organisation or industries studied. This can only really be assessed with further comparison studies of organisations undertaking innovation at different levels and would benefit from the inclusion of those working at the mid levels of architectural and modular innovations.

  , therefore, gives rise to potential barriers to success

  categorised innovations into structural -those which change responsibilities, information flow, hierarchical levels

  successful; they see improving things as part of the norm.

Figure 1 .Figure 2 .Page

 12 Figure 1. Force Field Analysis diagram of the innovation process at Case 1

  also found lacking in extant literature; and which forms an

http://mc.manuscriptcentral.com/tprs Email: ijpr@lboro.ac.ukInternational Journal of Production Research

Acknowledgements

The support of the Engineering and Physical Sciences Research Council under grant EP/C534239/1 and the Economic and Social Research Council under grant RES331270005 for this work is gratefully acknowledged.


Chouki Tibermacine
email: chouki.tibermacine@lirmm.fr

Mohamed Lamine Kerdoudi
email: lamine.kerdoudi@gmail.com

Migration d'applications à base de composants Web en services et orchestration de services Web

Le développement à base de composants Web permet de construire des applications distribuées, par assemblage de composants existants obtenus à partir de librairies de composants libres ou COTS (Commercial Off-The-Shelf). Par ailleurs, la technologie des services Web s'est affirmée comme une des solutions les plus pertinentes pour les fournisseurs de services, comme eBay, Amazon ou FedEx, pour ouvrir leurs solutions aux développeurs tiers. Dans ce papier, nous présentons une approche pour construire des architectures orientées services Web à partir des applications à base de composants Web et les déployer sur un serveur supportant les services Web. Nous avons implémenté notre solution en utilisant une collection de technologies Java. Des composants Java EE sont les entrées de l'implémentation proposée, et un ensemble de services Web Java, des chorégraphies et des orchestrations de ces services sont fournis en sortie.

Introduction : contexte et motivations

Le développement à base de composants Web vise à découpler une application Web en modules et les rendre des entités logiciels réutilisables et personnalisables. En effet, une étape importante a été franchie vers cette modularisation dans le domaine des applications Web. Celle-ci a permis notamment de séparer la présentation (la vue), des données (le modèle) et des traitements (le contrôleur) dans l'application. Une des technologies leaders dans ce domaine est Java EE 1 et ses nombreux Frameworks comme Struts et JSF. Les composants Web dans ces technologies sont des entités qui peuvent être utilisés et réutilisés dans différentes applications et personnalisés en fonction des besoins des utilisateurs. Ces technologies se sont affirmées ces dernières années comme des solutions idéales pour le développement des applications complexes avec de fortes exigences en termes de maintenabilité. Une fois les composants, implémentant ces applications, sont déployés sur un serveur d'applications, il n'existe pas de moyen pour publier directement les services fournis par ces applications pour un développement par de tierces parties. Un développeur tiers ne pourra pas exploiter directement les services métier fournis par ces composants pour développer, à distance, des extensions à ceux-ci. Même, si des « souches » (stubs) peuvent être générées et fournies pour les applications clientes, ces souches sont dépendantes d'un langage de programmation particulier (seuls les clients Java peuvent utiliser les souches générées pour les composants EJB) et ne peuvent pas être publiés dans des librairies de services.

Par ailleurs, depuis des années, la technologie des services Web s'est affirmée comme l'une des solutions les plus pertinentes pour les fournisseurs de services, comme eBay (enchères), Amazon (commerce électronique) ou FedEx (logistique), pour ouvrir leurs solutions aux développeurs tierces. Les services Web sont des fonctionnalités basées sur des standards qui sont indépendants d'un "langage de programmation" ou d'une "plate-forme d'exécution", comme WSDL (Web Service Description Language) ou SOAP. De nouvelles applications avec des clients légers ou lourds peuvent être construites pour accéder à ces fonctionnalités. Il suffit de formuler dans ces applications clientes des requêtes, qui intègrent des messages (SOAP) basées sur XML, et de les transmettre au fournisseur de services Web. Des messages du même type sont renvoyés à ces applications, contenants les résultats (réponse à la requête). Sur la base de ces résultats, plusieurs actions peuvent être effectuées par ces nouvelles applications pour implémenter une nouvelle logique métier. De cette façon, les fournisseurs de services Web, qui détiennent des ressources précieuses (comme les grandes bases de données de produits d'Amazon, ou des prévisions météorologiques de Météo France) offrent aux développeurs tierces la possibilité de construire des nouvelles applications par l'extension de ces services publics, et ainsi, capitaliser ces ressources.

Dans ce papier, nous présentons une approche (section 3) pour construire des architectures orientées services à partir des applications à base composants Web et de les déployer sur un serveur avec un support aux services Web. De cette façon, les développeurs des composants Web offrent aux autres développeurs la possibilité de construire des extensions de services offerts par leurs artefacts. Cette transformation passe par plusieurs étapes. Premièrement, une analyse des différents éléments, qui constituent les composants Web, est réalisée pour extraire l'ensemble de services Web potentiels. Ensuite, les messages d'entrée et de sortie liés à chaque service Web sont définis à partir des éléments analysés. Cette étape est suivie par un filtrage des opérations non pertinentes dans les services Web. Celles-ci sont éliminées sur la base d'un ensemble de contraintes de filtrage et avec l'intervention du développeur. Dans l'étape suivante, les dépendances entre les différents services Web sélectionnés sont identifiées, et utilisées pour construire des services Web composites. Finalement, l'ensemble de services Web validés (les primitifs et les composites) est déployé sur un serveur d'application, et publié sur le moteur de recherche Seekda2 .

Nous avons implémenté notre solution avec une collection de technologies Java. Les composants Java EE sont les artefacts d'entrées de l'implémentation proposée, et un ensemble de services Web Java et des orchestrations/chorégraphies de ces services sont fournis en sortie. Avant de conclure et présenter les perspectives de ce travail à la fin de ce papier, nous faisons un résumé des travaux connexes.

Dans la prochaine section, nous présentons un exemple simple d'un composant Web qui est utilisé dans le reste du papier pour illustrer nos propositions. envoyer un e-mail avec une liste détaillée de directives diététiques. Supposant maintenant, un développeur tiers qui souhaite étendre les services fournis par le composant présenté ci-dessus. Ce développeur souhaite apporter une solution pour vendre des produits et des recettes diététiques. Il cherche à utiliser la sortie obtenue à partir du -./6 *&*0123.4+, pour faire la publicité de ses produits avant d'envoyer l'e-mail à l'utilisateur. Pour implémenter cette solution, le tiers développeur doit soit : i) redévelopper la logique métier implémentée dans les composants Web présentés ci-dessus, ii) demander aux fournisseurs de ces composants les binaires (ou les packages source de ces composants) de l'application et les déployer sur le même espace de nom de sa solution, iii) ou demander un accès distant à ces composants. Ces scénarios rendent difficile l'accès aux composants Web pour les raisons suivantes :

Exemple Illustratif

Flexibilité. Les développeurs originaux doivent publier les composants dans un serveur de noms. Les Stubs pour donner l'accès à distance à ces services doivent aussi être générés et fournis aux développeurs tiers. Cela rend cette solution encombrante, surtout pour un déve-loppement intensif par les tiers, dans le cadre d'un écosystème logiciel, par exemple. Le développement d'extensions à un système logiciel doit être ouvert aux développeurs tiers avec un minimum d'efforts.

Portabilité. Les développeurs tiers sont contraints d'utiliser le même langage d'implémentation que les composants originaux. Nous soutenons l'idée que le développement doit être ouvert aux développeurs tiers utilisant différentes technologies.

Cohérence. Supposons ici que les développeurs tiers déploient des instances de composants Web sur leurs machines. Cette solution encombrante oblige ces développeurs à installer et lancer un serveur d'application et un serveur de base de données. Cette solution peut introduire de nombreuses incohérences dans les données utilisées par ces composants. En effet, si de nouveaux standards et directives diététiques apparaissent, les différentes bases de données (utilisées par les instances originales et les nouvelles instances des composants Web) doivent être mises à jour et synchronisées.

Une solution intéressante pour ouvrir ce type de développement aux tierces parties est de transformer l'ancienne l'application en services Web qui sont décrits ci-dessous :

-DietaryAdvising7: un service Web composé de deux opérations :

-calculateBMI7retourne une valeur réelle qui représente l'IMC.

-getBMI_Category retourne la catégorie de l'IMC : sous-poids, normal, surpoids ou obésité.7 -provideSummaryDG retourne un résumé des directives diététiques.

-MailSending : un service Web avec une seule opération pour l'envoi d'un e-mail. Ces services Web sont présentés en détail à travers le processus de transformation et de génération de services Web de la section suivante. Le scénario d'extension de l'application discuté précédemment peut facilement être implémenté par l'invocation des opérations des services Web listées ci-dessus. Cette extension de l'application "HealthyDiet" peut être construite comme un processus métier (orchestration) basé sur ces services (voir les détails dans la section 3.4.2).

Approche proposée

Comme indiqué dans l'introduction, la transformation des composants Web en des services Web est un processus en cinq étapes illustré dans la Figure 2. Ce processus a été initialement introduit dans [START_REF] Tibermacine | From Web Components to Web Services: Opening Development for Third Parties[END_REF]. Dans ce papier, le processus est mieux détaillé et illustré par des exemples.

Extraction des opérations

Premièrement, une analyse récursive des différents éléments du composant Web est effectuée pour extraire l'ensemble des services Web potentiels. Toutes les opérations dans les classes et les autres éléments de code structuré sont capturées. Par ailleurs, le code présent dans les programmes côté serveur (les pages JSP, par exemple) est formaté en une seule opération. Dans la sous-section suivante, nous expliquons comment ce formatage est réalisé.

Les opérations similaires sont réparties dans différents services Web. Cela assure un certain niveau de fiabilité et d'exactitude fonctionnelle dans les services Web publiés. D'un côté, si un service Web n'assure pas correctement un besoin qualité (comme la disponibilité ou les performances) pour les utilisateurs d'une opération d'un service, un autre service contenant une opération similaire peut être trouvé chez le même fournisseur (fiabilité). D'un autre côté (et dans une perspective d'exactitude fonctionnelle dans la description du service Web), un service ne devrait pas fournir deux ou plusieurs opérations similaires.

FIG. 2 -Le Processus de Transformation.

Les opérations similaires sont identifiées en utilisant certaines mesures de similarité. Dans l'implémentation actuelle, une solution basée sur les signatures des opérations a été mise en place. Elle compare le type de retour et les paramètres. Des techniques plus évoluées basées sur nos précédents travaux [START_REF] Falleri | Automatic tag identification in web service descriptions[END_REF]) qui s'appuient sur l'extraction des mots clés à partir de la documentation et des signatures de services, et leurs synonymes vont être intégrées dans un futur proche.

Identification des messages d'entrée et de sortie

Les messages d'entrée et de sortie liés à chaque opération dans les services Web sont identifiés à partir des éléments analysés dans le composant Web. Pour les classes et d'autres éléments de code structuré, les paramètres et la valeur retournée sont formatés en messages SOAP. Le code présent dans les autres programmes (comme les pages JSP) est analysé pour extraire les valeurs d'entrée reçues dans les requêtes HTTP. Leurs types sont déduits à partir du code analysé par l'analyse statique des instructions de conversion de types.

Par exemple, dans le composant BMI_Calculator de la section précédente, deux messages sont définis à partir des instructions request.getParameter(…) dans le fichier JSP. Ils correspondent à la taille et le poids. Au départ, ces entrées sont définies comme des variables de type chaine de caractères. Mais, après une analyse du code JSP (Java) qui extrait ces va-leurs, on déduit que le type final est le type float (réel). La valeur retournée est le résultat calculé par une méthode JavaBean liée à l'interface Web. Celle-ci est utilisée pour créer un message SOAP de type float (réel).

Filtrage des opérations

Dans cette étape, les opérations non-pertinentes des services Web sont éliminées de l'ensemble de départ selon une collection de contraintes de filtrage. Ces contraintes sont des expressions booléennes représentées par des expressions OCL 4 (OMG 2006), qui peuvent être ajoutées, modifiées ou supprimées par le développeur. Les expressions OCL sont limitées aux invariants. Elles naviguent dans un méta-modèle d'opérations (inspiré du métamodèle UML2). OCL a été choisi en raison de sa simplicité [START_REF] Briand | An experimental investigation of formality in uml-based development[END_REF]) et de l'existence d'outils efficaces qui le supportent (OCL Toolkit [START_REF] Dresden | Ocl compiler web site[END_REF]) ou Eclipse MDT/OCL (Eclipse Foundation, 2009)).

Voici un exemple de contrainte de filtrage : les opérations qui utilisent une variable standard de session ne sont pas prises en compte. Celle-ci est formalisé comme suit : not (self.body.usedType ->includes(t | t.name='HTTPSession')) Enfin, le développeur est sollicité pour choisir parmi les opérations sélectionnées celles qui ne sont pas conceptuellement utiles en tant que parties de services Web publiés.

Création de services Web composites

Dans cette étape, les dépendances entre les différentes opérations sélectionnées dans les services Web sont identifiées. Il existe deux types de dépendances entre les opérations : des dépendances sous la forme d'appels d'opérations (qui donnent lieu à une chorégraphie de services Web) et des relations de navigation Web (qui permettent de générer des orchestrations de services Web). Celles-ci sont détaillées ci-dessous :

Création de chorégraphies de services Web

Tous les appels d'opérations dans le code sont capturés. Si les opérations appelées sont publiées dans le même service Web que l'opération appelante, rien n'est fait, les appels sont laissés comme des invocations de méthode. Si les opérations appelées sont dans d'autres services Web publiés, nous vérifions si ces services sont déployés sur un serveur distant ou sur le même serveur, et s'ils s'exécutent dans la même machine virtuelle que le service appelant. Si les services sont déployés dans le même contexte d'exécution, les invocations de méthode sont laissées telles qu'elles. Sinon, ces dépendances d'opérations sont remplacées par des requêtes de services Web.

De cette façon, nous construisons des services Web composites comme des chorégraphies au niveau du code. Nous envisageons dans un futur proche de générer des spécifications de haut niveau de chorégraphies avec des langages conformes au «WS-CDL » (W3C 2005). Ces spécifications devront jouer un rôle important dans la maintenance/évolution des chorégraphies générées. Toute modification appliquée sur les collaborations de services Web devient plus simple, parce que nous aurions des spécifications à un haut niveau d'abstraction (par opposition aux chorégraphies au niveau du code).

Dans l'exemple précédent (section 2), l'opération calculateBMI() appelle d'autres opérations pour effectuer les calculs arithmétiques. Ces opérations (power(n,m), division(x, y), conversion du poids et de taille) sont extraites et assemblées dans deux différents services Web : calculationWS and conversionWS. L'opération calculateBMI commence premièrement par, l'invocation de l'opération de conversion du poids (conversionWS) pour transformer les grammes en kilogrammes. Cela est fait à travers l'appel à l'opération de division (calculationWS). Ensuite, les centimètres sont transformés en mètres en utilisant l'opération de conversion de taille, qui est basée sur la même opération de calcul. Enfin, les opérations power(…) et division(…) sont appelées pour obtenir la valeur finale de l'IMC. Il s'agit d'un exemple simple d'une chorégraphie créée à partir du composant Web BMI_Calculator.

Création d'orchestration de services Web

Dans cette étape, les documents de navigation tels que les fichiers faces-config de composants JSF sont analysés. Cela permet l'identification des différentes relations entre les pages Web, et donc la spécification des collaborations potentielles des différents services Web extraits de ces pages. Cette tâche est implémentée selon l'algorithme suivant :

(01) algorithm WebNavigationParsing { (02) let process := ProcessFactory.createProcess(); ( 03 25) } (26) } Dans cet algorithme, nous commençons par la création d'un processus, et pour chaque règle dans le document de navigation définie dans le composant Web analysé, nous identi-fions l'opération source (ligne 04). L'opération source correspond à l'opération qui a été générée à partir de la page Web spécifiée dans la source de navigation. La même tâche est effectuée pour la page Web destination (ligne 19).

Une règle de navigation contient trois éléments : i) la vue source, qui représente la page(s) Web à partir de laquelle la navigation commence (la page qui représente le formulaire pour calculer l'IMC dans l'exemple présenté précédemment : bmi.jsp) ; ii) la vue destination, qui correspond à la page vers laquelle l'utilisateur sera dirigé automatiquement (la page Web qui présente l'interface du composant Web DietaryAdvising : diet.jsp); et iii) une condition d'exécution, qui contient une expression et une valeur (l'expression correspond à un appel à l'opération du JavaBean pour obtenir la catégorie de l'IMC dans le composant Web : #{diet.getBMICategory}, et la valeur est "obésité").

Pour chaque règle de navigation, nous testons premièrement, si cette opération est déjà appelée dans le processus durant l'analyse d'une autre règle de navigation (ligne 05). Cela assure que les invocations d'opérations ne sont pas dupliquées. Dans le cas d'une opération qui a été invoquée dans le processus, on récupère seulement la valeur retournée par cette invocation. Ce type de valeurs est stocké après chaque invocation d'opération (lignes 09 et 23). Ensuite, nous comparons la valeur obtenue par l'appel à l'opération définie dans l'expression de la condition et la valeur de cette condition (lignes 16 et 17). Si les deux valeurs sont égales, on invoque alors l'opération destination correspondante (lignes 19 à 22).

Dans l'exemple de la section 2, nous générons un processus BPEL (Business Process Execution Language). Dans la description de ce processus, nous invoquons premièrement l'opération calculateBMI du premier service. Ensuite, nous stockons le résultat dans une variable et invoquons la deuxième opération dans le même service pour obtenir la catégorie IMC, en utilisant le contenu de la variable comme message d'entrée. Si la valeur retournée, qui a été stockée dans la deuxième variable, est différente de "Taille normale" (c'est à dire, elle est égale aux trois autres catégories d'IMC), la troisième opération est invoquée, en utilisant la catégorie IMC stockée et d'autres informations (habitudes diététiques et troubles alimentaires) pour obtenir les directives diététiques correspondantes. Enfin, nous invoquons l'opération SendMail avec les données nécessaires.

A la fin de cette étape, le processus BPEL est exporté comme un service Web. Il est associé aux autres services primitifs pour le déploiement.

Déploiement et indexation de services Web

L'ensemble validé de services Web (les composites et primitifs) sont déployés sur un serveur d'application choisi par le développeur ou l'administrateur de l'application à base de composants Web. Si le développeur déploie les services Web sur des serveurs différents, les dépendances entre les opérations en collaboration dans les services composites sont résolues.

Pour l'indexation, la première tâche consiste à demander au développeur d'ouvrir une session ou s'inscrire pour un nouveau compte dans le moteur de recherche Seekda. Par la suite, l'intervention du développeur est requise pour entrer les URLs des services déployés sur le moteur de recherche Seekda via l'URL : https://webservices.seekda.com/add_url.jsp. Une fois les services indexés, nous proposons aux développeurs un mécanisme intelligent d'extraction de mots clés, basé sur nos précédents travaux [START_REF] Falleri | Automatic tag identification in web service descriptions[END_REF]. Ce mécanisme identifie des tags pour les services à partir de leur description WSDL. La liste de mots clés (basée sur les identificateurs dans les noms d'opérations de services, les noms de paramètres, ...) est proposée aux développeurs afin de tagger les services déployés.

Travaux connexes

Roger [START_REF] Lee | A framework for dynamically converting components to web services[END_REF] ont proposé une approche qui permet à un client de spécifier une requête pour rechercher une fonctionnalité donnée dans les composants déployés dans un serveur Web. En réponse, un service Web ou une composition de services Web est généré automatiquement. Comparativement à cette approche réactive, notre approche est plutôt proactive, elle ne réagit pas à une requête. Elle permet au développeur de l'application Web d'anticiper l'exportation de certaines fonctionnalités aux tierces parties.

Avec le système Wike [START_REF] Han | Wike: A web information/knowledge extraction system for web service generation[END_REF], les développeurs peuvent définir des patrons pour extraire des informations partielles à partir de pages Web. Ces patrons sont encapsulés dans des opérations qui peuvent être exportées comme des services Web. Cette solution intéressante n'aborde pas le même problème que dans notre travail. L'analyse de pages Web basées sur un contenu statique n'est pas notre principale préoccupation. Wike est considéré comme une solution complémentaire à notre travail.

Plusieurs travaux dans la littérature ont proposé des techniques dirigées par les modèles pour générer des applications orientées services. [START_REF] Bauer | Mda applied: From sequence diagrams to web service choreography[END_REF] ont définis une approche pour faire des transformations d'éléments de diagrammes de séquence UML2 (considérés comme des PIMs -Platform Independent Models) en compositions de services Web en BPEL (considérés comme des PSMs -Platform Specific Models). Dans [START_REF] Yu | Towards a model driven approach to automatic bpel generation[END_REF] les auteurs ont proposé des règles de transformation pour convertir des modèles d'orchestrations spécifiés en CCM (Component Collaboration Architecture), qui fait partie du profil UML pour EDOC (Enterprise Distributed Object Computing) [START_REF] Omg | Uml profile for enterprise distributed object computing (edoc)[END_REF], en spécifications BPEL. Une autre approche dirigée par les modèles pour la création des solutions orientées services a été proposée dans [START_REF] Johnson | A model-driven development approach to creating serviceoriented solutions[END_REF]. Dans ce travail, un profile UML a été défini pour la spécification des applications orientées services.

Tous ces travaux sont parfaitement complémentaires à notre approche. Notre transformation est effectuée de PSM à PSM. Les composants Web, qui sont des modèles spécifiques à une plateforme donnée (dans l'implémentation actuelle, JEE), sont convertis vers des services Web qui sont considérés comme d'autres modèles spécifiques à une plateforme (WSDL, Java et BPEL). Le profil UML présenté en [START_REF] Johnson | A model-driven development approach to creating serviceoriented solutions[END_REF] peut être utilisé pour définir des modèles de haut niveau des services Web générés.

Conclusion et perspectives

Dans ce papier nous avons présenté un processus de transformation des applications à base composants Web en applications orientées services Web. Nous avons implémenté le processus de transformation dans l'outil WSGen: Web Service Generator. Les composants Web sont considérés ici comme des artefacts logiciels intégrant le code de logique métier et exportant des interfaces Web. Ce type de modules est analysé par WSGen, les différents éléments qui le composent sont extraits pour identifier les différents services Web et les collaborations possibles entre ces services. Tous les services qui en résultent sont déployés sur le Web. Nous considérons ces services, générés et déployés, comme des APIs distantes. Elles offrent la possibilité aux développeurs tiers d'étendre les fonctionnalités offertes par ces services, et d'exploiter les ressources utilisées par eux.

Au niveau conceptuel, nous avons envisageons d'étudier la formalisation de la transformation en un ensemble de règles déclaratives de haut niveau. Nous définissons ensuite ces règles dans un langage déclaratif conforme au MOF/QVT (OMG, 2008) et intégrons ainsi notre solution dans un processus d'ingénierie dirigée par les modèles. Au niveau de l'outil, nous projetons de travailler sur la génération des spécifications de haut niveau des chorégraphies de services Web dans un langage de haut niveau conforme à « WS-CDL ».

FIG. 1 -

 1 FIG. 1 -Une architecture abstraite du composant Web "HealthyDiet". La Figure 1 montre une architecture abstraite d'un composant Web simple, qui est composé des trois sous-composants suivants : -Le composant !"#$%&'()'&*+, calcule l'IMC 3 à partir des valeurs entrées par l'utilisateur via l'interface Web. Ces valeurs sont la taille et le poids. -Le composant -./*&,0123.4+, demande à l'utilisateur d'entrer son âge et son titre de civilité (sexe), et de cocher certaines cases représentants les habitudes nutritionnelles et les troubles alimentaires de la personne (les faims de minuit, ...). Ce composant fournit un résumé des directives diététiques. -Le composant 5"&.'/, demande à l'utilisateur d'entrer son adresse e-mail pour luienvoyer un e-mail avec une liste détaillée de directives diététiques. Supposant maintenant, un développeur tiers qui souhaite étendre les services fournis par le composant présenté ci-dessus. Ce développeur souhaite apporter une solution pour vendre des produits et des recettes diététiques. Il cherche à utiliser la sortie obtenue à partir du -./6 *&*0123.4+, pour faire la publicité de ses produits avant d'envoyer l'e-mail à l'utilisateur. Pour implémenter cette solution, le tiers développeur doit soit : i) redévelopper la logique métier implémentée dans les composants Web présentés ci-dessus, ii) demander aux fournisseurs de ces composants les binaires (ou les packages source de ces composants) de l'application et les déployer sur le même espace de nom de sa solution, iii) ou demander un accès distant à ces composants. Ces scénarios rendent difficile l'accès aux composants Web pour les raisons suivantes :

Java Enterprise Edition de Sun Microsystems : http://java.sun.com/javaee/

Moteur de recherché de services Web Seekda : http://webservices.seekda.com/

Indice de Masse Corporelle ou BMI en anglais (Body Mass Index). IMC = poids (kg) / taille 2 (m 2 )

Summary

Web component based development allows developing distributed applications by assembling existing COTS (Commercial Off-The-Shelf) or free components. Besides this, since many years, Web services confirmed their status of the most pertinent solution for a given service provider, like Google, Amazon or FedEx, to open its solutions for third party developers. In this paper, we present an approach to build web service-oriented architectures starting from existing web component-based applications and deploy them on a web service provider. This transformation helps server-side web application developers in transforming their "user interface"-based web components into a set of web services, choreographies and orchestrations. We implemented our solution on a collection of Java EE-related technologies.