I want to develop an enterprise level application using spring MVC in presentation layer and spring in Business Logic Layer and hibernate in data access layer.
But i want to keep the presentation layer in a web server, multiple business logic layer in multiple server and data access layer in another physical server that means i want to establish a n tier solution using spring mvc.
I am able to separate the layer in my architecture. But the problem is my solution is just work on a single server. I cant do a architecture for multiple physical server.
Suppose that, from controller i use #Autowired annotation to inject the object of business logic layer. But how can i establish a system where controller talks to business logic layer over the network and business logic layer talks to data access layer over network as well.
If anyone can describe the solution in details then it would be very helpful for me.
Thanks...
You should be able to divide your code quite easily. Let's call your data access layer a "Data Provider" service and business logic layer "Business Service".
Now, you have to decide what kind of network protocol are you going to use.
These days REST is the most popular one and also it is very easy to setup your REST endpoints with Spring MVC (use #RestController on the server and RestTemplate on the client). You can also use RMI if you want to really couple your services (Data Provider and Business Service) using the same Java code (interfaces, DTOs etc.)
Related
I have developed a web application with Java EE, which connects to a DB. The app is deployed on Tomcat 8. The app is divided in three layers: db layer, business layer, and presentation layer.
Now I need to develop a RESTful API that will use the business layer and will provide most of the functions that the presentation layer provides. Clients will have two options to choose from: open a browser, connect to the APP and use it or consume the RESTful web services from their own software.
My question is: should I deploy the RESTful API on the same server where the APP is deployed or separately? What are your suggestions?
And, what kind of authentication would you suggest for the REST web services?
Thanks!
It is a rather broad question and the short answer is it depends.
Functionnally, you have three parts here:
the presentation layer
the API interface
the back office: business and db layers behind the 2 first ones
Common technical architectures are:
one app for the API and business and db layers, one app for the web layer using the API
everything (API, Web and business) on the same application.
The former offer a better separation and can be interesting for heavy loaded applications, or if you plan to move to a javascript interface (AngularJS ofr example), the latter will be simpler to implement.
For the authentication, it is simpler to pass the credentials along with each request for an API, but you should considere managing it outside the application itself through filters and/or AOP concepts. Spring Security is an example of how this is possible and gives a very loose coupling between the business code and the authentication and authorization ones. You can then choose and change your authentication methods with little impact on the core of the application.
There are a lot of best practices about writing RESTful API Services, but it hard to find any useful information about writing scalable, easy to maintain and well structured RESTful API Services client.
Short description on architecture that I use:
I have a web application written using Java language and Spring MVC on the back-end and HTML+CSS+JavaScript+AJAX on the front-end.
I divided my back-end part of the Client into 3 parts:
Data access objects level (here requests to the API are encapsulated, so I can easily change implementation of it, e.g. move from URLConnection to Spring RestTemplate);
Aggregation level (here data from different API methods is aggregated);
Controller level (for communication with front-end).
Questions:
As for me, it is very flexible architecture. However, many of my friends says that DAO level can be used only for communication with databases.
Should I rename my DAO classes. E.g. from "CarDAO" to "CarRepository", etc?
Is it good architecture of RESTful API Client?
What can be improved? Can the same flexibility be reached with the less number of levels?
You can improve dao layer.
1) Create a dao service and dao objects seperately.
Service gets info from the dao layer where the dao implementation can be changed to another, along with replace dao layer with dummy data layer for test data. Use JPA annotation here.
2) Maintain marshalling and unmarshalling of request response layer seperately from the controller.
3) Maintain modularity so that it should be like a plugin play architecture.
4) I suggest you to use JAX-RS annotations so that rest service implementations both server and client can be a simple one min job and we can use existing frameworks to make it very simple.
Is there a possible architecture that a developer can think of when it comes to extending a web application by introducing Web Services to the existing architecture or vice-verse. The main concern in this context is the data integrity and security.
The following images will suggest two approaches that a developer can think of.
This architecture indicates that all the request should be handled by an individual service layer. Therefore, only the service layer can communicate with the Data Base and satisfy request for both the web application and the gate way.
The second approach shows the web application is directly communicating with DB. For an example an Admin Portal. Meantime there can be an external web services also communicating with the DB. This approach may lead to Data Integrity Violating scenarios. However, introducing external web services might be easier than refactoring an existing Web Application to call a web service from developer end. Hence, can we still compromise for the long term consequences by having external web service and a separate web application instead of both the Web Application and the Gateway being catered with a single web service layer. Any reasonable comment on this would be appreciated.
You could build an API that has access to everything. In other word, the web application could work trough a rest/rpc api using Ajax/WebSockets.
Since everything goes through the API, data integrity shouldn't be enforced at any time. Also, you'll get a clear separation from Client, Api and Database.
This will allow you to replace the database by anything else without breaking other parts of your system.
I would personally advise to have at least a shared data access layer which handle data validation and persistence.
The best way would be however as defined in your first diagram with a shared service layer to factorize transaction management which should be defined at this level. You could so take advantage of custom transaction isolation and / or locking policy in order to ensure Data integrity. Public service layer methods could be in this case directly exposed as rest services and consumed by both mobile and web apps (gateway / API component is not necessary).
All of this will depend on the estimated time to refactor the legacy app architecture on a way and to duplicate data access logic (and business one ???) on the other. Of course the duplication will decrease maintainability and extensibility.
I've had to answer this question on several projects; there's a 3rd option which you don't mention, which is my favourite.
The problem with option 1 - "web services as persistence and business logic layer" is that it introduces a lot of additional moving parts into the design. Those moving parts are expensive - you have to write, test and maintain a lot more code, and very often the services you want from your web services to run your own application are not the ones that would make sense to a 3rd party developer.
You are also introducing a potentially significant performance and scalability risk - calling a web service which calls a database is measurably slower than just calling the database.
The second option - duplicating business logic across web app and service layer - has all the problems of duplication.
The option I prefer is to develop the business logic layer as a separate component, and have it used by both the web app and the web services; each application uses the component as a library. This means you have to have separate teams - the "library" team and the "app" teams - but you avoid duplication, and you avoid invoking a bunch of web services every time you have to render a web page.
The business logic layer is responsible for persistence - including making sure that database consistency is honoured, and managing transactions. As the business logic layer is shared between both the web app and the web services, this logic is concentrated into a single code base, and - ideally - made entirely transparent to the apps.
The web services now do far less. Their job is to handle incoming requests, translate them into method invocations on the business logic component, and returning any response data in the appropriate format (XML, JSON). They may offer "coarse grained" service requests and map them onto several more granular business logic methods. They may deal with authentication, authorization, request throttling etc. They just don't deal with the actual business logic.
I want to create a web service (SOAP) under Apache Tomcat with Axis2, and I must respect the three-tiered architecture:
DAO -> Business Logic Layer -> Presentation Layer
I'm new to web services. Is there a step-by-step tutorial for this?
There isn't really a presentation layer in a web service, unless you consider the service itself to be the presentation layer.
http://www.roseindia.net/webservices/axis2/
There is tons of DAO information on the web, and there's nothing special about a DAO layer for a service versus any other application. A lot of this will depend upon how you want to build your DAO layer. I like using Spring JDBC.
Three tiered architecture means different things to different people.
One common interpretation is (with tiers from the user starting with #1):
Presentation layer running in the browser. I.e. Javascript (possibly from some framework such as jQuery, GWT, etc).
Business Logic layer running on the server. I.e. A dynamic web server (Tomcat in this case)
Database such as MySQL, SqlServer, Oracle, PostgreSql, etc.
It's also possible to have a layer #2.5 doing the DAO work for you (or a custom DAO) such as Hibernate.
Another interpretation is that #1 is actually the web server, and #2 is a separate business logic server, where #1 and #2 live in separate server instances (likely on separate machines or VMs) for security, isolation, and the ability to scale and release separately (and many other motivations).
In any case, you should read up on typical Java serving architectures and possibly describe your goals better. I.e. you use "Presentation Layer" which in some definitions doesn't make sense for a non-UI based web service. Of course, Axis2 could be your "presentation layer" for a web service as well :)
Can anyone point me in the direction of documentation for exposing a DAO as an external web service? Currently, in my application we follow a DAO -> Service -> UI layered architecture. Everything is internal to the app, our DAOs access the DB through Spring JDBC and the services are visible only to the web application.
We now have a need for downstream systems within my company to access the DAOs we've created. I need to know what the effort would be to expose our DAOs and what, if any, other technologies I would need to perform this task.
Also, would I expose the DAOs themselves or the services?
I guess I don't fully understand the problem. You'll have to create service operations that do CRUD operations for you DAOs, along with operations for any special data processing your DAOs perform. You already expose the DAOs via service to your current UI. Can you not simply use that service as a template for your externally facing service?
If I were you, I'll just wrap the DAOs in a webservice. So, first define the wsdl, then generate the java code that goes with that wsdl. Then, in the webservice implementation, just hand-copy the entity beans into this webservice beans. Guess you could use bean copy utils if that is too tedious.
Not sure if you can use the entity beans directly in java2wsdl style webservice development, but that seems like a bad idea because you don't have an abstraction layer between entity beans and webservice interface in that case.