I noticed from the site stats that a lot of our visitors are reaching us via Google Images, often for the SVG icon library that we have built from the Tango project base images. It's good to know that people are finding these useful, I certainly appreciate the combination of icons and Inkscape as a useful replacement for Visio!

However when I dug around on Google images myself I realised that the metadata on most of our images is pretty poor and this makes it hard to search and find unless you know exactly what you are looking for.

Therefore I have cleaned up the image descriptions (title and alt text tags), which should result in smoother searching. I'll go through the rest of the site in the coming weeks as well

For the 09_02 release we will probably look to update the icons library with some new images. Let us know via email if there are icons you want to see.

There are several technology trends that push the development and adoption of distributed systems. Probably most discussed are "Service Oriented Architecture (SOA)" and "Software as a Service (SaaS)".

SOA is often advertised as a great means to standardize business processes within a corporation. The business processes are herefore divided into (reusable) subprocesses which eventually are digitally implemented as "IT Services". The promoter of this method believe that SOA is good way to replace these (old legacy) monolithic IT systems.

One of the unique new characteristics of SOA (when compared to other distributed computing paradigms (such as RMI, CORBA, RPC…) is that SOA services can be dynamically located. The oponents of SOA however consider this dynamicity as the death of current best testing practices, because you basically abandon system integration testing, because the "integration", i.e. the calling context, is not known before deployment time.

Another point of criticism is that (due to limited resources and skills) most implementations do not have information on pre and post-conditions for service calls. As a consequence, if you really wanted reliability and security, every called service needs to make enough checks to induce the trust level that it needs in the current calling context. Of course this is not feasible due to restricted development resources and later due to restricted computing resources.

Compare this to your SAP system or old RACF protected mainframe system where the trust boundaries are at least clear and you can take appropriate actions because the trust assumptions are static.

The author believes that the dynamicity and the lack of notion of trust boundaries in the SOA concept will eventually reduce the security of SOA based systems (because most system developments take a short cut and abandon the tedious trust establishment).

Don't believe me? Ask your system architect where the trust boundaries are for the new SOA services that she is developing.