Let's take the simple example, where I have multiplication service as part of single monolithic MathService(deployed as war).
Now I need to deploy multiplication service as separate service(rest service) which MathService can call. The concept of dividing the single monolithic
in to small maintainable service is microservice.
But I am not sure is it mandatory to deploy Multiplication service as war file? Can it be still deployed as jar file on the web server?
My understanding is that it should be war file as rest calls(HTTP call) needs to be handled by the servlet. Including servlet means it has to be war file.
Is that correct?
No, it's not mandatory to deployed war file, microservices can also be deployed as jar or war file on the server.
you can also run your microservices as the jar file in external tomcat server
Read this.
No.
Indeed, to work with web server, you would need a war file. But Web server just for receiving and responding network connections. You absolutely can manage connections by your self, with jdk or 3rd party libraries like netty. So you can just build a standalone java application, which actually can be called as a web server.
If you mean "can I deploy service without WAR?", then the answer is no, because the service should be a part of some WAR. If you mean "should every microservice be put to a separate WAR", the answer is not so simple. WAR should contain a single microservice. And dont think of microservice as a technically single end point, single REST or SOAP service, it can consist of several such services/endpoints.
Related
My application has two separate parts, back-end in Java (Spring boot) and front-end in Vuejs.
I can simply deploy the JAR for my back-end code where I need to, and that's it for deployment.
But when it comes to deploying the Vuejs app, I can do something similar and just put the compiled Vuejs application in the proper path in a Java Spring boot application and that will be all for the front-end too.
It just doesn't seem right to me to put that application in Spring boot when it doesn't really have to do anything with it really other than for deployment (Maybe I know nothing like Jon Snow).
Also, when its put under a Spring boot application, manual URL editing doesn't work.
This app doesn't do anything on its own, it fetches all its data from the back-end app.
So what are my options here, can someone please guide me in the right direction?
Do I just setup a nodejs server and deploy the Vuejs app in that? I am not sure how that works, or whether should I even be doing that for a production application. And if so, where do I start with setting up nodejs?
It makes sense to deploy it together with spring, and it's very common practice, at least from my experience with Angular (which I suppose would be very similar to VueJS).
You don't need to have 2 servers running. You just let Spring server your HTML/js/CSS files, which helps you avoid any problems with CORS.
I am not really sure what 'URL manual editing', do you mean by navigating the web page by editing the URL? I don't see much use cases there tbh and I would guess that is only a matter of few settings.
In gradle - I would set up a build task (not sure if task is correct word, 2 build.gradle files, each for FE/BE, the BE would depend on FE), the FE would be run when BE is run, it creates static HTML/js (in my case from angular, but it should be similar for Vue) and BE task adds the output to the classpath of the java application so that Spring can register the HTML and serve it to you.
You could use Docker to create a Dockerized version of your Vue.js app and then you can deploy this onto a cloud service provider such as AWS (e.g. EC2).
Check out this link for a basic guide https://v2.vuejs.org/v2/cookbook/dockerize-vuejs-app.html
My approach is to deploy front-end and back-end separately.
You can use web-server to proxy requests to Vuejs or Spring boot.
For example, if you use Nginx, you can use this configuration to pass requests
# pass root request to index file
location / {
root /front_files/;
index /index.html;
}
# pass requests to static files
location ~ ^/(js|styles) {
root /front_files/;
}
# pass requests to back-end
location /api/ {
proxy_pass http://127.0.0.1:8080/;
}
i have a legacy webspere soap web service provider to be migrated to tomcat.
soap service is using IBM native libraries, any suggestions? can i reuse the existing wsdl file from this project? and what is the best approach to achieve this? considering consumer should'nt make any code changes other than the service url.
One way to do this without changing anything would be to move your war file to Tomcat. Identify the native jars that are being used. Place these jars in tomcat's lib. This approach requires minimal code change.
WSDL files are not technology specific and you can reuse it. You can even re create the web service skeleton using the WSDL file but that would still mean writing the code for Business logic. See if this is what you want :-
https://wiki.eclipse.org/Creating_a_Top-Down_Java_Web_Service_Skeleton_from_a_WSDL_Document
I am trying to do a project with micro-webservices with spring boot and tomcat. My idea is pull apart each one services in different projects.
However there are shared services. For this I thought of creating the shared services like web services, however the final system increases the latency, for this reason I think doing it like library .jar and share the folder in tomcat with shared/lib and change the conf/catalina.properties file like here with:
shared.loader=${catalina.home}/shared/lib,${catalina.home}/shared/lib/*.jar
The problem occurs when I replace the library .jar for a newer version, I have to restart the server tomcat and all web services within, this is not ok.
Could someone tell me other option to do it?
Regards.
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'm new to Java so I may be misunderstanding some of nouns - I hope I'll get it right.
We are creating an extension to a third party software which loads our JAR dynamically. As part of the implementation, the extension should have a service endpoint (I think servlet is right noun) waiting for requests from my company's backend servers.
The entire solution should run on Websphere (probably 7.0).
I'm looking for a way to open a service endpoint without creating a WAR file. The reason I don't want the WAR is because our JAR is loaded dynamically and I'm not convinced that the third party system will be able to load the WAR.
In addition, I afraid that by creating a WAR I'll basically create a new application which will not have access to the objects allocated in the host process of our extension.
Is that doable?
Thanks,
Nadav
Yes you can, just use Enpoint.publish() method comes with JDK itself.
Please look at the link
Publishing a WS with Jax-WS Endpoint