Newsgroup: it.comp.java
Titolo: Web services J2SE

 come gli passo l'applicazione?
* Il framework ws vuole il costruttore senza parametri perché, credo,
vuole gestire l'intero lifecycle -> come gli passo l'applicazione?
Io non ho idea su come fare. Ho dato una letta anche al libro "Getting
Started with Axis2" ma non mi pare molto un "Getting Started".... mi
pare dia per scontato che uno sappia vita morte e miracoli dei WS....
Alla fine, miracolo, ho scoperto che Java dalla ver 6 ha un motore di
ws integrato: Jax-ws. In pochissimi minuti, e usando una sola
annotazione, usando i tool commandline wsimport e wsgen ho creato un
webservice funzionante ed embedded (usando l'API Endpoint.publish()).
Questo approccio richiede ancora che sia presente un costruttore senza
argomenti (chissa perché!?!) ma poi per l'implementazione viene usato
un oggetto java, e non una classe. Meno male! In questo modo, posso
avere due costruttori, uno per far felice i tool commandline, l'altro
per poter passare l'oggetto Application e poi chiamare il publish.
Mi è venuto però un dubbio: sto facendo una cosa corretta, o è
'hacking'? Lo chiedo perché poi non vorrei trovarmi in una brutta
situazione poi...
Ho provato a creare un client Axis2 che si connettesse al servizio
creato con il JAX-WS del JDK. Stranamente, il server viene chiamato
correttamente con i parametri giusti, ma poi il dopo aver processato
la logica di business il metodo non ritorna client. Ovvero, il client
rimane in attesa all'infinito, come se il server si bloccasse da
qualche parte _dopo_ aver eseguito la logica del servizio. E' mai
capitato a qualcuno di voi? Il client generato invece da JAX-WS invece
funziona a meraviglia...
Ultima domanda: creando il servizio usando 'publish' del JDK, viene
instanziato un nuovo server http, per cui non posso usare la porta su
cui risponde l'applicazione web solitamente. Sapete se c'è per caso un
modo per farle convivere? Ad es, dicendo al servizio della JVM di
basarsi sul servlet container per lo strato di trasporto e informando
il servlet container di redirigere certe info al jdk...
Infine, se avete suggerimenti, non tanto per le domande specifiche, ma
per risolvere il mio problema di fondo, ovvero come creare un
webservice soap standard che possa avere un riferimento all'oggetto
della applicazione, sono tutto orecchi.
grazie e a buon rendere
Alex

Ciao,
prima di risponderti, ho una domanda da porti: Come mai la scelta dei
web services tradizionali? hai la necessità imposta da qualcuno o è
tutto nuovo?
Detto questo, axis2 è una delle implementazioni possibili dei web
service, forse una delle più "antiche", passatemi il termine. A fianco
ad essa ci sono le implementazioni specifiche che ruotano, ciascuna,
nell'ambito del proprio application server. WebSphere ha il suo,
glassfish il suo e via dicendo.
Sun ha così deciso di creare uno standard, chiamato Jax-ws, quello che
poi hai scoperto ed utilizzato tu stesso. Quest'ultimo, in quanto uno
standard, puoi metterlo un po' dove ti pare, credo tu possa
addirittura embeddarlo all'interno di un grizzly container. Nulla ti
vieta pertanto di utilizzarlo, è uno strumento eccellente.
**Il costruttore di default**
Come mai i WS impongono i costruttori di default? In realtà un po'
tutti i framework moderni li impongono, in quanto hanno tutti, chi
più, chi meno, integrati dei framework di dependency injection, ovvero
dei framework che si occupano di creare gli oggetti, secondo una
logica centralizzata e iniettarla all'interno del tuo oggetto. Il più
famoso di questi framework è spring.
**WS Alternativi**
Giusto perchè tu lo sappia, oltre a WS tradizionali, ne esistono anche
altre tipologie "nuove" nel senso che sono ancora in via di
consolidamento, non strettamente legate ad un protocollo di
comunicazione come soap, ma che ti danno la libertà di scegliere in
base alla necessità del momento o addirittura alla necessità che ha il
client specifico.
Uno di questi è jersey (jax-rs), estensione proprio di jax-ws e ti
consente di fare applicazioni in stile REST, ovvero un modello
applicativo che ti costringe a riflettere sull'albero di navigazione
delle risorse, usando almeno quattro dei metodi HTTP: GET, POST, PUT,
DELETE.
Oltre al vantaggio che una risorsa ha un unico URL, sul quale agisci
con uno dei metodi di cui sopra, avviene anche un concetto detto di
"negoziazione", grazie al quale il client dichiara la lingua che sta
parlando, dopo di chè, il messaggio viaggerà con quel content type,
chessò, json, ad esempio.
Dico JSON, perché se il tuo client è il browser, non effettua un
parsing del documento, l'ggetto viene immediatamente iniettato nella
pagina, come codice sorgente nativo, velocizzando l'esecuzione.
Maggiori info su REST su: 
http://it.wikipedia.org/wiki/Representational_State_Transfer
Maggiori info su Jersey (JAX-RS) su: 
http://en.wikipedia.org/wiki/JAX-RS
e su 
https://jersey.dev.java.net/
Maggiori info su come embeddare un servizio con Grizzly su:
http://weblogs.java.net/blog/survivant/archive/2010/08/07/grizzly-deployer-1919-new-features
Spero di essere stato di aiuto,
Davide.
On 27 Set, 13:01, "Alessandro Carraro (JUG Padova)"


 paiono dei limiti.
Ciao Alessandro,
io ti consiglio di lasciar perdere Axis2 e provare invece Apache CXF:
http://cxf.apache.org/
C'è anche un buon libro della PACKT:
https://www.packtpub.com/apache-cxf-web-service-development/book
Ciao
   Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org

Alex
ciao Nicola
-- 

 argomenti (chissa perché!?!)
Mi pare ovvio: come credi che il container crei il tuo servizio, se non 
invocando il costruttore senza parametri?
Se tu avessi un costruttore come dici tu (con parametro di tipo 
Application), come diavolo fa il container a sapere quale oggetto di 
tipo Application passare? Non lo può sapere.
L'oggetto Application di cui hai bisogno tu lo devi passare in altro 
modo, e soprattutto devi avere un contesto da cui reperirlo (questo se 
l'oggetto ha uno stato, altrimenti basta anche chiamare il costruttore 
ogni volta che si ha la necessità di accedere ai metodi definiti in 
Application).

 **WS Alternativi**
Come detto prima, mi piacciono, ma li vorrei evitare
1) Per potermi interfacciare con il maggior numero di potenziali
partner, ho bisogno di uno standard
2) Vorrei qualcosa di autodocumentativo (come WSDL, il quale non credo
funzioni anche per rest o json, ma sei liberissimo di smentirmi) per
ridurre al max l'ambiguità nella comunicazione con i partners e la
quantità di documentazione che è necessario inviare


