Rails e SOA

[Antonio]

Salve a tutti,

prima di (ri)mettermi a studiacchiare Rails, volevo sapere in ambito SOA come è messo questo linguaggio.

In particolare supporto a SOAP (con le eventuali estenzioni per la sicurezza & Co), generazione WSDL, generazione automatica metodi-stub dai WSDL, REST, XML-RPC et similia

Mi interesserebbe una risposta da chi ha usato questi strumenti, perché, se anche ci fossero (come in PHP), ma fossero fatti con i piedi (sempre PHP), sarebbero comunque inutili .

Un saluto a tutti gli amanti delle rotaie

[Valeriano Manassero]

Salve a tutti,

prima di (ri)mettermi a studiacchiare Rails, volevo sapere in ambito SOA come è messo questo linguaggio.

In particolare supporto a SOAP (con le eventuali estenzioni per la sicurezza & Co), generazione WSDL, generazione automatica metodi-stub dai WSDL, REST, XML-RPC et similia

Mi interesserebbe una risposta da chi ha usato questi strumenti, perché, se anche ci fossero (come in PHP), ma fossero fatti con i piedi (sempre PHP), sarebbero comunque inutili .

Un saluto a tutti gli amanti delle rotaie

Rails ha seguoto l'approccio RESTful, esistono ottimi recipes in merito, ma non posso sharare il PDF ne tantomento il libro
Comunque, tanto per cominciare a farsi un'idea puoi dare un occhio a queste slides (salta le prime, sono solo marketing ):
RESTful XML Web Services with Ruby on Rails

Poi ti metti li 2 ore e scribacchi qualcosa e fai molto prima così a capire l'andazzo

[Antonio]

Rails ha seguoto l'approccio RESTful, esistono ottimi recipes in merito, ma non posso sharare il PDF ne tantomento il libro
Comunque, tanto per cominciare a farsi un'idea puoi dare un occhio a queste slides (salta le prime, sono solo marketing ):
RESTful XML Web Services with Ruby on Rails

Poi ti metti li 2 ore e scribacchi qualcosa e fai molto prima così a capire l'andazzo

Conosco l'approccio REST, ma per applicativi più complessi preferisco SOAP ed il poter passare strutture dati complesse ben definite (leggi oggetti) (ed è qui che PHP, non essendo tipizzato, entra completamente in crisi con SOAP, portandoti a dover fare ulteriore lavoro aggiuntivo).

[Valeriano Manassero]

Conosco l'approccio REST, ma per applicativi più complessi preferisco SOAP ed il poter passare strutture dati complesse ben definite (leggi oggetti) (ed è qui che PHP, non essendo tipizzato, entra completamente in crisi con SOAP, portandoti a dover fare ulteriore lavoro aggiuntivo).

Per un approccio più specifico, ho rintracciato un articolo che, a mio avviso, era piuttosto interessante anche se fatto a mo' di tutorial:
All Around the e-World: Tutorial : Cos' è REST ?

Se non erro, tratta anche la tipizzazione seppure solo in superficie, vedi se ti è utile.

[Antonio]

Per un approccio più specifico, ho rintracciato un articolo che, a mio avviso, era piuttosto interessante anche se fatto a mo' di tutorial:
All Around the e-World: Tutorial : Cos' è REST ?

Se non erro, tratta anche la tipizzazione seppure solo in superficie, vedi se ti è utile.

REST per API semplici può anche andar bene, ma i limiti si raggiungono abbastanza velocemente se si vuol fare qualcosa in più (basta soltanto avere la necessità di mettere in piedi una conversazione and ROA approach is out ).

Comuqne grazie per gli hint

[rtacconi]

Ho utilizzato WSDL con Rails. Ti devi salvere il WSDL per accedere ad un servizio SOAP, a parte questo e` molto semplice. Non ho mai creato un servizio con SOAP e Ruby, ma anche quello dovrebbe essere abbastanza semplice.

Come sai Rails e` basato su REST quindi altri linguaggi come Java e C# (.NET) sono molto piu` utilizzati ed hanno molte librerie da usare.

Mi piacerebbe capire perche` dici che REST e` limitato. Non sono un esperto di SOA, anche se conosco i vari pirncipi e teconologie. La parte forte di REST sono le sue ridotte operazioni fondamentali, ma e` possibile passare i dati che vuoi.

Certo se vuoi usare un workflow con BPEL, credo che Java sia meglio. E' possibile usare librerie Java con JRuby, eventualmente.

SOA non e` solamente REST o SOAP, ma puoi usare MOM o ESB. Trovo un sistema basato sui messaggi molto semplice e veloce. ActiveMQ, per esempio, puo` essere usato da svariati linguaggi ed e` molto performante.

[Antonio]

