Web Log di Raffaele Rialdi

# re: SQL 2008 torna in carreggiata

Concordo pienamente, molto meglio un polling del client verso il server, più scalabile ed anche più affidabile IMHO.

# re: SQL 2008 torna in carreggiata

Bisogna però tenere conto di come MS abbia preso in giro le tante persone che hanno creato prodotti o semplicemente hanno studiato per la certificazione e lo hanno venduto ai loro "clienti".
Un'azienda come MS che fa strumenti di sviluppo rivolti ai programmatori, non si puo' permettere di tirare fuori tecnologie che non intende supportare in un futuro così prossimo. Se era così pessimo come progetto (e non l'ho ha detto... anzi, lo ha spacciato nei vari WorkShop come una soluzione affidabile) perde di credibilità.
Con queste premesse, ho addirittura paura a studiare WPF che non è detto faccia la stessa fine (vedi XAML è gli editor di form inesistenti).
Ad ora non esiste nessuna applicazione "di larga diffusione" su questa piattoforma (WPF) pur essendo stata rilasciata in versione ufficiale.
Lo stesso discorso si puo' fare per qualsiasi cosa nuova.

Cosa ne pensate di questo pensiero?

CIAO
Fabio
Genova

# re: SQL 2008 torna in carreggiata

Ciao Fabio, fa piacere sentire un concittadino :)
Concordo con il dissenso e infatti ho scritto che non è bello abbandonare una tecnologia presente nella precedente versione. L'unica spiegazione che mi sono dato è quella che ho scritto, e cioè che i danni che provoca sono di gran lunga superiori ai benefici.

Personalmente non mi faccio mai abbagliare da un prodotto solo perché l'ha lanciato MS in modo più o meno solenne. I notification services non mi sono mai piaciuti per i motivi architetturali che ho esposto e so di non essere da solo.
Quindi non sono daccordo quando dici che tutte le novità possano essere assimilabili a questa "paura" di ritiro delle features.

Tanto per capirci, tecnologie come WPF sono progetti radicalmente differenti in quanto hanno una solidità progettuale ben diversa.
Personalmente al look grafico di WPF una bassa motivazione per scegliere WPF. Ce ne sono tante altre che hanno un valore più alto.

# re: SQL 2008 torna in carreggiata

Mi chiedo se prima di scrivere cose che non centrano nulla con i Notification Services li avete mai usati, od almeno provati: "Suppongo che in SQL 2005 i notification services siano nati per andare incontro ad applicazioni RAD " se c'è qualcosa che non ha proprio nulla a che vedere con il RAD questi sono i NS...ed è per questo che non hanno avuto successo.

Le notifiche sono intese come EMAIL, SMS e quant'altro...non eventi COM et simili..che pur ci sono ma servono ad altro ed è piuttosto ovvio che creare un'applicazione completamente basata su questa parte dei NS non ha senso. I NS leggono "eventi" da SQL Server o da File System...e si possono sviluppare Event Provider ad hoc (poche righe di codice) che permettono di sfruttare al 100% un'architettura SOA...basta non fermarsi alla "pappa pronta" ed andare più in la. La cosa importante e di valore dei NS è il motore che permette di creare piccoli o grandi "Rule Engine", tutto il resto è contorno.

L'interesse verso i NS è prossimo allo zero perchè nessuno si è mai preso la briga di studiarseli bene (troppo faticoso?), tranne il sottoscritto e pochi altri (Adam Machanic ad esempio, ed infatti concorda con me su tutto il discorso NS) e chi è riuscito a superare l'alta curva di apprendimento iniziale è riuscito a fare grandi cose senza dover re-inventare l'acqua calda, creando soluzioni di notifica centralizzate a livello enterprise, rendendo applicazioni molto più snelle e disaccoppiate dall'invio di notifiche sottoforma di email.

Per il resto, concordo al 100% con quello che dice Fabio.

# re: SQL 2008 torna in carreggiata

