Vaulting e procedure di esecuzione remota

Specifiche generali per le caratteristiche di vaulting

• Application server: questa unità gestisce la logica e i vari sottosistemi che costituiscono l'applicazione EDM-PDM.
• File server: una o più unità che mettono a disposizione lo storage fisico necessario per immagazzinare i dati documentali associate alle unità atomiche d'informazione gestite dal sistema EDM-PDM. Il file server gestisce, a livello di sistema, l'interazione con uno o più zone di memorizzazione (vault), che normalmente sono fatte coincidere con aree di filesystem.

(Questa stipulazione in pratica esclude interazioni - quali quelle tramite condivisione del filesystem - che richiedono una speciale preparazione sistemistica del client, al di là dell'installazione del software indispensabile).

Il vaulting è definito come il complesso di azioni che regola l'inserimento (check-in) e il prelievo (check-out), da parte di un client, del contenuto documentale di un'unità d'informazione.

In quest'ambito, possiamo distinguere almeno due domini funzionali, che sono discussi in quanto segue.

Vaulting logico

Checkout logico

Autorizzazione

Verifica che l'operazione richiesta sia permessa dal contesto del client e del documento

Esclusione (lock)

Distingue tra checkout esclusivo, che richiede l'esclusione di altri client dalla stessa operazione, e checkout condiviso. Ulteriori raffinamenti possono prevedere, nell'ambito del checkout esclusivo, di distinguere tra un lock opaco - che proibisca la possibilità di effettuare checkout condivisi - e un lock trasparente, che invece li consente. Se il sistema prevede la possibilità di effettuare il lock stealing, questa fase può interessare ulteriormente i sottosistemi di autorizzazione e messaging.

Name mapping

Al termine delle fasi precedenti, il sistema si occupa di prelevare dai metadati i dati di storage relativi al documento richiesto, convertendoli in un formato adatto al client. Ipotizzeremo che il risultato di quest'attività sia una URL, ad esempio:

ftp://user:password@ftp.cadlab.it/private/winzip.exe
http://www.microsoft.com/pub/BillSpeaksOut.doc
file://pcserver/cadvault/Assembly.e3

Questa ipotesi ha il vantaggio di permettere una rappresentazione omogenea dei vault, e capitalizza lo stato attuale della tecnologia, che mette a disposizioni una gran varietà di strumenti per la manipolazione delle URL.

Rollback

Nel caso in cui il client incontri un errore durante il checkout fisico, le azioni precedenti debbono essere cancellate e il database riportato in uno stato consistente. (Questa operazione complica notevolmente l'interazione col client, e viene talvolta trascurata, demandandone le funzioni ad un reset manuale della condizione di errore).

Messaging

Facoltativamente, al termine del checkout può essere attivata una fase di comunicazione ad altri utenti del sistema che possono essere registrati come osservatori di questo particolare evento.

Checkin logico

Autorizzazione

Verifica che l'operazione richiesta sia permessa dal contesto del client e del documento

Esclusione (lock)

A seconda dei livelli di lock implementati e della logica di esclusione, l'operazione può essere permessa o vietata. Ad esempio una logica abbastanza diffusa, mutuata da sistemi quali RCS, impedisce il checkin a chi non detenga già un lock esclusivo per il documento interessato.

Name mapping

Il compito di questo sottosistema è convertire l'identificativo del documento in una URL. Nel caso il documento sia già associato ad un file, questo processo è analogo a quanto visto nel caso del checkout; se, invece, non esistono file associati (si tratta, cioè del primo checkin) il sottosistema si deve occupare di generare i dati di storage appropriati, determinando un nome di forma adatta per il file) tale, ad esempio, da garantire che non avvengano collisioni con altri file al momento della scrittura fisica. Il risultato di questa operazione sarà, come già discusso, una URL.

Rollback

Agisce analogamente al caso del checkout.

Messaging

Agisce analogamente al caso del checkout.

Vaulting fisico

Compiti del client

• Segnalazione inizio attività
• GET (checkout) o PUT (checkin) generalizzati della URL che viene restituita dall'application server;
• Gestione degli eventuali errori e segnalazione all'application server della fine della transazione (come notato poc'anzi, alcuni scelgono di non implementare questo passo)

Interazioni nel quadro del progetto SPI-10

Invocazione di applicazioni

A seguito della richiesta di apertura del documento, il tmm_server deve compiere alcune operazioni, così schematizzabili :

• A seconda del tipo di documento, tmm_server deve identificare un agente appropriato e, ove richiesto, eseguire operazioni preparatorie;
• L'informazione così sintetizzata deve essere trasmessa a Java UI (questo può essere fatto, ad esempio, trasmettendo la URL di una pagina attiva - cgi-bin, ad esempio - che generi dinamicamente un tag <APPLET> completo dei parametri appropriati alla fase successiva)

Interazione con il vaulting e il sistema

Al termine dell'interazione con il sistema di vaulting (e ipotizzando che l'agente sia stato in grado di procurarsi i permessi di esecuzione adeguati interagendo con il Java Security Manager del browser) sarà mandato in esecuzione il programma di manipolazione dei dati vero e proprio.

Dettagli implementativi

• url:=doc->checkout()
  esegue le operazioni di checkout e restituisce l'url alla quale e' possibile reperire il file corrispondente all'entità di tipo documento. Nel caso il documento non sia nel vault viene restituito un errore.
• url:=doc->checkin()
  esegue le operazioni di checkin e restituisce l'url alla quale deve essere memorizzato il file corrispondente all'entità di tipo documento. Nel caso di primo checkin il documento viene registrato nel vault.
• doc->uncheckout()
  esegue le operazioni di uncheckout.

Note