[JAVA] Webservice e invocazione periodica controllo dati...

[Fabiusssss]

Ciao a tutti! :-)

Scrivo per porvi una questione e vedere se qualche anima Pia può aiutarmi con la sua esperienza...
Allora, sostanzialmente io ho da realizzare un software Java che prevede l'interfacciamento di un workflow con un web service che "rappresenta" una rete di sensori di temperatura.

Bene, il mio software dovrebbe effettuare periodicamente dei controlli su questi valori di temperatura ricavati dai sensori (vedere se sono contenuti entro un certo range) e in base al risultato di validità ottenuto eseguire altre operazioni...

Il primo problema che mi si presenta è quello di stabilire come inserire il controllo sui valori...nel senso:

meglio invocare periodicamente il web service ricavando i valori di temperature e poi, lato client, effettuare i controlli, o meglio effettuae i controlli direttamente lato server (modificando il web service e passando tramite client i range da rispettare) e ritornare al client direttamente il risultato di tali controlli?
Io pensavo quasi alla seconda ipotesi, in modo da poter realizzare magari qualcosa di asincrono come la gestione interrupt...cioè il webservice continua ad analizzare le temperature e poi nel caso non siano valide ritorna il risultato al client...

ma è possibile secondo voi e la vostra esperienza, realizzare qualcosa di simile?

Eventualmente, poi, come posso implementare la periodicità dei controlli? Che classe è più opportuno utilizzare?

Vi ringrazio dell'attenzione...
Se qualcuno ha qualche suggerimento che mi può aiutare, grazie in anticipo!

Ciao

[tomminno]

Considera che il webservice è un'entità passiva, si attiva solo su chiamata, di suo non può monitorare continuamente una risorsa. Quello che puoi fare è avere un applicativo che continuamente lo chiama per ottenere i valori.
Per quanto riguarda la distribuzione delle competenze, io preferirei avere un webservice che ritorna i dati e il chiamante che li valida, in quanto non necessariamente tutti i chiamanti potrebbero applicare le stesse validazioni ai dati (potresti anche essere interessato a quelli fuori range per verificare lo stato di salute della tua rete di sensori) ed inoltre non è chiaro quali messaggi ritornare in caso di dati non validi, dovrebbe comunque ritornarti il valore con l'indicazione "fuori range"?

[PGI-Bis]

In verità il web-service può anche "attivarsi".

Cioè io posso scrivere un "modulo" che periodicamente piglia i dati dai sensori e li pasticcia e associarlo al contesto dell'applicazione web (si fa in Java EE ma anche in Rails o Lift e immagino pure in altri server). A quel punto ogni servlet, che è poi un risponditore, può servire la pagina, quando richiesta, appoggiandosi al modulo per... che ne so, trovare i dati analizzati più recenti o quel che deve fare.

Se questa sia anche una soluzione idonea al caso di specie dipende. Se la manipolazione dei dati è onerosa e i client sono delle ciofeche (tipo smartphone o altri dispositivi "thin") allora sarebbe meglio avere il modulo di acquisizione e trattamento sul server. Se sono dei PC allora si può pensare che la distribuzione del calcolo dia dei vantaggi in termini di prestazioni.

[Fabiusssss]

Intanto vi ringrazio entrambi delle risposte! Davvero gentilissimi!

Sostanzialmente, in caso di valori fuori range dovrebbe determinarsi il blocco dell'esecuzione di uno dei moduli del workflow, ragion per cui l'importanza è proprio basata solo su un concetto di validità: appena al workflow viene comunicata la presenza di un valore fuori range, esso sospende l'esecuzione.
In pratica il modulo del mio workflow deve rimanere in esecuzione per un tot di tempo e durante tutto questo tempo deve tenere monitorate le temperature.

Secondo voi quindi non è fattibile la realizzazione di un web-service che una volta invocato dal client (che gli fornisce quale è il range e la durata di esecuzione del suddetto modulo) continui per tutta la durata di esecuzione a tenere monitorate le temperature e in caso di non validità ritorni subito risposta negativa altrimenti continui per tutta la durata ritornando risposta positiva alla fine? Una sorta di sistema asincrono...non so come spiegarmi...
Sicuramente, dal punto di vista prestazionale e di autonomia del workflow dal servizio di monitoraggio temperatura, l'ideale sarebbe proprio quello di mettere il controllo nel lato server diciamo...però appunto ho le idee un po' confuse su ciò che sia realmente fattibile.

