When all else fails, try SOA best practices: "'We have a best practices driven approach that SOA is architecture,' Bloomberg said. 'Architecture consists of best practices for leveraging IT to meet changing business needs. It doesn't start with the technology. It doesn't start with vendors. It starts with asking what do you want to do and what is the best way to do it?'"
In other words, a "services oriented architecture" seems to exist but nobody is about to lay claim to having found the right one yet as it is a burgeoning activity. If software is designed as a set of intricate services that are linked or are not linked; it sounds simple enough. But design is everything. If you do not fit things together properly early on for the activity, then when do we have? Lots of little activities. Each one may have a level of complexity but part of the idea of SOA is to keep services independent of each other. That is avoiding complexity.
The idea being to create parts of a system that can operate independent of each other. They do not contain parts of each other but send "function calls" to each other using WDSL and SOAP protocols. These are just ways to communicate that both end will understand and can verify.
The idea of foreign calls or "SOA viruses" or more accurately interceding services can be prevented by the protocol. It provides glue to link legacy systems to web access, as well as provide for inter-system functionality.
But the quote above implies that the reason for SOA is that IT is too hard to adapt to changing business needs. I would argue that changing business needs are just a factor of instability that arises when uncertainty exists in the business model. That an evolving business tries to adapt software to meet it needs but its own evolution is pegged to its understanding of IT capability.
No, the idea is to allow software to be adapted to suit new business conditions. The days of "the software is like that, so the business must follow" are over.