Distributed Weekly 43

Architecture

• A Discussion with Allard Buijze on CQRS with the Axon framework
• Windows Server AppFabric Architecture
• UDDI R.I.P.

BizTalk/WF

• ESB Toolkit 2.0 Architecture Poster Available
• Windows Workflow Foundation in .NET4

REST

• Three Levels of the REST Maturity Model
• OData SDK Released
• Microsoft Has Released OData SDK and “Dallas” CTP 2
• not all Web APIs are the same

Posted in Distributed Weekly | 1 Comment »

Using WCF MessageContract to Model A Composite Schema

I have been working on a project where I needed to take an XML Schema Definition created in BizTalk and create a WCF service that would receive messages using the same schema. In this particular case, the XSD was a composite schema and was too complex for svcutil to automatically generate a data contract. (I prefer to create data contracts by hand anyway. The code generated by svcutil is a mess.) Attempting to model this using just the DataContract and DataMember attributes proved to be impossible because you can’t specify an XML namespace on a DataMember.

For example, if you have an XSD that imports elements from another XSD with a different target namespace, when you try and model it as a data contract there is no way to specify the that the imported schema elements belong to a different namespace. So if you have an XML document like this:

Sample XML message

<?xml version="1.0" encoding="utf-8" ?>
<ns0:MyMessage xmlns:ns0="http://someservice.example.com/">
    <ns0:Message>
        <ns0:MyElement>Data</ns0:MyElement>
    </ns0:Message>
    <ns1:OtherMessage xmlns:ns1="http://someservice.example.com/other/">
        <ns1:MyOtherElement>OtherData</ns1:MyOtherElement>
    </ns1:OtherMessage>
</ns0:MyMessage>

You might try and model that schema with something that looks like this:

DataContract

[DataContract(Namespace = @"http://someservice.example.com/")]
public class MyMessage
{
    [DataMember(Order = 1)]
    public Message Message { get; set; }
 
    [DataMember(Order = 2)]
    public OtherMessage OtherMessage { get; set; }
}
 
[DataContract(Namespace = @"http://someservice.example.com/")]
public class Message
{
    [DataMember(Order = 1)]
    public string MyElement { get; set; }
}
 
[DataContract(Namespace = @"http://someservice.example.com/other/")]
public class OtherMessage
{
    [DataMember(Order = 1)]
    public string MyOtherElement { get; set; }
}

If you use DataContract and DataMember attributes exclusively WCF will produce XML that looks like this:

WCF DataContract XML

<?xml version="1.0" encoding="utf-8" ?>
<ns0:MyMessage xmlns:ns0="http://someservice.example.com/">
    <ns0:Message>
        <ns0:MyElement>Data</ns0:MyElement>
    </ns0:Message>
    <ns0:OtherMessage xmlns:ns1="http://someservice.example.com/other/">
        <ns1:MyOtherElement>OtherData</ns1:MyOtherElement>
    </ns0:OtherMessage>
</ns0:MyMessage>

Note the incorrect namespace prefix on the OtherMessage elements. To get WCF to model the XSD correctly we need to turn the MessageContract attribute to get the job done. The MessageContract attribute along with the MessageBodyMember attribute (among others) gives you full control over the structure off your XML. So now we take the data contract we defined earlier for the Message and OtherMessage elements and combine it with a message contract to get the final result we are looking for.

MessageContract

[MessageContract(WrapperNamespace = @"http://someservice.example.com/")]
public class MyMessage
{
    [MessageBodyMember(Namespace = @"http://someservice.example.com/")]
    public Message Message { get; set; }
 
    [MessageBodyMember(Namespace = @"http://someservice.example.com/other/")]
    public OtherMessage { get; set; }
}

Posted in .NET, Technology | 1 Comment »

WCF Service Namespaces

Since I seem to forget this on a regular basis, I wanted to leave a note to myself for future reference. I also want to post a link to the Tech Talk blog where I found most of this information.

By default, WCF assigns the namespace “http://tempuri.org/” to all web service operations. (For more information on tempuri.org, see the W3C Note on WSDL.) Typically you will want to assign your own namespace to uniquely identify any web services you have deployed. Since WCF has a (seemingly) infinite number of configuration options, there are no fewer than three places you need to set the namespace to keep WCF from using the default tempuri.org.

The first is on the ServiceContract attribute. Set the namespace in the attribute constructor.

[ServiceContract(Namespace = @"http://someservice.example.com/")]
public interface ISomeService

The second place it needs to be set is on the ServiceBehavior attribute. Again, set the namespace in the attribute constructor.

[ServiceBehavior(Namespace = @"http://someservice.example.com/")]
public class SomeService : ISomeService

The third and final place it needs to be set is the bindingNamespace attribute on the endpoint element in the App.config file.

<endpoint bindingNamespace="http://someservice.example.com/"...>
...
</endpoint>

Posted in .NET, Technology | Comments Off

Distributed Weekly 42

BizTalk/ESB

• BizTalk & NService Bus Whitepaper
• Submitting messages to BizTalk using c# code

REST

• Creating a REST API with Agavi
• Versioning REST Services
• Dealing with REST Services Security
• Richardson Maturity Model: steps toward the glory of REST
• JSON-Mash

SQL Server Modeling

• The Busy Developer’s Guide to SQL Server Modeling *

WCF

• Working with WCF: Part Two – Your First Host and A Bit About Configuration
• Fix to Disable Transport Security with Message Credentials
• Fix to Allow Providing Outgoing Supporting Tokens
• Fix to Disable Security on Responses
• Fix for HTTP Configuration Errors using WebScriptEnablingBehavior

* Courtesy of Sam Gentile

Posted in Distributed Weekly | Comments Off

Distributed Weekly 41

BizTalk / M

• BTS Data Services – More info
• Codename “M”: Language, Data, and Modeling, Oh My!

REST

• The H Factor for Media Types
• RESTful Web services with Apache Wink, Part 2: Advanced topics in Apache Wink REST development
• DELETE and 201 Created

SOA

• SOA Manifesto – 4 Months After
• Why SOA still matters
• Emerging Industry SOA Best Practices
• Revisiting Biases Against Open Source SOA Solutions

WCF / WF

• SIMPLER Way of Hosting the WCF 4.0 Routing Service in IIS7
• Comparing Two Bindings
• Getting WCF 4 Release Candidate Documentation
• Working with WCF: Part One: Introduction and Your First Service
• New CTP Available for Download: WF Migration Kit

Posted in Distributed Weekly | Comments Off

Distributed Weekly 40

BizTalk

• Modifying BTS Send Ports and Receive Locations using SQL and .Net Code
• New white paper “BizTalk ESB Toolkit: Core Components and Examples”
• “Route Failed Messages” routes the wrong message – really?
• BizTalk Data Services: Making BizTalk more RESTful with OData
• Reasons for moving from BizTalk Server 2006 to BizTalk Server 2009 R2.

ESB

• NServiceBus 2.0 RTM

REST

• “PATCH is a very simple method”
• Classifying the CouchDB API
• The Farmer in the Dell
• Fielding Property Maps
• Versioning Strategies For RESTful Services
• REST-* Message Draft 5: new post and subcription protocol
• PubSubHubBub Publisher
• RESTWeekly Feb 22 2010

SOA

• Anti-Principles

WCF

• Windows Server AppFabric Beta 2 is Available!
• Parsing Standard Uris, Part 2
• AppFabric Beta 2 and Samples
• Compatibility Update for Serialization

Posted in Distributed Weekly | Comments Off