Ciao Lucio!
Volevo chiederla nel JUG, ma ultimamente abbiamo avuto incompatibilità
di disponibilità: smettete di fare le riunioni i giorni in cui
battezzo i miei figli :D !
Cmq grazie mille della segnalazione, ammetto che delle alternative era
l'ultima che mi mancava di valutare era proprio quella... Murphy
rules! :)
corro a comprare il libro :)
p.s. per la presentazione sul ns. mirabolante framework, si sta
muovendo qualcosa... :) ti terrò infomrato

 ejb cosi' li rintracci via jndi
La ns. tencologia richiede solo un servlet container. Sarebbe bello
non dover introdurre nuove dipendenze, anche se di fatto il 99% dei
nostri deploy va su un Tomcat...


 Application).
L'oggetto è unico per tutta l'applicazione, e lo teniamo nel parametro
application del contsto del servlet container. Ovvero, la prima riga
della nostra unica servlet è:
Application app = (Application)mCtx.getAttribute("application")
Come detto prima, però, Axis correttamente è agnostico rispetto al
sistema di trasporto, per cui il servizio non ha a disposizione il
contesto della servlet (potrebbe non esserci). Ho il sospetto di dover
scrivere un modulo Axis, per poter risolvere, ma speravo ci fossero
vie alternative (vedi JAX-WS) più facili!

 Guarderò
