Lavori futuri - WOODLE: un generatore di workflow basato sull'individuazione dinamica di compon

Woodle, al suo stato attuale, non pretende di essere un prodotto maturo, ma è

semplicemente un prototipo funzionante che serve come proof-of-concept. Ne sono

prova alcune delle limitazioni descritte nei capitoli precedenti come, in particolare,

l’interfacciamento con un singolo workflow engine. Per poter trasformare lo Woodle in

uno strumento realmente utilizzabile per risolvere problemi di grosse dimensioni, è

necessario estendere le funzionalità di alcuni moduli.

In questo capitolo conclusivo verrà elencata una serie di idee che, una volta

implementate, porterebbero al completamento delle funzionalità del prototipo. Per

semplicità esplicativa, si è deciso di raggrupparle per moduli, suggerendo, per ciascuno

dei quattro componenti dello strumento, quali siano i lavori di miglioramento da

intraprendere.

Al momento, “Parser” e “Selector” sono i moduli più maturi che possono ritenersi più

aderenti ad un ipotetico prodotto finale. Le attuali maggiori limitazioni, riguardanti il

primo modulo, sono dovute alla presenza di un singolo parser specializzato (quello per

il formato XML). Una naturale estensione del modulo comporterebbe l’aggiunta di altri

oggetti in grado di effettuare il parsing di formati diversi; in ogni caso, i lavori di

standardizzazione portati avanti dal W3C [WWWC], rendono sempre meno pressante la

necessità di offrire alternative all’XML.

Altri due aspetti, anche se non molto rilevanti, possono essere presi in considerazione

per un completamento dello strumento: il primo riguarda il sottomodulo di analisi dei

file di input, il secondo la struttura dei documenti XML.

Per quanto concerne il primo aspetto, si è detto, nella presentazione del “Parser”

(capitolo 3), che l’analizzatore di formato (FormatAnalyzer) basa le sue scelte

sull’estensione del file passatogli in ingresso. Questo significa, ad esempio, che è in

grado di richiamare il parser per il formato XML qualora riscontri la presenza

dell’estensione .xml nel nome del file di input. Se l’utente modificasse il nome del file,

sostituendo il suffisso con un altro differente, il sottomodulo si troverebbe a dover

smistare un tipo di file di cui ignora la struttura. Nella versione attuale, in casi come

questo, si richiedono comunque i servizi del parser XML. Si potrebbe, però, essere certi

di questa scelta andando a controllare le prime righe del file stesso, in cui, se si è

effettivamente in presenza di un documento XML, dovrebbe trovarsi la stringa: “

<?xml version=”xx” encoding=”xx”?>

”. È probabile che lo stesso concetto si possa

applicare anche ad altri formati che potrebbero nascere in un prossimo futuro.

Il secondo punto ha a che vedere con la strutturazione del documento XML che,

attualmente, rappresenta il punto di partenza di Woodle. Nel definire l’insieme di

elementi e di attributi da inserire per descrivere un problema, si è cercato di esporre la

maggiore flessibilità possibile, per evitare di dover costringere l’utente a rinunciare a

dei vincoli a causa dell’impossibilità di esprimerli. Sarebbe interessante eseguire uno

studio per cercare di evidenziare le carenze dell’attuale definizione e poter porre

rimedio ampliando o correggendo la struttura richiesta ai documenti.

Il secondo modulo che compone Woodle, il Searcher, è quello che dovrebbe richiedere

il maggior numero di interventi per il suo completamento. Nei capitoli precedenti (in

particolare nel capitolo 3), si è detto che, a causa dello stato attuale delle applicazioni

con cui si dovrebbe interfacciare, il modulo di ricerca si limita a simulare i risultati che

un ipotetico search engine per componenti (Gridle, per esempio) potrebbe restituire ad

un utente. In questo caso, sarebbe necessario effettuare delle ricerche per venire a

conoscenza di strumenti utili per gli scopi di Woodle e fornire le classi, estensioni della

classe astratta Querier, che consentano l’interrogazione dei motori di ricerca

individuati.

Una volta in possesso di un insieme funzionante di strumenti di ricerca, sarebbe

necessario eseguire uno studio per individuare quali siano le caratteristiche, associate ai

vari risultati, che i motori di ricerca restituiscono con maggiore frequenza. Tali attributi

dovrebbero, poi, venire utilizzati per aggiornare la struttura della classe SingleResult (il

singolo risultato della fase di ricerca), inducendo un miglioramento anche nei passi

