ClemensV

ClemensV

ClemensVasters

Niner since 2011

Clemens Vasters is the Technical Lead in Microsoft's PM team for the Windows Azure Service Bus. In that function, Clemens is responsible for the technical strategy of the product and to help Windows Azure customers to leverage Service Bus and other middleware components from the Windows Azure and Windows Server stack to build sophisticated, distributed business and consumer solutions. Clemens has over 20 years of industry experience with a deep background in Solution Architecture. He's an accomplished conference speaker, author, teacher, and will soon also be an Internet-video-show host. Follow @ClemensV on Twitter.

Posts
Comments

See more posts…

Where's the ESB?
Mar 19, 2013 at 10:03 AM

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
Where's the ESB?
Mar 19, 2013 at 9:29 AM

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.
Where's the ESB?
Mar 18, 2013 at 1:45 PM

@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.
Where's the ESB?
Mar 18, 2013 at 11:03 AM

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.
Data/Contract Coupling in Messaging
Feb 09, 2013 at 1:41 AM

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.
Service Bus Notification Hubs - Code Walkthrough - Windows 8 Edition
Feb 04, 2013 at 4:23 AM

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.
Service Bus Notification Hubs - Code Walkthrough - Windows 8 Edition
Jan 27, 2013 at 1:56 AM

We will take a look at that, @GeraldH. Could you send me an email to clemensv@microsoft.com, please?
-- edit: We think this related to the code signing issue we fixed earlier.
Service Bus Notification Hubs - Code Walkthrough - Windows 8 Edition
Jan 24, 2013 at 12:53 AM

Thanks, @YsFred4. The code signing issue is something we caught just before going live and the signed bits are either in the pipeline or already in the download location, so I'd encourage you to download them once more and check.
How Halo 4 is using Windows Azure Service Bus
Jan 17, 2013 at 11:30 AM

@Zane:The audio has been fixed now
Overview and Roadmap of Windows Azure Service Bus
Jun 16, 2012 at 7:24 PM

Well, Vlad, we had the first version of the Relay in 05/2006. So that's not quite 7 years since 2005. See: http://blogs.msdn.com/b/labsrelay/archive/2006/05/31/612288.aspx

And what's up with "Please keep in mind that HttpVPN is still a Beta and is a bit unpolished." on the page you point to?
Kind Regards
Clemens

See more comments…

Staff