Davide, ho letto i NS sul libro ''Programming Microsoft SQL Server 2005". Non sto parlando per dicerie.
La notifica da parte dei NS al layer superiore è contro qualsiasi logica di applicazione multi tier scalabile. È un concetto consolidato da più di 10 anni.
Dopo aver letto come funzionano, i NS non mi hanno interessato e quindi non ci ho mai sviluppato sopra.
Chi è pigro e non sa come strutturare l'application layer ha sicuramente nei NS una notevole scorciatoia. Questa però è solo fumo e niente arrosto, considerati gli svantaggi in termini di scalabilità.
Lasciamo fare al DB quello che sa fare, e lo fa certamente bene. Il resto non è per lui.

# re: SQL 2008 torna in carreggiata

I NS sono una delle varie colonne portanti della architettura BizTalk.
Io credo che il problema sta sul fatto che forse le persone non hanno compreso esattamente il vero e propio significato dei NS.

Esempio banale è vedere persone utilizzare BizTalk per operazioni di ETL, in parte è sicuramente corretto, ma pretendere, senza effettuare alcun reale accorgimento, di utilizzare BizTalk per eseguire una import su database di 1.000.000 di righe e chiedere che abbia le stesse performance di un ETL DB standar... beh.
Conseguenza?, Biztalk qui.... BizTalk la....

Io credo che i NS facciano il loro mestiere, forse alcuni li hanno fraintesi.
Ritengo comunque che le tecnologie, inizialmente, debbano sempre essere fraintese, questo è quello che porta alla grande scoperta e innovazione, ma non bisogna persistere.

# re: SQL 2008 torna in carreggiata

Nino, Biztalk ha un ruolo totalmente differente da quello dello sviluppo di una applicazione.
L'impatto della rimozione dei NS in Biztalk sarà certamente stato valutato ma non conoscendo Biztalk non riesco ad immaginare cosa comporterà nella prossima versione.

Il problema è che usare il DB come pseudo application server è un autogol. In una moderna applicazione la logica non va dentro il DB ed è l'application server a dover "schermare" gli accessi al DB... non ci sono altre soluzioni scalabili.

# re: SQL 2008 torna in carreggiata

Ciao Davide,
Mi spiace ma non potro' mai applicare le cose che ci hai fatto vedere al workshop che hai tenuto nella azienda in cui lavoro a Genova.
MS è stata troppo veloce nel togliere di mezzo i NS.
Questo è un esempio di come un consulente riskia la propria faccia a causa di MS.
Se fossimo partiti con uno sviluppo di 1 anno x 5 persone (queste sono le misure tipiche per un progetto) quanto avremmo buttato via. E Davide (ASSOLUTAMENTE incolpevole) che figura avrebbe fatto nel consigliarci un prodotto "adatto allo scopo" ma senza futuro?


Raffaele, quando scrivi che la logica non va dentro il DB in parte non sono d'accordo in quanto mi trovo spesso a vedere applicazioni che "non conoscendo il DB" fanno transitare vagonate di record solo per fare ad esempio una samma. Si che il calcolo potrebbe essere logica business ma potrebbe essere fatto da una SP senza creare tutto quel traffico. Poi sono dell'idea che in caso di bug sia molto più semplice modificare una SP nel DB che non ricompilare/rilasciare/installare un binario.
Concordo invece sul non confondere il DB con un'application Server.

Su WPF non so quante piccole aziende che trattano i soliti gestionali et simila vedano il lato positivo di questa tecnologia anche se ha fondamente + solide. Ho Ms usa la forza bruta (depreca WindowsForm) o WPF richia quello che hanno passato i NS. Tutto IHMO.

CIAO

# re: SQL 2008 torna in carreggiata

