Distributed Objects

I have my doubts about the performance of 'distributed objects' in the real world.

What are your doubts? I confess I fail to understand how OO or the lack of it is relevant to the performance of distributed components. When you come down to it OO is simply good factoring - good for maintainability - and that has nothing to do one way or the other with performance. Or is there some kind of inobvious connection?

My experience has been that network traffic concerns impact negatively on the design of object collaborations when the objects are distributed. I think that there's a mis-match here like the mis-match between OO and RDBMS technologies. That doesn't mean that the technologies shouldn't be used together, however. What it means is that using the technologies together creates, rather than solves, engineering problems.

So, naively "distributing objects" probably won't ever result in a usable system. But, designing a system that uses both network capabilities and object oriented design techniques to their fullest advantage is still possible and desirable. -- PhilGoodwin

"There is no such thing as a good distributed object model"

TedNeward commented on DistributedObjects in mid05 and viewed that all DistributedObjects implementation, irrespective of platform (EjbObject, ComPlus, CorbaComponentModel, etc) sucks. His blog was on EjbPlatform? and located at http://www.neward.net/ted/weblog/index.jsp?date=20050727#1122529218328

Not every problem we face lends itself to an object-oriented solution

The main thing to realize about any distributed system is that you can't treat it as if it the network doesn't exist. One of the problems with systems like COM, RMI and CORBA is that they tend to try and hide the fact that you are actually talking across a network.

Anyone tried JavaSpaces ? Seems to me like it's a protocol that doesn't try to pretend that the network doesn't exist.

More preciese, it does pretend that network exists. Rather common for everything related to JiniTechnology.

-- GlenStampoultzis

It is one type of factoring, along with templates and good old functions. Most new C++ libs seem to be using templates. Why? Because OO failed? We'll see what Java looks like when it is mature. (See 'Deprecated') OO has its good and bad points, and many of its idioms do not work well over a network. The golden rule 'the implemented system models the real world' for instance. 'Small and lots' of method calls for another instance. I'm not saying OO is no good - but it isn't suitable for everything. (I made the original comment)

Why does the fact that 'most new C++ libs seem to be using templates' imply that 'OO failed'? As I understand it from my limited C++, C++ templates are a mechanism for parameterising types and are a pre-processing add-on to a class definition that aids compile time type checking and reduces the need for downcasts. Templates are surely therefore explicitly bound to classes through the class definition and hence reinforce OO concepts. Or not? --LanceWalton

I didn't say OO failed - I left a question mark to let the reader make their own mind up. IMHO it wasn't entirely successful, although some people still treat it as a silver bullet. To me, the mechanisms OO brought, are just extra tools in the box. I think that the strength of OO is in analysis, not necessarily implementation.

C++ templates are, in the opinion of some, a better mechanism for building class libraries than a typical OO approach (such as Java's class libs). To me templates are just another tool in the box, but I can see the trade-offs with OO reuse. Polymorphism is definitely problematic.

If you're a Java programmer then you don't get the option, although I do hear that they intend to extend the language further to allow some type of templates.

I saw the question mark and I guess what I was asking was how the conclusion 'because OO failed' could be drawn from 'most new C++ libs use templates' at all (by anybody) i.e. I can't see the connection - I'm absolutely not saying that this conclusion cannot be drawn from the premise but I'd like some help connecting the two (even if I disagree with it once it's been elucidated :-)

The PizzaLanguage is Java with parameterized types and whatever else they've added since I last looked. --LanceWalton

Polymorphism is definitely problematic.

What?! Polymorphism is the key. The more dynamic bindings you make versus static bindings, the simpler the program.

What's wrong with polymorphism?

-- SunirShah

I don't think OO/polymorphism is either evil or a silver bullet. OO hasn't failed completely - but it hasn't been entirely successful. I'll state again that I think there are inherently some big problems with the distributed objects idea (the vision of CORBA?) - I don't think it will work (See PhilGoodwin's comments above). At the very least there'll be a comprimise situation to get it working.

TimEwald has commented elsewhere (where was it?) that transposing analysis to implementation is different on a distributed system than a local system. Simply put the OO tricks you may use on your local PC for one user, will not perform over the (inter)network, with a large number of users.

A number of people have commented on the testing, and maintenance issues with polymorphic interfaces.

To go back to a point raised above about trying to hide the distribution, I fell into a similar hole myself some years ago. In my case I was trying to make objects persistent but hide this detail from the users. Thus when a client asks for a collection of objects, it doesn't know that they are being dragged off a disk somewhere. This worked to a degree but I soon came up with a scenario where performance was terrible because the client wasn't considering the performance aspects with persisting data. In other words you can't expect things like distribution and persistence to be completely transparent to the user. There has to be some consideration from the outset, during design. If this happens then there is no issue with DOs.

RussFreeman

Have you read AnoteOnDistributedComputing? This "hole" you mentioned already considered more than decade ago.