Architettura

ASP, SaaS e Software plus Services e le piattaforme future

Giancarlo Sudano — Thu, 06 Dec 2007 10:36:35 GMT

Stuzzicato da un post su Guisa (che adesso non trovo :-), ma anche dal fatto di aver sentito direttamente da un po di persone che non c'è una chiara percezione delle differenze tra queste definizioni, ci scrivo su qualcosa.

Partiamo dalla definizione più vecchie:

OnPremise Installation
E' un Modello di Delivery che tutti conosciamo. Applicazioni, Line of Business, installate sui server della propria azienda. Per quanto le applicazioni in questo modo siano controllabili, customizzabili, rappresentano un costo per l'azienda in termini di manutenzione e personale specializzato. La controparte di OnPremise è un delivery OnDemand, cioè l'outsourcing delle applicazioni.

ASP (Application Service Provider)
E' la prima forma di delivery OnDemand. E qui facciamo un salto indietro anche di dieci anni. I principi di ASP partivano dal presupposto di spostare le applicazioni scritte per le aziende in host (o sarebbe meglio dire in "house") di terze parti in modo da liberarsi dell'infrastruttura necessaria per la gestione/manutenzione. E' una forma intermedia di outsourcing delle applicazioni.
Idea non malvagia ma fondamentalmente i problemi con questo modello rimanevano due:
Dal lato del provider: Si arriva ad avere DataCenter disomogeneri, ammassi di server con diverse caratteristiche e alti costi di manutenzione.
Dal lato dell'azienda enterprise consumer: La gestione dell'applicativo hostato in ASP necessità di risorse con skill specializzato sempre all'interno dell'azienda. Si è spostata l'infrastruttura ma non si risolve totalmente il problema.

SaaS (Software as a Service)
Veniamo ai tempi più moderni. Software as a Service è ancora un modello di Delivery.
Alcune aziende cominciano a fornire servizi specializzati totalmente OnDemand. Servizi hostati e manutenuti dal provider stesso. Questo è un modello più completo di outsourcing delle applicazioni.
Sia come installazione che come manutenzione giornaliera e operazioni tecniche di supporto.
Con SaaS, il software può anche essere reso disponibile a settori di mercato ampiamente differenti: Home consumer, small business, o enterprise.
Un esempio:
Applicazione OnPremise: Microsoft Exchange all'interno dell'azienda
Applicazione SaaS: Microsoft Exchange fornito da un provider di terze parti.
Questo è l'outsourcing.
Applicazione OnDemand e gestione dell'applicazione OnDemand.
E' un modello che funziona? Secondo gli analisti del mercato, AMR, Gartner, Forrester Research, non solo funziona ma avrà un trend di crescita molto forte nei prossimi anni, contro una diminuzione delle installazioni OnPremise.
Non è difficile capire il perchè del successo.
Le aziende non affrontano più grossi investimenti iniziali per i software, ma pagano OnDemand, con un ROI immediato.
Microsoft fornisce ad esempio il suo CRM come SaaS, SalesForce.com fa la stessa cosa. Segnatevi bene questo termine: "in the cloud" perchè lo sentirete spesso dire nei prossimi anni. I provider e le software house cominciano a spostare le proprie applicazioni "from OnDemand Installation, to the cloud".
Ma si può pensare a un modello SaaS puro...diciamo al 100%? Può un'enterprise avere tutto in outsourcing? Ci sono cmq dei problemi da affrontare, ad esempio la customizzazione, o l'identità e la sicurezza. Nascono già adesso e si incrementeranno in futuro applicazioni "composite" che uniscono servizi OnPremise, e in the cloud.

