David, Feel free to use the text. Would appreciate it you share these thoughts
in the enRoute app notes. Some might be applicable for the DTO app note?
Kind regards,
Peter Kriens
> On 20 Feb 2017, at 10:51, David Leangen <o...@leangen.net> wrote:
>
>
> 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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