seguenti che utilizzano oggetti di questo tipo.

Per quanto riguarda il modulo Parser, i miglioramenti, elencati sopra, sono già

realizzabili allo stato attuale delle tecnologie; questo, purtroppo, non è anche il caso del

Searcher. Nel capitolo 3 si è parlato, infatti, delle difficoltà incontrate nel reperire

motori di ricerca per componenti che soddisfacessero le esigenze dell’applicazione. Si

può immaginare che, con l’evolvere delle tecnologie e con la concretizzazione delle

idee espresse in [PSOL04], gli strumenti necessari per il completamento del modulo

possano diventare disponibili per un loro utilizzo effettivo.

In precedenza, all’interno di questo ultimo capitolo, si è affermato che il modulo

Selector è, insieme al Parser, il componente il cui stato può ritenersi più vicino alla

forma finale rispetto agli altri pezzi che compongono Woodle. Ovviamente, anche in

questo caso, esistono dei miglioramenti che possono essere apportati.

In primo luogo, sarebbe interessante definire nuovi tipi di algoritmi d’assegnamento,

basati sul calcolo di metriche diverse o con tempi di elaborazione differenti. Queste

nuove strategie risolutive andrebbero ad arricchire l’insieme posseduto dal modulo,

consentendo all’applicazione di effettuare una scelta più accurata della soluzione da

fornire e, all’utente, di poter richiedere il tipo di assegnamento che ritiene più consono

per la soluzione del suo problema.

Un ulteriore miglioramento potrebbe scaturire da un uso più accurato delle risorse:

attualmente il Selector richiede l’esecuzione in parallelo dei vari Assigner di cui dispone

e, dopo aver raccolto i dati da questi generati, seleziona la soluzione migliore.

È probabile che, con l’inserimento di nuovi algoritmi di assegnamento, alcuni dei

vecchi Assigner possano risultare meno buoni di altri per l’individuazione di una

soluzione ottima, magari perché il loro tempo d’esecuzione è maggiore di quello di un

altro algoritmo che riporta un risultato con le stesse caratteristiche. Il loro utilizzo si

restringerebbe, quindi, a quei casi in cui è l’utente stesso, per un qualsiasi motivo, a

richiederne le prestazioni, mentre nel normale comportamento dello strumento la loro

esecuzione non dovrebbe venire contemplata in quanto corrispondente ad un inutile

spreco di risorse.

Il quarto ed ultimo modulo, il WFCreator, è il cuore dell’applicazione. Allo stato attuale

consente la realizzazione di workflow sequenziali per l’elaborazione, secondo un

modello pipeline, di valori numerici. Inoltre, l’unico linguaggio di definizione di

workflow supportato è BPEL [A03] e, tra gli enactor capaci di gestire l’esecuzione di

processi scritti in tale formato, l’unico integrato all’interno di Woodle è ActiveBpel.

Per quanto riguarda l’estensione di questo modulo, il lavoro da svolgere è doppio

rispetto ai componenti descritti in precedenza. In primo luogo, bisogna fornire un

supporto per i vari linguaggi di definizione di workflow, individuando quelli più adatti

per l’integrazione in uno strumento come Woodle. Quest’ultimo aspetto è di importanza

fondamentale: nel capitolo 3 si è detto che l’idea iniziale prevedeva l’interfacciamento

con l’enactor FreeFluo e l’utilizzo del linguaggio Scufl, fondamentalmente a causa della

loro origine “scientifica” e non “aziendale”.

Durante i lavori di integrazione, si è dovuta riscontrare l’impossibilità di sfruttare lo

strumento, senza modificarlo, per un uso all’esterno del suo ambiente nativo, rendendo

inutile la capacità di Woodle di generare workflow in formato Scufl.

L’integrazione di vari workflow engine può procedere di pari passo con la ricerca di

nuovi linguaggi di definizione di workflow. Ad esempio, è possibile pensare di svolgere

un lavoro mirato ad ampliare l’insieme di enactor in grado di eseguire processi BPEL,

individuando i prodotti più interessanti e fornendo l’implementazione dell’interfaccia

Invoker che ne consenta l’utilizzo. Sarebbe utile poter inserire, nell’insieme di Invoker

posseduto dal modulo, oggetti capaci di interfacciarsi con strumenti di esecuzione di

workflow pensati e sviluppati per il mondo scientifico, in modo da fornire una prova

effettiva della flessibilità di Woodle.

Parallelamente a queste operazioni di ampliamento dell’insieme di linguaggi e strumenti

supportati, sarebbe bene apportare delle modifiche alle classi già esistenti

(BPELWFWriter e ActiveBpelInvoker) per permettere la realizzazione di workflow non

aderenti alla singola struttura pipeline e capaci di elaborare dati diversi da quelli

numerici.

Inoltre, sarebbe necessario effettuare delle analisi più approfondite sui documenti

WSDL, per permettere il reperimento dei dati d’interesse anche da file con

caratteristiche diverse da quelle proprie dei file dell’insieme di prova.

Esistono ancora alcuni miglioramenti che non si riferiscono ad un modulo in particolare

ma che hanno a che vedere con l’intera applicazione.

Innanzitutto, per permettere una diffusione dello strumento, sarebbe utile l’introduzione

di una interfaccia grafica che semplifichi l’interazione con l’utente. È abbastanza ovvio

che uno scambio di comunicazioni per mezzo della riga di comando non può avere lo

stesso impatto, anche in termini di soddisfazione del cliente, rispetto all’utilizzo di un

ambiente grafico.

Nella descrizione dell’applicazione è stato detto che Woodle ha bisogno d’interagire con

il suo utilizzatore soprattutto per il raffinamento della soluzione proposta dal Selector.

In presenza di un interfaccia grafica, l’utente potrebbe eliminare le soluzioni ritenute

non consone o soddisfacenti, agendo direttamente sulla rappresentazione del problema,

senza dover inserire manualmente l’identificatore del segnaposto il cui assegnamento

non lo soddisfa.

L’interfaccia potrebbe anche permettere di visualizzare, in seguito alla fase di ricerca,

l’elenco dei risultati associati ad un segnaposto, semplicemente cliccando sul nodo

d’interesse del grafo che rappresenta il problema. Inoltre, potrebbe consentire di

mostrare all’utente le caratteristiche della soluzione globale scelta e delle sue singole

sottoparti attraverso l’utilizzo di menù a tendina associati ai nodi o attraverso una

visualizzazione per mezzo di frame, come avviene, ad esempio, nello strumento di

amministrazione di ActiveBpel (BpelAdmin) [AB].

Una possibile estensione di Woodle potrebbe richiedere l’inserimento di un modulo in

grado di fornire suggerimenti all’utente durante la fase di creazione dell’assegnamento

segnaposti-componenti. Lo spunto per tale estensione è preso da [G04] presentato al

GGF11 [GGF11]. Probabilmente, per fornire funzionalità di questo tipo, potrebbe

risultare necessaria la codifica di tecniche di intelligenza artificiale, che permettano di

valutare dove l’utente possa avere dei dubbi sul modo di esprimere il problema.

L’ultimo miglioramento che viene proposto in questo capitolo ha a che vedere con la

personalizzazione dello strumento. Alcune idee sono già state riportate nei capitoli

precedenti, in questo caso vengono condensate in un’unica soluzione. Si potrebbe

pensare a Woodle come ad un’applicazione disponibile come un servizio, al quale gli

utenti si registrano per poter accedere. In questo modo sarebbe possibile mantenere una

sorta di data-base degli iscritti, nel quale sarebbero contenuti i profili e le preferenze dei

vari utenti. Una soluzione di questo genere consentirebbe di personalizzare l’esecuzione

dello strumento senza dover richiedere operazioni aggiuntive ai suoi clienti, favorendo

l’usabilità del prodotto.

Le impostazioni di default potrebbero riguardare il motore di ricerca da utilizzare per

individuare i componenti, i vincoli aggiuntivi che si vorrebbero sempre soddisfatti da

qualsiasi risultato trovato e che, quindi, potrebbero non venire ripetuti in ogni specifica

del problema, il tipo di assegnamento che si vuole venga generato, il formato del

workflow preferito ed il suo conseguente enactor.

Si noti che alcuni di questi dati potrebbero venire estratti semplicemente da una singola

informazione come l’appartenenza ad un determinato settore. Ad esempio, se un utente

dovesse indicare nel suo profilo che, per quanto lo riguarda, l’utilizzo principale di

Woodle è riservato alla generazione di workflow aziendali, sarebbe abbastanza ovvio

selezionare come linguaggio di descrizione del workflow lo standard BPEL.

