Domande frequenti sul servizio di inoltro di Azure

Il servizio di inoltro di Azure facilita le applicazioni ibride grazie alla possibilità di esporre in modo sicuro i servizi che risiedono all'interno di una rete aziendale nel cloud pubblico. È possibile esporre i servizi senza dover aprire una connessione firewall e senza richiedere modifiche di notevole impatto a un'infrastruttura di rete aziendale.

Uno spazio dei nomi è un contenitore di ambiti che è possibile usare per gestire le risorse di inoltro nell'applicazione. È necessario creare uno spazio dei nomi per usare l'inoltro. Questo è uno dei primi passaggi nella guida introduttiva.

Il servizio in precedenza denominato Inoltro del bus di servizio ora è denominato Inoltro di Azure. È possibile continuare a usarlo come un tempo. La funzionalità Connessioni ibride è una versione aggiornata di un servizio trasferito da Servizi BizTalk di Azure. Verrà fornito ancora il supporto per l'inoltro WCF e per Connessioni ibride.

Prezzi

Questa sezione contiene le risposte ad alcune domande frequenti sulla struttura dei prezzi del servizio di inoltro. Per informazioni generali sui prezzi di Azure, vedere Domande frequenti sul supporto di Azure. Per informazioni complete sui prezzi del servizio di inoltro, vedere la pagina contenente i dettagli dei prezzi del bus di servizio.

Per informazioni complete sui prezzi di inoltro, vedere la tabella relativa alle connessioni ibride e agli inoltri WCF nella pagina dei dettagli dei prezzi del bus di servizio. Oltre ai prezzi indicati in tale pagina, vengono addebitati i trasferimenti di dati associati per i trasferimenti di dati in uscita all'esterno del data center in cui viene effettuato il provisioning dell'applicazione.

L'inoltro WCF è disponibile solo negli spazi dei nomi di livello Standard. I prezzi e le quote di connessione per gli inoltri altrimenti non sono stati modificati. Ciò significa che gli inoltri continueranno a essere addebitati in base al numero di messaggi (non alle operazioni) e alle ore per l'inoltro. Per altre informazioni, vedere la tabella relativa alle connessioni ibride e agli inoltri WCF nella pagina dei dettagli dei prezzi.

In alcuni casi, un singolo inoltro ha molti listener connessi. Un inoltro viene considerato "aperto" quando vi è connesso almeno un listener di inoltro. L'aggiunta di listener a un inoltro aperto genera ore per l'inoltro aggiuntive. Il numero di mittenti di inoltro (client che richiamano o inviano messaggi agli inoltri) connessi a un inoltro non influisce sul calcolo delle ore di inoltro.

Questo vale solo per gli inoltri WCF. I messaggi non sono un costo per le connessioni ibride.

In generale, i messaggi fatturabili per gli inoltri vengono calcolati con lo stesso metodo usato per le entità con broker, come code, argomenti e sottoscrizioni, descritti in precedenza. Esistono tuttavia alcune differenze significative.

L'invio di un messaggio all'inoltro di Azure viene considerato come un invio "completo" al listener di inoltro che riceve il messaggio. Non viene considerato come un'operazione di invio all'inoltro di Azure, seguito da un recapito al listener di inoltro. Una chiamata al servizio di tipo richiesta-risposta di dimensioni fino a 64 KB per un listener di inoltro genera due messaggi fatturabili, uno per la richiesta e uno per la risposta, presupponendo che anche la risposta sia pari a 64 KB o a un valore inferiore. Questo comportamento è diverso dall'uso di una coda per la mediazione tra un client e un servizio. Se si usa una coda per la mediazione tra un client e un servizio, lo stesso modello di richiesta-risposta richiede l'invio di una richiesta alla coda, seguita da un'operazione di rimozione dalla coda/recapito dalla coda al servizio. Questa operazione è seguita dall'invio di una risposta a un'altra coda e da un'operazione di rimozione dalla coda o recapito da tale coda al client. Presupponendo sempre le stesse dimensioni (fino a 64 KB), il modello di accodamento mediato comporterà 4 messaggi fatturabili. Verrà addebitato per due volte il numero di messaggi per implementare lo stesso modello completato usando l'inoltro. L'uso delle code per applicare questo modello presenta ovviamente alcuni vantaggi, tra cui durabilità e livellamento del carico. Questi vantaggi possono giustificare costi aggiuntivi.

