SIGALRM's Journal: My first SOA .NET project

I've done some work in the past on various n-tier apps, mostly J2EE, and recently one interesting prototype using XML-RPC in a .NET client -> Apache -> XML-RPC -> PHP configuration.

OOA vs. SOA. It was with a little trepidation that we carefully examined and began to examine SOA (service-oriented architecture) in a .NET environment. We began by assessing this project in terms of service boundary requirements, including the fact that our zone of trust will span extra- as well as intra-nets. Something I'm learning is knowing when to build a service interface for an application feature. After analyzing the requirements of this project, it seemed appropriate to build a SOA spanning the entire mid-tier of our project.

Back and forth. OK, now that we settled on SOA it was time to pick a technology. I accuse one of our developers--who is an ex-Microsoft employee--of being irrationally "wedded" to any Redmond idea. We seem to argue endlessly on J2EE vs. .NET, merits and weaknesses. But when it comes to SOA, we agree that it's more than just a pragmatic marketing term; it unites many existing architectural principles around SOAP. There was some discussion about whether asynchronous messaging was a necessary part of a service orientation. My feeling is that since you can achieve synchronous patterns over asynchronous communications that having asynchronous messaging capabilities is extremely useful... but we're still open on that question. Although it's possible that these principles could be applied without SOAP, it's the fact that Microsoft, IBM, BEA and others have agreed that SOAP will be the lowest common denominator that is the pragmatic reason behind the current push for SOA.

Our platform decision. This article did alot to convince me that Microsoft has a very strong commitment to, and mature implementation of SOA. And Indigo and the entire .NET roadmap will only improve their position vis-a-vis SOA. Yes, they've undergone a period of adjustment. Every implementation does, right? So we decided to give this a shot in our project.

Writing some code. This is where it got fun. Microsoft has some amazingly seamless integration of server-to-client exposure of web service via an XML Web Service Proxy. I'm impressed. I won't bore you with the details, if you're interested in knowing more check out this MSDN article. Suffice to say, it's so easy my Grandma could code web services in .NET... OK, maybe not, but I'm impressed by the thought and effort that's gone into the framework.

Conclusion. If you're considering J2EE right now, there may of course be compelling reasons to implement it in your application framework. But don't overlook .NET. Don't allow some anti-Microsoft bias prevent you from exploring the "other service-orientation", it's very robust and the patterns required to see a project like yours (and ours) may be quite simpler under .NET than J2EE.

I'd be interested in your thoughts, of course.

-Sig