Ovviamente, lo strumento dovrebbe anche essere in grado di ricevere informazioni che

permettano di non utilizzare i valori preimpostati, qualora l’utente decida di voler

sfruttare caratteristiche diverse da quelle decise al momento della registrazione.

Bibliografia

[AB] ActiveBpel, an open source BPEL engine. Informazioni disponibili su:

http://www.activebpel.org/info/intro.html.

[ABD] Deploying BPEL process. Disponibile su:

http://www.activebpel.org/docs/deploy.html.

[ACG86] S. Ahuja, N. Carriero, D. Gelernter. Linda and friends. IEEE Computer

(1986).

[AE] Active Endpoints, Inc. www.active-endpoints.com.

[AGG99] R. Armstrong, D. Gannon, A. Geist, K. Keahey, S. Kohn, L. McInnes, S.

Parker, B. Slominski. Toward a common component architecture for high performance

scientific computing. In: Conference on high performance distributed computing (1999)

[AHS93] F. Arbab, I. Herman, P. Spilling. An overview of manifold and its

implementations. Concurrency, practice and experience (1993).

[AM02] F. Arbab, F. Mevaddat. Dynamically adapting the behaviuor of software

components. In F. Arbab and C. Talcot, editors, Proc. 5

International Conference on

Coordination Models and Languages (COORDINATION 2002), volume 2315 di

LNCS, pagine 22-39, York, 2002. Springer.

[AP02] Apple Computer, Inc. Web Services Disponibile su:

http://developer.apple.com/documentation/WebObjects/Web_Services/Web_Services.pdf

[AT] Apache Tomcat servlet container. http://jakarta.apache.org/tomcat.

[AW] Active Webflow, Standard.

[A01] A. Albano. Costruire sistemi per basi di dati. Addison Wesley Longman, Milano,

2001.

[A03] T. Andrews, et. al. Specification: Business process execution language for web

services version 1.1. Technical report, IBM (2003) Disponibile su: http://www-

106.ibm.com/developerworks/webservices/library/ws-bpel

[A99] E. Angel. Interactive Computer Graphics: A top-down approach with OpenGL

(2nd edition). Addison Wesley (1999)

[BC91] A. Brogi, P. Ciancarini. The concurrent language, shared prolog. ACM

transcations on programming languages and systems (1991).

[BFGPS02] G. Bigi, A. Frangioni, G. Gallo, S. Pallottino, M. G. Scutellà. Appunti di

ricerca operativa. SEU (Servizio Editoriale Universitario), Pisa, 2002.

[BMCFPS] A. Bondavalli, I. Mura, S. Chiaradonna, R. Filippini, S. Poli, F. Sandrini.

DEEM: A Tool for the Dependability Modeling and Evaluation of Multiple Phased

Systems. dsn, vol. 00, no. , p. 231, International 2000.

[BP] S. Brin, L. Page. The Anatomy of a Large-Scale Hypertextual Web Search Engine.

[BPSMY04] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau.

Extensible Markup Language (XML) 1.0 (Third Edition). Disponibile su:

http://www.w3.org/TR/REC-xml/

[BR99] R. Baeza-Yates, B. Ribeiro-Neto. Modern Information Retrieval. Addison

Wesley 1999.

[B02] K. Burton. .NET Common Language Runtime Unleashed. SAMS (2002).

[CCMW03] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana. Web Services

Description Language (WSDL) 1.1. Technical report, W3C (2003). Disponibile su:

http://www.w3c.org/TR/wsdl.

[CFHIWT02] M. Clark, P. Fletcher, J. J. Hanson, R. Irani, M. Waterhouse, J. Thelin.

Web Services Business Strategies and Architectures. Wrox Press (2002)

[CG04] C. Globe. Building ad hoc (personal) workflows in an open world: myGrid

experiences. Disponibile su: http://www.isi.edu/~deelman/wfm-rg/.

[CG89] N. Carriero, D. Gelernter. Linda in context. Communications of the ACM

(1989)

[CG92] N. Carriero, D. Gelernter. Coordination languages and their significance.

Communication of the ACM, 35 (2): 97-107, 1992.

[CLK03] F. Curbera, F. Leymann, R. Khalaf. BPEL4WS (Business Process Execution

Language for Web Services). IBM (2003). Disponibile su:

http://www.daml.org/services/swsl/materials/bpel11.pdf

[CP] C. Plesums. Introduction to workflow.