[PGI-Bis]

Puoi farlo tranquillamente, devi solo tenere a mente il fatto che una servlet muore nel momento in cui il client riceve la risposta.

Per avviare un flusso di calcolo parallelo destinato a persistere tra chiamate diverse al servizio web usi il contesto dell'applicazione web. Che, in pratica, significa avere un ContextListener che genera un modulo di servizio per la creazione e associazione dei flussi di monitoraggio, la servlet che riceve la richiesta del client usa questo modulo per avviare il monitoraggio.

Per la lettura dei dati il client deve mandare una seconda richiesta, alla stessa servlet o ad una servlet, mantenere la connessione http aperta per tutto il tempo mi sembra eccessivo.

[Fabiusssss]

Capisco...
dovrò approfondire meglio la questione del contextListener allora perchè non mi è sufficientemente chiara...sarò io che sono de coccio :)

Ciò che intendi dire è il rendere il flusso dei valori di temperatura generati dai sensori a se stante rispetto alle richieste di controllo provenienti dai client e quindi diciamo "indipendente"?
In modo tale che poi ogni richiesta, tramite un'apposito modulo personalizzato, sfrutti questo flusso di valori effettuandone i controlli e il monitoraggio necessari?

Ah, visto che ci sono ti faccio un'altra domanda...
per dare una ripetitività, una periodicità all'invocazione del web service che mi ritorna le temperature, che classe converrebbe utilizzare?

Scusami del disturbo e grazie di tutto il preziosissimo aiuto...

[PGI-Bis]

Dunque tu hai un flusso dati che consideriamo continuo. Poi hai dei client che ti danno dei parametri che devi applicare a questo flusso e che producono dei risultati che possono essere validi o invalidi.

Io qui ci vedo tre "moduli".

1. la rappresentazione del flusso dati - che arriverà da qualche periferica
2. il monitoraggio come funzione periodica applicata al flusso dati di prima
3. i client che inviano i parametri per la creazione dei monitoraggi e che vogliono sapere "come sia andata a finire".

1 va nel ContextListener
3 è una servlet (o due, una per l'avvio e una per l'ottenimento dei risultati)

Le servlet del punto 3 usano il contesto (getServletContext) per accedere al flusso dati e appioppargli un monitor creato secondo le richieste del client di turno e per leggere il risultato del monitoraggio.

Perchè usi il contesto? Semplicemente perchè il contesto è l'unica regione di memoria condivisa a cui le servlet possono accedere in sicurezza. il limite sussiste per via delle specifiche J2EE: le servlet nascono e muoiono insieme alle corrispondenti richieste http, non solo come istanze ma come classi, quindi non puoi usare campi che non siano immutabili.

Uno potrebbe pensare di poter creare un Timer nel processRequest di una servlet, associarlo ad un campo di istanza o di classe e di poterlo rileggere la volta dopo... no, non si può fare: non c'è alcuna garanzia che due esecuzione successive del servizio rappresentato da una stessa servlet siano gestite non solo dalla stessa istanza ma neppure dalla stessa classe.

Il contesto fa le veci di questa zona di memoria condivisa (è inizializzato all'avvio dell'applicazione web e perdura finchè l'applicazione è in esecuzione, a prescindere dalle richieste dei client).

La ripetizione dell'invocazione del servizio web è un compito del client. Non credo che ci siano istruzioni jsp per farlo ma puoi usare un setTimeout javascript (per il caso "fai partire il monitoraggio e controlla tra un'ora il risultato) o un setInterval (per ripetere a intervalli determinati l'invio della richiesta http di risultato).

Nota però che io mi sono fatto una certa idea del programma che dovresti fare e parlo di quella: non è detto che sia esattamente quello che cerchi anzi, magari parliamo di tutt'altro.

[Fabiusssss]

Sì sì, era grosso modo quello che avevo intuito...
N.B: le servlet del punto 3 sarebbero quindi appunto quella che riceve le richieste dai client che poi implementa il monitoraggio e quella che restituisce il risultato del monitoraggio al client, giusto?
Grazie mille per la spiegazione dettagliata!

Ah, a proposito...se il mio web-service rappresentante i sensori fosse già esistente e basato sul sistema SOAP quindi con un WSDL che lo descrive, ecc...potrei comunque adattare in qualche modo il tutto sencondo l'idea che hai proposto? Perchè teoricamente, per quel poco che ne so, l'uso di servlet o di un web service basato su SOAP e WSDL sono "tecniche" diverse (una usa richieste Http l'altra appunto SOAP con il descrittore), o sbaglio?

Riguardo al discorso sulla periodicità, ho sbagliato a scrivere, a spiegarmi... :)
intendevo riferirmi proprio al componente 2 della tua spiegazione, la funzione che si occupa del monitoraggio periodico...cioè, quale classe può essere ottimale per realizzare questa periodicità nel controllo?

[PGI-Bis]

Per l'idea che mi sono fatto come ti arrivino i dati dai sensori non è un problema anzi, forse qualche problema te lo risolve.

Avresti il server che in avvio (cioè quando il contextlistener ti dice che il servizio web è stato avviato) si connette al web-service per ricevere i dati.

Se il web-service trasmette i dati continuamente non devi star lì a creare un timer che periodicamente invii una richiesta di aggiornamento per ricevere le informazioni dai sensori: quella parte è già fatta.

Se invece il web-service usa http come transport-layer per i messaggi SOAP allora ti tocca il timer.

Per il timer puoi usare ScheduledThreadPoolExecutor che altro non è se non un thread (o più ma a te ne basta uno) che esegue a intervalli determinati una certa funzione.

Tieni sempre a mente che il timer devi crearlo e avviarlo nel ContextListener. Significa che tu crei tutte le classi che ti servono per gestire la ricezione dei dati dal web-service e per associargli dei monitor e salvare i dati, tutto quello che vuoi dopodichè crei l'istanza di questo "modulo" nel contextInitialized del ContextListener, la "registri" associandola ad una qualche chiave convenzionale nel ServletContext - che ottieni dal ServletContextEvent.

Le servlet che vogliano accedere ai metodi di questo modulo diranno:

ServletContext c = getContext();
IlMioModulone m = (IlMioModulone) c.getAttribute(la chiave di registrazione);
...fai qualcosa con m tipo m.registraMonitor(tempo, client, pimpumpam);

Ricorda anche di "uccidere" i thread che portano avanti il monitoraggio e la connessione al web-service nel metodo contextDestroyed del ContextListener.

[Fabiusssss]

Capisco...

Quindi, siccome il mio workflow YAWL (composto da più moduli in sequenza che rappresetano le fasi di un processo industriale), prevede che ci sia un motore che decide il modulo da mandare in esecuzione e che affida poi l'esecuzione di questo stesso modulo ad un custom service di gestione che alla fine altro non è che una servlet (il quale ha tutti i paramentri del range e della durata di esecuzione del modulo, già disponibili), potrei considerare il motore stesso come client e il custom service un server (motore e custom service dialogano via http)?
In modo tale da andare a modificare opportunamente lo stesso custom service creando l'altra servlet e usando l'idea di contesto che hai cosi dettagliatamente proposto?

In sostanza:


Motore di workflow -> custom service (servlet) -> webservice SOAP(sensori)

Andando ovviamente ad aggiungere nel punto e l'idea del contesto per avere accesso al flusso dati proveniente dal webservice e la creazione delle altre servlet per monitoraggio e restituzione risultati.
Può essere corretto?

Grazie di tutto

[PGI-Bis]

Sarebbe in verità:

motore -> servlet -> controllo -> ws-soap

Dove "controllo" è un secondo servizio in esecuzione permanente (gestito dal contesto) che dialoga con il servizio soap.

Esemplifichiamo uno scenario.

1. Il motore decide di attivare un certo monitoraggio
2. si collega alla servlet passandole i dati necessari
3. la servlet ottiene un riferimento al controllo e attiva il monitoraggio
4. la servlet "restituisce il controllo" (cioè invia al motore la risposta "monitoraggio attivato)

Il passaggio 3 fa sì che il server inizi un flusso di esecuzione separato che parla col sw-soap, raccoglie o trasforma dati... fa quel che vuole.

In soldoni significa che, http o non http, il protocollo di comunicazione tra motore e servlet non è persistente: è un po' come accendere la televisione, premi il pulsante una volta e quella parte, non serve tenere lì il dito.

Non è l'unica soluzione possibile. Se immaginiamo che motore e servlet dialoghino usando un protocollo persistente - cioè la connessione può restare attiva per periodi di tempo non brevi - allora potremmo dire:

1. il motore decide
2. si collega alla server
3. la servlet inizia a raccogliere/analizzare dati
4. la servlet termina il monitoraggio e risponde al motore

A differenza di prima qui motore e servlet restano in connessione per tutto il tempo necessario all'esecuzione del monitoraggio.

In questo caso la connessione è persistente. Non userei http come protocollo - sebbene sia opzionalmente persistente - ma una servlet non è necessariamente una HttpServlet. Non serve più il contesto per via della persistenza della connessione.

Esiste però un problema di parallellismo nel motore: se la connessione è persistente allora il motore in tanto può eseguire più monitoraggi in quanto sia in grado di generare più flussi di esecuzione paralleli - cioè mantenere attive più connessioni contemporaneamente.

Se vedessimo il motore come un browser web significherebbe dover aprire e tenere aperte più pagine (una per ogni richiesta di monitoraggio).

[Fabiusssss]

Il motore, in effetti, comunica via http con il custom service (la servlet) per delle interazioni fondamentali di base costituite da uno scambio di "messaggi" inerenti l'affidamento, da parte del motore al custom service, del modulo da eseguire: praticamente il controllo del modulo, le operazioni che deve fare (come il monitoraggio) il suo avvio e il suo arresto sono delegati a questo custom service.
Effettivamente non ci sono poi altre comunicazione intermiedie durante le operazioni del custom service, quindi è proprio il primo scenario prospettato.

Una volta terminata l'esecuzione del modulo e delle sue attività, il custom service non fa altro che segnalare al motore il completamento dell'esecuzione del modulo o in casi particolari la sua cancellazione dall'esecuzione; questo è proprio quello che dovrebbe accadere quando il custom service si accorge che le temperature provenienti dal sensore non sono più valide:
appena il modulo viene affidato dal motore al custom service (servlet), questo dovrebbe "dare il via" al monitoraggio sulle temperature provenienti dal WebService e, in caso di non validità, sospendere IMMEDIATAMENTE l'esecuzione segnalando il tutto al motore. In caso contrario invece il monitoraggio arriva fino alla fine della durata prevista senza incontrare alcuna violazione e quindi, alla fine, il custom service segnala al motore l'andata a buon fine dell'esecuzione del modulo).

Quindi alla fine si:
motore -> custom service (servlet di esecuzione del modulo) -> servlet di controllo -> WebService

[PGI-Bis]

Il controllo però non sarebbe una servlet ma una "semplice" istanza di un classe Java.

Considera che un web-server non è limitato all'esecuzione di servlet, a conti fatti è in tutto e per tutto una "normale" applicazione desktop con delle utilità predefinite (le servlet) che gli permettono di stabilire delle connessioni di rete.

Tieni anche conto del fatto che se il protocollo non è persistente il server non può notificare al motore il termine dell'esecuzione - regolare o per invalidità: dev'essere il motore a interrogare periodicamente il server per determinare lo stato della computazione.

[Fabiusssss]

Però secondo il manuale tecnico del workflow, il custom service estende un'interfaccia particolare che prevede degli end point predefiniti per le comunicazioni con il motore e lo stesso prevede il motore per le comunicazioni con il custom service...il tutto basato sull'invio di messaggi predefiniti che indicano appunto l'affidamento dell'esecuzione, il completamento, ecc.
Il tutto previsto diciamo così di default.

Ipotizziamo ad esempio di avere uno scenario di workflow di questo tipo:

ho 3 moduli da eseguire in successione e che devono avere garantite delle condizioni di temperatura per la loro esecuzione (ogni modulo ha i propri parametri);

nella specifica di workflow, ogni modulo ha indicato un custom service (tramite url) che, in sostanza, si occuperà dell'esecuzione del modulo stesso (può essere anche il medesimo custom service in comune fra tutti i moduli);

ho un motore che gestisce il flusso di esecuzione del workflow e quindi l'esecuzione dei vari moduli;

all'atto dell'esecuzione del workflow cosa accade?
il motore prende il primo modulo, vede quale custom service è indicato in esso, lo contatta e gli comunica che il "suo" modulo deve essere eseguito;
il custom service risponde con un messaggio di conferma e ottiene i parametri del modulo;
il custom service esegue le operazioni del modulo;
il custom service segnala al motore la fine dell'esecuzione:
N.B: queste comunicazioni sono svolte mediante appunto messaggi predefiniti su endpoint predefiniti dati dalle interfacce...

Chiaro che nel mio caso le operazioni che i moduli prevedono sono proprio questi monitoraggi sulle temperature. Quindi se il monitoraggio va a buon fine, ovvio che il custom service ritornerà il messaggio predefinito di esecuzione completata correttamente, in caso contrario dovrò trovare il modo di sollevare un eccezione...

Supponendo di avere già un webservice che ritorna le temperature e che si basa su SOAP e WSDL, ciò che inizialmente avevo pensato indipendentemente dalle interazioni tra motore e custom service, era di affidare a questo custom service (che appunto alla fine è una servlet) il ruolo di client, il quale avrebbe invocato un server così strutturato: una parte implementante l'interazione con il webservice dei sensori e una parte implementante i controlli sui dati ottenuti dai sensori stessi.
Questo per cercare appunto, come scritto all'inizio, di porre i controlli sul lato server e creare una sorta di asincronicità:
dal custom server (che avrebbe solo il ruolo di avviare e fermare l'esecuzione del modulo) invoco un metodo "controlla" sul server a cui passo gli estremi del range e la durata di esecuzione del modulo che diventa quindi pure il periodo di tempo in cui devo continuare a monitorare le temperature.
Tale metodo avvia il controllo sulle temperature ricavate invocando il web service SOAP e in caso negativo ritorna subito al client un messaggio, altrimenti prosegue per tutta la durata indicata e ritorna alla fine un messaggio positivo al client.

Questo per rendere un po' più dettagliato lo scenario in cui opero...

Lo stabilire come tutte queste componenti possano essere sistemate, il fare chiarezza riguardo a chi debba davvero fare la parte del client e chi del server e questa serie di "chiamate concatenate" è ciò che appunto mi manda in confusione...
Purtroppo mi rendo conto di avere poche conoscenze e una gran confusione... :muro: dovrò approfondire bene e riflettere

Grazie di tutto...

[Fabiusssss]

Scusa se ti disturbo ancora, ma vorrei ragionare un attimo e ridomandarti un parere... :)

supponendo di avere il mio custom service (che agli effetti è una servlet e infatti viene contattata dal motore) con a carico l'esecuzione di un modulo del workflow; potrei considerare questo una sorta di client e da esso invocare quello che potrei considerare il vero e proprio web-server, composto dal "blocco di controllo" + il "blocco"-webservice che mi fornisce le temperature?
In modo tale che il custom service, svolgendo la parte di client, si occupi solo delle operazioni di attivazione, sospensione e completamento del modulo, della ricezione risposta proveniente dal server di controllo e quindi delle interazioni con il motore.

Se io poi, come avevo accennato, considerassi di avere già un web service SOAP,m con proprio WSDL, che mi restituisce in uscita le temperature con una certa continuità, potrei modificarlo opportunamente integrandolo con un "blocco" di controllo?
Dovrei eventualmente realizzare un "metodo" che condensa in se il ricavare le temperature e le controlla, modificando quindi pure il wsdl?
O il blocco di controllo dovrei realizzarlo separatamente da ciò che è il webservice delle temperature?

Non riesco a inquadrare bene se ci sono alternative...

[PGI-Bis]

In realtà non c'è un problema di "dovere": l'application server è sufficientemente flessibile da permetterti di realizzare il programma nel modo che preferisci.

Puoi usare la servlet per contattare il web-service o puoi creare un modulo separato (cioè una classe che istanzi e rendi disponibile tramite il contesto) che la servlet userà, condividendolo, per gestire la comunicazione con il web-service.

Se devi scrivere anche il servizio SOAP le opzioni si espandono ulteriormente.

L'unico limite che il server ti dà è il fatto che il funzionamento della servlet deve essere interamente definito nel metodo processRequest e nel suo contesto. Non puoi (in linea di massima, poi ci sono un tot di eccezioni) usare campi dichiarati nella classe che estende la servlet, il che significa che non puoi lanciare processi in background definiti nella classe della servlet - ma puoi farlo se sono definiti in qualche altra classe ed esposti tramite il contesto.

Per il resto hai mano libera.

[Fabiusssss]

La servlet che intendi, è il custom service giusto?

Se hai ancora un attimo di pazienza dopo tutte le rotture che ti ho dato, cerco di spiegare meglio l'idea che avevo io (visto che tramite una tastiera e senza schemi è difficile rendere bene bene l'idea)... :-)

Io sino ad ora, nell'ambito del mio sistema, ho tre componenti sicure:

1 - motore che affida i moduli del workflow ai relativi custom service;
2 - custom service che gestisce i moduli del workflow li fa partire, li esegue, li completa (ed è una servlet, un servizio);
3 - WebService SOAP che mi fornisce temperature.

(1 e 2 costituiscono il mio workflow di gestione del processo industriale)

La mia idea, era quella di porre la parte dei controlli sul lato server in modo da lasciare il lato client (che consideravo essere il custom service) sgravato da compiti di controllo...in sostanza, quella di modificare il mio web service SOAP (e quindi i suoi eventuali metodi e il suo WSDL) facendo in modo che non ritorni più le temperature soltanto, ma che "salga di un livello" ritornando già il risultato del controllo sulle temperature…
ovviamente tale web service SOAP sarebbe stato invocato dal custom service passandogli gli estremi del range e il tempo di durata dei controlli: quando si rileva una temperatura invalida, il web service invia risposta negativa al custom service il quale blocca tutto, altrimenti prosegue il monitoraggio e alla scadenza del tempo di monitoraggio ritornerà risposta positiva.
Il tutto senza l’intenzione di creare ulteriori servlet. Solo modificando e “integrando” il web service SOAP con la parte di controllo.
Questa era l’idea iniziale…mi pare di capire però che non è realizzabile in effetti, giusto?

Ora, con la possibilità proposta da te di introdurre il contesto e rendere il “flusso di temperature” (e quindi l’interfacciamento con il web-service) una zona condivisa alle varie servlet, le quali vi accedono tramite un modulo implementante il monitoraggio e che ricevono le richieste dal client, mi ha un po’ sballato il tutto…nel senso che non capisco come inquadrare il custom service che già ho. E’ parte del server? Posso invece considerarlo il client?
Cioè, mi sarebbe chiaro se io avessi, poniamo il caso, un browser che fa da client e che invia richieste di monitoraggio temperatura ad una servlet…ma in una situazione come la mia dove in pratica è già una servlet a fare la richiesta di monitorare le temperature provenienti dal web service…come si inquadra il tutto?

[PGI-Bis]

Puoi fare anche quello che avevi in mente tu ma in quel caso il client deve restare connesso alla servlet per tutto il tempo di durata del monitoraggio.

Senza quella connessione la servlet non può dire al client "il monitoraggio è finito - nel bene o nel male".

[Fabiusssss]

Intendi che il custom service (la servlet) deve rimanere collegata per tutto il tempo al WebService SOAP modificato, giusto?
Perchè alla base della mia idea c'è il considerare come client il custom service, non il motore.

Perchè poi nel momento in cui il custom service riceve il responso sulla validità dal web service, invia il messaggio predefinito di terminata esecuzione al motore e termina l'esecuzione.

[PGI-Bis]

La connessione con una servlet http termina quando la servlet invia la prima risposta - a meno che l'http non sia impostato per persistere ma il firewall potrebbe non consentirlo.

Io motore mando in esecuzione la servlet X, la servlet risponde dicendo "ok" -> PAF, connessione terminata: la servlet non può più comunicare con il suo client. Dev'essere il client a contattarla una seconda volta.

Se vuoi che la servlet possa dire al motore che l'esecuzione è terminata devi tenere aperta la connessione tra motore e servlet per tutto il tempo in cui resta attiva la connessione servlet-webservice.

[Fabiusssss]

Credo in questo specifico caso del workflow in YAWL sia impostato per persistere...
le comunicazioni fra il motore e il custom service (quindi fra client e servlet), così come sono "impostate" nel workflow YAWL, prevedono una prima interazione del motore verso la servlet che la invita ad andare in esecuzione a cui corrisponde una risposta della servlet verso il motore che dice Ok avvio l'esecuzione...
Poi però, il client non invia altri messaggi alla servlet, la quale esegue le operazioni che deve eseguire (in questo caso sarebbe il monitoraggio) e alla fine invia al client, di spontanea iniziativa, un messaggio predefinito che indica il completamento dell'esecuzione.
Questo perlomeno è ciò che è scritto nel manuale tecnico di YAWL...

