How are distributed services better than distributed objects?

I am not interested in the technology e.g. CORBA vs Web Services, I am interested in principles. When we are doing OOP, why should we have something so procedural at higher level? Is not it the same as with OOP and relational databases? Often services are supported through code generation, apart from boilerplate, I think it is because we new SOM 开发者_StackOverflow中文版- service object mapper. So again, what are the reasons for wervices rather than objects?

---

The main difference between distributing services vs distributing objects is that services and their operations are by definition coarse-grained while objects are by default fine-grained.

When doing remote calls, network latency is a fact and the more coarse is your interface, the better. Service-oriented patterns and practices focus on building such interfaces.

So, to sum up, the problem is not in the technology or protocol (binary vs XML) but rather in usage scenarios. You can create 'services' in CORBA and do old-school distributed objects programming in WCF, but the former seems to be more biased towards objects while the latter -- towards services...

---

Distributed objects and remote procedure calls are kind of like shared state between processes, while Services are self contained.

It can be compared to the relationship between normal OOP in a shared state language, and a language using the Actor model and no shared state (like in Erlang, where you have a lot of light-weight processes not sharing anything, but communicating through messages only). The Actor model approach is much less complex, and can give you benefits in relation to concurrency etc.

---

IMHO, there is little difference at a high level. But at an implementation level, distributed objects, CORBA, Java RMI, etc. leave a lot to be desired. I tried to work with CORBA and later RMI in real production systems, and keeping versions in sync was a nightmare.

These days, I send messages and get responses.

---

Distributed object means what? Two copies of the same object which must be synchronized? two-phase commit to each change to the object? Complex.

Moving an object around the network from location to location? In this case, you've got to be sure that "ownership" is correctly relinquished. How does one host know the other has changed state on the object? It has to be -- what -- copied back again?

The "distributed object" model rapidly gets complex.

A service -- at it's simplest -- means that exactly one host offers the service and maintains state. Relational databases have exemplified this services model for decades. As do other traditional services (i.e., email, NIS, etc.)

With one host offering services, there's no synchronization among copies, no duplication and very limited complexity.

"why should we have something so procedural at higher level"

You don't have something procedural at a higher level.

You have an object (the host that offers the services) with multiple methods. It's perfectly object-oriented.

It's -- generally -- a Singleton, which makes life very simple.

---

Why the contraposition? Concepts of distributed services and distributed objects overlap greatly, if not entirely (and SOAP is object access protocol, after all). WCF is one example of switching between 'web service' and 'remote object' by a single line of configuration.

Difference is mostly terminological, explained by historical areas of application.

(Szymon wrote essentially the same eariler)