Fabio, qui non è una questione di opinioni ma di pratiche consolidate.
Ci sono esempi eclatanti come eBay (http://blogs.ugidotnet.org/raffaele/archive/2006/12/29/63835.aspx) ma anche tanti altri.
Il database è solo uno e gli application server (se si lavora come si deve) possono crescere su necessità e scalare le performance in maniera splendida.
In una moderna applicazione il DB è totalmente nascosto da uno strato di servizi che prendono in carico la logica.
Ogni operazione lasciata sul database impatta pesantemente visto che è il collo di bottiglia. Ogni operazione su un application server può avere impatto zero semplicemente aumentando il numero degli application server che possono usare una politica di caching per minimizzare gli hit sul DB.
Il fatto di usare sp o query non ha alcuna importanza in questo scenario visto che le performance (se usi i command bene) sono assolutamente identici. Ne parlavo proprio con Gianluca (Hotz) la scorsa settimana agli Open Days.

In questo scenario se usi i NS, ti spari sui piedi. E questo è il motivo per cui non li ho mai ritenuti uno strumento usabile.

Per quello che riguarda WPF le motivazioni come dicevo sono altre. MS non dismetterà il supporto nè di Winform tantomeno di MFC.
Lo sviluppatore che comincerà a sbirciare dentro WPF si accorgerà che:
- skin. Applicare diverse skin a seconda del privilegio dell'utente ottenendo un'interfaccia differente (con tanto di posizioni, dimensioni, etc. dei controlli diverse da skin a skin)
- template e styles. Li usi una volta e non li molli più.
- internazionalizzazione. Il meccanismo per globalizzare una applicazione WPF è decisamente più semplice
- Custom control. Niente più sporchi trucchi sulla message pump o subclassing per customizzare un controllo o crearne di nuovi. Tutto di gran lunga più semplice
- Sandoboxing dei controlli WPF (fx 3.5). Controlli che girano con meno privilegi della applicazione che li hosta
- Performance. Basato su DirectX ...
- Multilayer. La gestione a più strati permette di pensare le UI in modo molto più semplice
- ...

Ripeto, la grafica e i 3D sono l'ultimo dei vantaggi per passare a WPF. Vedremo cosa sceglieranno gli utenti ... sulle UI saranno loro a decretare quale tecnologia avrà la meglio.

# re: SQL 2008 torna in carreggiata

@ Raffaele:

piccolo OT, rispetto al post, su WPF: il prob è che l'ultimo dei motivi (3D e grafica) per noi "tecnici" (scusa se mi ci sono messo anche io) è il primo per l'ut(o)ente.. :(

su tutto il resto assolutamente d'accordo sulla "forzatura" di design specialmente nel caso gli NS vengano usati come messagging tra livelli differenti. Un pò meno se uso gli NS per "allineare" server di back end differenti (anche se questo potrebbe essere un compito più relegato a BizTalk).

# re: SQL 2008 torna in carreggiata

Stefano condivido perfettamente il discorso WPF. All'epoca delle prime beta di WinFX (oggi fx 3.0) dissi che la tecnologia che avrebbe fatto vendere di più era proprio WPF perché alle finezze tecnologiche sono "invisibili" agli utenti.
Se ragioniamo però a livello di costi/benefici, devo anche giustificare l'addozione di una nuova tecnologia. Se il vantaggio fosse solo estetico, probabilmente lo sforzo iniziale per imparare WPF non giustificherebbe la migrazione per molte software house.
Perciò considero, dal punto di vista dello sviluppatore, che la prima motivazione sia tecnologica. La software house impiega comunque meno tempo a sviluppare, ha nuovi vantaggi (le features si vendono bene) ed infine (ma concordo che sia tra le prime per l'utente) la grafica che ipnotizza tutti nella demo.

Se poi vogliamo essere più critici la grafica ha anche il vantaggio di dare maggiore ergonomia alla UI e quindi è un ulteriore vantaggio per l'utente finale.

Per quanto riguarda i NS io continuo a credere che anche sul lato server il disaccoppiamento può solo fare del bene. Usare un messaging a livello data server ha implicazioni critiche sulla scalabilità e la manutenzione. Pensa cosa implichi un aggiornamento sullo schema del DB ... tragedia.

# re: SQL 2008 torna in carreggiata

"sopratutto nelcaso gli NS vengano usati come messagging tra livelli differenti"
Boh...mi sa che proprio non avete capito a cosa servono i notification services....servono per mandare EVENTI ALL'UTENTE FINALE!!!!!!!!!! Una mail, un SMS, un piccione viaggiatore....certo che sono inutili e deleteri se pensiamo di usarli come collante di applicazioni enterprise!!!!!

# re: SQL 2008 torna in carreggiata

Solo una precisazione: quando ne abbiamo parlato, lo abbiamo fatto discutendo di un O/R mapper ideale: tra una stored procedure con un singolo comando DML semplice (quelli di insert, update e delete che svilupperesti a mano, tanto per intenderci) e un prepared statement non c'è molta differenza per quanto riguarda il fatto che per entrambi in fin dei conti il piano compilato viene riutilizzato.

Ma non sono strettamente identici, anche solo per il numero di byte che passano sulla rete e per il tempo differente di parsing, hashing e ricerca nella cache dei piani di esecuzione.

Questo può fare o non fare la differenza, dipende dalle solite cose (carico di lavoro ecc.)

Per statement più complessi, poi, il discorso si fa più complicato visto che per una stored procedure complessa in 2005 possono essere ricompilate solo porzioni del piano di esecuzione, per contro ci sono tutti problemi di parameter sniffing.

Insomma non vorrei che passasse il messaggio di usare strumenti di mapping con leggerezza: quando le cose sono semplici è un conto, quando diventano più complesse (ovviamente) ci vuole sempre un pò più di attenzione :)

# re: SQL 2008 torna in carreggiata

@Gianluca. Giusto chiarimento. Io infatti non ho mai precluso a priori l'uso di stored procedure. Concordo su quanto scrivi.

# re: SQL 2008 torna in carreggiata

@Davide. Mi porti delle motivazioni per i NS che sono totalmente inutili se l'architettura dell'applicazione è fatta decentemente.

# re: SQL 2008 torna in carreggiata

@Raf. Non ho capito la tua affermazione, ma provo a porti un problema reale. Una società molto grossa a "n" applicazioni (dove n > 30) in cui in ogni applicazione è stato cablato il codice per inviare una o più mail - sulla base della sussistenza di certe condizioni - ad una o più persone. Ogni giorno. Il risultato è che molte persone ricevono mail che sono praticamente ormai spam, in quanto troppe mail è uguale a nessuna mail. Il risultato è che c'è una enormita di perdita di tempo per ogni persona e che alcune mail importanti si perdono.
Ora, non è forse meglio che le applicazioni, al posto che inviare una email ed averne in pancia il codice per farlo non possano inviare una notifica (ossia un messaggio XML) via SOAP (quindi invocando un web service) ad un'application servcer centralizzato che gestisca in un'unico punto tutto il meccanismo del chi-riceve-cosa?
In questo caso i NS sono un aiuto notevole, IMHO, in quanto permettono di utilizzare il loro motore di Rule Matching senza dovrlo scrivere da zero, e non è affatto poco. Contanto che stiamo parlando di >3000 utenti che usano questo sistema, che i messaggi XML (ove possibile, in altri modi da mainframe) fluiscono da un insieme eterogeeono di applicazioni (da VB6 a RPG, da .NET a CICS) e che su tutto questo si può costruire un sistema di monitoring (interamente basato su SQL Server) che permette di tenere traccia di tutti i messaggi scambiati....non mi sembra affatto male. Sopratutto per il cliente.

# re: SQL 2008 torna in carreggiata

Davide, sono il primo a parlare di servizi e quindi la soluzione di incapsulare in un servizio la logica dell'invio email è ovvia.
Il discorso del codice cablato fa parte delle "zozzate informatiche" al pari delle execsql dentro le stored. Le porcherie le trovi ovunque e non è questa la soluzione a cui alludo.

L'unico punto di cui parli dovrebbe essere un servizio e non un database. E per garantire il cross platform, i servizi si appoggiano sugli standard WS-*.

Quello su cui non concordo è che la parte di logica sia implementata in un SQL server (anche se ad-hoc non importa).
Sviluppare un servizio senza cablare le regole oggi è triviale e ci sono diverse soluzioni. Una di queste si chiama Workflow Foundation che ha il suo meccanismo di rules decisamente evoluto ed espandibile, tanto da essere stato usato anche in BizTalk.