ClemensV

@pkanavos:Thank you. The new files are encoding and this should be fixed in a little while.

@compupc1: Premium Messaging is brokered messaging only, and does not include the Relay. The current version of the Relay would not benefit as much from the resource isolation that we provide here, so the Relay remains available in Standard as you know it. We're in early planning for a significant upgrade of the Relay, and that new version might indeed have a Premium tier. I can't talk about particular capabilities as of yet.

@Mike Schellenberger:Thank you for your patience, Mike. This happens to a few customers and our portal folks are working on figuring it out.

@MattYetAnotherUserName: I'm very sorry about that. We've identified a portal glitch and are working on it. Try going via New > Hybrid Integration > Service Bus

Use the link in the write-up above (points to https://portal.azure.com/?Microsoft_Azure_ServiceBus=true&l=en&r=1#create/Microsoft.ServiceBus ).

We'll take a look at why you can't see it.  

@JordiGOnzalez: @arcturien: Added the PPT linked from the text

I'll get there in one of the next few episodes, Dave. The security intro will likely be a whiteboard session since there'll be a lot of basic to cover.

Very punny, @joshnock

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 https://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.

NServiceBus is a commercial messaging framework that layers over the actual messaging infrastructure. My understanding is that it favors a peer-to-peer model over centralization.