[CWH00] M. Campione, K. Walrath, A. Hulm. The Java(TM) Tutorial: A Short Course

on the Basics (3

Edition). Addison-Wesley Professional 2000

[C01] P. Ciancarini. Lectures on Coordination: Theoretical Issues. Disponibile su:

http://www.cs.unibo.it/~cianca/wwwpages/seminari/2theory.pdf.

[DFP98] R. De Nicola, G. Ferrari, R. Pugliese. Klaim: a kernel language for agents

interaction and mobility. IEEE Transactions on Software Engineering (1998).

[D05] E. Deelman, et al. Pegasus: a Framework for Mapping Complex Scientific

Workflows onto Distributed Systems.Scientific Programming Journal, Gennaio 2005.

[FD] Dr. Frederica Darema, Senior Science and Technology Advisor. Next Generation

Software Research Directions. Director of the Next Generation Software Program.

National Science Foundation.

[FF] FreeFluo Overview. Disponibile su: http://freefluo.sourceforge.net/.

[FHRG] The Fraunhofer Resource Grid (FhRG). http://www.fhrg.fhg.de.

[FK99] I. Foster, C. Kesselman. The GRID: blueprint for a new computing

infrastructure. Morgan Kaufmann Publishers, USA, 1999

[FPTV04] T. Fahringer, S. Pllana, J. Testori, A. Villazon. Teuta: UML-based Modeling

and Specification of Grid Workflow Applications. Disponibile su:

http://www.isi.edu/~deelman/wfm-rg/.

[F04] I. Foster, et al. The WS Resource Framework, version 1.0. Disponibile su:

http://www.globus.org/wsrf/specs/ws-wsrf.pdf.

[GGF] The Grid Global Forum. http://www.gridforum.org o http://www.ggf.org.

[GGFA] The Grid Global Forum, Area/Group Structure.

http://www.ggf.org/ggf_areasgrps_overview.htm.

[GGF10] The tenth Grid Global Forum (Berlino, Marzo 2004).

http://www.ggf.org/ggf_events_past_10.htm.

[GGF11] The eleventh Grid Global Forum 11 (Honolulu, Giugno 2004)

http://www.ggf.org/ggf_events_past_11.htm.

[GGF12] The twelveth Grid Global Forum 12 (Bruxelles, Settembre 2004)

http://www.ggf.org/ggf_events_past_12.htm.

[GT] The Globus Toolkit.

http://www.globus.org.

[G04] Y. Gil. Interactive Composition of Scientific Workflows. Disponibile su:

http://www.isi.edu/~deelman/wfm-rg/.

[HP04] A. Hoheisel, F. J. Pfreundt. Workflow Specification in the Fraunhofer Resource

Grid.

Disponibile su: http://www.isi.edu/~deelman/wfm-rg/.

[H05] H. Haas. Web Service Activity. www.w3.org/2002/ws/.

[H97] G. Hamilton. Java Beans, API specification, version 1.01-a (1997).

[IBM] International Business Machine (IBM) Corporation. www.ibm.com.

[ISNP] Istituto sperimentale per la nutrizione delle piante.

www.isnp.it/manuali/glossario.htm

[ITI] IT Innovation. http://www.it-innovation.soton.ac.uk/.

[JRMI] Sun Technologies Inc. Java Remote Method Invocation (Java RMI).

http://java.sun.com/products/jdk/rmi/.

[J2API] Sun Technologies Inc. Java 1.4.2 API. Disponibili su:

http://java.sun.com/j2se/1.4.2/docs/api/.

[J2SE] Sun Technologies Inc. Java 2 SDK, Standard Edition Documentation.

http://java.sun.com/j2se/1.4.2/docs/index.html.

[KP96] A. Kelley, I. Pohl. C, didattica e programmazione. Addison-Wesley 1996

[KR03] J. F. Kurose, K. W. Ross. Computer networking: a Top-Down Approch

Featuring the Internet (2

edition). Addison Wesley 2003.

[L03] F. Leymann.Web Services Flow Language (WSFL). Technical report, IBM

(2003).

Disponibile su: http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.

[ML00] B. McLaughlin Java and XML. O’Reilly and Associates (2000).

[MS] Microsoft Corporation. www.microsoft.com.

[MSC] Microsoft Corporation. Visual C#. http://msdn.microsoft.com/vcsharp/.

[M89] T. Murata. Petri Nets: Properties, Analysis and Applications. Proceedings of the