Gli inoltri aperti con il binding WCF netTCPRelay considerano i messaggi non come singoli messaggi, ma come flusso di dati che attraversa il sistema. Quando si usa questo binding, solo il mittente e il listener hanno visibilità sulla struttura dei singoli messaggi inviati/ricevuti. Per gli inoltri che usano il binding netTCPRelay, tutti i dati vengono considerati come flusso per il calcolo dei messaggi fatturabili. In questo caso, il bus di servizio calcola la quantità totale di dati inviati o ricevuti mediante ciascun inoltro ogni 5 minuti. Quindi divide la quantità totale di dati per 64 KB per determinare il numero di messaggi fatturabili per questo inoltro durante questo periodo di tempo.

Obiettivi di vendita

Per impostazione predefinita per qualsiasi servizio cloud, Microsoft imposta una quota di utilizzo mensile aggregata che viene calcolata su tutte le sottoscrizioni di un cliente. In alcuni casi le esigenze del cliente possono superare questi limiti. È possibile contattare il servizio clienti in qualsiasi momento per comunicare esigenze specifiche e consentire un adeguamento appropriato di tali limiti. Per il bus di servizio, le quote di utilizzo aggregate sono le seguenti:

• 5 miliardi di messaggi
• 2 milioni di ore di inoltro

Anche se si riserva il diritto di disabilitare un account che superi le quote di utilizzo previste in un mese, Microsoft invierà una notifica tramite posta elettronica ed effettuerà diversi tentativi di contattare il cliente prima di intraprendere qualsiasi azione. I clienti che superano tali quote saranno comunque responsabili degli addebiti delle eccedenze.

Lo spazio dei nomi dell'inoltro deve avere una lunghezza compresa tra 6 e 50 caratteri.

Per spostare uno spazio dei nomi da una sottoscrizione di Azure a un'altra sottoscrizione, è possibile usare il portale di Azure o i comandi di PowerShell. Per spostare uno spazio dei nomi in un'altra sottoscrizione, lo spazio dei nomi deve essere già attivo. L'utente che esegue i comandi deve inoltre essere un amministratore per le sottoscrizioni di origine e di destinazione.

Azure portal

Per usare il portale di Azure per migrare gli spazi dei nomi di inoltro di Azure da una sottoscrizione a un'altra sottoscrizione, vedere l'articolo relativo allo spostamento di risorse in un nuovo gruppo di risorse o in una nuova sottoscrizione.

PowerShell

Per usare PowerShell per spostare uno spazio dei nomi da una sottoscrizione di Azure a un'altra sottoscrizione, usare la sequenza di comandi seguente. Per eseguire questa operazione, lo spazio dei nomi deve essere già attivo e l'utente che esegue i comandi di PowerShell deve essere un utente amministratore nelle sottoscrizioni di origine e di destinazione.

# Create a new resource group in the target subscription.
Select-AzSubscription -SubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff'
New-AzResourceGroup -Name 'targetRG' -Location 'East US'

# Move the namespace from the source subscription to the target subscription.
Select-AzSubscription -SubscriptionId 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'
$res = Find-AzResource -ResourceNameContains <NAMESPACE NAME> -ResourceType 'Microsoft.ServiceBus/namespaces'
Move-AzResource -DestinationResourceGroupName 'targetRG' -DestinationSubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff' -ResourceId $res.ResourceId

Per una descrizione di eccezioni comuni e delle azioni consigliate, vedere Eccezioni di inoltro.

Le firme di accesso condiviso sono un meccanismo di autenticazione basato su hash sicuri SHA-256 o URI. Per informazioni su come generare firme personalizzate in Node.js, PHP, Python, Java, C e C#, vedere bus di servizio'autenticazione con firme di accesso condiviso.

Sì. Il client di inoltro stabilisce connessioni al servizio di inoltro di Azure usando nomi di dominio completi. I clienti possono aggiungere una voce per *.servicebus.windows.net nei firewall che supportano l'aggiunta all'elenco di elementi consentiti per DNS. È anche possibile consentire l'elenco di uno spazio dei nomi specifico usando your-namespace-name.servicebus.windows.net. In questo caso è anche necessario consentire l'elenco dei gateway per lo spazio dei nomi, disponibile usando questo script di PowerShell.

Passaggi successivi

• Creare uno spazio dei nomi
• Introduzione a .NET
• Introduzione a Node