SOAP listeners with Azure framework

A multi-thread service that needs to be able to support concurrent SOAP requests and running on an Azure VM instance. An inbound SOAP request will always have a user name and PIN code (possibly other data as well) All SOAP users will be registered; anonymous SOAP requests should be aborted with error message / number. Three different calls need to be handled: SOAP to place new items of work. When a valid SOAP ‘new job’ request is sent, the variable data will contain a binary object (a file) and the caller’s reference to this object (a string) and two formating codes (language and file format, both strings). The core purpose of the SOAP listener is to post the file to Azure blob storage and create a suitable reference to it using the variable data. The service will compare the user name and PIN to data stored in an SQL table (‘Clients’) and reject any failures with a suitable ‘invalid username or password’ message/number. It is also important to check another field (a PaymentHealth field, also in the Client table), a 0 means we abort the job with a message returned to the caller (they do not have enough money to pay for this job). Assuming these test pass, the SOAP service will create a new record with the user, the start time and other key data to the ‘Jobs’ database table. It will make a note of the Row ID it creates - this will be the reference used later. It will then post a new message to an Azure message queue called ‘NewJobs’. This message does not need any ID. This service will then monitor a second Azure message queue ‘DoneJobs’. This message queue will be filled by another service object once it has finished processing the file we stored; it will contain our Row ID and a filename and path. Once we see ‘our’ message, the service will return the file as an object to the caller and delete the ‘DoneJobs’ message from the queue. Once the request is serviced, the SOAP server will then resume listening for the next service request. SOAP query to check credit. When a valid SOAP ‘check credit’ request is accepted, there will be no variable data expected. The core purpose of the SOAP listener in this case is to reply to the caller with a value indicating how much credit they have and the currency of this credit. The Client SQL table will contain fields for ‘Account type’, ‘Pre-paid remaining’, ‘invoice currency’ and ‘payment health’ - these are the key fields we will now check and return to the caller. If the Account Type value tells us this is a pre-paid user, we return ‘Pre-paid remaining’ and an indicator that this is a count of the number of items they can still send. In all other cases, we query another table - the Jobs table - and total the Cost column for all rows with the same ClientID that have null in ‘Paid’ (we are calculating the total they owe for all the jobs we’ve done for them) and return this result with a currency indicator. One additional result might be returned: no credit available (if ‘Payment Health’ is zero for any account type). Once the request is serviced, the SOAP server will then resume listening for the next service request. SOAP to create an account. When a valid SOAP ‘CreateAccount’ request is received, the variable data will contain an email address, contact name (first and last), company name, a credit or pre-pay account type, PIN code, password and other useful data. ll this will be encrypted. It will create the named account and return the ftp login name for the account (new ‘Client’ SQL row) that is created. It will then return to a listening state. SOAP to add credit to a pre-pay account. This SOAP call is used to increase the numerical value in one field in one row of the SQL data. It will be passed encrypted data containing a Client ID row reference and the additional value we need to add to the existing data. If at all possible, NEITHER 'Account' functions should not appear to an external user of the SOAP interface. I expect to have the unprotected source (C#) code.