Even better, a link to the html spec javadoc: https://osgi.org/specification/osgi.enterprise/7.0.0/service.component.html#org.osgi.service.component.runtime.ServiceComponentRuntime
- Ray On Fri, Dec 7, 2018, 10:36 Clément Delgrange via osgi-dev < osgi-dev@mail.osgi.org wrote: > Thanks for the link! > > -- > Clément Delgrange <cl.delgra...@protonmail.com> > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday 7 December 2018 13:08, Christian Schneider < > ch...@die-schneider.net> wrote: > > A good example for the usage of DTOs is: > > > http://javadox.com/org.osgi/osgi.cmpn/6.0.0/org/osgi/service/component/runtime/ServiceComponentRuntime.html > > Christian > > Am Fr., 7. Dez. 2018 um 12:07 Uhr schrieb Clément Delgrange via osgi-dev < > osgi-dev@mail.osgi.org>: > >> Hi, thanks for your response. >> >> As I mention above, it would be very bad for the DAO to use entity types >> in its API as this would force the implementation decision... >> >> >> I agree, I would not replace API parameters with entity types I meant >> replacing entity types with DTOs and API parameters with plain Interface or >> Classes. >> >> The REST API is actually not coupled to the DTO representation... >> >> >> Yes indeed. >> >> It’s quite the opposite - the DTOs are the public inter-bundle >> communication data. They are used this way in a lot of OSGi specifications. >> >> >> I looked at the R7 osgi.cmpn in the org.osgi.service.* packages but I >> did not see services using DTOs in that way, maybe have you a link? Or >> better a realistic project that use DTOs for service parameters and return >> type?. >> >> Your response clarify a the way enRoute proposes to use DTOs but it is >> still hard to now when to use them. For example, if the microservice >> example change: now the REST service does not call the DAO layer directly >> but a PersonManager service that will send events, call other services, ... >> and finally call the DAO layer. The PersonManager service has almost the >> same methods than the PersonDao service, do you use DTOs for the >> PersonManager service? In this way DTOs seem less flexible than interfaces >> for parameters/return types, if later we want to add a `getFullName` or a >> method to filter Addresses? As mentioned in the tutorial, DTOs are not >> immutable or thread safe, does that mean each time you call a service you >> copy them? >> >> Clément. >> -- >> Clément Delgrange <cl.delgra...@protonmail.com> >> >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Friday, December 7, 2018 11:09 AM, Tim Ward <tim.w...@paremus.com> >> wrote: >> >> Hi Clément, >> >> >> - The de-coupling is not the fact that they are DTOs? If the API had >> defined Interfaces or Classes the de-coupling would be the same. >> >> In this case the decoupling is from the data model. If the DTO types were >> JPA entities (i.e. they had JPA annotations on them) then everyone would be >> coupled to the JPA data model, and in turn, the database. You are correct >> that the types don’t need to be DTOs for this to be the case, however DTOs >> are a good choice because they force you to treat the exchanged objects as >> pure data, rather than an implementation specific behaviour or mapping. >> Perhaps a slightly better wording would be "*Because of the de-coupling >> provided by the **DTO >> <https://enroute.osgi.org/FAQ/420-dtos.html> package**, all we need do >> is re-implement **dao-impl…”* >> >> >> - I understand the usage of DTOs for the REST service (as data are >> leaving/coming) but not for the *DAO services API. The actual data leaving >> the system are the *Entity classes in the implementation bundle (so the >> transferable objects are converted into other transferable objects!). >> >> >> As I mention above, it would be very bad for the DAO to use entity types >> in its API as this would force the implementation decision. The >> implementing bundle should be free to use JDBC, JPA, NoSQL or whatever it >> wants to store and retrieve values. The moment that you start talking about >> Entity Classes you’re already most of the way to an ORM implementation, >> which is one heck of an implementation internals leak. >> >> >> - Also the fact that the DTOs are exported and used in the service >> contract in the API bundle, the REST-API (and so the clients) is coupled >> to >> the internal representation of the Java application. >> >> The REST API is actually not coupled to the DTO representation - the REST >> service implementation could do whatever transformation it chose >> internally. For simplicity we have chosen to keep the REST responses close >> to the DTOs, but we could have quite easily changed all of the field names >> in the JSON. Again, the OSGi implementations communicate using an API, but >> they can convert between internal and external representations as needed. >> In this case the external “REST” representation doesn’t require a >> transformation, but it could easily be transformed to if required. >> >> I thought the DTOs was more data-api specific to a provider bundle, such >> as : some-framework-rest-provider (with private DTOs) --adapt--> Java >> application (with domain interface/class) --adapt--> jpa-dao-provider (with >> private DTOs) . >> >> It’s quite the opposite - the DTOs are the public inter-bundle >> communication data. They are used this way in a lot of OSGi specifications. >> >> If in contrary the purpose of the DTOs is to have one consistent data >> representation which evolves as soon as it is required by one of the system >> (rest, java application, database-schema), how to deal with framework >> specific annotations? >> >> Objects annotated with framework specific annotations belong on the >> *inside* of the bundle using the framework - the OSGi enRoute micro service >> example is a great place to look. The JPA entities are internal to the JPA >> implementation of the Data Access Service, as it is the only user bundle >> that knows that JPA is being used. >> >> Best Regards, >> >> Tim >> >> On 6 Dec 2018, at 19:30, Clément Delgrange via osgi-dev < >> osgi-dev@mail.osgi.org> wrote: >> >> Hi, >> >> I have some questions regarding the OSGi enRoute microservice example and >> the usage of DTOs. (enroute-tutorial-jpa >> <https://enroute.osgi.org/tutorial/032-tutorial_microservice-jpa.html>, >> enroute-dto <https://enroute.osgi.org/FAQ/420-dtos.html>). >> >> I think I understand the purpose of DTOs (easy to write, easy to process, >> useful when data leave the system) but their usage in the JPA example is >> not clear: >> >> *Because of the de-coupling provided by the **DTOs* >> <https://enroute.osgi.org/FAQ/420-dtos.html>*’s, all we need do is >> re-implement **dao-impl...* >> >> >> >> 1. The de-coupling is not the fact that they are DTOs? If the API had >> defined Interfaces or Classes the de-coupling would be the same. >> 2. I understand the usage of DTOs for the REST service (as data are >> leaving/coming) but not for the *DAO services API. The actual data leaving >> the system are the *Entity classes in the implementation bundle (so the >> transferable objects are converted into other transferable objects!). >> 3. Also the fact that the DTOs are exported and used in the service >> contract in the API bundle, the REST-API (and so the clients) is coupled >> to >> the internal representation of the Java application. >> >> I thought the DTOs was more data-api specific to a provider bundle, such >> as : some-framework-rest-provider (with private DTOs) --adapt--> Java >> application (with domain interface/class) --adapt--> jpa-dao-provider (with >> private DTOs) . >> >> If in contrary the purpose of the DTOs is to have one consistent data >> representation which evolves as soon as it is required by one of the system >> (rest, java application, database-schema), how to deal with framework >> specific annotations? >> >> I hope I was clear enough! >> Thanks. >> -- >> Clément Delgrange <cl.delgra...@protonmail.com> >> >> >> _______________________________________________ >> 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 >> > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com > > _______________________________________________ > 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
