Jean-Michel Fournier

Nathalie Rossi-Gensane

La conversion en français et en anglais : de la synchronie à la diachronie

Introduction

« Dans le cas d'une paire comme (la) danse, (il) danse, où l'homonymie formelle coïncide avec l'identité de valeur, [...] tout se présente sous l'aspect d'un transfert de classe, sans que l'on puisse toujours dire, en français d'aujourd'hui, s'il s'agit d'un transfert de nom à verbe ou de verbe à nom. De telles paires sont très nombreuses. »1 « Dans une perspective purement synchronique, on ne peut pas savoir, sans recours à l'histoire, si un couple verbenom [en français] est obtenu [par conversion] à partir du nom ou du verbe. » 2 Peut-on, malgré tout, établir des corrélations entre faits synchroniques et faits diachroniques ?

A. Préalables et pistes de recherches 1. Préalables 1.1. Orientation de la conversion : N → V ? « noms déverbaux processifs » Kerleroux, 1996b. « a nominalization names an event taken as an entity; however a 'verbalization' does not name 'an entity taken as an event' but simply names an event associated with some entity ». Hopper et Thomson, 1984, 745 (cités par M. Paillard, 1996).

« la polarité verbo-nominale s'est édifiée sur une base fonctionnelle : très souvent, le prédicat [qui renvoie au procès] est un verbe et le non-prédicat un nom ; le verbe ne connaît pas d'autre fonction que prédicat alors que le nom est plurifonctionnel » C. Hagège, « La polarité verbo-nominale », La linguistique, Vol. 20, Fasc. 2/1984, p. 15

) rapport catégoriel entre N construit et base V N -> [[ X] V (Y) af ] N N -> [[ X] V ] N 3)

Caractéristiques syntaxiques :

Peu de verbes pronominaux…

Les noms

Caractéristiques morphologiques :

Deux sous-ensembles :

-les verbes associés à des noms de genre masculin, sans e, voler > le vol, et -les verbes associés à des noms de genre féminin, avec e, marcher > la marche.

Emprunts, relativement récents :

Crawl : emprunté à l'

Détermination caractéristique des noms apparus avant les verbes correspondants (verbes d'activité)

Gaston Gross (1989, 71) :

Jean

1.2. Perspective synchronique ? Le modèle Corbin/Kerleroux

  à 28.« phénoménalement et par fonction, les noms sont polysémiques ». P. Cadiot et F. Nemo, « Pour une sémiogenèse du nom », Langue Française n°113, 1997, p. 24.

	glisse(r) > glissade	~	danse(r) ? danse
	« un changement catégoriel accompagné d'une opération sémantique. […] Dans la mesure où les variations
	sémantiques qui apparaissent lors de la conversion sont analogues à celles qui apparaissent lors de la dérivation par
	affixation, mon hypothèse est que les conversions s'intègrent aux paradigmes d'opérations morphologiques associés
	aux règles de construction de mots ».
	D. Corbin, 1987.

J.-M. Fournier et N. Rossi-Gensane, Langues et Représentation, Université de Tours -CerLiCO 2002 Exemple de Règle de Construction de Mots (RCM) -cadre théorique de D. Corbin : Règle de construction des noms déverbaux à sens de nom d'action, définie par le triplet d'opérations suivantes : 1) opération sémantique N : <action et résultat de l'action de V> 2

Comportement phonologique synchronique et diachronie 2.1. Assimilation et ancienneté : le cas des préfixes in-et un-

	paradigme d'opérations morphologiques
	conversion [+ masc] (-disponible)	ex : vol
	conversion [+ fem] (+ disponible)	ex : voltige
	-ade	ex : promenade
	-age	ex : patinage
	-ment	ex : cheminement
	-tion	ex : déambulation
	suffixe participe passé (en tant que suffixe dérivationnel)	ex : arrivée
	etc.
	(D'après F. Kerleroux, 1996, p. 161-2 ; les exemples sont les nôtres, V renvoyant ici exclusivement à un verbe de déplacement)
	2. (1)	in-négatif :
				inlaw (1000), inlet (1300), inlay (1631), inleak (1909)…
				input (1382), inmate (1589), inpouring (1853)…
				cf. in adv., prep.
	(3)	un-négatif :	G. :	unborn (897), unbound (900), unbutton (1325), unban (1968)…
				unlike (1200), unlearn (1450), unlimb (1694), unliquidate (1818)…
				unmeet (900), unmade (1250), unmaltable (1778), unmelodic (1849)…
				unright (888), unrest (1340), unreadable (1802)…
	2.2

< L. : impatience, illiterate irregular… A. : imbalance (1898), immethodic (1858), impartial (1593), implacental (1839), illoyal (1626), irreciprocal (1886)… (2a) in-spatial : < L. : imbue, immerge, impel, illumine, irradiate… < F <L. : embark… A. : inbody → embody, inbox → embox, inbosom → embosom (tous 16 ème ) empower (1654), empacket (1825)… (2b) in-spatial : G. : inborn (1000), inbreathe (1382), inbred (1592), inbound (1894)…

. Réduction et ancienneté : les composés

	2.3
	(4)	window (Vieux-Norrois : vindauga → Moyen-Anglais : 1225)
	(5a)	forehead (1000), cupboard (1325), breakfast (1463), necklace (1590) -saucepan (1686)
	(5b)	handshake (1873)
	(6)	blackbird (1486) : blacke bride (1486) → blacke-bird (1616) → blackbird (1766)
	(7)	[-mn] : spearman (1297), postman (1529), swordsman (1680)
		chinaman (1772), railway man (1845) → railwayman (1906)
		infantryman (1883) [-mn, -maen], spaceman (1892) [-maen, -mn]
	« This suffix 3 may be weak or strong. (i) In most well-established formations, written as one word, it is weak, policeman […]. (ii) Where written hyphenated or as two words, and in new formations, it is usually strong, maen : mn :
	spaceman… »
	J. C. Wells, Pronunciation Dictionary, Longman, Harlow : 2000.

. Accentuation et conversion : les préfixés dissyllabiques N/V

	Verbes dissyllabiques préfixés :	/01/ Mot	ex. : retain, detain, arrive, derive… Date-N Date-V Date N-V
	Noms dissyllabiques, préfixés ou non :	/10/ offer	ex. : butcher, congress, insect, narrow… 1433 825 608
		prefix	1646		1538		108
	Dissyllabes préfixés pluricatégoriels N/V : → chacun la logique de sa catégorie : summon 1300 1205 95 retail 1433 1365 68	a "record ~ to re"cord
		→ logique verbale : revel 1350		1325		25	an ad" dress -to ad"dress
		→ logique nominale : profit 1315 combat 1567	1303 1564		12 3	a "combat -to " combat
		forfeit purchase	1300 1297		Mot 1300 1297		0 0	Date-N Date-V	Date N-V
		suffix	1778		design 1778		0	1588	1548	40
		incense	1290		constraint/ain 1303	-13	1374	1340	34
		trespass	1290		release 1303		-13	1330	1297	33
		promise	1400		despatch 1420		-20	1550	1517	33
		compass	1300		descent/d 1325		-25	1330	1300	30
		rescue	1300		recall 1330		-30	1611	1582	29
		exile	1300		demise 1330		-30	1509	1480	29
		detail	1603		reproof/ve 1637	-34	1330	1303	27
		comment	1400		abuse 1450		-50	1439	1413	26
		comfort	1225		return 1290		-65	1390	1366	24
		purport	1455		reward 1528		-73	1338	1315	23
		envy	1280		remark 1382		-102	1654	1633	21
		concrete	1528		attempt 1635		-107	1534	1513	21
		invoice	1560		conserve 1698		-138	1393	1374	19
		surface	1611		disguise 1778		-167	1340	1325	15
		surname	1330		revolt 1512		-182	1560	1548	12
		presage	1390		attest 1578		-188	1606	1596	10
		process	1330		support 1532		-202	1390	1382	8
		preface	1386		excess 1619		-233	1382	1374	8
		distance	1290		array 1578		-288	1300	1297	3
						assent		1300	1297	3
		decline advice/se (9a) Modèle accentuel verbal : V et N /01/	1327 1297	1325 1297	2 0
	V premier (diff. ≥ 40)		64		deceit/ve	50,39%	1300 77,11%	1300	0
	Indécidable (diff. < 40) N premier (diff. ≥ 40)		44 19		delight recruit disgust	34,65% 14,96%	1225 1643 1598 22,89%	1225 1643 1601	0 0 -3
			Total	127	complaint/ain	1368	1374	-6
						device/se		1290	1300	-10
						esteem		1450	1460	-10
		divorce (9b) Modèle accentuel nominal : V et N /10/	1377	1387	-10
	V premier (diff. ≥ 40)		4		review	13,79%	1565 25,00%	1576	-11
	Indécidable (diff. < 40)		13		report delay	44,83%	1374 1275	1386 1290	-12 -15
	N premier (diff. ≥ 40)		12		despair	41,38%	1325 75,00%	1340	-15
			Total	29		research surprise		1577 1457	1593 1474	-16 -17
						decay		1460	1483	-23
						belief/ve		1175	1200	-25
	2.4					resort escape		1374 1300	1400 1330	-26 -30
						appeal		1297	1330	-33
						relief/ve		1330	1366	-36
						relapse		1533	1570	-37
						distress		1297	13 . .	???
						debate		1300	1340	-40
						account		1260	1303	-43
						attire		1250	1297	-47
						retreat		1375	1422	-47
						expense/d	1382	1440	-58
						reproach		1420	1489	-69
						disdain		1290	1380	-90
						regard		1340	1430	-90
						award		1300	1393	-93
						decree		1303	1399	-96
						decease		1330	1439	-109
						default		1225	1340	-115
						respect		1391	1542	-151
						excise		1494	1652	-158
						demand		1290	1477	-187
						request		1330	1533	-203
						effect		1385	1589	-204
						assault		1230	1450	-220
						response/d	1300	1588	-288

J.-M. Fournier et N. Rossi-Gensane, Langues et Représentation, Université de Tours -CerLiCO 2002 (8b) Modèle accentuel nominal : V et N /10/

. Prononciation et conversion : les pluricatégoriels N/V en <ow> Prononciation

	Verbe	Equivalent	Date-N	Date-V	Pron.
		Mouvement (N : "activité de V")
	blow	souffler	1660	1000	[]
	flow	couler	1450	1000	[]
	throw	jeter	1530	1000	[]
	show	montrer	1300	1000	[]
		Mouvement (mais N : "objet")
	snow	neiger	825	1300	[]
		Son -V seulement (N : "rare")
	low	meugler	1549	1000	[]
	howl	hurlement	1599	1390	[a]
	growl	grondement	1727	1667	[a]
			mais
	crow	"cocorico"	1290	1000	* []

de la voyelle <ow> lorsqu'elle est accentuée : V → [] ~autres catégories → [a] Son (+attitude) (V : "émettre N") * Interférence de crow = corneille (1000), [] ? J.-M. Fournier et N. Rossi-Gensane, Langues et Représentation, Université de Tours -CerLiCO 2002 B. Les couples N/V

de déplacement en français et en anglais 3. Les couples N/V de déplacement en français

  Corpus : paires constituées d'un nom et d'un verbe de déplacement intransitif (cf. marche / marche(r), walk/walk), tant en français qu'en anglais. Pour le français, relevé effectué à partir duPetit Robert électronique (1996), non exhaustif mais, du moins, représentatif.

	Nom	Genre	Verbe	Aspect (*) Elt premier
	approche	fém	(s')approcher	act?	verbe
	arrêt	masc	(s')arrêter	ach	verbe
	aventure	fém	s'aventurer	act?	nom
	balade	fém	se balader	act	verbe
	bond	masc	bondir	ach	verbe
	cabriole	fém	cabrioler	act	nom
	cascade	fém	cascader	act	nom
	cavalcade	fém	cavalcader	act	nom
	cavale	fém	(se) cavaler	act?	verbe
	chute	fém	chuter	ach	nom
	crawl	masc	crawler	act	nom
	danse	fém	danser	act	verbe
	dérive	fém	dériver	act?	verbe
	élan	masc	s'élancer	ach?	verbe
	envol	masc	s'envoler	ach?	verbe
	escalade	fém	escalader	act	nom
	esquive	fém	s'esquiver	ach	verbe
	exil	masc	s'exiler	acc?	nom
	fugue	fém	fuguer	acc?	nom
	galop	masc	galoper	act	verbe
	gambade	fém	gambader	act	nom
	glisse	fém	glisser	act	verbe
	godille	fém	godiller	act	nom
	heurt	masc	se heurter	ach	verbe
	marche	fém	marcher	act	verbe
	nage	fém	nager	act	verbe
	pirouette	fém	pirouette	act	nom
	pose	fém	se poser	ach	verbe
	recul	masc	reculer	act?	verbe
	rejet	masc	se rejeter	acc?	verbe
	remonte	fém	remonter	acc	verbe
	repli	masc	se replier	acc?	verbe
	retour	masc	retourner	acc	verbe
	saut	masc	sauter	act	verbe
	ski	masc	skier	act	nom
	slalom	masc	slalomer	act	nom
	spirale	fém	spiraler	act	nom
	sprint	masc	sprinter	act	nom
	surf	masc	surfer	act	nom
	tour	masc	tourner	act/acc	verbe
	transit	masc	transiter	act/acc	nom
	trot	masc	trotter	act	verbe
	trotte	fém	trotter	act	verbe
	vadrouille	fém	vadrouiller	act	verbe
	valdingue	fém	valdinguer	acc	verbe
	valse	fém	valser	act	verbe
	varappe	fém	varapper	act	nom
	vol	masc	voler	act	verbe
	voltige	fém	voltiger	act	verbe
	voyage	masc	voyager	act	nom
	zigzag	masc	zigzaguer	act	nom

* : act : activité ; acc : accomplissement ; ach : achèvement ; xxx? : discutable 3.1.

Quels verbes et quels noms supportent « l'homonymie formelle » ? 3.1.1. Les verbes Caractéristiques morphologiques : verbes

  du premier groupe (exception : bondir, du deuxième groupe).

	Caractéristiques sémantiques :
	V act	31	58,49%
	V act?	5	9,43%	67,92%
	V acc	5	9,43%
	V acc?	4	7,55%	16,98%
	V ach	6	11,32%
	V ach?	2	3,77%	15,09%
	Total	53 *
	* : deux cas doubles act/acc : tourner, transiter.

Caractéristiques morphologiques des noms apparus avant les verbes correspondants

	3.2. La conversion
			N premier		21	41,18%
			V premier		30	58,82%
				Total	51
	3.2.1. aventure, cascade, cavalcade, escalade, gambade, voyage	~	balade
	→ suffixes :	-ade, -age, -ure
	→ « bases liées » ?:	avent-, casc-, cavalc-, escal-, gamb-, voy-(et bal-)
	Cf. :	(un) voyage	comme :	(un) décrochage, (un) patinage… ~ (une) page
	3.2.2. Caractéristiques syntaxiques (modes de construction) des noms apparus avant les verbes correspondants
		« Lorsqu'un nom est dérivé d'un verbe, le type catégoriel et sémantique de complémentation du nom est souvent le
		même que celui associé au verbe »
		Haïk 1995, p. 79
	Construction Verbe support + Nom prédicatif, paraphrase du verbe « lexical » :
		cabrioler = faire des cabrioles.
					dénotation de
		l'action vers celle de résultat de l'action » (phénomène de concrétisation) »
		Kerleroux, 1997, 167.
	Noms correspondant à des verbes d'achèvement :
		Arrêt : action de s'arrêter, état de ce qui n'est plus en mouvement
		Heurt : action de heurter, résultat de cette action
	Noms correspondant à des verbes d'activité :
		Marche : action de marcher
		Nage : action, manière de nager

anglais (1905)

Ski : emprunté au norvégien, d'abord sous la forme skie au féminin (1841) puis au masculin (1876), enfin écrit ski (1891) Slalom : reprend un mot norvégien (1908) Sprint : emprunté à l'anglais (1895) Surf : (1961) mot anglo-américain, abrégé de surf-board

Caractéristiques sémantiques :

« Selon les analyses de Adouani et de Roché, convergentes, la majorité des déverbaux sont des noms d'action, mais « selon un processus habituel, ils évoluent très souvent, et très tôt, de l'abstrait vers le concret », de la G.

Gross et Robert Vivès (1986, 24)

: Luc s'intéresse (aux + *pour les) mathématiques Luc a de l'intérêt (*aux + pour les) mathématiques J.

Giry-Schneider (1987, 115)

Marie voyage (?*à Lyon + au Mexique) Marie fait un voyage

(à Lyon + au Mexique)

de déplacement en anglais

  Le corpus des paires formées d'un nom et d'un verbe de déplacement intransitif en anglais a été constitué à partir de l'Oxford English Dictionary électronique (1997). Ici encore, le relevé n'est sans doute pas exhaustif.

	fait une marche Jean fait de la marche Jean fait des marches a) La paraphrase comporte un déterminant indéfini, préférentiellement au pluriel. Jean marche  cabrioler  faire des cabrioles gambader  faire des gambades pirouetter  faire des pirouettes spiraler  faire des spirales voyager  faire des voyages zigzaguer  faire des zigzags b) La paraphrase comporte un déterminant partitif. crawler  faire du crawl skier  faire du ski surfer  faire du surf Forme Equivalent Fr. Rom./Ger. Date-N row ramer G 1832 ride avec un moyen de trsp G 1759 wander errer G 1843 drive conduire G 1697 sail "à voile" G 1604 dive plonger G 1700 tread parcourir G 1400 slide glisser G 1596 flutter virevolter G 1641 flit voltiger G 1835 run courir G 1450 strut "en se pavanant" G 1607 swim nager G 1599 glide glisser G 1596 wiggle "en se déhanchant" G 1816 strike sauter sur qqn G 1587 climb grimper G 1577 spring sauter/franchir G 1450 crawl ramper/crawler G 1818 swerve dévier G 1741 hop sautiller G 1508 flow couler G 1450 advance avancer R 1668 spin tournoyer G 1831 hobble clopiner G 1727 tumble trébucher/dégringoler G 1716 move bouger R 1656 tramp "lourdement", "a pied" G 1786 clamber se hisser G 1818 walk marcher G 1386 roll rouler R 1743 bolt se sauver G 1550 plod cheminer G 1880 fall tomber G 1200 sweep "rapidement" G 1607 sprint foncer/sprinter G 1865 bounce (re)bondir G 1523 waddle se dandiner G 1691 trudge "péniblement" R ? 1835 gush jaillir G 1682 venture s'aventurer R 1810 reel "chancelant" G ? 1572 stop s'arrêter G 1483 turn tourner R 1250 stumble trébucher G 1547 saunter flâner R ? 1712 slip déraper G 1567 flop s'affaler G 1823 withdraw se retirer G 1444 stroll se promener G 1814 whirl tourbillonner G 1480 approach approcher R 1489 crash se fracasser G 1580 scramble "avec difficulté" G ? 1755 skip sautiller G 1440 swagger plastronner G 1725 dart foncer R 1721 plunge plonger R 1496 stomp "lourdement" G 1912 step un pas G 1000 mount monter R 1486 travel voyager R 1375 dash se précipiter G 1375 march marche R 1590 sway "en tanguant" G 1374 lift s'élever/emmener G 1470 stagger chanceler G 1600 collapse s'effondrer R 1801 jog cahoter G 1611 shuffle "en traînant" G 1659 hike randonnée ? 1865 cruise croisière G 1706 take off décoller G 1869 arrest s'arrêter R 1375 canter petit galop G 1755 wobble "en chancelant" G 1699 flounce "impatient" G 1583 vault sauter (d'un bond) R 1576 leap bondir G 900 ramble excursion G ? 1654 leave partir G 1250 stride "à grand pas" G 725 return retourner R 1390 jaunt se balader R 1592 jump sauter G 1552 scamper gambader R 1697 dodge esquiver G 1575 rush se ruer R 1380 caper gambader R 1592 amble amble + "tranquille" R 1386 dance danser R 1300 exile exiler R 1300 transit transiter R 1440 trek cheminer S. Afr. (Du) 1849 chase poursuivre R 1297 gallop galloper R 1523 meander vagabonder R 1599 waltz valser G 1781 stampede débandade Esp. 1828 swoop fondre/piquer G 1544 escape échapper R 1300 slalom slalomer Norv. 1921 trot trotter R 1300 lurch vaciller G 1769 valse valser R 1796 zigzag zigzaguer R (Fr.<?) 1712 swirl tourbillonner G 1425 journey voyager R 1225 adventure s'aventurer R 1230 pirouette pirouetter R 1706 cavalcade cavalcade R 1591 progress progresser R 1461 spiral spiraler R 1656 voyage voyager (par mer) R 1297 pace pas "mesuré" R 1290 drift dériver G 1300 stream "à flots" G 875 race course G 1300 Relativité des écarts selon les dates : slalom 1297 Forme Date-V 950 888 1000 900 893 1000 700 950 1000 1200 825 1000 1000 1000 1225 1000 1000 888 1300 1225 1000 1000 1230 1400 1300 1300 1250 1388 1430 1000 1375 1225 1566 890 1300 1566 1225 1400 1547 1400 1534 1300 1225 1000 1303 1475 1340 1602 1225 1603 1290 1305 1400 1596 1300 1590 1592 1375 1803 897 1384 1290 1515 1300 1400 1530 1732 1548 1598 1809 1651 1814 1325 1706 1657 1542 1538 865 1620 1225 700 1366 1570 1530 1687 1568 1375 1588 1386 1300 1300 1440 1850 1300 1533 1612 1794 1848 1566 1330 1956 1362 1833 1870 1787 1513 1330 1340 1822 1710 1590 1834 1477 1513 1584 1225 1680 Equivalent Fr. Rom./Ger. Date-N Date-V 4.1.	Date N-V 882 871 843 797 711 700 700 646 641 635 625 607 599 596 591 587 577 562 518 516 508 450 438 431 427 416 406 398 388 386 368 325 314 310 307 299 298 291 288 282 276 272 258 250 244 237 227 221 219 211 190 184 180 159 140 135 129 121 109 103 102 85 75 74 70 70 69 63 61 56 55 55 50 49 42 41 38 35 34 25 25 24 22 22 10 7 5 4 0 0 0 0 -1 -3 -10 -13 -13 -20 -22 -30 -35 -62 -64 -74 -75 -88 -105 -110 -116 -119 -129 -178 -180 -223 -284 -350 -380 Date N-V

→ Verbe d'activité  Verbe support + syntagme non individué 4. Les couples N/V J.-M. Fournier et N. Rossi-Gensane, Langues et Représentation, Université de Tours -CerLiCO 2002

Datation de l'unité et datation du sens de déplacement :

  Continuïté sémantique, Verbe de mouvement > Verbe de déplacement : bounce (frapper : 1225 > 1519), crash (briser : 1400 > 1694), strut (make efforts : 1000 >1518), stop (make an obstruction 1225 > 1529) Continuïté sémantique, Verbe de déplacement figuré > Verbe de déplacement : advance (1230 > 1483), saunter (1475 > 1667), stumble (1303 > 1325) "Discontinuïté" sémantique : leave (autorisation : 900, 1000 > 1250, 1225) , venture (luck/chance : 1450, 1430 > 1810, 1534) Continuïté sémantique, objet "mouvant" > Nom de déplacement : stream (course of water : 1225 > 1600), swirl (whirlpool (<whirl 1290 !) : 1425 > 1818) vs spin V (filer (la laine…) : 725 > 1400) Discontinuïté sémantique, "objet" > Nom de déplacement : bolt (carreau : 1000 > 1550, 1225), dart (dard : 1314 > 1721, 1592), sail (voile : 888 > 1604, 893)

	4.1. La conversion :
	V premier (diff. > 40)	77	65,25%	81,91%
	Indécidable (diff. < 40)	24	20,34%
	N premier (diff. > 40)	17	14,41%	18,09%
		Total	118
		V premier (diff. ≥ 40)		59	83,10%	92,19%
	Germanique	Indécidable (diff. < 40)		7	9,86%
		N premier (diff. ≥ 40)		5	7,04%	7,81%
		Total	71	60,17%
		V premier (diff. ≥ 40)		13	35,14%	56,52%
	Roman	Indécidable (diff. < 40)		14	37,84%
		N premier (diff. ≥ 40)		10	27,03%	43,48%
		Total	37	31,36%
	Autres	V premier (diff. ≥ 40)		5	50,00%	71,43%
	ou	Indécidable (diff. < 40)		3	30,00%
	douteux	N premier (diff.≥ 40)		2	20,00%	28,57%
		Total	10	8,47%
		Total général	118

A. Martinet, Grammaire Fonctionnelle duFrançais, 1979, p.

2 M. Riegel et al., Grammaire Méthodique du Français, 1994, p. 547.

J.-M. Fournier et N. Rossi-Gensane, Langues et Représentation, Université de Tours -CerLiCO 2002


Paulo Melo
email: pmelo@fe.uc.pt

Paulo Rupino Da Cunha

André Catarina Ferreira Da Silva

André Macedo

P Cunha

C Ferreira

Automatic run-time versioning for BPEL processes

Keywords: Business Process Versioning, Business Process Execution Language (BPEL), BPEL versioning, Service-Oriented Architecture (SOA), Web Services, Middleware 1 Introduction

come   L'archive ouverte pluridisciplinaire

ing their business processes as orchestrations of web services using BPEL (Business Process Execution Language).

One of the main advantages of this approach is agility. In theory, any changes to the workflows, dictated by new business needs, can easily be made by process owners and then quickly deployed to the execution engine to immediately change system behaviour. However, this is only true in cases where no instances of the modified business process are still running in the engine. Otherwise, the deployment of the new version would leave the running instances in inconsistent states, having partially run the old workflow and seeing it suddenly replaced by a new one. Aborting the running instances before deploying the new version is not a solution, since that would lead to the cancelation of ongoing business process (e.g. consider the installation and activation of a triple-play service at the customer home, with only some of the required steps completed at a given moment). Waiting for existing instances to conclude is often also unfeasible. Several business processes are long-running, meaning that they can take weeks, months, or even years to complete [6, page 23]. Besides, new ones are constantly being started -stopping that would mean stopping the business. Finally, running instances must be allowed to conclude following their original business logic, to ensure that contractual or regulatory issues that applied when the process was started are not violated.

The above constraints mean that an effective SOA implementation needs mechanisms to enable multiple versions of the same process to coexist and run in the engine simultaneously, ensuring that each one follows its original workflow.

Complex as the problem is, several additional challenges emerge when considering the thousands of person-months invested in existing enterprise systems and the stringent controls exerted in production environments. These preclude solutions that require extensive rewriting of code, involve risky changes, degrade performance, or lock-in the enterprise to products that may be discontinued or become inadequate for the workload.

So far, the process versioning problem has been solved by ignoring the latter concern. Several BPEL engines, such as IBM WebSphere Process Server [START_REF] Neth | Versioning business processes and human tasks in WebSphere Process Server[END_REF] and Oracle BPEL Process Manager [START_REF]Oracle. Oracle BPEL Process Manager Developer's Guide 10g[END_REF] (now part of Oracle SOA Suite [START_REF]Oracle fusion middleware developing SOA applications with Oracle SOA Suite[END_REF]), implement the required workflow versioning, but in a closed, proprietary manner, not portable across different engines, should the need to replace them arises.

To overcome this situation, Juric et al. have proposed BPEL extensions for versioning, to be used at development, deployment, and run-time [START_REF] Juric | WS-BPEL Extensions for Versioning[END_REF]. Naturally, this solution requires an engine that supports those extensions and that all existing BPEL processes will be modified to use the suggested syntax. Additional related works are presented in Section 2.

The novelty in our solution is that we propose to handle versioning using only run-time mechanisms, implemented in a middleware component. To match the challenges of the scenario described above, we defined the following design principles:

-High transparency, meaning that the process owner, BPEL editor, BPEL engine, and invoked web services don't need to be aware of our component. The process owner, in particular, can continue to manage his/her own design-time versions of the process source files, without being concerned with the additional automatic versioning that will take place at run-time to account for running instances in new deployments; -Low invasiveness, avoiding the need to introduce changes to the code of dozens or hundreds of existing of web services and BPEL processes, thus also reducing the risk of introducing new problems in production environments; -Low overhead, ensuring that the versioning mechanisms do not cause excessive performance penalties; -High independence, avoiding lock-in to specific BPEL engines or non-standard BPEL syntax extensions; -High extensibility, enabling the expansion of the middleware component to new uses, such as load balancing, testing and diagnostics, fault injection, or other operations than can benefit from intermediating the exchanges between the BPEL engine and the web services.

In Section 2, we discuss previous work on versioning in SOA environments, after which, in Section 3, we describe the architecture and algorithms for our solution.

Section 4 is dedicated to the performance analysis of the proposed solution, based on measurements of almost one year of operation in the production environment of a telecommunications company. Finally, in Section 5, we present conclusions, limitations and future work.

Versioning Services and Versioning Long-Running BPEL Processes

Inappropriate support for versioning in SOA has been identified as an important problem [START_REF] Juric | Version management of BPEL processes in SOA[END_REF][START_REF] Louridas | Orchestrating Web Services with BPEL[END_REF]. A lot of work has been done on versioning of web services, but much less ground has been covered on the versioning of the BPEL workflows that orchestrate those web services.

Web Service Versioning

When dealing with versioning of web services due to their evolution, two approaches can be proposed [START_REF] Andrikopoulos | On the Evolution of Services[END_REF]: corrective, changing the producer or the consumer of the service so it continues to interoperate with the new service; and preventive, avoiding changes caused by the evolution on the service that breaks interoperability. Both approaches, however, require some amount of control over either side of the interoperating equation. Service versioning can be achieved explicitly by changing invocations in source code or by using suitably configured UDDI registries, but remains one of the most difficult issues faced by developers of distributed systems [START_REF] Brown | Best practices for Web services versioning[END_REF]. Versioning has also been considered in more specific contexts, including those of service provenance [START_REF] Ibrahim | The Concept of Web Service Versioning in Provenance[END_REF][START_REF] Michlmayr | Selective Service Provenance in the VRESCo Runtime[END_REF] or automatic service matching [START_REF] Becker | Automatic determination of compatibility in evolving services[END_REF]. In these areas, service versioning may be seen as either something to be natively supported by the environment [START_REF] Michlmayr | Selective Service Provenance in the VRESCo Runtime[END_REF] or achieved using UDDI [START_REF] Ibrahim | The Concept of Web Service Versioning in Provenance[END_REF]. In service matching approaches, where more than managing the instanced services directly, the intent is to apply them to new uses, versioning is considered something better handled using the service data description [START_REF] Becker | Automatic determination of compatibility in evolving services[END_REF], but these approaches do not usually handle processes already running.

The existence of versioning may be mostly transparent to the service user, or it may be exposed in the interface of the services. To support several concurrent versions of the same services, different approaches have been proposed, including creating new XML namespaces or explicit version identifiers [START_REF] Andrikopoulos | On the Evolution of Services[END_REF]. In [START_REF] Frank | An Approach to Hosting Versioned Web Services[END_REF] the difference between implementation versioning and interface versioning was explored, and an infrastructure was proposed that allowed routing of versioned requests to the most recent compatible service (that is, the most recent one with the same interface version). The proposed implementation, however, was dependent of WebSphere, and did not mention support for asynchronous web services invocation.

A mechanism for transparent version handling of web-services may be the use of proxies to map the requests to the different service versions, while maintaining a fixed service address. Support for proxying webservices can be provided by standardized HTTP proxies, like Squid [START_REF] Wessels | Squid the Definitive Guide[END_REF], or by specialized tools geared towards web-services, like the Web Service Gateway support present in WebSphere [START_REF] O'hanlon | Create a simple HTTP Web Services Gateway Service with Web-Sphere Application Server V6[END_REF] or the Mule Framework [START_REF] Mulesoft | Mule user guide: Proxying web services[END_REF].

Fang and colleagues [START_REF] Fang | A Version-aware Approach for Web Service Client Application[END_REF] propose an automatic web service versioning support using UDDI and a service interface proxy, but this solution requires the clients to be fitted with specialized proxies to access the service.

In the context of cloud services, TOSCA (Topology and Orchestration Specification for Cloud Applications [START_REF]OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC. Topology and orchestration specification for cloud applications version 1.0. OASIS Standard, OASIS[END_REF]), an OASIS standard specification, stipulates a language to specify service templates that can define the topology of a service and that can utilize existing process modeling standards to define orchestration (via "plans") that can "invoke the manageability behavior of services" [START_REF]OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC. Topology and orchestration specification for cloud applications version 1.0. OASIS Standard, OASIS[END_REF]. TOSCA describes what is needed to be preserved across deployments in different environments to enable interoperable deployment of cloud services and their management. Although the TOSCA standard is useful to enable application lifecycle automation while ensuring interoperability [START_REF] Harrer | Towards uniform BPEL engine management in the cloud[END_REF][START_REF] Aria | About ARIA TOSCA[END_REF], it requires rewriting workflows and services in standardsupporting manner. This effort is unfeasible when large scale operations and past investments are at stake. SOA versioning, however, requires more than versioning web services as described above. It requires versioning of their orchestrations.

Orchestration versioning

Versioning of orchestrations to support long-running processes is a complex problem for which no completely satisfactory solution is in widespread use. The complexity of the evolution of long-running processes may even require that it itself is considered as long-running [START_REF] Frank | A continuous long running batch orchestration model for workflow instance migration[END_REF] where the process migration/evolution is handled on a process-by-process basis, migrating/evolving processes only when they are in a stage where its change will create less disruptions. However, such approach requires inner knowledge on the long-running processes state and also state migration abilities that may not always be present.

Although support for versioning BPEL processes is available internally to some engines, such as IBM Web-Sphere Process Server [START_REF] Neth | Versioning business processes and human tasks in WebSphere Process Server[END_REF] and Oracle BPEL Process Manager [START_REF]Oracle. Oracle BPEL Process Manager Developer's Guide 10g[END_REF][START_REF]Oracle fusion middleware developing SOA applications with Oracle SOA Suite[END_REF], this approach has some drawbacks. It may be coupled with requirements on the deployment methods used and, being proprietary to each vendor, it is usually not portable across different engines, even if both support versioning. The following alternative approaches have been proposed to endow BPEL processes with versioning:

-Juric and colleagues [START_REF] Juric | WS-BPEL Extensions for Versioning[END_REF] specify BPEL processes versioning as an integral part of development, deployment, and run-time, by proposing an explicit WS-BPEL extension for versioning. They suggest the use of a version handler to assist in routing requests to appropriate versions of a process and deal with pre-processing and post-processing transformations. They also introduce an extension attribute bpelx:vid to specify the required version of the partner link, then enabling the invocation of specific partner link versions. This approach restricts the choice of BPEL engine to those supporting the proposed extensions. To the best of our knowledge, vendors have not implemented these extensions in the years since the paper was published. Should compatible engines exist, legacy BPEL processes would still need to be modified to use the proposed syntax. -In the context of service choreographies, Baresi et al. [START_REF] Baresi | Consistent runtime evolution of service-based business processes[END_REF] distinguish between independent requests, which can use different versions of the same service safely, and dependent requests, which must always exploit the same version. These authors propose extensions to a version consistency algorithm applied to BPEL. They take as input a BPEL process and create a directed acyclic graph which is then labeled to further enable a static analysis of the services' control-flows and determine which are dependent and which are not. Authors deployed their BPEL provisioning and execution environment as an extension of Dynamo, which is an extension of the open-source Active-BPEL engine. In a previous work by the authors, DyBPEL [START_REF] Baresi | Serviceoriented dynamic software product lines[END_REF] directly addressed orchestration evolution, although not transparently, and did not provide transparent/automatic version management. These authors have also compared their work against quiescence [START_REF] Kramer | The evolving philosophers problem: dynamic change management[END_REF], and tranquility [START_REF] Vandewoude | Tranquility: A low disruptive alternative to quiescence for ensuring safe dynamic updates[END_REF], that is, against the "classical" approaches for the runtime evolution of component-based distributed systems. However, these approaches can not directly solve the problem of versioning of long-running orchestrations, because these cannot be stopped for the purpose of doing static analysis or be modified at run-time.

The silver lining when dealing with BPEL orchestration evolution is that the interfaces exposed by the BPEL engine may be considered as immutable, so the main challenge of supporting several process versions would be to use the right process version when an orchestration is running, and route the messages to that version by applying a proxying mechanism. Moreover, if the versioning protocol used is kept simple, namely by preventing the reuse of a version that has been replaced -so that the identification of the "current" version and of the "old" versions can be performed automaticallymuch of the complexity of versioning can be reduced.

In this article we propose a simple framework to handle the process orchestration versioning problem, where neither the producer nor the consumer of the service needs to be modified. This is achieved by using middleware components that handle versioning and proxy the dialog between service provider and consumer. The overall system hides the complexity of versioning from both sides and allows uninterrupted use of the existing software/code base, while supporting an arbitrary number of versions.

Design of the Versioning Middleware

Typical work routines should not be disturbed for the high transparency design principle to be met. The user must be allowed to retain full control over his/her own design-time versions of the business processes and deploy them in the same manner. However, since the deployment of a new version of a given process cannot disrupt the instances currently running in the BPEL engine (abort them or leave them in inconsistent states), an additional run-time versioning must occur.

To achieve this, our middleware component intercepts the deployment of a BPEL process from the editor and creates a version with a different name than the one already residing in the engine, thus avoiding overwriting the process model that the running instances are using. The same business process can, thus, originate various run-time versions in the engine, as shown in Figure 1. All but the most current, however, are only kept until the associated running instances terminate. New invocations of the process always use the latest version deployed by the user.

On the left in Figure 1 we see how the various designtime versions of the ActivateDSL process, managed by the user according to business needs, evolve through time. On the right, we see how various run-time versions, managed by our middleware, are kept in the BPEL engine, to ensure that instances of previous process models are not disrupted. Without this run-time versioning, deploying a new user version would replace the one residing in the engine, thus aborting running instances or leaving them in inconsistent states.

The UML sequence diagram in Figure 2 details the algorithm underlying the creation of the run-time versions. As shown there, the deployment of the original BPEL process (e.g. ActivateDSL) from the editor to the engine, is intercepted by the Deployer component of our versioning middleware, which, after consulting a repository where we store information about existing run-time versions, determines the next one and adds a sequential Id to the process name before letting the transaction proceed. The answer returned by the engine to the Deployer is then passed back to the editor. Neither the BPEL editor nor the BPEL engine are aware of the intermediation made by our Deployer, further contributing to the high transparency and low invasiveness design principles stated in the introduction. As a final step, the Deployer gets the WSDL used in the invocation of the newly deployed process from the engine and stores it in our versioning repository. It also notifies the Gateway, who caches all this information in RAM, all for improved performance.

Having managed to keep multiple run-time versions of the same user process in the engine, then raises the challenge of ensuring that new invocations of a BPEL process and callbacks from previously invoked asynchronous web services are routed to the appropriate instances. The algorithm for the simplest case -a new invocation of a process by an external service -is shown in the UML sequence diagram of Figure 3.

New invocations of a process should always use its most up-to-date version (the last one deployed). To this end, upon intercepting an invocation of a process (e.g. ActivateDSL), the Gateway determines its most current run-time version (e.g. ActivateDSL_Id), invokes that version, receives its reply, and passes it on to the original external caller.

There is, however, another far more complex scenario: when an external service has been asynchronously called by an instance of a given run-time version of a process and, sometime later, calls back with its reply. In this case, the Gateway must ensure that the callback is routed to the specific version and instance that made the original call and not, erroneously, to the most recent one. We achieve this by handling BPEL's correlation set -a collection of properties that enable the unambiguous identification of an instance. Correlation sets are already used by BPEL engines in asynchronous exchanges, to ensure that the callbacks are directed to the correct caller instance. However, since we created multiple run-time versions for the same user process, we must also intermediate this exchange to ensure that the correct instance of the correct run-time version is iden- 4. As seen there, when the asynchronous callback (1.1) occurs in response to the invocation of the external service (1), our Gateway intercepts it. Then, it asks the BPEL engine for all correlation sets for all active instances, finds the run-time instance whose correlation set matches the correlation set of the callback, and routes the callback to that instance. The reply from the process is passed back to the external service.

In both scenarios -new invocation and asynchronous callbacks -neither the external service nor the invoked process residing in the BPEL engine are aware of the intermediation made by our Gateway, to ensure the high transparency and low invasiveness design principles. Note how the external service always uses the original process name "ActivateDSL" -thus avoiding the need for modifications to support versioning -leaving it to the Gateway to translate as needed to an "Ac-tivateDSL_Id", corresponding to the correct run-time version.

Besides minimizing risky and massive changes to the assets, solutions meant for use in a production environment must not introduce unduly overhead -our third design principle. This issue is particularly relevant for our Gateway component, since it intermediates all traffic between external services and processes running in the BPEL engine. Aiming for low overhead, the following architectural decisions were made:

-The WSDLs of the various processes deployed to the engine are stored in a repository of versioning data, for quicker response when requested by a caller. This saves the time it would take for the Gateway to call the BPEL engine to get this information. As seen in Figure 2, these WSDLs are stored in the repository by the Deployer immediately after it finishes the deployment. -A cache of these WSDLs and remaining versioning information is kept in RAM by the Gateway. Since this component only performs "reads", to find out to which version and instance of a process to forward a message to, a cache speeds up computation significantly. The only "writes" are done by the De- Another relevant aspect of low invasiveness in this architecture is that is does not require modifications to the source code of the BPEL engine, as other solutions do [START_REF] Baresi | Consistent runtime evolution of service-based business processes[END_REF]. This is very important, as it enables the adoption of new engine updates as they are released, avoiding the cost and trouble of adapting their source code every time. High independence is also promoted, Fig. 4 Assynchronous Invocation of a process using correlation identifiers since no particular BPEL engine or non-standard BPEL extensions are required. It is highly extensible, since all traffic between external services and processes running on the engine is intercepted and can be manipulated.

In summary, our solution intercepts deployments of business processes to a BPEL engine and creates runtime versions as needed, to maintain the integrity of running instances relying on previous versions of the process model. It then tracks and manages all invocations from external services to the BPEL processes to ensure that: Consequently, the user can deploy improved business processes as needed, resting assured that any existing instances that are still running will be allowed to complete following their original workflows. This is of key importance, since several business processes are longrunning.

Performance and scalability issues are described in detail in the next section.

Field Measurements And Discussion

To measure the overhead created by our versioning middleware we performed some laboratory tests (results shown in Table 1) to evaluate baseline efects on system memory and runtime delays. Those lab tests, ran with various combinations of versions per service and instances per version, shown moderate impact of under 15% increase in memory usage and under 10% increase in process runtime in the worst cases.

Since the previous results were obtained in lab settings, to further validate the approach, data was collected on actual system usage on the production environment of a telecommunications company, for about 200 days distributed throughout almost one year. During this period, the invocation of nearly 2 million processes was recorded. From this data, the following conclusions can be extracted regarding the overhead introduced by our solution.

Most processes experienced very low overhead (less than 20ms in over 98% of invocations) as shown on Table 2. In fact, some kinds of processes never experienced overheads of over 250ms. These processes (called origi- nally "Bus2OM", "PendingManager", "ReSender", "Start-Process" and "XMLManager") are named the "Low Overhead" processes. They were frequently invoked (over 1.9 million invocations in total). Some processes, however, (namely "AutomaticActivity", "ManualActivity" and "Orchestrator") have shown higher average and maximum overheads, although they were less frequent (the logs show about 37200 invocations in total). These processes are therefore called the "High Overhead" ones. It can also be inferred, from the number of versions of those processes present in the system, that they are the longest-running ones, where the additional overhead on invocation will be probably less relevant in the overall process life cycle. Even for high overhead processes, data shows that almost 90% of invocations presented an overhead of less than 1 second and over 97% of invocations were processed by the versioning middleware in under 2 seconds. This is illustrated in Figure 5, where the data was quantized [START_REF] Widrow | Statistical theory of quantization[END_REF] using bins of 1 second. However some invocations took a lot longer, including a couple of outliers requiring over one minute to process.

A detailed analysis for processes which took more than two seconds (just high overhead processes were found), shows that while the number of high overhead processes in each bin decreases with time, clusters can be found at around 5 seconds and (smaller ones) at 15 and 30 seconds, marked by dashed lines in Figure 5. These clusters may reflect the time required for accessing slower resources. A possibility is that they reflect time required for establishing the original access to the database or the overhead brought by the exhaustion of the database connection pool, both of which would require a time an order of magnitude higher than the simple access to disk, which, in turn, can be an order of magnitude higher than access to memory.

The one big difference between high overhead and low overhead processes, in our telecom case, appeared to be the number of different versions present in the versioning manager at the same time1 , as seen in Table 3. It illustrates, for each process where a certain number of different versions were present in the same day, the average overhead, the average of the maximum overhead and the number of days on which that number of versions occurred. The higher overhead processes are usually those for which more than one version is present. This was expected, since answering calls for processes for which just one version is active should be very fast due to caching. However, there doesn't seem to be a general rule relating average (or even maximum) overhead with the number of processes present in the system (for some processes, the average overhead even seems to decrease with more versions), which may be a sign that higher numbers of versions impose no undue overhead on the versioning system.

To discern whether a lower number of instances in particular days could be responsible for the variance on average overhead according to the number of versions active in the same day, this information is presented on Table 4. It shows, for each high overhead process version with a determined number of versions of that process present in the same day, the number of days in which that situation occurred, the total number of process instances ran, and, for those, the average overhead and average number of instances per day. This data does not seem to support the hypothesis of the number of instances on days with a larger number of versions present being the cause of the variation on the average overhead noticed in Table 3.

To further investigate the relationship between the processes and the overhead recorded, the data was coded into a series and correlated using the Stata™ software. Performing an analysis on the correlation2 between average overhead for the days where both processes shown invocations, it can be shown that the high overhead processes average overheads are correlated among themselves to a high degree, but no such correlation can be found among the low overhead processes or between members of the two groups, as seen on Table 5. The maximum overhead per day also displays the same correlation pattern, as shown in Table 6.

No statistically significant correlation can be found among the number of different versions of each process started per day (except, obviously, the correlation with themselves), as seen on Table 7. This was expected, since the different processes were not necessarily being developed/deployed in sync.

We have also constructed binary variables ("Binary Avg Ov" and "Binary Nr. Versions") which, for each process, codified whether a particular day had higher than average overhead (Table 8) or had a lower than average number of versions present (Table 9). Again, correlation exists among the "usual suspects", that is the high overhead processes, as depicted on Table 8. A weak (-0.3754), even if statistically significant, negative correlation between the low overhead processes "StartProcess" and "PendingManager" is noted, but this may be just a statistical artifact of the coding used, since isn't present in any other correlation.

From the previous correlations it can be suggested that either the high overhead processes are influencing each other or are being influenced in the same way by some environmental factor (e.g. high network latency or high CPU usage on the host computer). It should be noticed that the low overhead processes seem undisturbed by it, which may point to difficulties on the access to resources that aren't required by their versioning.

For all the processes, data shows that the average overhead is strongly correlated with the maximum overhead (and sometimes also with the minimum overhead) but not correlated, with statistical significance, with the number of versions of the processes started each day. Table 10 shows the results for the process "Automatic Activity", but the results were common with small variations among all the processes, both high and low overhead. This seems to imply that, once there is more than one version to be considered, the actual number of versions of a process in versioning has no measurable re-

Conclusions and Future work

We presented and discussed the design of a standalone, vendor agnostic middleware, capable of versioning BPEL processes, and then assessed the overhead it introduces under production environment conditions in a telecommunications company. The feasibility of the proposed solution was tested with data recorded for about 2 million process invocations in 200 days distributed across a period of almost one year. The presented approach to versioning is especially relevant for environments where new instances of processes are constantly being created and those processes are long-running and can take weeks, months, or even years to complete [6, page 23]. Such systems can not be paused, running instances must be allowed to complete following their original workflows, but improvements to the business processes must still be able to be deployed and used for new cases.

Our middleware handles the versioning exclusively via run-time mechanisms, and was architected to be:

-Highly transparent, so that the process owner, the BPEL editor, BPEL engine and orchestrated web services don't need to be aware of its existence. Any high-level versioning done by the user is also unaffected; -Non-invasive, so that legacy code of dozens or hundreds of web services and BPEL processes don't need to be changed, thus reducing the risk for complex production environments serving millions of customers; -Low overhead, so that the versioning mechanisms do not become unfeasible in real world environments.

Our tests have shown that the impact on performance is negligible, with most processes experiencing a very low overhead, of less than 20ms in over 98% of invocations. Results also show that the overhead does not seem to increase with the number of processes being versioned, thus ensuring good scalability; -Highly independent, so that the solution does not require a specific brand of BPEL engine or any nonstandard extensions to BPEL that might lock-in the company. As designed, the versioning middleware has a limitation in that it requires that whatever BPEL engine is used, it provides a mechanism to inquire about which deployed processes are waiting for external invocations; -Highly extensible, so that new functionalities can be added. In fact, for future work, we are considering experiments in which the middleware would be modified to act as a load balancer for multiple BPEL engines for high performance scenarios. Other possi-bilities of expansion include leveraging the intermediation role of the middleware to perform diagnostics and testing in SOA architectures or deliberately injecting faults to assess SOA robustness.

Alternative avenues to pursue in future work include examining the applicability of the approach for non-BPEL services that exhibit the same characteristics (including long runtimes and group identification), and to explore the merits of this approach versus other versioning mechanisms for those services.

Fig. 1

 1 Fig. 1 Mapping of design-time process versions to run-time versions in the BPEL engine

Fig. 2 Fig. 3 (

 23 Fig. 2 Deploying a new version to the BPEL engine

  (a) new ones are routed the most current version; (b) callbacks resulting from assynchronous invocations made by previous versions are routed to the original caller.

Fig. 5

 5 Fig. 5 Overhead Distribution

Table 1

 1 Laboratory Test Results

			Test#	1	2	3	4
	Features	Number of versions deployed per service Number of instances per deployed version Number of (main) processes Total Memory without versioning (MB)	1 1 1000 100.448 110.799 115.552 119.325 5 5 5 1 2 2 1000 1000 3000
			Process runtime without versioning (s)	0.397	0.409	0.436	0.457
	Memory	Increase	Core Memory Peak Memory Virtual Memory	7.0% 7.9% 6.6%	11.3% 13.9% 12.0%	8.0% 11.7% 12.1%	9.0% 12.2% 8.8%
	Runtime Increase	Process runtime Number of instances created Number of instances per second	2.2% 0.0% -2.2%	7.3% -1.5% -9.0%	7.6% -1.6% -9.3%	7.0% -1.3% -8.3%

Table 2

 2 Process Overhead (Invocations, Average and Maximum -all times in milliseconds)

		Process	Invocations Average Overhead Max Overhead
		AutomaticActivity	1915	423.015	31665
	High Overhead	ManualActivity	21239	677.513	50385
		Orchestrator	13958	382.862	75735
		BUS2OM	13696	15.002	30
		PendingManager	960739	15.001	210
	Low Overhead	ReSender	599911	15.008	90
		StartProcess	361355	15.005	30
		XMLManager	53	15.000	15
		Total	1972866	25.135	75735

Table 3

 3 Overhead versus number of versions per day

	# Different Versions Per Day
	1	2	3	Total

Table 4

 4 Average Overhead versus Version number for High Overhead processes according to number of concurrent versions present in the system

	Process Name	Version	Versions per day	Days	Instances	Average Overhead	Average Instances per day
		0.1	2	1	2	796.50	2
		0.2	1	14	135	347.82	10
	AutomaticActivity	0.3 0.3	1 2	23 1	298 26	531.16 597.96	13 26
		0.4	1	62	977	488.51	16
		0.5	1	33	477	172.62	14
		0.1	2	19	67	765.37	4
		0.1	3	2	2	820.50	1
		0.2	1	5	177	501.57	35
		0.2	2	14	849	364.90	61
		0.2	3	2	10	909.10	5
		0.3	2	8	12 1510.25	2
		0.3	3	5	87	674.64	17
	ManualActivity	0.4	1	11 1222 1008.53 111
		0.4	2	21 1247 1011.76	59
		0.4	3	4	283	769.13	71
		0.6	1	52 9030	738.32 174
		0.6	2	18 2543	522.95 141
		0.6	3	2	245	108.40 123
		0.7	1	28 3301	405.79 118
		0.7	2	6	2164	679.08 361
		0.1	2	17	195	304.40	11
		0.1	3	2	6	304.83	3
		0.2	1	95 9917	297.36 104
	Orchestrator	0.2 0.2	2 3	46 1878 2 52	920.98 240.35	41 26
		0.3	1	2	157	205.99	79
		0.3	2	29 1593	212.58	55
		0.3	3	2	160	192.93	80

Table 5

 5 Average Overhead time-series correlation

		AutomaticActivity	ManualActivity	Orchestrator	BUS2OM	PendingManager	ReSender	StartProcess	XMLManager
	AutomaticActivity	1
	ManualActivity 0.5562	1
	Orchestrator 0.7639 0.5472	1
	BUS2OM				1
	PendingManager					1
	ReSender						1
	StartProcess							1
	XMLManager	.	.	.	.	.	.	.	.

Table 6

 6 Maximum Overhead time-series correlation

		AutomaticActivity	ManualActivity	Orchestrator	BUS2OM	PendingManager	ReSender	StartProcess	XMLManager
	AutomaticActivity	1
	ManualActivity 0.7623	1
	Orchestrator 0.6005 0.6797	1
	BUS2OM				1
	PendingManager					1
	ReSender						1
	StartProcess							1
	XMLManager	.	.	.	.	.	.	.	.

Table 7

 7 Number of versions per day time-series correlation

		AutomaticActivity	ManualActivity	Orchestrator	BUS2OM	PendingManager	ReSender	StartProcess	XMLManager
	AutomaticActivity	1
	ManualActivity		1
	Orchestrator			1
	BUS2OM	.	.	.	.
	PendingManager	.	.	.	.	.
	ReSender	.			.	.	1
	StartProcess					.	.	.
	XMLManager	.	.	.	.	.	.	.	.

Table 8

 8 Correlation among the days with higher than average overhead

		AutomaticActivity	ManualActivity	Orchestrator	BUS2OM	PendingManager	ReSender	StartProcess	XMLManager
	AutomaticActivity	1
	ManualActivity 0.5384	1
	Orchestrator 0.5730 0.3085	1
	BUS2OM				1
	PendingManager					1
	ReSender						1
	StartProcess					-0.3745		1
	XMLManager	.	.	.	.	.	.	.	.
	lation with the versioning overhead, which leads us to
	expect good scalability for the versioning solution.

Table 9

 9 Correlation among the days with not less than average number of versions

		AutomaticActivity	ManualActivity	Orchestrator	BUS2OM	PendingManager	ReSender	StartProcess	XMLManager
	AutomaticActivity	1
	ManualActivity		1
	Orchestrator			1
	BUS2OM	.	.	.	.
	PendingManager	.	.	.	.	.
	ReSender	.			.	.	1
	StartProcess				.	.	.	1
	XMLManager	.	.	.	.	.	.	.	.

Table 10

 10 Correlation among the different measures for "Automatic Activity"

		Average Ov	Nr. Versions	Maximum Ov	Minimum Ov	Binary Avg Ov	Binary Nr. Versions
	Average Ov	1
	Nr. Versions		1
	Maximum Ov 0.8629		1
	Minimum Ov 0.4346			1
	Binary Avg Ov 0.6153		0.2953 0.3803	1
	Binary Nr. Versions		1				1

As the number of concurrent versions of a process present on the versioning manager for each invocation was unavailable, it is assumed to be the number of different versions of the process launched on the same day. While this metric may be incorrect in the case of very long or very short running processes, in this case it was considered a plausible approximation.

All correlation tables are shown presenting only the results where a significance level of at least 0.05 (after applying the Dunn-Šidák correction) is found. A dot is shown where not enough valid data was available to ascertain a significant correlation.

Acknowledgements The authors acknowledge the valuable comments and suggestions by the editor and anonymous reviewers.