There's no I in Interface

So, I was recently asked to look into a custom BizTalk solution whereby we could have a single receive location that takes a particular operation of type T. For example, DistributedOperation<OrderHold> .  The DistributedOperation would have a few properties that are common across all the messages that would be sent to this generic receive location, and T, of course, would be the specifics - the guts of the message for the most part. I guess you could think of the DistributedOperation properties as those that are "auditable" properties (timestamp, originating application, originating user, etc.), ubiquitous across all messages. I suppose the idea is that these things could be persisted, and then later queried for a traceable path of operations. The design, as explained to me, would be that a custom pipeline would take those DistributedOperation properties and make them distinguished fields of the message. Then take the payload ( OrderHold in our example) and make that t

Recently, I got the opportunity to start learning BizTalk: first BizTalk 2010 and, more recently, BizTalk 2013. It has been quite an experience. All the things I sorta took for granted (WCF, SOAP message formats, etc.) are now proving to be little nuggets (with deep threads!) of knowledge that, until now, I haven't needed to know.  BizTalk is Microsoft's answer for an Enterprise Service Bus (ESB). It can be used as a mediator/broker between multiple systems in a company infrastructure. It relies heavily on the pub/sub design pattern and uses the concept of  messaging almost exclusively.  BizTalk is designed to be extremely flexible. Which is good. And bad. Good in that it can most likely fill any gap that you may have in your company, but bad in that specificity is difficult to define: there are so many options! We're also in the process of establishing a new approach to the software systems we are responsible for. Along with that, we're implementing the notion of

One of the best parts of working in software development is the constant learning curve. This can also be a source of frustration. A long time ago, my physics professor said confusion is fine, but when you get to the point of frustration, that's not. Or something like that. I'm paraphrasing of course - that was {redacted} years ago. I like the process of learning and in the field of software development, there's no end in sight from what I can tell. To a point, sometimes, that it is overwhelming.