Multiple UI's

[rhart]

I think that the software architecture Roo generates is great! I have a scenraio though where I need 2 different web UI's backed by the same domain and deployed on different boxes. How can I best utilize Roo's archticture to deal with this? Traditionally we have used a service layer and then wrapped it with a web service for the remoting but this doesnt seem to fit with Roo's rich domain object approach. What would Roo do?

[Stefan Schmidt]

@rhart,

Roo does currently support remoting via JMS. So one option is to create a complete application (including front-end) for the first box and then create a JMS listener to listen for object requests from your second application.

The relevant commands for JMS are as follows:

install jms -provider ACTIVEMQ_IN_MEMORY
new java jms listener -class com.foo.MyListener
add field jms template -class com.foo.MyService

I have written a blog article a while back which shows JMS usage with Roo:
http://stsmedia.net/introducing-spri...email-support/

Hope this gets you started.

-Stefan

[Rod Johnson]

Note that you can also easily create a service layer in a Roo app. Roo turns on annotation scanning by default, so you can just write @Service classes (preferably behind interfaces) and access entities and the static finders on them.

So if you NEED a service layer, you can add one. Roo just doesn't generate one by default because it may not be necessary. But it doesn't do anything to preclude one.

[rhart]

Thank you both for your speedy replies. It never ceases to amaze me how quick these forums are!

So is the consensus that a service layer of sorts is required in this scenario? I'm more interested in how you would design Roo to generate an architecture to deal with this local and remote access rather than how you would currently use Roo to achieve what I've done previously.

One thing that I REALLY like about Roo though is the fact that it doesn’t preclude you from doing anything, it just tries to help you as much as possible. Good work SpringSource!

[Stefan Schmidt]

The point is that it is your architectural decision to have a service layer or not. As stated before, Roo makes it very easy for you to create one.

In your case this layer would act more as a facade for integration with remoting services and that is something you can best implement yourself since you know the purpose and architecture of your application better than Roo would.

As you stated before Roo does support you as much as possible to implement this (it enables component scanning, allows JMS integration, generation of new java types, etc) but the actual design of the service layer interface should be done by you as you know best what should be exposed via remoting and what should not .

Regards,
Stefan

[rhart]

The point is that it is your architectural decision to have a service layer or not. As stated before, Roo makes it very easy for you to create one.

Hi Stefan,

You're right in saying it's my decision and I'm just making sure I make the right one. It seemed natural to pose the question here as the architecture Roo generates is Spring best practice and I wanted to find out how best to architect this scenario using Spring whilst remaining as productive as possible utilizing Roo.

As far as I can tell though, if I want to use my generated persistent classes between both UI's then I would need to put my domain objects into a seperate jar and deploy them to both boxes. If I go down the service layer route then I can remote from the 2nd box but loose the ability to for example do address.persist(); I'd have to do addressService.persist(address); and therefore loose the richness from my domain objects and have to remove the @RooEntity annotation from all my domain objects. Am I right or missing an obvious trick here?

Thanks for your pointer so far.