Ah, non avevo riconosciuto l'url.... l'avevo già letto, risponde a
tutte le domande, meno quelle che ho posto ieri :)
Per quello le ho poste :) !

 gliene frega di come l'ho costruito?
Ma lascia stare quella roba che serve per casi particolari. Mettiamo che 
tu abbia il tuo webservice annotato:
@WebService
public class MyService {
     @Resource
     private WebServiceContext wsContext;
    //se Application è un EJB
    @EJB Application application;
    //se non è un EJB
    protected Application getApplication() {
        return ApplicationFactory.instance();
    }
    //se lo vuoi ottenerlo dal servlet container
    protected Application getApplication() {
       ServletContext sc = (ServletContext) 
wsContext.getMessageContext().get(MessageContext.SERVLET_CONTEXT);
       return (Application) sc.get("myApplication");
    }
    public String doSomething() {
       return application.doWork();
    }
}

     }
Ecco, è questo che andavo cercando! Grazie!! Ma dove si trova la
documentazione che spiega questa cosa basilare!!!
Ora rimane solo un problema: come diamine funziona la annotazione
@Resource?
Anche questo, purtroppo mi lega al container. IMHO è concettualmente
errato far si che una applicazione viva dentro un container, dovrebbe
essere lei a far partire un servlet engine come fosse un 'servizio'.
Btw, questa si che è una sega mentale. Fortunatamente ho trovato un
tutorial che spiega come integrare un servlet container a JAXWS:
http://java.dzone.com/articles/jax-ws-deployment-five-minute
Mi spiace che cmq queste cose non siano citate nei manuali ufficiali,
e uno debba andare in cerca su NG e tutorials...
grazie mille per l'interessamento e il prezioso aiuto
p.s.
La lib che importo per jax-ws mi fa pensare che l'impl del JDK non sia
poi sto granché. Usando la lib citata nel tutorial, si risolve anche
il problema di compatibilità con il client Axis :)

 essere lei a far partire un servlet engine come fosse un 'servizio'.
Non voglio scervellarmi troppo, ma non credo abbia molto senso quello 
che hai scritto ;)

 che hai scritto ;)
E' un po' il concetto dell'Application Server (per brevità
chiamiamolo  AS). Un tempo esistevano per java solo servlet
containers, gli AS sono venuti dopo con l'avvento degli EJB. Ma un AS,
strettamente da definizione, non è altro che un programma il cui scopo
è far andare altri programmi, fornendogli dei servizi come:
* Lifecycle
* JNDI
* Servlet Container
* Datasource Pool
* Server JMS
* Server SMTP
* ...
IMHO questi servizi dovrebbero essere fra loro scollegati, e ciascuna
app dovrebbe usufruire solo di quelli richiesti. Il punto è che imho
una applicazione non dovrebbe VIVERE dentro un servlet container, ma
al più USARE un servlet container per offrire la funzionalità web. un
AS non dovrebbe sempre imho dare per scontato che l'app usi il web
il discorso dell embedding è: come fa l'app container (mettiamo
glassfish) a far partire metro e poi a collegarlo a tomcat? meno male
che è tutto oss :)

 AS non dovrebbe sempre imho dare per scontato che l'app usi il web
guarda che gli ejb vengono deployati nel jar all'interno dell'ear e sono
completamente scollegati dal war che addirittura puo' non esserci.
l'ejb e' invocato via jndi e non c'entra nulla con il war e la web app.
Il fatto poi che la stragrandemaggioranza delle applicazioni hanno pure il
war e la webapp e' perche' semplicemente viene comodo spesso utilizzare il
browser come GUI piuttosto che farsi le applicazioni stand alone
ciauz Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/