Re: [osgi-dev] enRoute JPA example questions

[Raymond Auge via osgi-dev]

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 
>
>
> ‐‐‐ 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 
>>
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Friday, December 7, 2018 11:09 AM, Tim Ward 
>> 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
>>  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 : 

Re: [osgi-dev] enRoute JPA example questions

[Clément Delgrange via osgi-dev]

Thanks for the link!

--
Clément Delgrange 

‐‐‐ Original Message ‐‐‐
On Friday 7 December 2018 13:08, Christian Schneider  
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 
> :
>
>> 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 
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Friday, December 7, 2018 11:09 AM, Tim Ward  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.
>>>

Re: [osgi-dev] enRoute JPA example questions

[Christian Schneider via osgi-dev]

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 
>
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, December 7, 2018 11:09 AM, Tim Ward 
> 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
>  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 

Re: [osgi-dev] enRoute JPA example questions

[Clément Delgrange via osgi-dev]

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 

‐‐‐ Original Message ‐‐‐
On Friday, December 7, 2018 11:09 AM, Tim Ward  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 

Re: [osgi-dev] enRoute JPA example questions

[Tim Ward via osgi-dev]

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 
 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 
>  wrote:
> 
> Hi,
> 
> I have some questions regarding the OSGi enRoute microservice example and the 
> usage of DTOs. (enroute-tutorial-jpa 
> , 
> enroute-dto ).
> 
> 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 
> ’s, all we need do is 
> re-implement dao-impl...
> 
> 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.
> 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!).
> 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 

[osgi-dev] enRoute JPA example questions

[Clément Delgrange via osgi-dev]

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...

- 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.
- 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!).
- 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 ___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev