Newsgroup: it.comp.java
Titolo: Sviluppare sistemi facilmente integrabili

La mia sfida è sviluppare 2 sistemi che dovranno, in futuro, dialogare
tra loro , passandosi dati e formalmente verificando che i processi di
transazione siano andati a buon fine.
Dopo una piccola ricerca su internet ho scoperto che Java mette a
disposizione diverse tecnologie atte all'integrazione di sistemi, come
Java RMI, JMS, WSDL* e altri di cui non ricordo il nome.
Ora, visto che lo sviluppo deve ancora partire, vorrei sapere se
conoscete una buona metodologia di analisi e quindi di implementazione
che ci permetta in futuro di integrare i 2 sistemi.
Ho pensato che, essendo i 2 sistemi basati su TOMCAT 5.0.16 e
j2sdk1.4.1, non dovrebbero esserci problemi a livello di
compatibilità: ma secondo voi è meglio utilizzare una tecnologia
"proprietaria" come RMI o JMS, oppure scriversi Servlet e/o Beans
sulla base di un analisi "soggettiva" ?
tempo max per lo sviluppo: ca. 10gg

sulla base di un analisi "soggettiva" ?
JMS non e' "proprietaria" - e' semplicemente l'interfaccia java-centric per 
una miriade di prodotti di message queueing (tipo JDBC coi database).
Il trucco per la facilita' di integrazione e' tutto li': o message-oriented 
middleware, oppure web services. Io in genere opto per il primo.
-- 
You dont know what to do when you dont know what you're doing.
http://space.tin.it/computer/csadun

...

Ti ringrazio della tempestiva risposta, ora perň il mio vero problema
č "capire" come realmente vada implementata una soluzione che leghi 2
sistemi in ottica MOM, il che mi fa pensare ad una implementazione di
JMS.
Pensi che l'utilizzo di tale interfaccia, quindi il tempo di
studiarselo e poi l'implementazione, possa giovare al progetto o
altrimenti possa rallentarlo ulteriormente?
Come mi dovrei comportare secondo te?
Ciao,
Grazie! e Buon Natale!!!



Data un archiettura con message bus e connectors per ogni applicazione, 
ci sono due livelli possibili: in uno, l'integrazione resta "tattica" 
(cioe' costruita ad hoc) ma la comunicazione tra i due sistemi avviene 
via coda (con messaggi punto-punto o publish/subscribe).
Cioe', invece di scrivere software che faccia direttamente da "ponte" tra 
i due sistemi ("chiama il primo", "chiama il secondo", "processa i 
risultati" eccetera), definisci un processo in termini di 
condizioni/eventi e passi relativi, e scrivi/configuri i connectors in 
modo tale che partecipino in questo processo - scambiandosi o abbonandosi 
a messaggi sul bus.
Nota che in questo modo, per ogni integrazione, in genere ti scrivi un 
processo nuovo e passi nuovi (ad esempio, query SQL specifiche sul 
database di uno dei due sistemi, etc). I vantaggi vengono dal fatto che 
le applicazioni sono disaccoppiate (piu' disaccoppiate che con tecniche 
di integrazione piu' ovvie), ma il reuso e' limitato.
Il secondo livello e' "strategico": in questo caso, le applicazioni 
espongono un'interfaccia standard (non in senso java, ma in senso di 
"servizi disponibili"), e ogni integrazione viene costruita invocando 
tale interfaccia. Ovviamente, cio' presume che l'interfaccia sia 
sufficientemente espressiva e potente - il che non e' affatto semplice, 
anche con applicazioni piu' o meno pre-packaged come moduli SAP, CRMs 
eccetera. In questo secondo caso, usi sia bus/messaggi (nel qual caso, 
sono i messaggi ad essere "standard") che webservices (RPC asincrone) per 
invocare i servizi.
In questo caso, hai sia vantaggi di disaccoppiamento che di reuso.