Mi piacerebbe capire perche` dici che REST e` limitato. Non sono un esperto di SOA, anche se conosco i vari pirncipi e teconologie. La parte forte di REST sono le sue ridotte operazioni fondamentali, ma e` possibile passare i dati che vuoi.

Certo se vuoi usare un workflow con BPEL, credo che Java sia meglio. E' possibile usare librerie Java con JRuby, eventualmente.

SOA non e` solamente REST o SOAP, ma puoi usare MOM o ESB. Trovo un sistema basato sui messaggi molto semplice e veloce. ActiveMQ, per esempio, puo` essere usato da svariati linguaggi ed e` molto performante.

REST è ottimo per servizi che non siano propriamente di backend (fare ad esempio un widget con SOAP è da pazzi insomma), ma SOAP è il più completo e ti permette l'interazione tra diversi sw in maniera trasparente (se implementato per bene)

SOAP è stateful ed usando le varie estensioni del protocollo puoi gestirti anche la sicurezza e fare molte altre cose interessanti che con REST dovresti implementarti: per avere una connessione pseudo-stateful dovresti prima richiedere la creazione di una sessione, riceverla, e poi usarla per i vari scambi di informazioni; poi devi controllare che i dati che ti sono passati corrispondano ai tipi che ti aspetti etc etc...

Con ESB, invece, devi sempre interfacciarti in qualche modo e preferisco farlo sempre con SOAP per avere degli applicativi che di default possano comunque dialogare tra loro in maniera standard (che, quindi, di base, non necessitano di ESB).

