| Suggestions for a good "single sourced" RAP application [message #552728] |
Fri, 13 August 2010 05:38  |
Eclipse User |
|
|
|
Hi All,
i'm investigating the "single sourcing" techniques to implement both a RCP and RAP frontend to a JEE business application and I would like to have your opinion about the best strategies/patterns to follow.
I thought it is a good thing to encapsulate the access to the business layer in a separate bundles, so I created a core bundle with the interfaces of all the services required to support the UI scenarios and I plugged the implementation, defined in a core.ejb bundle, using DS; in this way I can switch from EJB access to a WS or Dummy (to scaffold the BL for testing purposes) access simply stopping a bundle and starting another. Is this a good approach?
From the RAP/FAQ I learned that it is a good approach to always access business services through remote interfaces (e.g. because the UI may be deployed on another application server); is this right and only way to go ?
My last question is about architecture. My BL is implemented by several EJB3 stateless session beans that manipulate data using fine grained JPA entities; I thisnk that it is preferable to introduce coarse grained DTO to external systems like rich clients, do you agree that this also true for a RAP application that may be eventually be served as an RCP client (single sourcing) ?
If this is the case, I think that it could also be valuable to introduce some Service Facade (e.g. one for each user story) that manages coarse grained DTO and leverages several BL services to perform the work; in this way the BL services could use objects from the domain model (some of which are JPA beans) while the Facade could be responsible to map DTP to the appropriate domain model object(s), as well as manage the Tx boundaries of the application (from the user interface point of view). Do you agree with this approach or there is some other better way to organize things?
Sorry for so many questions, but I really would like to adopt a good approach since the beginning and I consider invaluable the suggestions a more experienced community is compared to any technology book or google search
Thanks a lot for any suggestion
Best Regards,
Patrick
|
|
|
| Re: Suggestions for a good "single sourced" RAP application [message #552741 is a reply to message #552728] |
Fri, 13 August 2010 06:56  |
| Eclipse User |
|
|
|
| Patrick wrote on Fri, 13 August 2010 11:38 | Hi All,
i'm investigating the "single sourcing" techniques to implement both a RCP and RAP frontend to a JEE business application and I would like to have your opinion about the best strategies/patterns to follow.
I thought it is a good thing to encapsulate the access to the business layer in a separate bundles, so I created a core bundle with the interfaces of all the services required to support the UI scenarios and I plugged the implementation, defined in a core.ejb bundle, using DS; in this way I can switch from EJB access to a WS or Dummy (to scaffold the BL for testing purposes) access simply stopping a bundle and starting another. Is this a good approach?
From the RAP/FAQ I learned that it is a good approach to always access business services through remote interfaces (e.g. because the UI may be deployed on another application server); is this right and only way to go ?
My last question is about architecture. My BL is implemented by several EJB3 stateless session beans that manipulate data using fine grained JPA entities; I thisnk that it is preferable to introduce coarse grained DTO to external systems like rich clients, do you agree that this also true for a RAP application that may be eventually be served as an RCP client (single sourcing) ?
If this is the case, I think that it could also be valuable to introduce some Service Facade (e.g. one for each user story) that manages coarse grained DTO and leverages several BL services to perform the work; in this way the BL services could use objects from the domain model (some of which are JPA beans) while the Facade could be responsible to map DTP to the appropriate domain model object(s), as well as manage the Tx boundaries of the application (from the user interface point of view). Do you agree with this approach or there is some other better way to organize things?
Sorry for so many questions, but I really would like to adopt a good approach since the beginning and I consider invaluable the suggestions a more experienced community is compared to any technology book or google search
Thanks a lot for any suggestion
Best Regards,
Patrick
|
Hey Patrick,
Great to see more people willing to implement single sourcing. The way to single source is how you feel think about it. How I go about is is when I am not using SVN is create the following file structure:
\Projectnamefolder\common
\Projectnamefolder\RAP
\Projectnamefolder\RAP\Workbench
\Projectnamefolder\RAP\Target
\Projectnamefolder\RAP\Source
\Projectnamefolder\RCP\Workbench
\Projectnamefolder\RCP\Source
You may or may not want to keep the source out of the workbench. But the general idea is in the common folder you put all bundles that work in all environments. And in the other you put fragments or rcp/rap specific implementations.
A tip I give you is to install the target separate. You do get the option to install in your eclips folder but if your like me and always checking out the new versions of rap and the Alfa's betas etc... it isn't smart to constantly reinstall it. So just keep per project your own target.
|
|
|
|
| Re: Suggestions for a good "single sourced" RAP application [message #552906 is a reply to message #552728] |
Sat, 14 August 2010 06:10 |
| Eclipse User |
|
|
|
Hi Patrick,
See this url for the Single Sourcing Guide:
http://eclipsesource.com/en/eclipse/eclipse-rap-overview/#c7 49
HTH,
Ivan
On 08/13/2010 12:38 PM, hurricane wrote:
> Hi All,
>
> i'm investigating the "single sourcing" techniques to implement both a
> RCP and RAP frontend to a JEE business application and I would like to
> have your opinion about the best strategies/patterns to follow.
>
> I thought it is a good thing to encapsulate the access to the business
> layer in a separate bundles, so I created a core bundle with the
> interfaces of all the services required to support the UI scenarios
> and I plugged the implementation, defined in a core.ejb bundle, using
> DS; in this way I can switch from EJB access to a WS or Dummy (to
> scaffold the BL for testing purposes) access simply stopping a bundle
> and starting another. Is this a good approach?
>
> From the RAP/FAQ I learned that it is a good approach to always access
> business services through remote interfaces (e.g. because the UI may
> be deployed on another application server); is this right and only way
> to go ?
>
> My last question is about architecture. My BL is implemented by
> several EJB3 stateless session beans that manipulate data using fine
> grained JPA entities; I thisnk that it is preferable to introduce
> coarse grained DTO to external systems like rich clients, do you agree
> that this also true for a RAP application that may be eventually be
> served as an RCP client (single sourcing) ?
> If this is the case, I think that it could also be valuable to
> introduce some Service Facade (e.g. one for each user story) that
> manages coarse grained DTO and leverages several BL services to
> perform the work; in this way the BL services could use objects from
> the domain model (some of which are JPA beans) while the Facade could
> be responsible to map DTP to the appropriate domain model object(s),
> as well as manage the Tx boundaries of the application (from the user
> interface point of view). Do you agree with this approach or there is
> some other better way to organize things?
>
> Sorry for so many questions, but I really would like to adopt a good
> approach since the beginning and I consider invaluable the suggestions
> a more experienced community is compared to any technology book or
> google search
>
> Thanks a lot for any suggestion
>
> Best Regards,
> Patrick
|
|
|
|
Powered by
FUDForum. Page generated in 0.03320 seconds
Home