Hi! Peter just wrote a very interesting note in a separate thread:
> After working in this area for too many years I’ve come to the conclusion > that objects cannot be really transferred to other systems in a reliable way, > only self typed data can. JPA, RMI, and many other systems promise heaven to > the programmer that they can use their objects local and remote > transparently. The consequence of this dream is a huge amount of complexity > that far outweighs any gains in programmer friendliness. Few things have > caused so much trauma in the software world as ORM. (Persistence is > communications to a future process.) > > The reason objects are so complex to use in communications is that it is in > direct violation of the goal of OO to hide your data. However, once you > expose the internal data on the wire you have effectively made it public but > too many people they can still have the advantages of abstract data types. > OSGi is a bitch in this case because it tells you that you’re trying to do > something wrong by refusing to cooperate. In this case, it balks at you > because you create an invisible dependency between the sender and the > receiver. Though this is a good thing too often the receivers of this message > blame the messenger. > > You can handle this dependency but you’ll find out is that it is a hugely > complex task that introduces a lot of frailty in the overall system. Having > tried this several times I can assure you that any gains in programmer > friendliness are dwarfed by the complexity of creating this facade. > > The best solution I found is to give up on data hiding. The fact your objects > is on the wire means that that wire format is public. I therefore use Data > Transfer Objects, in my case objects with public fields. On both sides I have > my own objects to provide behavior to this data with methods and classes but > this data record is at the core of my code. Since this data is public because > it goes over the wire it is better to wrap you code around that ‘standardized > public’ object than to try you internal object data. > > If you look at the OSGi specifications of the past 5 year then you will > notice that all applicable APIs have been designed to be useful with > Distributed OSGi. Calls do not pass objects but they pass DTOs back and > forth. They do not rely that the receiver and sender have exactly the same > type and version. In this model it is easy to replace an endpoint using > another language, which is a really good sign. > > For Java developers this is often an unpleasant message, and quite often OSGi > get the blame. However, the fact OSGi gives you these problems means that > you’re trying to do something that has hidden dependencies. > > Distributed computing has 7 well known fallacies[1] but I strongly believe > that there is an eighth: ’One can communicate objects over a network’. > > Now your question. Yes, you could run a resolve and load the proper bundles > but you introduce a huge amount of error cases and a large amount of > complexity and you won’t solve the fundamental problem. > > Kind regards, > > Peter Kriens > > [1]: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing > <https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing> > Peter, may I copy and reuse some of this text? I have already bought into the concepts you mention here, and am trying to apply it to my systems. I am calling it “DTO-as-Schema”. Currently, I don’t have much reference documentation or code, but I am (very slowly) working on that. Here are two sources: * https://github.com/apache/felix/tree/trunk/converter/schematizer <https://github.com/apache/felix/tree/trunk/converter/schematizer> (Describes the high level principle) * https://groups.google.com/forum/#!msg/bndtools-users/BEXkeWpvMPY/Ywvpi2niEwAJ <https://groups.google.com/forum/#!msg/bndtools-users/BEXkeWpvMPY/Ywvpi2niEwAJ> (Earlier post that describes some more technical details) Other than your permission to copy/paste, of course comments are always welcome. Would be happy to convert your comments + the above to an AppNote. Cheers, =David
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
