Ricevo, e pubblico con piacere un lungo commento al mio precedente post.
Grazie Davide (si è un mio omonimo) per le accese discussioni durante le ore lavorative :)!

Raccolgo con piacere il tuo invito ad integrare (integration! XD) e poi mi conosci e sai già che se non ti faccio opposizione mi manca il respiro…
Iniziamo mettendo in discussione l’indissolubilità di alcuni luoghi comuni presenti nel post.

Il progetto “sfidante”

I commerciali vendono per mestiere, ed è più che ovvio il fatto che l’immagine del prodotto conta molto. Sfondi una porta aperta. Se poi dici che allo sviluppatore questo stesso progetto verrà presentato come “sfidante”, piove sul bagnato.

Per quanto ne so, la prima cosa che la vita ti insegna, appena dopo aver appreso l’uso della parola, è che di norma “sfidante” = “sóla clamorosa”.

Dico di norma poiché è possibile distinguere almeno 2 tipi di sóle:

1. la sóla temporale: il progetto con 1000 giorni elapsed diventa da 100. Tipo un pokemon ma in modo meno fantasioso.
2. la sóla architetturale: il progetto diventa “sfidante” poiché l’architetto del progetto ha definito un’architettura talmente complessa che è finito in analisi (intendo dallo psichiatra).

More…Mentre nel primo caso il risultato è scontato (sviluppatore con evidenti sintomi da stress e in preda ai tic nervosi), nel secondo caso non è da escludere che lo sviluppatore impari anche qualcosa di utile. Innanzitutto che l’uso di un certo strumento/prodotto non è adatto a tutte le situazioni (specialmente la sua), e magari inizia a entrare in quell’ordine di idee che gli permetterà di individuare il contesto in cui sarebbe utile impiegarlo.

Quindi, con la sóla di tipo 2 non tutti i mali vengono per nuocere (invito quelli che stanno leggendo a trovare tutti i proverbi e modi di dire).

Le novità commerciali

Sarà anche una mia opinione personale poco condivisa, ma ritenere alcune architetture non usate essendo dei castelli in aria (non di carta! Di carte, semmai…) è un po’ inutilmente provocatorio. In realtà le prime cause di snobbamento (o snobbaggio?) delle nuove soluzioni sono la non comprensione della filosofia behind-the-architecture e l’ingente investimento (pecunia).

Esempio 1: la SOA è vastamente adottata. Che poi abbiano comprato o meno la suite AquaLogic (anche solo in parte) è un altro discorso. Non è possibile censire chi usa o meno la SOA, in quale misura e con quale criterio ( e non è obbligatorio che “servizio” = “WebServiceSOAPoverHTTPoJMSdefinitodaWSDL”).

Esempio 2: il Business Process Engeneering è una manna per alcuni e uno spauracchio per molti. A cominciare da tutti quelli che al suono di “processo” capiscono “batch notturno”.
Ovviamente, l’impiego di un prodotto costoso sotto molti punti di vista come un BPM, rappresenta una scelta strategica non incasellabile in tutti i contesti. [Chi ha letto il tuo intervento forse non sa che un’accesa discussione sul BPM è stato proprio il pomo della discordia che ti ha spinto a esternalizzare la tua opinione sul blog… XD ]

E questa WOA? Significa solo ed esclusivamente un ritorno alle origini?
Se fosse veramente così, cosa avrebbero da offrirci le società come Oracle (BEA), RedHat (Jboss), IBM, ecc.? Ci venderanno davvero qualcosa che integra a meraviglia tutta quella roba colorata tipo albero di Natale ruotato di 90 gradi in senso antiorario che c’è nel grafico? Sarà qualcosa di sconosciuto e dannatamente rivoluzionario, tipo un browser? Sarà uno pseudo-Google-Chrome Enterprise da 40.000€ per CPU?
Per ora non mi esprimo, ma spero di capirci di più a breve… Invito le società sopra citate a stupirci tutti.

Semplice e genuino

Ok sfruttare a pieno le potenzialità  delle tecnologie già esistenti che hanno fatto grande internet, ma ciò non deve diventare un pretesto per fare i McGyver muniti di notepad e tanta inventiva. Teniamo presente che il concetto di “semplice e genuino” è morto con la pubblicità del Mulino Bianco.

Il portale come una web application

Parlo solo ora del portale, isolandolo dagli altri argomenti in quanto nel tuo intervento si è trasformato in una sorta di capro espiatorio.
Il tuo esempio del palazzo calza solo dal punto di vista rappresentativo e commerciale, ovvero estrinseco.
Proviamo così:
Web application = casa (di qualsiasi genere)
Portale = condominio; portlet = appartamento.
Questo paragone dimostra che ti sbagli sull’interpretazione delle feature di un portale (i punti sono rifieriti ai tuoi):

1. Il fatto che il portale gestisca una profilazione anche ESTREMA degli attori è oggettivamente un vantaggio. Che poi una authentication/authorization esista già negli AppServer non è certo una novità. Per esempio JBoss Portal si basa addirittura sull’esistentissimo j_security_check e possiede un modulo di login che insiste su di esso. Questo implica la possibilità di autorizzare gli utenti ad accedere alle risorse web (page) o parti di esse (portlet) espandendo semplicente il modulo complesso messo a disposizione, senza implementarne uno di sana pianta. Traduzione: o’ login nun te lo devi mica inventà! ‘o devi allargà? Ce sta ggià un moduletto tanto caruccio da personalizzà. T’è capì?

2. Vero, ma nel portale è standard e out-of-the-box. Altrimenti dovresti demandare questa “feature” alla componente umana. Non ti basta partire già avanti? Vuoi anche il sangue?

3. Ma non ti lamentare proprio sempre… Hai pur sempre qualcosa di simil MVC… Anche se in realtà è più VC senza la M…

4. Si certo. Ma con SSO integrato, architettura standandard (JSR-168) e tutto il resto? Finchè ti gestisci sia portal che portlet, sono d’accordo. Immagina che tu debba integrare la portlet remota X sviluppata dal tizio Y. Glielo spieghi tu che deve rifare tutto per adattarsi ai tuoi non-standard?

Va distinto il CONCETTO dall’INTERPRETAZIONE e dall’IMPLEMENTAZIONE. Giudicare il concetto di portale da come è stato interpretato in un prodotto e implementato in uno scenario, non è corretto.
Se prendi una portlet e inizi a toglierle il proprio header e footer (con tasti per il minimize, maximize e funzioni aggiuntive tipo il doHelp, doEdit ecc), la rendi fissa all’interno dell’impaginazione, e continui con lobotomizzazioni del genere, è ovvio che poi il tuo portale strizzerà l’occhio alle web application generiche invece che apparire come la pagina personalizzata di Google.
Pensando a ciò che un portale può offrire, ce n’è parecchia di acqua calda da reinventare.

Il portale NON NASCE come una web application generica, ma LO PUO’ DIVENTARE a seconda di come viene messo in opera.

Concludendo…

Sono pienamente d’accordo con te quando dici che “Bisogna sforzarsi e sfruttare al meglio ciò che la tecnologia attuale ci offre”, ma ricordiamoci che fanno parte di questo insieme tutte le architetture, prodotti e strumenti citati nel corso dei nostri interventi. E pure quelli non citati.
E le tovaglie a quadrettoni mi fan venire l’orticaria!