SOA & J2EE, Revisited In More Detail

Undoubtedly, the J2EE enthusiasts will argue that my transaction model is unfair; that the MVC model is more flexible than I've portrayed. My goal is not to be "fair", but to determine the strengths and weaknesses of each model. SOA is still gaining strength. Why?

Updated SOA model with more detail. Notice how SOA pushes some transactions (routing and transformation) into the services layer, which is designed to be dynamically assignable, ergo it is quite scalable with good hardware.

Updated J2EE model. Notice how the controller really is... well... the controller. Of everything.

Q: What is one of the failure modes of a centralized network?
A: Saturation... the electronic equivalent of micro-management.

You can only push so many electrons through a single point source.
(that's a derivative of Kirchoff's law).

The saturation potential of MVC (closely associated with J2EE designs) is clearly shown.

It is true that J2EE and SOA are not mutual exclusive models, but... I could do an SOA system in Microsoft .Net.
Or with straight java or visual basic. SOA is a more abstract, more scalable model for large, heterogenous networks.

This is why it continues to gain mindshare (see graph at top of page).

Other thoughts... The separation of control from creation intrigues me. I believe that delegated creation is a better model for large organizations with many bodies of specialized domain knowledge. The network controls the interface, the domain specialists control how it works. I'd be very interested to see how SOA deploys into companies doing biotech, legal or accounting work.

I'm not surprised that IBM chose AbstractFactory as the foundation for the Business Directory. In my experience, it provides the maxiumum level of heterogenuity for the minimum amount of complexity, so it spans a level of design that most business applications can fit into.

Related articles -
cost curves for SOA versus J2EE
Saving J2EE, revisited