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?

Technical Debt, the real costs of corner cutting

Found on Martin Fowlers Bliki yesterday:

http://martinfowler.com/bliki/TechnicalDebt.html

Technical Debt, a term invented by Ward Cunningham to describe the effects of having code being badly designed for current circumstances (my paraphrasing) due to a variety of circumstances.

In our case this debt is incurred by not re-working our software for new situations or platforms. The system as a whole isn't bad, but we have a few cranky old parts to our system that need a bit of TLC (Tender Love and Care). Whenever we need to look at those screens, we see how much work it would be to rewrite them the way we all know we want to but every time we have a project effect them we 'um' and 'ah' and finally decide that the project can't afford the rewrite, or schedules don't allow for it or there is no testing resource for the rewrite.

Optimisation, afterthought or not

It is funny how placing your ideas on an open stage makes one re-consider ones position.

I mentioned in this post on How Google Earth Really Works about how optimisation at my workplace is an afterthought.

Ahhhh, no!

I started to realise that optimisation of our applications has such a solid foundation that it 'blends into the woodwork' of my daily existence. It was enlightening looking at another problem domain's optimisations.

We develop business software in Oracle, SQL, PL/SQL, Forms and Java with all sorts of other things like Perl, PHP and Shell scripting, even some old PRO*C code.

So what has blended into the background:

• SQL statements over networks are course grained calls, which work well.
  
• Indexes are always used for primary keys and foreign keys.
  
• Oracle Forms uses those indexes and have reasonable optimisation defaults.
  
• We tend to design using denormalised large tables, normalisation can have a drastic effect on performance, even in todays crazy supercomputers.
  
• Probably a lot more that I can't see for the trees at the moment.
  

p.s. My spellchecker makes me aware that I am not writing US English, I am writing in UK/NZ English. For those who don't know, the words above do not end in 'ize' :).