IEEE, Vol. 77, No 4, April, 1989, pp. 541-580.

[NB] NetBeans community. www.netbeans.org.

[N05] D. Nickull. Service Oriented Architecture.

http://www.adobe.com/enterprise/pdfs/Services_Oriented_Architecture_from_Adobe.pd

f.

[PA98] G. Papadopoulos, F. Arbab. Coordination models and languages. Advances in

computers (1998).

[PG] Philip Greenspun, glossario disponibile alla pagina:

http://philip.greenspun.com/seia/glossary.

[PSOL04] D. Puppin, F. Silvestri, S. Orlando, D. Laforenza. Toward Gridle: a way to

build grid applications searching through an ecosystem of components. in Grid

Computing: Software Environments and Tools. Rana, Omer F.; Cunha, Jose C. (Eds.).

2006, Approx. 415 p. 140 illus., Softcover. ISBN: 1-85233-998-5

[PSOL05] Toward a Search Architecture for Software Components. To appear in

Concurrency & Computation: Practice & Experience.

[RLJ] D. Raggett, A. Le Hors, I. Jacobs. HTML 4.01 Specification. Disponibile su:

http://www.w3.org/TR/REC-html40/

[R04] M. Riou. WS-BPEL Guide (2004). Disponibile su:

http://smartcomps.kgbinternet.com/

[SJS] The Sun Java System Application Server 8.01. Disponibile su:

http://www.sun.com/software/products/appsrvr/index.xml.

[SOAP] Simple Object Access Protocol (SOAP) version 1.2. Disponibile su:

http://www.w3.org/TR/soap/.

[SRG03] R. Stevens, A. Robinson, C. A. Goble. myGrid: Personalised Bioinformatics

on the Information Grid. In proceedings of 11th International Conference on Intelligent

Systems in Molecular Biology, 29th June–3rd July 2003, Brisbane, Australia, published

Bioinformatics Vol. 19 Suppl. 1 2003, i302-i304.

[S04] A. Slominski. BPEL in Grids. Disponibile su: http://www.isi.edu/~deelman/wfm-

rg/.

[S97] B. Stroustrup. The C++ Programming Language, Third Edition. Addison-Wesley

1997

[TIA] GGF: Technology Innovators Area. http://www.ggf.org/ggf_areas_techinn.htm.

[TV12] Taverna 1.2. Disponibile su: http://taverna.sourceforge.net/.

[UML] Unified Modeling Language. http://www.uml.org.

[WFMRG] GGF: Workflow Management Research Group.

https://forge.gridforum.org/projects/wfm-rg/ o http://www.isi.edu/~deelman/wfm-rg/.

[WWWC] World Wide Web Consortium. http://www.w3c.org.

[W98] P. Wegner. Interactive foundation of computing. Theoretical Computer Science

1992.

Appendice: codice sorgente di Woodle

woodle.WFMain.java

/* * WFMain.java * * Created on 24 marzo 2005, 11.01 */ package woodle; import java.io.File; import woodle.structures.parser.UserRequests; import woodle.structures.searcher.SearchResults; import woodle.structures.selector.Assignment; import woodle.wfcreator.WFCreator; import woodle.selector.Selector; import woodle.searcher.Searcher; import woodle.parser.Parser; /** *

* @author Marco Scarpellini */

public class WFMain {

//parser module

private static Parser parser;

//search module, interfaces with the search engine private static Searcher searcher;

//selection module

private static Selector selector;

//workflow creation and execution module private static WFCreator creator;

//application input

private static File inputFile;

//directory that contains the enactors' directories String enactorsDir="C:\\enactors";

/**

* Creates a new instance of WFMain

* @param input the path of the file with the description of the user needs

public WFMain(String input) {

//set up the object representing the input file try{

inputFile=new File(input); }catch(NullPointerException npe){

System.out.println("wrong input file"); System.exit(-1);

}

//construct the parser parser=new Parser(inputFile); //construct the searcher searcher=new Searcher();

//construct the selector selector=new Selector();

//construct the creator

creator=new WFCreator(enactorsDir); }

/**

* Construct a new Main object,

* parse the input file, search for code using a given search engine.

* Select an Assignment between place holders and services. * Creates a workflow and asks an enactor for his execution. * @param args the command line arguments

public static void main(String[] args) { //construct the application

Nel documento WOODLE: un generatore di workflow basato sull'individuazione dinamica di componenti per applicazioni Grid-aware (pagine 81-200)