Sorry for the late reply... was under heavy load for the last weeks...
C'mon Remi, what's so hard about all of this?
Nothing...
If we stick to the known usecases, setup some kind of conversational context for security/ transactionality, surely we can implement a few data queries and update methods to fulfill that usecase.
Yep RDBMS do this fine since years.
SQL is *far* more interoperable than SOAP or REST or XML, if you forget Objects.
But yes, you could do it many ways...
It's only when we try and invent generalized object semantics and try to automagically remote objects without having well-understood behaviour & boundaries, that the problem gets complex.
I don't see it that way. Complexity is bound to requirements IMHO. But there's the technological factor too.
Just consider databases : we all used painful SQL statements for years before (working) OODBs and (efficient) ORMs... Do you still SQL ?
Well most of the times I rely on an OO persistence layer, just because it's simpler and far more powerful !
I mean, OO design has no comparison with procedural approaches. So no, I would not say the problem gets complex !
Also, I never said everything should be remote (would be great if possible but unfortunately this has a performance cost no one can afford).
CORBA has value types too, don't forget that !
It's only a question of design, you know, Distributed Applications Architect always struggle with granularity, that's the most recurrent issue...
So I'd say yes, you can do ugly things with CORBA... but you can't do OO things with SOAP ! And that's quite a bad thing IMHO.
Just imagine the CORBA works perfectly with firewalls etc.
What would you do to purchase an Amazon book (in CorbaScript for the sake of simplicity) would be more or less like (dummy example of course) :
// get amazon from NS
az =
ORB.resolve_initial_references("NamingService").resolve("Amazon");
// search books (returns value types)
books = az.search("books", "GoF", ...);
// buy a product
az.buy(books[i], my account data);
Now the REST equivalent (not the code, would be too long !) :
1/ define an XML mapping for your objects 'cause you don't want to write XML "by hand" of course - hibernate, castor, whatever...
2/ Open a pipe to the web server (yeaaaah, back to sockets !)
3/ Write the HTTP request (by hand ! check out corresponding RFC for the grammar), agree on the method semantics, parameter names, etc (no compiler can help there)...
4/ Add XML-serialized stuff to the HTTP request
5/ Look for XML coming back
6/ De-serialize to your prog language
7/ Re-serialize and send again for buying (or pass an ID !!!)
8/ Wait again for XML result...
9/ Parse, convert, transform again and show result
Still convinced ?
:-)
Either REST, with its verb-space URLs and parameter tuples,
or SOAP with its XML documents, are suited to pass requests with well-understood effects & transactional behaviour.
My problem is that it forces you to write additional code (translations). This costs, it is subject to bugs, maintenance is more expensive, etc.
Now my turn to ask a question : what's your problem in using business objects instead of using intermediate formats to finally to the same thing with thousands LOC more ???
:-)
Distributed services are fine & simple, but distributed objects are a mismatch for most architectural purposes.
I guess bad designers put that idea in the mind of people, it's not the first time I hear that.
A so-called "senior consultant" even told me that "OO development represent the old way, now it's services time" !!!
To me, nothing makes it impossible to build distributed services as Objects. I don't know why so many people can't think about OO implementations of SOAs...
Have fun,
Remi
