I often find that a SOA is a tough sell. First from the technology point of view. In most organisations, there is a tight coupling between the consumer and the provider of the service. It is usually some kind of HTTP (RESTian services) or SOAP (web services) TCP/IP connection, involving the provider to be up and running, healthy, ready (e.g. not overloaded), appropriately monitored, and on top of that the consumer must know the physical address of a service (hostname and port number). That's much more than loading a jar file... Then from the maintenance point of view. Network services must, over time, handle many clients, usually supporting concurrent request (with all the race conditions and long debugging nights this is implying), handling most likely more than one request format because the services do evolve independently from the clients etc... On top of that, we have the lack of trackability (how do I know what the hell am i going to break if i upgrade the service?). Yep, there is no compiler telling me the broken dependencies here, no safety net. Often, when the risk is there, we prefer duplicating different versions of the same service, just because it is easier, less risky, and costing less, which goes against the holy grail of reusability that a SOA architecture is trying to promote even further... All of these problems, makes a SOA architecture very expensive. Expensive because of the maintenance. Expensive because of the race conditions. Expensive because of the top-notch developers we have to hire to SOA right. Expensive from the so many pitfalls companies keep falling in, the most famous of them being too fine grained services resulting in architectures spending their time waiting for the network... Yet, we want to keep breaking the first law of distributed objects: Don't distribute them (Martin Fowler). So... It is a tough sell... Sorry, that's a fact. You might think that i do not advocate a SOA right ?. You'd be dead wrong. I am actually implementing one, or trying to. But i know too well the pitfalls i want to avoid... I don't want to have to upgrade all my clients if the host is changing. I don't want to crash all my clients if the service is down. I don't want tight coupling between providers and consumers. I think we can achieve a pretty good SOA with a message oriented middleware, a la Tibco or JMS. The issue remaining to solve is the interoperability. I have all sort of clients , C sharp clients Perl clients, MS Office (VB, Excel etc...) clients; How do i send JMS messages (in the open source world, that is staying away from proprietary technologies, otherwise that'd be too easy :-)). I welcome toughts and ideas :-).