Attualmente sto utilizzando JBossAS+Seam, ma questo non significa che davanti non possa esserci un ESB che si occupa della gestione di tutti i servizi messi a disposizione e si comporta da firewall (quindi la parte relativa alla sicurezza la sposti dalle chiamate soap del sw all'ESB server).

[andrea.paiola]

EDITo

[rtacconi]

Ti segnalo questo progetto: ruote - index

Si tratta di un workflow engine dove il flusso puo` essere scritto con una DSL fatta in Ruby, oppure in XML o JSON.

Qui trovi la presentazione: ruote - presentations

Credo che possa essere usato al posto di BPEL e che sia molto piu` veloce e meno tedioso.

Potrebbe essere usato come processo in background e le applicationi posso interagire con REST. Altrimenti potrebbe essere integrato in una applicazione per configurare il suo workflow interno. Non credo che REST possa essere una limitazione, puoi passare quanti dati vuoi con il POST ed alla fine e` HTTP/HTTPS

[WizOfOz]

Visto che c'è fermento... chi sa dirmi in due parole... quali sono i "plus" di un linguaggio come Ruby e di RoR?

grazie

[Valeriano Manassero]

Visto che c'è fermento... chi sa dirmi in due parole... quali sono i "plus" di un linguaggio come Ruby e di RoR?

Ruby
Linguaggio completamente OOP che ha una particolarità, accomuna una potenza enorme dovuta, appunto, alla struttura ad oggetti con tanto di ereditarietà e polimorfismo (tanto per citare alcune possibilità) ad un linguaggio estremamente semplice ed intuitivo che ti da la possibilità di sviluppare dal piccolo script per un cron con quattro righe di codice fino ad arrivare a strutture molto complesse per le quali puoi sfruttare un sacco di librerie che puoi includere.
Cosa non da poco è, vista la struttura dell'ecosistema, la facilità nel riutilizzo del codice.
Inoltre, proprio data la forte leggibilità del linguaggio stesso, la curva di apprendimento è davvero irrisoria.

Ruby on Rails
Il Rails, di fatto, è un framework Web che vive di vita sua e si basa sul Ruby (ovviamente) per il linguaggio con cui sviluppi.
Naturalmente eredità tutti i vantaggi di Ruby con in più una gestione completamente MVC degli applicativi, un ORM integrato (che, tra l'altro ti rende molto più libero nella scelta del DB), la possibilità di gestire il routing dei metodi HTTP come più ti aggrada e molte altre belle feature secondarie che sono sempre utili.
La gestione delle Gems ti permette di sfruttare un sacco di plugin dalle più disparate funzionalità con un sistema molto semplice della gestione delle dipendenze.
Anche qui, curve di apprendimento davvero irrisorie e la gamma di potenziali sviluppatori è molto ampia perchè sia il newbie, sia l'advanced trovano ciò che serve, infatti vi sono davvero tonnellate di "magics", ovvero funzionalità già fatte dove, il solo richiamare un metodo in una tal maniera fa capire al framework come comportarsi (ad esempio nella gestione dei nomi plurali delle classi), ma ciò non è limitante per chi ha bisogno di maggior potenza visto che *tutto* è overridable. In parole povere, se devi tirar giù quattro paginette vai di scaffolding e poi rifinisci (qualche ora di lavoro totale), se invece devi andare fino, il tempo ovviamente sale, ma il framework non è mai di impedimento dandoti libertà assoluta.
Un ultima cosa che dai newbie non viene apprezzata, è la struttura di unit testing integrata che ti permete di rilasciare nuove versioni con vari upgrade avendo estrema velocità nel debugging per verificare di non aver reso qualche funzionalità antecedente "broken", tutto ciò, ovviamente, a patto di aver lavorato anche sulle classi di test in precedenza.

Se hai altre domande, se sono in grado di rispondere, fai pure

[rtacconi]

Concordo, poi grazie alle funzioni lambda anonime permette di creare DSL, per esempio:

validates_presence_of :title

e` una funzione come se fosse parte del linguaggio, ma e` definita da Rails. Come dice Valeriano e` semplice aggiungere e sovrascrivere funzionalita`. Le classi possono essere modificate in run-time e la stessa cosa per gli oggetti, questo da la possibilita` di metaprogrammazione avanzata. Pensa ad un oggetto che legge i metadati di una tabella e si mappa le colonne con delle nuove proprieta` dell'oggetto.

La possibilita` di creare DSL ha dato vita a vari framework per il testing e non solo. Come dice Valeriano il testing in Ruby e` ottimo. I test sono stati inventati ed adottati in Smalltalk e Ruby ne e` l'erede. Rails permette di essere testato semplicemente e genera tutta la struttura per iniziare a scrivere i test. La TDD e` molto semplice in Rails ed e` la scelta ideale.

Alla fine la qualita` del codice e` molto migliore ed anche le nostre 'skill'. Quando programmo in PHP torno a casa digrignado di denti, con Ruby con il sorriso e questo per me e` l'indicatore che funziona

Ruby
Linguaggio completamente OOP che ha una particolarità, accomuna una potenza enorme dovuta, appunto, alla struttura ad oggetti con tanto di ereditarietà e polimorfismo (tanto per citare alcune possibilità) ad un linguaggio estremamente semplice ed intuitivo che ti da la possibilità di sviluppare dal piccolo script per un cron con quattro righe di codice fino ad arrivare a strutture molto complesse per le quali puoi sfruttare un sacco di librerie che puoi includere.
Cosa non da poco è, vista la struttura dell'ecosistema, la facilità nel riutilizzo del codice.
Inoltre, proprio data la forte leggibilità del linguaggio stesso, la curva di apprendimento è davvero irrisoria.

Ruby on Rails
Il Rails, di fatto, è un framework Web che vive di vita sua e si basa sul Ruby (ovviamente) per il linguaggio con cui sviluppi.
Naturalmente eredità tutti i vantaggi di Ruby con in più una gestione completamente MVC degli applicativi, un ORM integrato (che, tra l'altro ti rende molto più libero nella scelta del DB), la possibilità di gestire il routing dei metodi HTTP come più ti aggrada e molte altre belle feature secondarie che sono sempre utili.
La gestione delle Gems ti permette di sfruttare un sacco di plugin dalle più disparate funzionalità con un sistema molto semplice della gestione delle dipendenze.
Anche qui, curve di apprendimento davvero irrisorie e la gamma di potenziali sviluppatori è molto ampia perchè sia il newbie, sia l'advanced trovano ciò che serve, infatti vi sono davvero tonnellate di "magics", ovvero funzionalità già fatte dove, il solo richiamare un metodo in una tal maniera fa capire al framework come comportarsi (ad esempio nella gestione dei nomi plurali delle classi), ma ciò non è limitante per chi ha bisogno di maggior potenza visto che *tutto* è overridable. In parole povere, se devi tirar giù quattro paginette vai di scaffolding e poi rifinisci (qualche ora di lavoro totale), se invece devi andare fino, il tempo ovviamente sale, ma il framework non è mai di impedimento dandoti libertà assoluta.
Un ultima cosa che dai newbie non viene apprezzata, è la struttura di unit testing integrata che ti permete di rilasciare nuove versioni con vari upgrade avendo estrema velocità nel debugging per verificare di non aver reso qualche funzionalità antecedente "broken", tutto ciò, ovviamente, a patto di aver lavorato anche sulle classi di test in precedenza.

Se hai altre domande, se sono in grado di rispondere, fai pure

[WizOfOz]

Mi avete incuriosito, magari gli darò un occhio, anche se molte di queste cose le ho già sentite promettere da altri linguaggi (e dal governo Berlusconi )

[rtacconi]

Mi avete incuriosito, magari gli darò un occhio, anche se molte di queste cose le ho già sentite promettere da altri linguaggi (e dal governo Berlusconi )

Ahah. Il linguaggio piu` simile e` Python, ma la fortuna di Ruby e` Rails,e` molto popolare e comodo.

[Valeriano Manassero]

Mi avete incuriosito, magari gli darò un occhio, anche se molte di queste cose le ho già sentite promettere da altri linguaggi (e dal governo Berlusconi )

Emh, queste non sono promesse, lo erano
Oggi è realtà, tra l'altro sto lavorando con la terza major release (attualmente in beta) ed hanno fatto un ulteriore passo in avanti.
Insomma, PHP ne esce a pezzi.
Il fatto che non sia molto diffuso è da attestarsi ad un discorso di gestione hosting. Lato sistemistico, infatti, Rails è un pelino più una rogna perchè bisogna dare all'utente la possibilità di installarsi le gemme (magari anche autoprodotte), io non mi sono mai posto il problema dato che lavoro su ambienti che gestisco, ma su uno shared la cosa è più complessa.