I'm an amateur java developer and I have been working on this web application in my current company. The application is made in the Spring MVC framework. Hibernate is used as the ORM tool while the database is the DB2. Maven is used as the build and deployment tool for this application. The presentation layer and the service layer are totally seperated from each other, I mean both the layers are in seperate web application containers. We use two different servers for this, an Apache Tomcat and a JBoss Application server. Apache Tomcat is used as the server that contains presentation layer and JSPs with all the CSS and javascript stuff. While the business logic and service classes are present in the JBoss Application server. Below is the diagram representing the architecture of the appplication.

Web Application Architecture

So the Idea here is that all the presentation logic of my application is present in the apache tomcat server while all the business logic is present in the JBoss server. In order to connect the presentation layer with the business logic we use the Spring HTTPInvoker. Spring HTTPInvoker is similar to Remote method Invocation but through HTTP Protocol. Data is passed between the two layers through form objects. The form classes are present in both the servers. Hibernate takes care of all the connections with the database.I asked my supervisor about the benefits of such architecture he said that the presentation logic is completely decoupled and even if the JBoss stack is down we can add another stack resume the oprations as soon as possible. I argued with him that the MVC Pattern already gives that amount of abstraction and decoupling. Just for the sake of scalability they are seperated the two layers in two different servers.

I wanted to know the advantages and disadvantages of the architecture in terms of performance,scalability and flexibility. I'm currently studying the enterprise application design patterns. Please tell me your opinions on the architecture and what needs to be fixed or improved.

2 Answers 2


I've never seen such an architecture and frankly speaking I can't see any substantial advantage.

1) If JBoss server is down - does this mean that you need to set up another instance. But if your application is entirely on one server - you need to set up another instance as well. No difference.

2) HTTP channel between servers - here we get an performance overhead and gain nothing except for problems related to developming and maintaining this stuff.

3) Separation of presentation and business logic - this kind of stuff sounds good in theory, but there may be exceptions in practice. The thing itself is good, it makes the code way more clean, but one doesn't have to go to extremities.

Thus, I see no benefit in this configuration at all. Maybe I miss something important, everything above is just my point of view.

  • I completely agree with your concerns. I also had raised a concern with my supervisor for the HTTP channel between servers being an overhead but my complaint fell on deaf ears. My supervisor told me that this architecture was conjured by the client's technical advisors and he could'nt argue with the client. Jul 29, 2016 at 14:50
  • @AdityaCherla: If you only have a year or so of experience, you probably shouldn't be worried about the architecture. Your supervisor should be giving you assignments that are very specifically scoped to one piece of the architecture. Jul 29, 2016 at 14:54
  • @AdityaCherla yes, that's quite common thing. Every so often the client has poor understanding of the technical side of the project, but pretends to know everything in depth. Then there are two options - to persuade the client that he wants something stupid / to agree but to implement the way you believe correct / to implement the way the client wants. There is nothing to do here. Anyway, from the developer point of view it may be very useful for you because you can better understand why this is a bad idea, and there are chances that the idea isn't actually that bad.
    – ekaerovets
    Jul 29, 2016 at 14:58
  • 1
    @RobertHarvey do you think there is a point at which a programmer should start to worry about architecture? I disagree, from my viewpoint a person that writes code should always keep architecture in mind. And always learn.
    – ekaerovets
    Jul 29, 2016 at 15:00
  • @Robert Harvey: I totally understand what your saying. But I have been in this project for two years and frankly speaking each change request causes a lot of code to be changed , that causes a lot of frustration for me and my colleagues. Jul 29, 2016 at 15:01

If you have multiple applications (or plan to have in near future), this architecture makes sense. You can reuse the business/service layer. I am assuming the service layer is coarse grained and not tied to UI layers so that every UI change does not require a change in the service. Often the problem is not with the architecture/design pattern. It's a poor implementation/abstraction/contract.

  • your right. People's intentions are good but the poor implementation screws up everything. Jun 11, 2017 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.