S+S (Software plus Services)
Differenza fondamentale! questo non è un modello di delivery. Comprende piuttosto la scrittura di applicativi o line of business "mashup" sia con servizi OnPremise che con servizi in the cloud.
Esempio:
Applicazione S+S: Microsoft Exchange all'interno dell'azienda e Microsoft Exchange Hosted Services.
Non sono la stessa applicazione, una volta OnPremise, una volta in the cloud. Gli hosted services offrono servizi aggiuntivi e non condividono una linea di codice con Exchange.
S+S è un "brand" di Microsoft.
La definizione "sotto sotto" è proprio: applicativi/servizi/LOB compositi con servizi OnPremise e in the cloud per prendere il meglio dei due mondi.
Il fatto di mettere un brand ha assolutamente senso! E vi sarà chiaro tra un po.
Errori che ho visto in giro:
1. Accostare S+S a SaaS considerandoli sinomini. No! S+S è un modello di scrittura di applicazioni, SaaS è un modello di delivery. Tutti e due investono anche architetturalmente il disegno degli applicativi ma non facciamo errori grossolani.
2. Accostare S+S con gli Smart Client. No! Altro errore grossolano, gli Smart Client sono applicazioni che possono girare sui Client anche in assenza di connessione e con capacità di sincronizzazione...tutt'altra premessa.

Come dicevo prima gli Hosted Exchange Services forniscono servizi aggiuntivi, e non condividono linee di codice con Exchange stesso. Stessa cosa dicasi con i BizTalk Services rispetto a Biztalk Server. Questo è un importante punto di riflessione:
Non esiste allo stato attuale un modello unificato per costruire applicazioni che rispondano alle premesse di S+S.
E questo è esattamente la visione strategica di Oslo. Cioè una piattaforma orientata allo sviluppo di applicazioni S+S, dalla modellazione, alla gestione del ciclo di vita al deploy finale.

Ecco perchè un brand nuovo. S+S.
Perchè questo è il terreno dove i grandi vendor si stanno dando battaglia e dove vedremo scontri titanici nei prossimi due anni.

Qualche indiscrezione sull'imminente libro di Martin Fowler

Giancarlo Sudano — Tue, 27 Nov 2007 17:48:22 GMT

Tratterà dei DSL (Domain Specific Language).
Leggete qui.

Nuovi Mastering Objectway: Architetture e Web

Giancarlo Sudano — Tue, 28 Aug 2007 19:05:53 GMT

La stagione scorsa, il progetto Mastering di Objectway (visto nell'ottica delle due giornate di formazione) è andato benissimo con i tre mastering di NHibernate. Quest'anno si riparte alla grande, con due grossi appuntamenti nel mese di Ottobre.

Il 2/3 Ottobre terrò un:
Mastering .NET Enterprise Architecture
e il 29/30:
Mastering .NET Enterprise Web Application

Una premessa fondamentale: sono due corsi basati fortemente su architetture a servizi secondo i principi SOA.
Il primo si concentra sulle architetture applicative in generale, e il secondo si focalizza sul applicazioni web di tipo enterprise fortemente "scalabili" in complessità.

Ho voluto evitare la strada dello studio e dell'applicazione dei classici design pattern.
Verrà data invece molta importanza agli attuali framework:
Windows Communication Foundation per il disegno orientato ai servizi
Windows Workflow Foundation per modellare e orchestrare i processi di business
ORM per costruire Layer di accesso ai dati basati su Contesti di Persistenza
Spring.NET per l'inversione di controllo e l'Aspect Oriented Programming
E sugli impatti architetturali derivanti dalla loro adozione.

Fondamentale: Software Factories!
Queste ultime sono un mezzo molto potente per far si che le figure di Solution Architect possano:

1. Preparare piani di implementazione per gruppi anche numerosi di sviluppatori.
2. Imporre regole e guidelines architetturali da far rispettare durante tutto il ciclo di vita applicativo.
3. Creare progetti non rigidi, ma estendibili e manutenibili.
4. Consentire il Test su tutte le parti dell'applicativo (non solo unit test! ma fare architetture che permettano test web efficaci).

Parleremo quindi di di Web Client Software Factory, e di Web Service Software Factory.
Non mancherà neanche qualche "giusto" cenno al ruolo di architetto e del team di lavor, secondo Microsoft Solution Framework.

Come di consueto....si pranza tutti al Picahna, con le mie due colleghe (gnocche) Elena e Gilda che dietro le quinte organizzano la comunicazione e la logistica dei vari mastering.

JAOO 2007 in Danimarca

Giancarlo Sudano — Sun, 01 Jul 2007 11:29:00 GMT

Questa sarebbe rigorosamente da non perdere, per architetti e sviluppatori...

JAOO 2007 Si svolgerà dal 23 al 28 Settembre, in Danimarca (ottimo motivo per andare a prescindere dalla conferenza...:-))

