rdschneider

At first glance, SOA appears to simply be OO with the Internet factored in. But this is a serious misconception, one that has caused many projects to go off the rails. Bill Blondeau has written an excellent article that contrasts these two disciplines.

Some of my favorite quotes from the article:

 SOA is something new and different, with unprecedented capabilities; but it has its own logic and its own requirements. If you treat SOA as merely a different way to conduct the business of OO, it won’t go well. Unfortunately, aspects of IT culture have discouraged treating SOA as anything else.

It’s very easy to fall into this trap:

The IT industry’s reflex, nowadays, is to try to force-fit an Object Oriented paradigm over anything it can, and that’s not always a good idea. (An awful lot of Hibernate, to take just one example out of many, is not very technically valuable; its benefit is mainly cultural rather than technical: pleasing the sensibilities of the OO heuristic community.)

He provides a very useful, five-step guideline for re-architecting monolithic applications. In summary:

1. Conduct a thorough business-oriented analysis.
2. Compose the results of this research into effective service contract definitions.
3. Implement each service as an independent, standalone project.
4. While developing the business services – which the Mainstream SOA Methodology labels Entity services – determine any other necessary supporting services. These are commonly known as Utility services.
5. Finally, write the application (typically known as Task or Orchestrated Task services) to use all of these services.

Bill closes the article with a list of really smart points to ponder. Here are just two of these suggestions:

Don’t get sucked into implementation discussions (e.g. “Well, should we use SOAP or REST? What about JSON, can we use JSON?”) prematurely. They can easily obscure the points you need to concentrate on in the early stages of your analysis.

On our SOA design projects, I’m frequently asked how to compute the ideal number of services. In the absence of a hard-and-fast formula, try this out:

Shoot for the smallest number of simple Services you can get away with. Obviously, the simpler the individual Services, the more of them you need for a given set of functionality. Balancing Service simplicity against the Service number is an art not a science; do your best, and pay attention to the clarity and maintainability of the resulting suite.

Tagged: OO, SOA

Comments are closed.