Have I got an architecture for you!
It's cool. We have a set of services that underlie the user interface and collaboration infrastructure. The U/I can be built entirely on services, and the services are independent of one another. On paper, we are isolated and clean.
One problem... some of those services don't belong in this app!
You see, we are building an infrastructure that will allow integration as a "root behavior" of the app, not an add-on. The app will call services in other systems to get key data. That data won't be local. So, part of the services infrastructure includes services in other apps.
Those services don't exist.
Three choices here
All three are poor options.
If you want to know why SOA has a hard time taking off, this is it.
Two ways to counteract this, both must be done simultaneously:
SOA is intentional. In order to build services that others "may" need, you have to know what those services are, before you need them, and you have to know what systems should provide them, so that when funding happens against those systems, you are ready to pounce with a requirement to build the service. That requires you to plan out the interactions between most every system... a complete future state architecture. It doesn't get much more difficult, or important, than that.
I have a nagging question - is it common to build web applications where the UI completely relies completely on web services and the only consumer of these services is the one web application. I ask this question because the architect in my company believes that is way to go because we are an SOA shop. I don't see reuse of these services from any other application. My argument being if you design these stand alone web applications as three tier apps but all the tiers are hosted in the same app domain (meaning web apps calling into BLL across stack frames), it is much more efficient because you don't incur the penality of serialziation and deserialization. And authorization is much simpler because you don't run into the double-hop issue. Just wondering if you have any thoughts on this....
Web services does not an SOA make. That is one technical mechanism for passing messages, and it is a good one, but you can build a Service Oriented Architecture on any service technology.
Tell you what: tell your architect that you are happy, no thrilled, to build his Service Oriented Business Application (SOBA), but you want the messages to be passed using Windows Communication Foundation services (WCF). It is still service oriented, but far more efficient because you are passing messages in binary instead of XML, and the security issues can be more easily handled.
You both win with WCF.
In a better place, your services need to be published and reused by other apps. You can build a SOBA without collaboration, but it is only a start on a SOA. Perhaps your architect has a grander plan than you see... or perhaps he has no mechanism to build that grander plan... that would be where Enterprise Architecture could help out.