La lista degli speaker fa realisticamente paura, stiamo parlando infatti dei migliori "guru" mondiali, giusto per nominarne qualcuno:

Frank Buschmann, Jimmy Nilsson, Jeff Sutherland e Ken Schwaber, Robert Martin, Martin Fowler, Eric Evans, Erik Meijer, Ted Neward...(ne devo dire altri??)

Ci sono circa 6 track in parallelo al giorno. Giusto per far venire invidia queste sono le track.
E devo dire con molto piacere che brilla la track LINQ, con un bellissimo Linq for Domain Driven Design finale di Jimmy Nilsson.

SPE-TTA-CO-LO.

Domain Model e compromessi tecnologici

Giancarlo Sudano — Fri, 29 Jun 2007 17:46:00 GMT

Approfitto di questo commento sul mio post dell'altro ieri, per scrivere due parole, perchè l'argomento meritava di essere approfondito.

Mario dice:

"...L'unico passaggio su cui non concordo proprio in pieno, se l'ho capito bene, è questo:
...ma si vede che cmq in ogni caso, qualche "pezzo" di pulizia del modello di dominio, in un modo o nell'altro bisogna cederlo.
Mi ricordo l'illuminante chiacchierata con te sulle collection; quando hai detto che utilizzare IList<T> non era un vincolo di NH ma la scelta migliore di design ci ho pensato su 10 secondi e ti ho risposto "Vero! Hai ragione!" e da allora nelle mie entities compare IList<T>..."

Cioè si parla di come alcuni O/RM possano incidere in qualche modo sul disegno delle classi.

Il mio pensiero è questo (cerco di espanderlo):

Sia con NHibernate che con Linq to SQL, ma con qualsiasi sistema di persistenza c'è la necessità di adattare (con impatti magari diversi) il proprio Domain Model in modo che possa funzionare a puntino.

Chiavi primarie
In un mondo puramente teorico, uno potremme immaginare di modellare delle Entity, senza l'informazione della chiave primaria. Ques'ultima è un dato che serve solo ed esclusivamente al sistema di storage. Anche NHibernate potrebbe funzionare senza chiavi primarie (pratica sconsigliatissima).
Il contesto di persistenza (la sua session) potrebbe, una volta tirati su gli oggetti, tenere in memoria l'accoppiata Entity/Chiave. La responsabilità della gestione di una chiave che arriva dal database (o anche generata sul client poco importa) non dovrebbe essere della entità, poichè quest'ultima dovrebbe essere ignorante al modo in cui viene persistita.
Ma ovviamente i contraccolpi sarebbero pesantissimi. I contesti di persistenza sarebbero costretti a sopravvivere a tutta la conversazione applicativa, e questo (in alcuni casi) non è per niente una bella soluzione.

Gestione dei Proxy
Se il Domain Model è costituito da un grafo complesso in cui alcuni dei nodi non vengono caricati immediatamente perchè non servono allo scenario corrente, devo disegnare le classi in modo che una factory ci possa costruire sopra dei proxy. E quindi devo evitare sealed, usare metodi virtual oppure inventarmi delle interfacce. Cambio il disegno, e l'unico motivo per cui lo faccio è perchè devo abilitare il mio domain model alla persistenza.

Identità
NHibernate per garantire l'identità (così come espressa nel CLR) entity che hanno chiavi composite impone che la entity in questione implementi i metodi Equals() e GetHashcode(). Ma ancora è un problema di persistenza. Non di dominio.

Avrei altri esempi in termini di serializzazione, stati e tracking, ma non mi dilungo.

