Fellow Austinite and champion ranter Scott Bellware has some great insight on the impedance mismatch between application architecture and the newer SOA paradigm. Overall, I think SOA is an advance in the construction of software solutions, especially in large IT infrastructures. What always bugs me is the seeming disdain (or ignorance) the SOA guys have for good OO or even application design. I’m familiar with the situation and perpetrator of the (very foolish) guidance of mandatory SOAP web services between the UI and backend (even if the code is all running in the same process space!) “just in case” they need a connected service later. In no way does the existence of SOA services abrogate the need to create well-factored solutions. Write a well-structured code base and your application will always be able to expose SOA endpoints later. And if you’re doing SOA, keep the internals of your service or system completely independent of the messaging transport. Like Scott implies, serializing your real domain classes as part of the SOAP contract strongly couples your clients to the internals of your service.
How I'm using StoryTeller to test FubuMVC
Building a "Lookup" html convention w/ FubuMVC
FubuMVC's Configuration Model "Special Sauce"
Managing Script dependencies with FubuMVC
Authorization and FubuMVC
Composing Views with FubuMVC
Extensible Model Binding with FubuMVC
Modular Packaging with FubuMVC
Self-Installing Apps w/ FubuMVC
Routing and Behavioral Conventions with FubuMVC
What Should I Learn?