Am new to programming. I have created a Spring MVC web application.
It has JSPs for the frontend, Spring MVC as the middleware component and for data part a request is made to webservice to fetch the data. The middleware component does not have too much business logic since the application itself and exists just for fetching data.
My friend says that my application is missing the application tier. Is this correct?
Currently I deploy my application in Tomcat and DB is Teradata.
Am not using any app server(only web server).
So does this mean my application is missing the app tier? Please elaborate.
If your friend is thinking of a 3-tier application, then yours doesn't have the Web Tier, or in fact, you have combined the Web and App tiers.
It depends on the logic implemented in your controllers. Usually JSPs an controllers are part of the view layer, business logic is in business layer an persistance layer is basically a database. This is called three tier application.
The logic in controllers should only care about how the data are presented to the user and should't do any operation on the data itself. Then you would have clean view layer.
There is no problem in having all business logic on the side of the webservice. Actually I would say this is quite common.
Related
I have a spring boot application with 3 tier architecture client->Application server(Spring boot application)->DB.
I want to split the current app server into two, one for handling the client request/response and business logic like controllers and services only.
Another one is for only communicating with DB like DAO,and spring data jpa's only.
These two servers will communicate through REST api.
I don't know this approach is good or not. Please suggest.
Looking at the sample Spring Web MVC application PetClinic https://github.com/spring-projects/spring-petclinic as an example.
Application typically broken up into 3 different physical tiers and within the server side it is broken into different layers:
Client side: (JavaScript/CSS etc...)
Server side:
- Web
- Service
- Repository
Database:
Using above application as an example what constitutes front-end and back-end?
I always believe everything within the server side (web controllers/service/repositories) + database makes up the backend. But one of my colleague argue that only the database is what 'back-end' is.
Another of my colleague says only the 'Service & Repository' layers constitutes backend and he argue that stuff inside the web layer (consisting of JSP/Thymeleaf templates, form-backing objects, Controllers) is considered 'front-end'
In a SpringMVC app the front-end is the views. jsp files in the petclinic app are used to generate html files that are served from the server to the client. These files allow the user to view the model's data.
In a web application the backend is certainly not just the database. The controllers are also part of the backend. In a SpringMVC app these are classes annotated with #Controller.
Regarding files the petclinic app you may consider everything in src/main/webapp as the front-end and everything else the backend. Other people may disagree.
Mind you that a server app built with SpringMVC may be also used to expose a REST api receiving and transmitting JSON documents to a mobile app for instance. This app may implement the MVC pattern itself with its own frontend and backend.
In simple words
I would say whatever you want display to user irrespective of technology will go in View (Like HTML forms or any informative HTML page).
Regarding backend i would say you want some data to display on Frontend (View in SpringMVC) so you will do any preprocessing which includes getting data from another systems through web services and all , it will go in the backend part.In the same case if you are getting data from DB you can say its backend as well.
I'd like to create a decoupled frontend (vaadin) and backend (spring). Both should run on the same tomcat application server, but each is a single war so I can redeploy the frontend without having to restart the backend.
I want to minimize the remoting code between both applications to exchange data. Therefore I thought I could maybe inject the service beans from backend into the frontend war. But it that possible? How would I share the service declaration between both war files / java projects?
And what type of remoting would be apropriate here? Ideally I could imagine to have a mechanism where I could just "use" the backend service classes also in frontend, and spring clues the proxies together. But how?
You want to decouple the backend and the frontend, nice till there. You want to put them in separate wars on same tomcat, still possible but it has implications.
But now you want to inject beans from backend into frontend. If they are in separate wars it is no longer possible. Even on same same tomcat, each war if fully independant of the other and they should only communicate through the network (normally through web services).
You have two decoupling levels available :
one single war for both. The frontend would here consist on the view and controller layers, the backend of service and persistence layer. The coupling is provided by the service interfaces that you inject in your controllers. This is a single web application
each in its own war as 2 separate web applications. The frontend will have same view and controller layers than in previous case, and a thin service layer that would send REST requests to the backend. And the backend will have same service and persistence layer that in previous case, no view layer and REST controllers to process requests from the frontend.
For low to medium load, first solution will use a little less ressources, but under really huge load, the second one would be more scalable with farms of servers for frontend and backend (not speaking of reverse proxies before frontend and database servers behind backend)
If I understood your question correct, you want to separate your front end code from your back end.
What you could do, is create a .jar file of your back end implementation and in your front end instantiate the beans from an XML or Java application context.
If you don't want to redeploy your app for each change in the configuration I would prefer to use XML configuration.
In your front end code you have to include your back end jar and you can call these services in the regular Spring way.
yes you can load an external spring-context.xml from a jar / war in order to get the beans, check this answer here
You can bind your spring beans to JNDI and receive this objects in your frontend.
http://docs.spring.io/autorepo/docs/spring/3.2.3.RELEASE/javadoc-api/org/springframework/jndi/JndiTemplate.html#bind%28java.lang.String,%20java.lang.Object%29
But in this solution the decoupling of both wars is not really succeeded. I didn't see any benefit to separate frontend and backend in two war files when this must be deployed in the same container.
I would prefer to deploy one war file or communicate with REST between frontend and backend.
I would like to ask what would be the best wa to modify a Spring MVC to be accessed via remoting from Eclipse RCP application? What approach would you choose and why?
And is there any tutorial regarding Eclipse RCP remoting on the web?
Any advices and recommendations are appreciated.
My approach would be to have the Spring MVC app split in layers:
the presentation layer is where Spring MVC is used. It contains the presentation logic and calls the service layer
the service layer is where the business logic is. It calls the data access layer
the data access layer is where the persistence logic is.
I would thus have to make some or all of the services of the service layer remotely accessible (using Spring HttpInvoker, web services or whatever), and potentially add some more dedicated to the specifics of the RCP app.
We are working on a SOA Project consisting of multiple web services.
Each web service is based on Metro JAX-WS Framework and internally uses spring and hibernate.Each web service loads as a web-application inside a separate spring container.
This means that our deployment architecture consists of multiple web-applications each running a different service.
However we are facing some performance issues because each web-application loads its own spring container/hibernate session factory.
Possible alternatives:
Single web-application single spring context
Multiple web-applications single spring context
All our web services will always run together on a single server. What will be the best architecture for our case? And how to achieve the same i.e. how to use a single spring context with multiple web services?
The "best" in "the best architecture" is quite subjective, as it depends on your current architecture, which you haven't defined very well.
However, I have some suggestions:
Consider the impact on maintenance that consolidating all the business logic related to your services in a single web app will have, not to mention all the spring-configured-beans that you will have to inter-mangle to re-factor all you services. In that sense, keeping separate web apps tends to be better according to my experience.
Consider to move the hibernate session factory away from each service and to a centralized location, for instance, in JBoss, you could create some type of "hibernate interface" in the way of a .HAR file, each service will only have to "ask" for a hibernate session. Maybe you could do something like that in your particular application server. There are several patterns to efficiently retrieve a Hibernate Session that apply here.
Most web services performance issues are also associated with the way they are used, sync or async. We solved one such issue at my company by implementing a messaging systems under the covers to handle the web service requests asynchronously, whenever a request comes in you place them in a Queue, there are other services waiting for certain types of requests to process them. This can be easily implemented with Spring and ActiveMQ.
That's enough for the moment.
Regards.