2

Our current Web Application Architecture consists of following :

Java 6, JBOss 5, MySQL 5.6

Presentation Layer (ZK Framework)

Delegate + Service + DAO Layers (Spring & Hibernate)

Packaging : Single War file containing all the above layers

Business Requirement :

Create mobile app for few modules of above mentioned web application, using HTML5 and Native iOS library.The mobile app would be able to perform CRUD, download/upload files and send emails.

Question :

We are in the process to determine the architecture for the above business requirement. Keeping in mind the following attributes

  • Data Logic sharing (Implemented in DAO layer using Hibernate)

  • Business Logic sharing (Implemented in Service layer using Spring)

  • QoS - Performance, Scalability

Some of our thoughts :

  1. Create a separate delegate layer within the web app and expose it as a REST API. The underlying, objects of service and DAO layer can be used as it is.

    • Will need to scale application, to handle the load of both web app and mobile app !

  2. Create a common project (Jar) for common functionalities, and share it with 2 different project, one for web app, and the other for mobile-app.

    • Will Hibernate will be OK , to share the same database with 2 applications, without any concurrency issues ?

I would really appreciate any advice/opinion about the above.

Thanks

BAhmed786
  • 51
  • 5

1 Answers1

0

In my opinion, you should сonsider using of the MQ systems (RabbitMQ e.g.) and split your app in 3 layers:

  1. Frontend - accepts client requests (one for browsers, second for mobile apps etc.) and transmit them to MQ.
  2. Intermediate (transport) - MQ system. Transports messages.
  3. Backend - accepts inbound messages from MQ, processes request and gives the answer back.

This is what you described in 2nd option. But i think it would be better to have intermediate layer (MQ) to avoid coupling.

I think Hibernate needs to be configured with distributed 2nd level cache (EhCache e.g.), to make backend scalable.
With this architecture you can simple scale throughput of your app by adding backend server and subscribing it on queue in MQ.

retroq
  • 572
  • 2
  • 7
  • Thanks very much for the response, fundamentally I understand that de-coupling between presentation layer and service layer is required to serve the business/service layer to different fron-ends. However I did some read-up about MQ, and usage of it, and found this good article, which explains MQ vs REST. Based on this information I tend to think that in our scenario, it would be appropriate to implement the middle layer as REST API. http://stackoverflow.com/questions/19246704/restful-v-s-mq-differences-and-other-key-features-apart-from-guaranteed-deliver – BAhmed786 Dec 03 '14 at 18:04
  • @BAhmed786 The choice is yours. Thanks for useful link. – retroq Dec 03 '14 at 18:51