In pratica, ci sono molte problematiche di persistenza che intaccano in un modo o nell'altro il disegno della propria entity, su questo non vi è dubbio. Poi ci possono essere soluzioni più o meno eleganti. L'uso di EntityRef su Linq to SQL per esempio non è una soluzione malvagia. E' la rappresentazione del concetto di proxy o wrapper, e non è riferita al sistema di persistenza. Vedo molto meno l'uso di EntitySet. Al suo posto avrei visto una soluzione un po più alla NHibernate, cioè lasciare che la gente scriva le proprie entity usanto interfacce e poi iniettando la collection corretta a seconda dello scenario (Devo ancora approfondire...magari qualcosa si può fare).

La conclusione è che, non necessariamente si deve essere totalmente "puristi".
Bisogna saggiamente valutare il valore aggiunto apportato ad esempio da una chiave primaria su una entity, o dell'aggiunta di virtual per garantire la creazione di proxy, o di qualsiasi altra cosa, e bilanciarlo con la pulizia concettuale del domain model, arrivando ne più ne meno ad un compromesso tecnologico.

Application Platform Roadshow...c'è anche GUISA

Giancarlo Sudano — Thu, 29 Mar 2007 21:30:00 GMT

L'evento di martedì prossimo (Application Platform Roadshow) organizzato da Microsoft, sarà di sicuro molto invitante e dedicato a professionisti IT e Dev..si parla di OLAP e Business Intelligence la mattina e di AJAX al pomeriggio...niente male...
In più ci sarà anche un desk per promuovere l'iniziativa di GUISA...mi troverete li, a chiacchierare di non_solo_architettura.
Io sarò li tutto il giorno...ovviamente visto che ci saranno centinaia di persone...l'appuntamento è allo Skyline di Milano (le info sono tutte nella scheda di iscrizione)...ahhh...ovviamente è gratuito...

Vediamo se riesco pure in serata ad andare a vedere il "7 e l'8"...il film dei miei compaesani...

Ci si vede li!

PS:

Adesso scappo che i soliti picciotti aggregati in quel di milano per lavoro che rispondono al nome di Bochicchio D., Golia R. e Mberù mi aspettano per andare a farci una cena a base di....non so ancora cosa...ma sarà a quintali...

"Linq for NHibernate"...prima o poi doveva accadere

Giancarlo Sudano — Thu, 22 Mar 2007 16:27:00 GMT

Lo dicevo qualcosa come due mesi fa al webcast che abbiamo fatto assieme io e Lorenzo,

