(转帖) BizTalk messages based on .NET types instead of XSD schemas

Abstract: You can create a BizTalk message from a custom .NET class, instead of using an Xsd schema. This practice has some pros and cons. Let’s see…

Usually, the most common process is to start creating Xsd schemas, and use them in Orchestrations, to define BizTalk messages. But, why would you like to have BizTalk messages based on Xml? It seems obvious that all messages should be Xml based, but in fact, sometimes Xsd/Xml is not necessary and adds complexity.

When is Xsd/Xml needed?
Xml messages are very nice if you need Messaging. That is, interoperatibility, external communications, schema publication. But surprisingly, I find many situations where people are defining Xsd schemas for Xml messages where Xml is not needed at all. Well, Xml is still fashionable, so…
If a message lives inside an orchestration (is being passed from within orchestrations), but it’s never going to be published externally, or is never going to be sent/received externally, there’s no advantage in using Xml. In fact, there’s no reason to use Xml.

Xsd hell: how do you create a message from the scratch?
It’s a well known issue that creating an empty instance of a message inside an orchestration is not easy. Having the xml string hardcoded is not very elegant. Pointing to a file is not very elegant at all. You would need the path harcoded. Well, you can put it in a .config file, but… isn’t too complex to just create an empty message?
I’ve read some discussion about using Maps to create empty (or default valued) instances. Since I agree it’s a good idea, it’s still too complex to just create an instance of a message.
This message-from-the-scratch problem is inherent to the use of Xml, since a message is not instantiable.

Using a .NET class
You can use a .NET class, instead a Xsd schema. Define your orchestration message as a .NET type, using your class. Use references to XLANGs Base Types to promote your class properties to distinguised fields or properties.
Pros:
Instantiate it. Use constructors, destructors, static members for instance creation or whatever you want.
Use rich properties. Mark public properties as promoted or distinguished fields. Use get and set methods.
Reuse as objects in other projects.
Cons:
External publication and Interoperatibility. There is no Schema, so if you intend to publish it externally, what do you publish?
Dependency of XLANG assemblies, so limited reuse outside your BizTalk project.

Simple Sample:
Create a .NET class:

using System;

namespace STCEAI.Messages

{

 [Serializable]

 public class SimpleMessage

 {

  private string _id;



  public SimpleMessage()

  {

  }



  [Microsoft.XLANGs.BaseTypes.DistinguishedField]

  public string Id

  {

   get{ return _id;}

   set{ _id = value;}

  }



  public static SimpleMessage Create()

  {

   SimpleMessage msg = new SimpleMessage();

   msg.Id = System.Guid.NewGuid().ToString();

   return msg;

  }

 }

}

Note the property is marked as Distinguished Field in order to make it visible from within the orchestration. This attribute is in Microsoft.BizTalk.XLANGs.BaseTypes.dll. You can also mark it as a promoted property, assign a Namespace, and include all the Xml serialization attributes as needed.

Usage inside an orchestration, in a Message Assignment Shape :

 

SimpleMessage_msg = new STCEAI.Messages.SimpleMessage();

SimpleMessage_msg.Id = myId;

or better:

SimpleMessage_msg = new STCEAI.Messages.SimpleMessage.Create();

转自BizTalk messages based on .NET types instead of Xsd schemas