Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Remote Application Platform (RAP) » Suggestions for a good "single sourced" RAP application(Which is the best approach to integrate RAP with a JEE backend when "single sourcing" is considered?)
Suggestions for a good "single sourced" RAP application [message #552728] Fri, 13 August 2010 09:38 Go to next message
Patrick is currently offline PatrickFriend
Messages: 17
Registered: August 2010
Location: Rome
Junior Member
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 10:56 Go to previous messageGo to next message
Martijn Cremer is currently offline Martijn CremerFriend
Messages: 77
Registered: January 2010
Location: Breda
Member

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.


hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
Re: Suggestions for a good "single sourced" RAP application [message #552780 is a reply to message #552728] Fri, 13 August 2010 13:33 Go to previous messageGo to next message
Patrick is currently offline PatrickFriend
Messages: 17
Registered: August 2010
Location: Rome
Junior Member
Hi Martijn, thanks a lot for the suggestion about workspace organization!

What I would better understand is which is the best way to connect a RAP application to a JEE backend. Does it make sense to create a "decoupling" bundle responsible to perform JNDI lookups and provide a UI-oriented service (a kind of business delegate) that the UI controller can use in order to fulfill user interaction scenarios?

Should the access be remote using IIOP protocol, or it is better to use some other lightweight protocol (e.g. Hessian) ?

If I introduce a "business delegate bundle", where should I obtain references to remote services? could I do this at startup and cache the reference to the backend service somewhere, in order to reduce the lookup overhead ?

Thanks again for any suggestion

Best Regards,
Patrick
Re: Suggestions for a good "single sourced" RAP application [message #552906 is a reply to message #552728] Sat, 14 August 2010 10:10 Go to previous messageGo to next message
Ivan Furnadjiev is currently offline Ivan FurnadjievFriend
Messages: 2426
Registered: July 2009
Location: Sofia, Bulgaria
Senior Member
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
Re: Suggestions for a good "single sourced" RAP application [message #553043 is a reply to message #552780] Mon, 16 August 2010 08:18 Go to previous message
Martijn Cremer is currently offline Martijn CremerFriend
Messages: 77
Registered: January 2010
Location: Breda
Member

I am all for decoupling bundles. The OSGi Standard even preference making bundles so untied that they don't know what the outside world does. I don't know much about the technologies you are using I think its best to indeed use a decoupled system.

hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
Previous Topic:RAP E4 target platform
Next Topic:Workbench UI from 3.5
Goto Forum:
  


Current Time: Tue Apr 23 00:42:38 GMT 2024

Powered by FUDForum. Page generated in 0.03381 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top