la famosa Sessione di Domande e Risposte (in cui tra l'altro ci siamo divertiti un casino...), che per come stavano andando le cose avevo intravisto una possibile sinergia tra Linq e NHibernate ed ecco la slide di allora:

Mi sarebbe piaciuto scriverci su qualcosa...ma in fondo in fondo...sapevo che "uno a caso" ci sarebbe arrivato prima...e quindi Linq for NHibernate comincia a prendere forma...

Avere Linq nel linguaggio e una trasformazione delle expression in clausole HQL o Criteria (poco importa) potrebbe voler dire il declino di qualsiasi forma di QueryObject Pattern, che tra l'altro è veramente tanto impegnativo. Disegnare un modello che comprenda anche inclusion (termine Linq che in NH ha un equivalente al FETCH di HQL o al SetFetch dei Criteria) e projection non è per niente facile.

Come al solito...mitico!

Nuovo nato: Hibernate Shards

Giancarlo Sudano — Thu, 22 Mar 2007 14:44:00 GMT

Purtroppo solo in casa Java...ma chissà che non si pensi ad un porting appena possibile.

Hibernate Shards è un framework (costruito su Hibernate) che permette di lavorare con le partizioni orizzontali dei database, il tutto con le interfacce abituali SessionFactory, Session, Criteria e Query.

Permette di sfruttare la distribuzione dei dati in qualsiasi configurazione di shards. C'è anche il supporto per shards virtuali (in modo che le shard fisiche possano essere rifattorizzate in qualsiasi modo).

Tutta la logica è ovviamente a plugin come nella buona tradizione Hibernate, con HQL e Transazioni distribuite.

Ecco l'attuale stack di tecnologie Hibernate...

Entity Framework e la spedizione punitiva all'MVP Summit

Giancarlo Sudano — Thu, 22 Mar 2007 11:23:00 GMT

Quando ho letto che i miei blogger preferiti (Jeremy Miller, Scott Bellware, Jeffrey Palermo...e altri "ragazzacci" di CodeBetter) avevano organizzato una "spedizione punitiva" e si sono presi a parte tutto il team di Linq for Entities per spiegare loro un po come va il mondo (giusto qualche lezioncina di NHibernate...quoto: "...teaching them about NHibernate...") mi è venuto troppo da ridere!

Una delle cose che da più fastidio della versione attuale di EF è che non rispetta neanche quel minimo principio della persistence ignorance. Classi base da cui ereditare, classi specifiche per le associazioni e interfacce specifiche per il tracciamento dei cambiamenti.

Sam Gentile dice che questo è il momento di dare i feedback...io qualche feedback sto cominciando a scriverlo, e nel blog del team (e anche nel forum) hanno già annunciato che la prossima versione non dovrebbe più appoggiarsi a classi generate ma dovrebbe utilizzare lo stile POCO. Almeno così dice Erick Thompson program manager di ADO.NET in risposta ad un mio commento sulle query polimorfiche.

Ora...sinceramente...dico io...
Ma con tanti ORM in giro che hanno anni di esperienza alle spalle e che queste cose le fanno "giusto" da qualche "lustro"...mi verrebbe da dire...ma quelli del team dove vivono? Va beh...

Esco da una serie di corsi che mi hanno piuttosto stancato e da ieri sto cominciando a lavorare su Orcas proprio in termini di EF.Il mio lavoro sarà di ispezione dello stato attuale, dei pro e contro rispetto a quelli che sono i sistemi attuali di ORM.

Sto costruendo una tabella di feature per il confronto con altre tecnologie, alimentata da un po di esperienza nel campo degli ORM...

Vi tengo aggiornati.

Sulle traccie di DLinq

Giancarlo Sudano — Fri, 16 Feb 2007 18:06:00 GMT

Qualche altra news al blog ufficiale del team di ADO.NET...
In Orcas verrà introdotto un nuovo data provider (EntityClient) per fornire un gateway per le query fatte sulle Entity.

Questo client utilizzerà un suo linguaggio definito (Entity SQL) e saranno disponibili i soliti Connection, Command, Parameter, e DataReader tanto cari a tutti i membri della famiglia dei dataprovider .net come SqlClient, OracleClient etc.

La tendenza sembra per ora la stessa:

Linq for SQL, Linq for Entities, come questo provider non gestiscono in modo automatico i DML (Data Manipulation Language) sul Db.
Niente insert/update/delete. In pratica coprono solo la parte della interrogazione pura.
Ok...viene si fornito un oggetto di Contesto (DataContext, ObjectContext a seconda dei vari linq) in cui però a scrivere l'SQL del database o a chiamare la SP dobbiamo essere noi.

Da quello che ho capito, Orcas non avrà niente di simile (o forse solo con l'ObjectContext e gli EDM?...).
DLinq servirà sicuramente come strumento per costruire dei Data Access Layer (Raf era di questa idea già da un pezzo).
Io aggiungo che servirà solo nel mapping unidirezionale dal modello relazionale al modello a oggetti e non viceversa.
Più che tool per scrivere DAL, io lo vedo come tool per scrivere interrogazioni, solo una nicchia di operazioni gestite dal un ipotetico DAL...e da qui ci vedo una possibile sinergia con tool ORM veri e propri.

Ecco qui la fonte.

Da prendere tutto con le pinze...visto che si parla di CTP.
Visto come ci hanno abitutati con Longhorn e Atlas...sarebbe già una bella cosa che non lo taglino prima del rilascio...gh...gh...gh...