Best practice for modularization

[Sebastien Cesbron]

Hi

I am currently thinking on using play for all our apps.

Each application will handle its part of the db and its own ui (backoffice, frontoffice, ...) and will have access to a common part (user management tables).

The first problem to deal with is how to share code between apps. The first use case, for example, is having a common user database an model layer for everybody so we have a sort of sso in our apps and user don't have to create an account for each app.

I see several way to deal with this but don't know which one is the best and what are exactly the pros/cons of each solution.

I can define my common model layer as a module. Doing so, I may need to have some kind of master application that will take car of database evolutions for this module. I am wondering if such a choice works well during all the development process

• is it flexible enough on the developer machine so he is not slowed down by this ?
• Is it easy to put in the continuous integration process. How does the ci server works ? Do I have to tag and store my module in a local repository before I can build my apps ?
• Is it easy to put in production. Currently I checkout my taggued version from my vcs on my production machine. It is simple and very easy to do. Will it be the same with my module ?

Another possibility is to make two distinct applications and have service calls between both. It better decouple parts but will be more tedious for the developer

The third possibility can be to just have one big app and everything inside.

The fourth one can be to duplicate user management code on each application.

And maybe there is other possibilities I don't think about.

The main question I have is how to grow on complexity in my play apps without loosing the productivity / simplicity I have.

If somebody have already solve this in the past and give me feedback I would be nice.

Regards
Seb

[Sebastien Cesbron]

Hi

It seems that I am alone in the dark with my problem :-)

After investigating a bit more in the different directions, it seems that modules are thought for this use case so I will go this direction.

I just want to know if somebody I have some experience to share on how to handle multiple apps and modules development in an elegant way with continuous integration.

Does somebody know any pointers that I have missed on how to automate custom module publication. Is there any best practice for building an in house module repository ?

Regards
Seb

2011/9/7 Sebastien Cesbron <sces...@gmail.com>

[Fehmi Can SAĞLAM]

Hi,

I thought it might be useful for you and others in the list and decided
to write about our enterprise woa platform.

We(as 4Primes, a startup founded in Turkey) have been developing an
enterprise platform(KURAM) using Play Framework for some months. It is
pretty mature now and we currently use the platform for our enterprise
projects. I can say that KURAM really improves the developer
productivity and code reusability. We have never sold one, neither
thought of selling or releasing as open source. But if you are
interested in just mail me.

KURAM has the features below:

* A RESTFUL service provider(ODAK) including Identity&Role management
services, Document management services, Log management services and SSO
using CAS protocol(recoded using play).
* A module(SEYYAR) for dealing with authentication, authorization(some
parts based on deadbolt module) and service calls.
* A web app(IRMAN) for managing users and roles.
* A web app(LOGMAN) for viewing and filtering application logs. All
requests from applications using the module SEYYAR and service calls
from ODAK are logged automatically. Manual logging is also available.
(Asynchronus and stored in MongoDB)

By service requests you can create users, roles or documents directly
from your application. Documents and logs are stored in mongodb, and
are available for search using elasticsearch(content is extracted from
any document and indexed). Any other data are stored in RDBMS. KURAM is
designed for easy replication from the beginning and has a stateless
architecture.

We are now improving document repository capabilities such as
versioning and trying to integrate with BPMN tools.

This was a real spontaneous writing. If anyone is interested in I could
explain deeply.

On Wed Sep 7 15:23:48 2011, Sebastien Cesbron wrote:
> Hi
>
> I am currently thinking on using play for all our apps.
>
> Each application will handle its part of the db and its own ui
> (backoffice, frontoffice, ...) and will have access to a common part
> (user management tables).
>
> The first problem to deal with is how to share code between apps. The
> first use case, for example, is having a common user database an model
> layer for everybody so we have a sort of sso in our apps and user
> don't have to create an account for each app.
>
> I see several way to deal with this but don't know which one is the
> best and what are exactly the pros/cons of each solution.
>
> I can define my common model layer as a module. Doing so, I may need
> to have some kind of master application that will take car of database
> evolutions for this module. I am wondering if such a choice works well
> during all the development process
>

> * is it flexible enough on the developer machine so he is not slowed
> down by this ?
> * Is it easy to put in the continuous integration process. How does

> the ci server works ? Do I have to tag and store my module in a
> local repository before I can build my apps ?

> * Is it easy to put in production. Currently I checkout my taggued

> version from my vcs on my production machine. It is simple and
> very easy to do. Will it be the same with my module ?
>
> Another possibility is to make two distinct applications and have
> service calls between both. It better decouple parts but will be more
> tedious for the developer
>
> The third possibility can be to just have one big app and everything
> inside.
>
> The fourth one can be to duplicate user management code on each
> application.
>
> And maybe there is other possibilities I don't think about.
>
> The main question I have is how to grow on complexity in my play apps
> without loosing the productivity / simplicity I have.
>
> If somebody have already solve this in the past and give me feedback I
> would be nice.
>
> Regards
> Seb
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.

[Keith Swallow]

Hi Seb,

I didn't reply sooner because your design is very different from what I would do. Given the scenario you described I wouldn't look for a module at all. Obviously what has worked for me in the past may not work in your specific situation.

I tend to use SOA when I have four apps that are going to work in concert. Sharing one database between multiple apps has never led to anything good in my experience.

One technique that has worked well for me in the past is to have each of my service apps present a service layer (rest-xml or rest-json) that is consumed by my ui app. This way the services can all play nice with each other and only the UI app has to worry about visual representation of the data. This also allows for each app to have its own database and limits the touch points for people working with UI.

Regarding your specific concerns: 

I haven't found many instances where sharing code would be useful across apps given the above design

User management would be one app that supplies auth tokens to the client who then uses those auth tokens to check identity

Several small apps are pretty cheap to run on a dev box as far as resources go, especially Play apps since they can all use the same JVM and Play code

Each of the discrete apps mentioned above would have its own source repo and could be deployed independently of the other apps. This is particularly easy when you implement a robust rest interface where API versioning is not required because the service app knows how to handle the request based on the payload.

Cheers,

Keith

[Sebastien Cesbron]

Hi

Thanks for he answer Keith. After some hours of brainstorming yesterday, my conclusion was the same as yours. Using rest communication seems simple with play and then apps are loosely coupled and the process can be simpler.

The only point I have to investigate now is how I can do continuous integration on an app that depends on a rest layer. I've done some seach and it does not seem to be easy to mock this services. The other possibility is to automatically deploy my apps on an integration server as part of the continuous integration process. This seems the better choice for me, I will try to put it in place.

Regards
Seb

2011/9/8 Keith Swallow <keit...@gmail.com>