It's not about SOA vs Spring
My opinion is that the hard part of SOA is defining the set of services in your architecture. That is a design challenge. Spring has nothing to do with that, nor does any ESB or any SOA-ish product sold by a vendor.
Where Spring always fits well for me is in the implementation of the services. You want to use good OO principles in building these services, and for me, Spring is excellent in wiring together loosely-coupled objects to build the services.
Once you have your services defined and implemented, you can then think about how to “orchestrate” them, as SOA enthusiasts like to say, and it sounds like that’s where your different camps disagree.
As an example of orchestration via an ESB, BEA’s AquaLogic Service Bus docs show a tutorial where a loan application is received and then routed to one of two loan services based on the content of the application. Using AquaLogic, you use an admin console to declaratively create a logical service (called a “project”) that has a proxy service that decides which business service to send the application to. AquaLogic has neat little wizards to help you do this graphically, so you can fire all of your developers after they’ve built the services ;). With Mule and ServiceMix, you’d do this work declaratively via XML configuration instead of a whiz-bang GUI (Mule and ServiceMix also cost about $75k less than AquaLogic).
But of course, there’s no reason why you can’t create this integration logic using Java code. You could easily make a “LoanServiceSelector” class that has dependencies on multiple loan services, and you could code the logic for selecting a loan service in that Java class. You could then define this as a bean in your Spring container and expose it as an Axis/Xfire/Glue/etc web service, or via RMI, or via Burlap or Hessian, or via anything you’d like. It’s a service no matter how you do it. And you can wire in dependencies on loan services through Spring, and those loan services could actually be web services, or Burlap services, or local objects. Spring’s remoting package will handle that plumbing, just like a lot of ESB products seem to handle this kind of integration plumbing.
And of course, Spring isn’t needed in this case, but most of us on this forum probably feel we get a lot of value out of Spring, so we use it.
So basically, my opinion is that the real work in building an SOA is identifying and designing your services. How you then orchestrate them is the easier part.
Do a trade study on ESBs, and if you feel like you get a lot of value from a particular one in relation to the cost, then use it. Mule has some pretty good examples of using an ESB, and if you read the user email list, you can read about other problems that people are trying to solve using an ESB. If it turns out that you don’t think you get enough value out of an ESB to warrant adopting it (and learning it), then code the integration logic in normal Java code like you’ve always been able to do, and use Spring to help with the development of that integration logic.