Can we build it? YES we can, but shouldn't because there's platform support for that.
Developers are an enthusiastic people, especially when it comes to solving problems. In their pursuit of solution Valhalla some tend do create their own solutions for problems the platform obviously offers support. A classic example:
There's two applications that need to communicate with each other for some reason. .Net offers a few ways of doing this:
SOAP over HTTP,
.Net remoting,
Socket communication
Someone with Bob the builder syndrome will always choose the later of the three. Reasons he would probably give are:
a) We have total control over what happens (control freak)
b) I've already looked into this and it looks pretty straightforward (oversimplifying)
c) The platform abstraction creates a lot of overhead (unfounded accusation)
I'm not saying you should never use socket communication, there might be perfectly good reasons to do so. But only after the other two have been ruled out for a really good reason. Before you know it the socket based approach will take you to your own proprietary “remoting” solution of streaming object between TCP endpoints.
Having a bob the builder in your project team can be quit a challenge. They usually are not easily persuaded and offer a well meant “I told you so” at every problem you run into. Though I sympathize with the Bob the builders in this world for building everything from the ground up is fun (I admit there's a Bob the builder in me too), there's often not a lot fun having to clean up the mess after the “pretty straightforward” solution develops into an over complex nightmare.
One of the new features in Biztalk 2006 is the use of pipeline in your orchestration. Recently I was involved in a Biztalk 2006 project were we needed to route messages through Biztalk were (for the larger part) Biztalk engine was unaware of the schema of the data being processed. In Biztalk 2004 this would involve some helper code to be written. In Biztalk 2006 you can accomplish this quit easilly.
Our main orchestration received the data from a soap call. The data we needed to proces was inside an any node in the received data. We needed to extract the XML in the any node and send along for further processing by another orchestration. Afterwards we received the processed data back to our main orchestration and needed to put the processed data in the respons of the soap call.
For both sending the data to be processed and extracting the processed data we used a pipeline call (send and receive pipeline respectively). The pipeline call executed a custom pipeline to envelope / de-envelope the data.
I'm quit pleased with this new addition to Biztalk 2006 because I think it can make life a lot easier in a couple of scenario's.
See also:
http://geekswithblogs.net/arnoudlems/articles/69521.aspx