We Keep Coding

Controller-Facade-Service architecture in a Restful Spring Boot web application

I'm developing a set of microservices for a web application with Spring Boot, and I'm unsure if the pattern design I'm using is correct, or makes sense, or has any advantages.
What I'm using is a controller-facade-service design, which in my mind should work in this way:
The controller delegates everything to the facade, passing the input DTO to it
The facade implements all the business logic and uses one or more services to create an output DTO to send back to the controller
Services implement core and atomic functionalities, mostly CRUDs, without any or minimal business logic so that different facades with different business logic can use them, and return a JPA entity to the facade
Is this a good design pattern? Is the facade unnecessary?
More specifically, should the business logic be in the facade or in the service? I believe services should be logic agnostic so that they can be shared across multiple facades, which may implement different logic depending on the endpoint.
Also, in the case of a CRUD operation, should the service return an entity to the facade? Or should it be up to the service to create an output DTO for the facade?

N-tier Architecture in Spring

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.)

RESTful API Client best practices

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.

Are Facades in EJB the same thing as service in a spring-based web application

I've participated in several projects of Spring-based web-application - and have written a quantity myself. Usually we have (roughly speaking) following folders to divide our classes by categories like dao, models, web (for controllers if we use Spring MVC or backing beans for JSF for example) and also service - here we keep what we think is business-logic (even when sometimes classes here simply forward methods to dao).
Now I am faced with development of EJB application - I've learnt that I will have some web and model classes anyway. Also I may use dedicated dao layer or may put data access into facades (I prefer dedicated folder though it increases verbosity).
But I do not understand clearly whether facades are exactly the place to put business-logic in it, or I should add services folder for it and use facades more like dao (eliminating dao itself).
I also would be glad for short and comprehensive compilation of hints on EJB application architecture.

I would go with a similar setup with EJB as you have done with Spring. You have your web package (MVC stuff), then your service layer which contains most business logic and then DAO layer which contains basic CRUD operations and some database queries.
In this scenario you can test the possibly complex business logic in the session beans with fast unit tests that don't need database and you can mock the DAO access here. Then you can have relatively simple tests for your DAO layer, so the number of tests requiring database (ie. that are consirably slower) is smaller.
Normally I would call facade a set of session beans that offer simple methods for operating the system via for example Web services. These beans would use the normal service layer beans. With just a web layer and no integration layers I don't see a reason to create an extra facade layer.

Exposing DAO as web service

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.