This project is read-only.
Using a schema to define a message can be very useful. The schema can give a clear structure to the data which will be communicated through the queues. If you want to use xsd to define a schema then this can be a good way to work with your messages using Service Bus and AppFx.ServiceBus.

One key thing to understand however is that by using xsd to define your data, you are not restricting yourself to having to use XML. You can still configure the framework to use JSON to serialize your object before sending it to the queue. The xsd is really just outlining the structure of the class your message will be based on.

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 Apr 6, 2014 at 2:39 AM by michaelstephenson, version 2


No comments yet.