Newsgroup: it.comp.java
Titolo: Ho bisogno di un consiglio

Ciao,
sto analizzando la tecnologia JAX-WS per realizzare dei webservice.
Questi webservice si dovranno appogiare ad uno strato di presistenza
gestito tramite JPA+Hibernate.
E' il primo esperimento che faccio di questo tipo. Fino ad oggi la mia
pila tecnologica prevedeva:
AXIS,SPRING,Ibatis
Dato che migreremo tutto il sistema su tecnologie più moderne
(pensavamo a SEAM) volevamo iniziare a farte un po' di esperienza con
alcune tecnologie che lo compongono.
Ecco la mia domanda è, prima il controller lo gestivo con SPRING. In
che direzione mi converrebbe cercare informazione per interfacciare
lo strato di persistenza con i  webservice?
Grazie Andrea


Ciao.
La domanda non e' molto chiara. Piu' precisamente non e' molto chiaro cosa
intendi per "nterfacciare"
Partendo alla larga Seam e' un framwork che permette e spinge verso la
destrutturazione dell'applicazione. Cioe' si tende a eliminare la
stratificazione forte a cipolla a cui si e' abituati. Questo non significa
che l'applicazione degrada ma al contrario che si e' piu' liberi.
Sta a voi poi decidere quanto e come isolare gli strati.
In questa ottica non c'e' molto da "interfacciare", si puo' tranquillamente
in un metodo chiamare il ws via Axis( o quello che vuoi ) e poi usare il db
via Ejb3-entity e quindi hibernate.
Se usate seam2 c'e' il supporto ws degli ejb che sostituisce axis. Io
personalmente ho usato gli ejb3-webservice solo per i WS lato server. E ho
sempre usato axis 1.4 per i ws-client ceh imho e' ottimo.
Quindi non so dirti se i ws degli ejb3 persistentizzano o meno, devi
documentarti. Ho avuto la tentazione di "attaccare" i ws agli ejb3-entity
creando una forma di persistenza dei ws, ma la cosa mi e' parsa da una
analisi veloce poco immediata e non molto standard e forse anche una idea
"sballata" ma magari era buona :)
Quindi prova a spiegare bene cosa intendi per
"Questi webservice si dovranno appogiare ad uno strato di presistenza"
se cioe' vuoi persistentizzare i dati in arrivo dai ws o usi la persistenza
per un db e magari viene fuori una discussione interessante :)
Ciao
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 "sballata" ma magari era buona :)
Che intendi dire?



Allora, non mi dare del matto :)
Mi e' capitato di lavorare su una applicazione che non aveva il db, ma solo
dei ws che parlavano a un'altra applicazione che aveva il db
In pratica i ws erano un db per molti aspetti.
Allora mi e' venuta il desiderio di avere hibernate ( JPA che sono
interfacce e non db api ) , non attaccate al db, ma ai ws che poi usavano il
db
Per capirci se io chiedevo le provincie di italia ai ws he li chiedevano al
db di fatto, se i Ws in qualche modo fossero stati "attaccati" ad hibernate
in pratica la jpa avrebbe potuto capire che io chiedevo di nuovo gli stessi
dati e non fare manco partire il ws.
Probabilmente e' fantascienza lol, ma magari neanche tanto ....



Beh direi che devo darti del matto ;).
IMHO webservice e database non sono due cose uniformabili nelle stesse
API.
Ad esempio i WS non hanno il concetto di transazione (che è anche un
concetto chiave).



Gia' infatti ci ho rinunciato hehe ;)
Pero' era intrigante l'idea.
oltre alle transazioni il problema grosso sono le chiavi/id
Si potrebbe fare che alcuni ws che hanno chiave obbligatoria ed estendono
una base class "ws-persistentable" potrebbero essere "persistentizzati"
Fossi all'universita' ci farei un pensierino a fare una JPA extension per
ws, magari per una tesi
verrebbe fuori una cosa carina



Secondo me non ha senso invece. Non che l'idea sia stupida, ma il
voler creare un provider JPA è fuori luogo, in quanto al massimo ti
può servire  solo una cache e un linguaggio per interrogare liste di
oggetti.
Entrambe le cose le puoi già implementare, ad sempio con EHCache e
JXPath, ma senza scomodare le JPA, le cui specifiche sono cablate su
database.
Per quanto riguarda invece il salvare oggetti, non è che
un'interfaccia JPa sarebbe più comoda di un
clientService.saveAnag(anag);