This project is read-only.
One of the things we have found to be important is communicating the structure of the message. To do this we have defined our messages using XSD which allows us to support many technologies which have the capability to generate classes from XSD.

These classes can then be serialized and the data sent via the Azure Service Bus.

Schema Example

The below is an example XSD form one of our samples.

<?xml version="1.0" encoding="utf-16"?>
  id ="Sample_v1_0"
  <xs:element name="SubmitClaim">
        <xs:element name="MessageID" type="xs:string" />
        <xs:element name="ClaimID" type="xs:string" />
        <xs:element name="MemberName" type="xs:string" />

The way you model your messages with XSD is really up to you. Some customers have a more advanced data model which makes it easy to define your messages, where as others may have no clear model at all. Often we have seen entities defined in canonical schema and then messages may make up command or query request and response messages which may import other entity schemas.

Generating Classes from the Schema

As mentioned earlier a lot of technologies support generating classes from schema. In C# we have tended to include an extension to the MsBuild process in the Visual Studio project containing our schemas to generate classes for them as part of the build process.

You will see this technique used in most of our samples.

An example of this is:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="">
    <SvcUtilPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools</SvcUtilPath>

  <Target Name="BeforeBuild">
    <Exec Command='"$(SvcUtilPath)\svcutil" /dconly Schema\Contracts_v1_0.xsd /language:C# /serializable /directory:Types /namespace:http://messaging/contracts/sample/v1.0,Contracts.Types' />


Once your class is generated it can then be used on the sender side or receiver side in the message handler.

Often for simplicity it can be best to generate your messages into an assembly which is then shared. This will work fine but when your working with B2B scenarios you can just give the partner the schema and let them generate their own types.

From an interop perspective as long as the message send to the queue meets the schema and follows the rules for properties defined in the AppFx.ServiceBus Message Specification section then it will work fine.

Last edited Feb 1, 2013 at 11:46 PM by michaelstephenson, version 4


No comments yet.