Jump to content
Sign in to follow this  
Antonio

Rails e SOA

Recommended Posts

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 :stordita:.

 

Un saluto a tutti gli amanti delle rotaie :)

Edited by Antonio

Share this post


Link to post
Share on other sites
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 :stordita:.

 

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 :asd: ):

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 :)

Share this post


Link to post
Share on other sites
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 :asd: ):

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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :zizi:).

 

Comuqne grazie per gli hint :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×