Pianificazione dello sviluppo di Service Broker
Durante la progettazione di un'applicazione di Service Broker esaminare gli elementi seguenti:
La metrica relativa al tipo e al volume di input e di output previsti dall'applicazione.
I requisiti per l'applicazione proposta.
Se si comprendono tali fattori, è possibile sviluppare un sistema che soddisfi gli obiettivi aziendali.
Elenco di controllo per la pianificazione
Durante la pianificazione dell'applicazione considerare le domande seguenti:
Che ruolo svolge Service Broker nell'applicazione?
La risposta a questa domanda agevola la pianificazione dei tipi di messaggio utilizzati nell'applicazione, la struttura dell'applicazione stessa e i relativi requisiti di archiviazione ed elaborazione.
Ad esempio, Service Broker può essere utilizzato per gestire i picchi di frequenza di arrivo dei messaggi tramite l'archiviazione in code nell'attesa di risorse disponibili per elaborarli. In questo caso, i tipi di messaggio utilizzati dall'applicazione devono pressoché corrispondere all'input e all'output dell'applicazione esistente. È possibile stimare i requisiti di archiviazione ed elaborazione per l'applicazione in base al carico di lavoro esistente.
Se si progetta invece una nuova applicazione, è opportuno valutare attentamente quali operazioni possono trarre il maggior vantaggio dall'utilizzo di Service Broker. Service Broker consente spesso di bilanciare i tempi di elaborazione stimati nel migliore dei case per garantire affidabilità, laddove un'applicazione convenzionale produrrebbe un esito negativo.
Ad esempio, un'applicazione per l'immissione di ordini in linea potrebbe non riuscire a elaborare completamente un ordine e dare la conferma finale nel momento in cui l'ordine viene inviato. Viceversa, potrebbe inviare l'ordine a un servizio che lo elabori e fornisca una conferma finale tramite un messaggio di posta elettronica. Utilizzando questa struttura di progettazione, è possibile continuare ad accettare ordini tramite l'applicazione anche se si verificano problemi di rete che impediscono di confermare l'ordine. Una volta risolti i problemi di rete, gli ordini vengono elaborati dall'applicazione. In questo caso, i requisiti di archiviazione ed elaborazione per l'applicazione dipendono dal numero di ordini previsto, dalla dimensione di ciascun messaggio di ordine e dal tempo necessario per l'elaborazione dell'ordine.
Quali informazioni sono necessarie in una conversazione per completare l'attività desiderata? Quali sono gli schemi dei messaggi che gli endpoint si scambieranno per fornire tali informazioni gli uni agli altri?
La maggior parte dei servizi consente lo scambio di informazioni semistrutturate, pertanto la codifica XML rappresenta una buona scelta. Una codifica binaria è utile per lo scambio di file binari come le immagini. Utilizzare un messaggio vuoto per inviare una semplice conferma di ricezione di un altro messaggio.
Selezionando il tipo di messaggio corretto, le probabilità che si debba effettuare in seguito l'aggiornamento dell'applicazione si riducono notevolmente. In base alla codifica del tipo di messaggio, gli aggiornamenti possono essere molteplici e variare dall'aggiornamento di un file di schema XML alle modifiche sostanziali di codifica da apportare all'applicazione. Se esistono dati di cui al momento non si ha bisogno ma che potrebbero rivelarsi utili in futuro, è preferibile includerli. Se si definiscono questi elementi nello schema iniziale, non è necessario apportare modifiche allo schema quando tali elementi vengono supportati.
Dove viene eseguita la logica per l'elaborazione dei messaggi?
È possibile progettare l'applicazione come una stored procedure attivata da Service Broker, un servizio in background, un evento programmato o un'applicazione esterna. La decisione finale dipende dal ruolo svolto da Service Broker nell'applicazione. Ad esempio, se l'applicazione elabora un flusso continuo di messaggi che arrivano con una frequenza stimabile, è possibile utilizzare un servizio in background. Se è necessario adattare in modo dinamico l'applicazione in base al numero di messaggi in arrivo, è possibile utilizzare una stored procedure attivata da una coda. Se i messaggi vengono messi in coda, quindi vengono elaborati tutti insieme a una determinata ora, è possibile avviare l'applicazione tramite un evento pianificato.
È possibile utilizzare un'applicazione esterna se il programma richiede l'accesso a risorse esterne al database, quali file o pagine Web. L'utilizzo di un'applicazione esterna può migliorare la scalabilità dell'applicazione, perché l'elaborazione viene effettuata nei server di livello medio anziché nel server di database. È semplice applicare la scalabilità orizzontale a un'applicazione che utilizza Service Broker, perché Service Broker fornisce accesso remoto tramite transazioni alle code. In qualsiasi applicazione che consente di inviare comandi Transact-SQL al database ed elaborare i risultati è possibile utilizzare Service Broker.
Ogni programma esterno è isolato dagli altri programmi in cui è previsto l'uso della coda. Pertanto, non è necessario adottare particolari precauzioni per la gestione dell'accesso alla coda da parte dei programmi esterni. Inoltre, se durante l'elaborazione di un messaggio la connessione non avviene, viene eseguito il rollback della transazione e il messaggio viene restituito alla coda da Service Broker. I problemi di rete non possono causare la perdita del messaggio da parte dell'applicazione.
Quale tecnologia si desidera utilizzare per implementare l'applicazione?
È possibile implementare un'applicazione esterna utilizzando qualsiasi tecnologia in grado di effettuare la connessione al database ed eseguire le istruzioni Transact-SQL in SQL Server. Tuttavia le applicazioni vengono in genere sviluppate in un linguaggio compatibile con .NET Framework e ADO.NET. È possibile implementare una stored procedure in Transact-SQL o uno dei linguaggi compatibili con .NET Framework e ottenere migliori prestazioni usando Transact-SQL anziché Motore di database. I linguaggi compatibili con CLR possono offrire migliore flessibilità, controllo più accurato del flusso di programma, prestazioni migliori per le applicazioni che richiedono un uso intensivo del processore e accesso diretto a .NET Framework.
Quali componenti server verranno utilizzati maggiormente dall'applicazione?
Collaborare con l'amministratore di sistema per accertarsi di disporre di risorse sufficienti per ottenere prestazioni ottimali. È importante sapere quali componenti verranno utilizzati con maggiore frequenza. Ad esempio, se l'applicazione utilizza code per bilanciare l'elaborazione del carico di lavoro o effettua la memorizzazione dei messaggi, assicurarsi che ci sia spazio sufficiente su disco per consentire l'aumento della coda. Viceversa, un'applicazione che registra volumi di messaggistica elevati ma tempi di attesa in coda inferiori potrebbe utilizzare più larghezza di banda di rete, occupando però meno spazio su disco.
I messaggi avranno priorità diverse?
In caso di sistemi con carico elevato, le priorità di conversazione di Service Broker contribuiscono a garantire che le attività più importanti non vengano bloccate da elevate quantità di attività meno cruciali. Le priorità di conversazione consentono anche progettazioni che supportano livelli diversi di servizio.