Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Can DI/IoC be used for a simplified, local SOA?

I have been reading up on SOA (examples: here, here and here) and it seems that at first a lot of the attention was at interoperability and enabeling distribution of tasks by using standard message-formats and transfer-protocols (web-services). Later the crux has been to achieve loose coupling: To find principles for partitioning business-logic, manage dependencies and how and when to share data between parts.

Is this a correct description? How is this related to DI/IoC? For a system with low performance requirements would it be a simplification to use DI as a "message broker", and asynchronous events to do "pub/sub" and only break out a service and go across an ESB or such as required by integrations?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

SOA (particularly the view championed by Udi Dahan) certainly shares its purpose with DI: decoupling systems. However, although the purpose is the same, and some of the mechanics superficially resemble each other (e.g. programming against contracts), the level of granularity is different.

The most important point in both systems is to be able to vary separate systems independently of each other. However, that ambition has a much more profound impact in SOA because each system may be implemented on different platforms and running on different hardware.

Imagine a 'true' SOA architecture implemented on a uniform platform (Java or .NET or similar). In this case you could conceivably collapse the architecture and run a single-box installation using in-memory message brokers, etc.

However, don't expect the reverse to hold. If you start out by writing an application that uses asynchronous messaging and what would look like a SOA architecture, there's no guarantee that you can subsequently scale it out.

There's a lot of subtle pitfalls that one tends to miss until one actually tries it out. One example is that services share data, but not class. If you don't think very hard about these things, you're likely to make some implicit assumptions about how messages are being passed around.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.