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 - service object mapper. So again, what are the reasons for wervices rather than objects?
A:
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.
fishtoprecords
2010-04-06 22:18:05
Ok, forget about technical difficulties as I asked in the question and tell me how different is sending messages in the WS way from the message passing in distributed objects?
Gabriel Ščerbák
2010-04-06 22:31:58
Passing a distributed object means you are passing the code and data of an Object. When I wrote about passing a message, I meant passing some text/string data that can be parsed/read into an Object on the receiving end.Its much like using a RDBMS package rather than doing your own file IO, with the DBMS, someone else can add columns, indexices, etc and your code doesn't care. When you pass Objects, you have to keep their definitions in sync.
fishtoprecords
2010-05-11 05:23:13
A:
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.
S.Lott
2010-04-06 22:33:48
I agree, implementing distributed objects might be more complex, but the mapping seams to weight it out. Also arguments to the services can be only pure data, no objects, so it still won't look any more non-procedural to me, even with the singleton idea. I don't say services and processes are unnatural, they are better for many cases as you mentioned, but OOP replaced procedural programming at lower level in the mainstream use, so I guess it is easier for developers to think in terms of OOP just as it is for me.
Gabriel Ščerbák
2010-04-06 22:52:40
@Gabriel Ščerbák: "Also arguments to the services can be only pure data, no objects": False. Arguments can be serialized objects. Services **are** objects. It's easy to apply OO design to services. Why do you keep repeating that services are simply procedures? They're **methods** of a singleton **Object**.
S.Lott
2010-04-07 10:00:36
Sometimes it might be valid use case to use an object as an argument, but not because of its data, but its behaviour. How would you model this using services? How can be behaviour put to the data passed as arguments to service calls? Would you pass as an argument some sort of url to another singleton?
Gabriel Ščerbák
2010-04-07 10:22:52
+3
A:
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...
Szymon Pobiega
2010-04-07 02:39:43
This seems like an actual point, but it still is not a real argument, because there are many concepts which are more coarse grained and can be used and as well as services modeled using objects.
Gabriel Ščerbák
2010-04-07 03:04:27
+1
A:
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.
Torbjørn
2010-04-07 05:30:49
I am not entirely sure if you mentioned actors just for example or if you indirectly proposed an object oriented alternative to services. Don't get me wrong, I just want to see beyond the hype.
Gabriel Ščerbák
2010-04-07 06:17:46
I just tried to bring some light to the subject in question by drawing a parallel to the difference between "vanilla OOP" and Actor model.
Torbjørn
2010-04-07 08:37:56
By vanilla OOP I mean mainstream OOP in C#/Java/whatever. OO - the idea - is bigger, and according to ppl like Alan Key it should have been all about messages in the first place: "I'm sorry I coined the term objects; It's all about messages". Erlang is also kind of OO - the idea - even though there are no classes or objects. http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
Torbjørn
2010-04-07 08:40:50
A:
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)
ima
2010-04-07 06:26:01
Web services were presented to me as better way of distributing then previous CORBA technologies. When I asked for arguments, only technical details were presented. OOP is IMHO nowadays prevailant (over procedural appraoch) so I am confused why to go back at the conceptual level?SOAP lost its original meaning long ago. I have no experience, but I will believe you about WCF, but isn't it any different from mixing procedural (C style) in C++ (OOP)? It seems to me conceptually wrong. If actor objects (as mentioned) were the web services, it would make sense to me.
Gabriel Ščerbák
2010-04-07 06:33:45
Why are you equating web services with procedural approach? It can be argued that SOA is procedural (and it will be still a big simplification), but technology of web services - certainly not.
ima
2010-04-07 08:08:49