BizTalk really is a premium-feature toolbox. If you need EDI or SWIFT or HL7 support or the adapters then you'll have to license that toolbox according to what you need. The "free" parts of .NET are licensed through Windows Server or through Windows Azure, these premium features are licensed with that toolbox. The BizTalk Branch edition already covers a lot of ground http://www.microsoft.com/biztalk/en/us/pricing-licensing.aspx

You need BizTalk's capabilities for certain paths, not all paths. Yes, if you want to handle EDI interchanges inbound or outbound you will still need a right-sized BizTalk installation for that particular path and scaled to the particular load (which usually isn't consumer-scale) that makes up part of a service's gateway, but it's not "the" gateway.

Multiples service can obviously share that same installation of that kind of traffic if there are clear rules about who owns what and the paths are distinct in order to minimize cross-service dependencies.

That said, I'm working on some pieces that aim to help with gluing things together for gateways. All the technology you'll need exists in the stack, but there's a gap on pulling it all together. You'll hear about this in the next few weeks and it's going to be an open initiative.

@codputer This isn't primarily a scalability issue. This is an ownership issue. Who owns that universal pub/sub bus abstraction? If I have a service and that service spews out financial market data, it's the service I go to to subscribe to that data. Yes, I could make a universal pub/sub bus so that I could subscribe to any other kind of market data as well, but now you've moved the problem of making multi-source market data uniformly consumable to the universal bus. A service that's the clearly chartered owner of a particular business domain is a lot better at that.

Thank you, Joey. Hundreds or thousands of fields are commonly some dozen sections of some dozen groups of some dozen fields. Looking at EDIFACT or X12 dictionaries I see composable groups of largely separate but related concerns. An X12 document can quite well be seen as a session or exchange of a set of small messages. Also, every field you send there matters, whether you send 1000 or 10, so I don't see how structural complexity makes a loosely coupled approach that anticipates change less valid. It is arguably less convenient to deal with.

Validation matters. But I am meanwhile convinced that the validation engine needs to know what it is doing and it needs to have a notion of the semantics. And it surely must not stand in the way of change. Validation along the lines of a markup-language-formalization-language that has no notion of context has largely proven to be harmful. Example: We had a schema validation code path that an eager developer put in slip by in code review and had to completely redesign the feature since we couldn't provide backwards compatibility with the schema-validating client we shipped in the previous version. It's not an isolated case.

Redownload the SDK if you see issues like Gerald has; also, the 404 error VkDev reports is actually a false-positive "error" reported by the VS Debugger based on the WinRT Http library. Just continue execution.