Tuesday, November 13, 2007

SOA vs Distributed Objects and performance

I don’t think this article goes into enough detail, but he delves into why object systems (such as EJB) have required architectural additions to simplify and control the performance problems.
i.e. EJB session beans to optimise and control access to EJB entity beans.

http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=507

Also I think he is onto an important point that the design of a service oriented architecture is more suited to optimisation on a network because it makes intuitable the network nature and tradeoffs of a call over a network (entirely my interpretation of his words).

And also if the caller of a service is requesting data then a large graph of data can be moved entirely into the callers context for rapid data use, managing the overhead and failure possibilities once and not hundreds of times (literally). Exactly why SQL over SQLNet can be easily optimised for net traffic.

When looking at a problem in a SOA way it seems that you naturally evolve a more optimal way to use the network. I don’t have enough experience with SOA to know what all the pitfalls are of that orientation though, there will definitely be pitfalls. Some pitfalls might be marshalling/demarshalling overhead, lack of data locking, brittleness of implementation due to change, cascading hidden service dependencies, service versioning issues.

When I went to an IBM seminar on SOA it was quite illuminating when they talked about a SOA ‘call’ with hundreds of parameter data elements. I actually thought it was rubbish to design a call with so many parameters, but I really don’t know enough to comment on the design of these systems. It might indeed be ‘good’(tm) to create such a call when the service is ‘state-free’, i.e. implements an algorithm that acts only on parameter supplied data. But a service/interface with so many parameters is sure to be volatile and that volatility could effect callers of the service.

What do other people think?, am I off the mark?

No comments: