Rourke on SOA

David Linthicum recently wrote a great piece on designing for performance in SOA-based development environments. It’s good to see an influential SOA blogger talking about performance; there’s far too little talk about performance among analysts and thought leader. Performance and scalability are extremely important, and if you don’t consider them from the beginning and design for performance you will pay for it later.

In traditional application development, architects could get away with ignoring performance concerns when the application in question had very minor load and latency requirements. In the world of SOA this isn’t an option. The service you write today for a low load application will be re-used tomorrow in a high load environment.

In many cases you will discover that there’s a tradeoff between strict architectural elegance and adherence to standards on one side, and performance on the other side. Tradeoffs of this sort will exist at the enterprise architecture level, where you need to consider the highest load scenario your enterprise is likely to encounter. In many cases you will need to have two ways of doing things, the right way and the fast way.

At the service level, you’ll face the same issue, and you should consider how each given service is likely to be used within an appropriate time horizon. Choosing that time horizon is important, as “forever” planning is dangerous and wasteful.

David’s post raised many excellent points, but I’d like to call out two of them and offer specific advice from my experience:

Second, many services are built on top of more traditional legacy APIs, and as such the translations between legacy APIs to expose them as services may cause performance problems.

Third, use of too many fine grained services may cause performance problems. Indeed, you should not be afraid to leverage fine grained services within your SOA. However, you need to understand the performance issues with doing so, taking careful consideration of the network bandwidth and how other applications leverage the services.

Do not make everything a service. Things that are likely to be re-used should be services, everything else should simply be leveraged as efficiently as possible. For example, if your organization has many applications that need to check a customer’s credit score you should build a service that does exactly that. Let’s say that getting the credit score requires querying a database, checking a mainframe system, making a SOAP call against a partner, and then executing SAS operation. Do not wrap each and every one of those operations in SOAP and then build a BPEL orchestration around those SOAP calls. Simply build a credit score service that natively leverages those other systems and expose your credit score service over SOAP for applications to re-use.

The above applies in all cases, as this is both the fast way and the right way to build composite services that make specific use of existing assets.