Azure Service Bus enables your applications to interact in several different ways such as: 1) letting applications send and receive messages through a simple queue, 2) a queue with a publish-and-subscribe mechanism when an ordinary queue isn’t enough, 3) no connection between applications, and queues are required. 

Service Bus is a multi-tenant cloud service, which means that the service is shared by multiple users. Each user, such as an application developer, creates a namespace, then defines the communication mechanisms needed within that namespace. Within a namespace, you can use one or more instances of three different communication mechanisms, each of which connects applications in a different way. The choices are:

Queues, which allow one-directional communication. Each queue acts as an intermediary (a broker) that stores sent messages until they are received. Each message is received by a single recipient.
Topics, which provide one-directional communication using subscriptions-a single topic can have multiple subscriptions. Like a queue, a topic acts as a broker, but each subscription can optionally use a filter to receive only messages that match specific criteria.
Relays, which provide bi-directional communication. Unlike queues and topics, a relay doesn’t store in-flight messages; it’s not a broker. Instead, it just passes them on to the destination application.
When you create a queue, topic, or relay, you give it a name. Combined with whatever you called your namespace, this name creates a unique identifier for the object. Applications can provide this name to Service Bus, then use that queue, topic, or relay to communicate with each other.

To use any of these objects in the relay scenario, Windows applications can use Windows Communication Foundation (WCF). This service is known as WCF Relay. For queues and topics, Windows applications can use Service Bus-defined messaging APIs. To make these objects easier to use from non-Windows applications, Microsoft provides SDKs for Java, Node.js, and other languages. You can also access queues and topics using REST APIs over HTTP(s).

It’s important to understand that even though Service Bus itself runs in the cloud, applications that use it can run anywhere. You can use Service Bus to connect applications running on Azure. You can also use it to connect an application running on Azure or another cloud platform with an on-premises application or with tablets and phones. It’s even possible to connect household appliances, sensors, and other devices to a central application, or to connect these devices to each other. Service Bus is a communication mechanism in the cloud that’s accessible from pretty much anywhere.

You can import data to SQL Azure and your data could exist in various sources such as SQL Server, Oracle, Excel, Access, flat files and others. Your data could exist in various locations. A location might be a data center, behind a corporate firewall, on a home network, or even in Windows Azure.

The following tools are commonly used for bulk upload:

BCP: This is a utility available with the SQL command line utilities that is designed for high performing bulk upload to a single SQL Server/Azure database.

SSIS: This is a powerful tool when operating on multiple heterogeneous data sources and destinations. 

Import & Export Data: A simple wizard that does not offer the wide range of configuration that SSIS provides, but is very handy for schema migration and smaller data uploads.

SSMS: This tool has the option of generating SQL Azure schema and data migration scripts. It is very useful for schema migration, but is not recommended for large data uploads.

Bulk Copy API: In the case where you need to build your own tool for maximum flexibility of programming, you could use the Bulk Copy API. This API is highly efficient and provides bulk performance similar to BCP.

Let’s dig deeper on Quarts Scheduler to learn why it should not be used in Azure for scheduling jobs.

Adding the quartz library to your app does not begin to ready your application to schedule jobs. You have to write your implementation of the job interface, then you have to construct large xml configuration files or add code to your application to build new instances of JobDetails and then schedule them using Schedule instance from a ScheduleFactory. What happens when you need to make a change to a job’s schedule? Temporarily disable a job? Change the parameters bound to a job? All these require a build/test/deploy cycle which is impractical for any organization.

Quartz does not meet the following enterprise scheduler requirements:

• No out of the box support for multiple execution nodes 
• No administration UI 
• No monitoring
• No alerts
• No strong mechanisms for dealing with errors/failures and recovery

What is AMQP ?

Traditionally, message-oriented middleware products have used proprietary protocols for communication between client applications and brokers. Connecting messaging brokers from different vendors is tricky. This typically requires application-level bridging to move messages from one system to another and to translate between their proprietary message formats. This is a common requirement; for example, when you must provide a new unified interface to older disparate systems, or integrate IT systems following a merger.

The main goal of developing the Advanced Message Queuing Protocol (AMQP) was to create an open-standard messaging protocol that made it possible to build message-based applications using components built using different languages, frameworks, and operating systems, all using best-of-breed components from a range of suppliers.

Both the Azure Service Bus cloud service and on-premises Service Bus for Windows Server (Service Bus 1.1) support the AMPQ. This protocol enables you to build cross-platform, hybrid applications. You can construct applications using components that are built using different languages and frameworks, and that run on different operating systems. All these components can connect to Service Bus and seamlessly exchange structured business messages efficiently and at full fidelity.

The main advantage of Azure WEbjobs are:

• They work great with message queues
• They are free
• They deserialise your messages without you perform any actions
• They auto-deploy from GitHub with the website
• You can easily track them via the management portal
• Config is a breeze
• They’re resilient to errors
• They are extremely simple to test
• They are parallelised and they auto scale-out with your site