There has been an ongoing debate over the value of REST and the value of SOAP, when it comes to SOA. Ss much as been said about it, I did not think I could add much value to the discussion.

Of course, the issues go well beyond performance, but lately I've been working with a number of companies that are focused on just that...SOA performance.

Indeed, Web Services are slow. There, I said it. They are very synchronous in nature, and do cause concern for those building a SOA around Web services (Keep in mind that Web services are only one type of technology you may use to build your SOA). However, tossing new standards and technology at the problem won't get you there. Instead, you need to think at a more fundamental level...the design of the service.

Truth-be-told is most developers have gotten accustomed to having commodity resources available in their deployment environments, meaning memory, CPU, bandwidth, I/O, etc., and many don't think "service efficiencies" when designing (if they do design), programming, and deploying a Web service. In fact I'm reviewing services now that with just some rethinking in terms of how they leverage resources, including when, how often, and why...they are increasing service performance by 200 percent in many cases. Also, the whole "too course grained" or "too fine grained" thing becomes issues as well.

The key issue is that most service developers don't understand service design yet, and build them without a clear understanding of the consequences of some of their design decisions. They build them, deploy them, get them working and any performance issues can be blamed on the inefficiencies of SOAP. While SOAP can take part of the wrap, as can the overall set of standards, most of the issues that cause performance problems can be tracked back a human with a compiler.

To that end, here are some general guidelines:

1. Design the service to minimize the number of times communications is required with other services, devices, or the container.
2. Consider organic growth of the data and amount of data transmission. Something working well today at 10 transactions-per-second, may die at 100.
3. Perform a practical number of POC performance tests using several design approaches. Make sure to address granularity.
4. Try different enabling standards. Don’t rely on others to tell you that something is faster, prove it within your own problem domain.
5. Think through your service design, and account for efficiency. Perhaps consider CMM level 3 design and review patterns.
6. Don’t be afraid to try new things…a small increase in performance could save you from a lot of problems down the road.
7. Make sure you decompose your services considering usability, functionality, and performance.

Posted by Dave Linthicum on January 16, 2007 09:06 AM