I am using Java EE for running my backend system and I have a question regarding how to layer it appropriately in terms of creating a web service.
I am pretty much organizing my application after the principles of DDD which means I have a domain layer, repository layer and a service layer. So the service layer are annotated with #Stateless and they are my EJBs.
Now, I could go crazy and annotate this service class with more annotations for the JAX-RS framework...but I don't know if this is correct for several reasons:
Wouldn't this mix the layering a bit?
How could I then version my webservice? Let say that I create a webservice today, and tomorrow I find out that it is really bad, however during the night someone have created an application that uses it and if I trash it the applications could no longer be used. What I want is a webservice that can be found on www.myurl.com/api/v1/customers
and the new webservice on www.myurl.com/api/v2/a_new_customers_webservice
That is what I want in some sort.
There may be other cons too?
So what would the solution be? Am I correct if I say that I create another set of classes that I annotate with JAX-RS annotations and then the methods could internally use the methods from the EJBs in the service layer?
If there is going to be another webservice version I can create another set of classes that uses other URLs and logic. Or am I all wrong? How would you organize this?
The underlying question is how to organize code for reuse. As you pointed out, you can:
annotate your EJB services with JAX-RS to make them web service;
create EJB web services (i.e. with JAX-RS annotations) that reuse other common EJB services (one level of indirection);
create EJB web services that reuse common logic as POJO (one level of indirection).
All three a valid choices to me.
If you're confident about the API of the EJB service, but not the API of the web service (there could be some impedance mismatch), I would go for 2.
If you are not confident about what your EJB service should do, then that's probably the first thing to figure out ;)
If you're confident now, but suspect it might change in the future, I would pick the simplest solution 1 for now, and refactor later as necessary depending on what must be changed. Apply YAGNI.
Related
Spring empowers POJO based programming.
It offers support for MVC out of the box
wires up code in less time.
How does it support layered architecture?
provides an abstraction layer to simplify development process(why is this a benefit and how does spring handle this?)
How does spring do that?
I read a lot of articles talking about the advantages of spring. But none of them explain in theory i.e. in words not code, how spring does that?
for example, one of the advantages says it empowers POJO programming? we can do that with plain java too, why is that a benefit or what's the opposite of POJO?
Kindly request everyone to address those 3 questions. THanks
in short:
spring was created a long time ago. it was probably compared to ejb2 that needed more setup code. POJO vs EJB vs EJB 3 Also spring does support pojos for example as return value in MVC-controllers. pojos dont have external dependencies so your application stays portable (non-functional requirement of an application).
yes you can easily (my opinion) create web applications.
at its core spring provides a container in which bean definitions are stored. when a service is requested that needs a dependecy, spring can look up whether it has a bean definition for that dependency, construct an instance of that bean and inject it in that service. That way you dont need to manually instantiate your service.
for example in web applications spring has abstractions for controllers, services and repositories. typically an application provides controllers so that caller can use your api. controllers should call services that handle your business logic. and services can call repositories that persist your data. that way you have a layered flow:
controllers --> services --> repository
this has the advantage that when you change e.g. your repository you dont have to make changes to your controllers.
spring provides many abstractions for common problems out-of-the-box (e.g. spring security) and empowers convention-over-configuration. That way you can reduce boilerplate code. less code -> less probability for a developer to make a mistake.
e.g. spring-security-oauth2: you can just set some properties in a .properties file and spring autoconfigures beans that solve the validation of an oauth-token when a user requests one of your controllers.
We are trying to split a big monolithic J2EE application into a set of modules to provide unified business logic for all web application clients.
Our goal is to have smaller and more specialized business modules that can be used in any combination by many distinct web applications. This way we expect the applications get easier to maintain individually (compared to the now heavily coupled monolithic one).
We are planning to arrange it like the following diagram:
Where Web Apps call module services on the upper layer to handle business logic through method calls (RMI was the intended protocol but we are open to other options).
J2EE makes it easy to arrange services on three tiers like this through EJB remote beans.
But we are also trying to setup these modules as spring boot applications (using the Spring Boot JPA Starter) because it makes development much more convenient.
My initial plan was to implement the modules with Spring Boot and expose a thin layer of EJB beans as proxies to spring beans with the actual implementation of the service. EJB beans would have spring beans injected using the SpringBeanAutowiringInterceptor class as in spring v4 documentation.
But since this kind of integration was removed from spring v5 I don't know how to proceed.
They are also considering "EJB as an effectively deprecated technology now" as stated in the issue above. But for my use case I can't find a good enough alternative.
So far I have thought of the following options:
Using a custom interceptor as the issue suggests. But it looks like reinventing a discarded old wheel (if that analogy makes any sense).
Spring remoting is an alternative but it's challenging to make it work with Wildfly JNDI for RMI configuration and trying to looks like re-implementing EJB remoting.
Spring Integration I think will add too much complexity and overhead for this simple task.
Message based integration (JMS, MQTT, etc...) may not fit well because of the synchronous nature of what we are trying to achieve.
REST API calls would add a lot of boilerplate code (for serialization and deserialization of objects into JSON, endpoints configuration and so on) and also add some ovehead because the HTTP handling.
Our goals, in this order of priority, are:
Make this integration as solid and fail-proof as possible.
Make calls to business logic from the web layer to the service layer as simple as possible.
Have as little overhead as possible.
With all that said which of those five options mentioned (or maybe another one I haven't considered) would be the best way and why?
I have a requirement, where a front-end application (written in spring MVC) needs to communicate with another backend application. Both the applications are going to be WAR running within the same tomcat instance. For understanding purpose, lets name it frontend.war and backend.war.
I have gone through many posts across various forum, and found many different strategies, some of them are as below:
1) Using EJB - Ruled out, EJB's are maintenance overhead and we have no plan to create a dedicated EAR to accomplish this; because we have plan to add more different forntend wars (application modules) which will communicate to same backend.war.
2) Using JNDI : Looks promising, but it needs to have one war to know about the 'interface' being exposed by 2nd war, its signature. So, it is making it tightly coupled with each other. Future change in the service contract can become nightmare.
3) Using REST API : This looks an ideal approach, with only one caveat that the communication is over HTTP call, hence it could be slow.
Other approaches like common parentContext (in Spring). ContextSwitching within application does have their own issues.
I am getting inclined to use REST API approach for this solution; as it is cleaner and easy to maintain. Further the http protocol is mature and has lots of know-how available for future development.
My query:
A) Is it possible to make a tomcat aware that a particular webservice call is indeed a call on the application running same JVM/Server (kind of 'internal'); rather than an 'external' webservice call?
B) If I use url like 'http://localhost:8080/rest/...' (note that backend.war is not intended for external world, so a domain name is not needed) ; will it do the trick?
I am looking for an approach, which gives me performance of JNDI (communication within same JVM) and flexibility of REST (You can change anything, anytime as long as public URLs are intact).
If you have thousand of war, maybe try the Enterprise service bus approach. WSO2 would be a good candidate. You could always change your entry point definition while keeping the backend intact.
Added benefit: your war can be deployed on multiple server and / or moved, but you keep only an entry point; only one address to change.
Create a jar file of the common functions, package them up as a dependcy to both projects - a service layer !
Alternatively, use rest and stick on different tomcat instances/servers - microservices!
I would use any "remote invocation" approach like Java RMI or CORBA. The latter applies also outside the Java world. Those have some benefits over others: they use TCP but not HTTP, therefore are lighter, serialize objects instead of creating new objects (like json or others). Additionally, I think RMI is simple to understand and use quickly.
I have a design/architectural problem:
I've started developing a java web application. I thought of using 3 layers: a persistence layer (with jpa and hibernate), a business layer and a presentation layer. My problem now is:
the jpa entities would make the model but can or may I use the entities as business objects?
Is this a practice? My common sense says I shouldn't, but then, I need to duplicate these entities as business objects?
Finally, I'd like the presentation layer to be really decoupled from the other layers. While using spring mvc with jsp at first, I'd like. if it's suitable, at some moment to switch to javascript-based application that communicates with the backend through rest requests.
Yes, you can. Outside the persistence context, the JPA Entities are like simple POJOs. It is legal to use them in business code (actually, as hinted by JB Nizet, you usually ALWAYS use them in your business layer without DAO). If it is tightly related to the Entity, you can even add business logic into your JPA beans. Nevertheless, it will be harder to read and understand what the code does. But if you have a reason to do that - there is nothing illegal. It all comes down to software design practices and what you need most.
When you want to change your app into the REST-powered service, it is not difficult. You will have to change the Servlet you are currently running your app with for a JAX-RS or other framework Servlet which will handle HTTP requests in a REST manner for you. It is done in web.xml. Then, you will place your html-pages in any place, where it is accesible for the remote hosts, and connect them to your REST-service with the Javascript AJAX or sth. You should take care of CORS then.
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.