[PGI-Bis]

Be', se deve persistere... persisterà. Tra l'altro è anche più "facile" da fare perché il passaggio da motore a servlet a webservice a servlet a motore diventa sequenziale. Avrai una servlet con un processRequest fatto di una manciata di righe:

ricevi i parametri del motore
chiama il webservice
aspetta la risposta
ripassala al motore

[Fabiusssss]

Infatti...

La connessione fra la servlet e il webservice modificato invece, anche quella sarebbe meglio che non rimanesse attiva per tutto il tempo, giusto?
Dovrei fare in modo che dopo l'invocazione da parte della servlet, il webservice iniziasse il monitoraggio con la connessione che però si chiude...di conseguenza, finito il monitoraggio, il webservice dovrebbe invocare la servlet per comunicargli i risultati, giusto?

[PGI-Bis]

Qui il problema è se sia possibile o no sospendere l'esecuzione della servlet in attesa che il web-service comunichi il suo risultato.

Non dovrebbe essere possibile, nel senso che l'invio e la ricezione di dati di una servlet verso il suo client è gestito con i socket non bloccanti. Significa banalmente che non puoi fermare il thread che esegue la servlet in attesa che il web-service risponda perchè così facendo rischi di bloccare l'esecuzione di altre comunicazioni.

Potresti farlo solo se il server garantisse l'affidamento di ciascuna risposta ad un thread distinto ma non so se ci sia un parametro di configurazione che permetta di imporlo.

[Fabiusssss]

ma nel momento in cui da una servlet io invoco il metodo di un web service SOAP e questo metodo esegue dei controlli di una certa durata, nel frattempo lo stato della servlet come resta?
Cioè, la servlet in che posizione rimane? Che possibilità ci sono?

[PGI-Bis]

Per via dei socket non bloccanti la servlet può restare in attesa che la comunicazione con il web-service produca una risposta senza dover bloccare il thread che la sta eseguendo.

In teoria. Poi io una prova la farei che non si sa mai :D.

[Fabiusssss]

capisco...
Grazie mille, vedrò di provare semmai... :)

In ogni caso, ti sembra allora un'idea fattibile modificare il web service e il suo WSDL integrandolo con un nuovo metodo che esegua i controlli e facendo quindi in modo che dopo essere stato invocato non ritorni più le temperature direttamente bensì inizi il monitoraggio sulle stesse?

[PGI-Bis]

Fattible dovrebbe esserlo, bisogna vedere se sia un bene farlo. Il web-service che restituisce le temperature e stop ha una sua "essenzialità" che io preserverei anche perchè in caso di problemi è più facile verificare se il responsabile sia il web-service o no: lo invochi, restituisce il suo risultato nudo e crudo -> sai che funziona e testi qualcos'altro.

[Fabiusssss]

Eh su questo hai proprio ragione... :)

quindi alla fine la soluzione migliore sarebbe proprio quella con l'uso del contesto e del modulo per il controllo separato dal custom service mi par di capire...
allora il mio custom service diventa parte della mia applicazione server...assieme ad una classe che implementa i controlli e al web service che tramite l'utilizzo del contesto diventa una specie di risorsa condivisa a cui i custom service possono accedere tramite il modulo di controllo. Corretto così?

[PGI-Bis]

Sì. Adesso bisogna solo scrivere il tutto in codice :D.

[Fabiusssss]

eh già... :D
grazie delle tantissime delucidazioni. Gentilissimo.

Eventualmente, mi venissero dubbi, posso contare ancora sulle tue ottime spiegazioni? :)

[PGI-Bis]

Siamo qui. Buona digitazione!

[banryu79]

Siamo qui. Buona digitazione!
Plurale majestatis? :Prrr:

[PGI-Bis]

Era inteso "noi del forum". Ci sarebbe da preoccuparsi se iniziassi a usare la terza persona, modello Cesare.

"pgi risponderà"... disse pgi.

[Fabiusssss]

:D :D :D