Responsabilità degli sviluppatori per Service Broker
Lo sviluppatore di applicazioni è responsabile della progettazione dell'applicazione di Service Broker e della creazione degli elementi che richiedono una programmazione. L'amministratore di sistema si occupa della configurazione e della gestione di Service Broker. È fondamentale che gli sviluppatori e gli amministratori collaborino durante la pianificazione del sistema per garantire che esso venga sviluppato e gestito in modo ottimale in base agli obiettivi specifici dell'ambiente utilizzato e dell'azienda.
Le attività implicate nella creazione di una singola applicazione dipendono dai requisiti dell'applicazione stessa. Di seguito è riportata una tipica serie di attività per lo sviluppo di un'applicazione di Service Broker:
Pianificare l'applicazione delineando le attività che devono essere portate a termine e descrivendo le conversazioni che avverranno durante ogni attività. Con quale endpoint devono essere fornite le informazioni? Di che tipo di informazioni si tratta e in quale ordine devono essere fornite? Quale elaborazione deve essere eseguita? Che priorità devono essere assegnate alle conversazioni? Tutte le informazioni successive dipendono da questa definizione.
Determinare il formato e la struttura di ogni messaggio in ogni conversazione. Pianificare la sequenza prevista di scambio dei messaggi e la modalità di risposta di ogni partecipante alla conversazione a fronte di errori e messaggi inviati secondo un ordine imprevisto.
Se per la conversazione vengono utilizzati messaggi XML, creare uno schema per ciascuno di questi messaggi. È possibile utilizzare schemi durante lo sviluppo, il test e la risoluzione dei problemi. Quando il servizio viene messo in produzione, è possibile decidere di rimuovere la convalida dello schema dai tipi di messaggio per migliorare le prestazioni.
Creare un tipo per ciascun messaggio in ogni conversazione.
Creare un contratto per ogni conversazione. Il contratto identifica i tipi di messaggio che possono essere utilizzati da ogni endpoint nella conversazione.
Creare una coda per archiviare i messaggi che saranno ricevuti dall'applicazione.
Creare un servizio per esporre la funzionalità definita dal contratto e implementata dalla stored procedure creata. Durante la creazione di un servizio, è possibile associarlo alla coda creata nel passaggio precedente. In questo modo, si comunica a Service Broker che tutti i messaggi in arrivo indirizzati a tale servizio devono essere inseriti nella coda identificata.
Esaminare le pianificazioni di priorità stabilite nel passaggio 1. Creare priorità di conversazione che includono tutti gli endpoint di conversazione progettati per utilizzare livelli di priorità diversi da quelli predefiniti. In caso sia necessario utilizzare livelli di priorità per la trasmissione dei messaggi da un database, assicurarsi che l'opzione HONOR_BROKER_PRIORITY in tale database sia impostata su ON.
Creare un'applicazione in cui sia implementato il modello di scambio dei messaggi previsto e i requisiti di elaborazione identificati nel passaggio 1. Se nell'applicazione viene utilizzata un'attivazione interna, l'applicazione è una stored procedure.
Se nell'applicazione viene utilizzata un'attivazione interna, modificare la coda per consentire l'attivazione. Specificare la stored procedure creata nel passaggio 8 come stored procedure di attivazione.
Identificare i servizi che utilizzano il servizio appena creato. Se all'esterno dell'istanza di SQL Server locale esiste uno qualsiasi di questi servizi, creare delle apposite route.
Esaminare i servizi remoti identificati nel passaggio precedente e determinare i requisiti di protezione per le comunicazioni con tali servizi. Se necessario, creare certificati per soddisfare tali requisiti, quindi creare utenti del database per i certificati. Associare i certificati a questi account di accesso. Gli amministratori o gli sviluppatori degli altri servizi devono creare associazioni a servizi remoti per attivare la protezione del dialogo sul traffico per questo servizio.
Durante lo sviluppo e il test, spesso è preferibile utilizzare in un'applicazione i nomi utente che verranno adottati in produzione, ma è bene associarli a certificati usati solo nell'ambiente di sviluppo e test. Quando l'applicazione viene spostata nell'ambiente di produzione, utilizzare i certificati creati per quest'ultimo ambiente. Utilizzando certificati diversi è possibile ridurre l'impegno richiesto per la distribuzione dell'applicazione, garantendo al contempo la protezione tra gli ambienti di sviluppo e di produzione.