Lately I started to learn Java EE and related technologies and there are some concepts which confuse me. Somewhere I read that whenever one is building a Java EE application then it is sort of mandatory to use a container.
Currently, I am learning Spring framework and trying to build a small application with it to get hands-on. Now in that I am not sure if it is mandatory for me to use a container (say Tomcat) or it depends application which I am building that I need a container or not.
If it depends on the application that one is building, then what are the factors which help to decide whether a container should be used or not?
Puuhhh, this is a very big question and there is no simple answer. But I will do my best to explain my own opinion at least:
What are containers?
Containers provide functionality to you. Such a functionality can be to handle web request and dispatch them to servlets - in this case we call them servlet containers (e.g. Tomcat or Jetty).
But containers can also provide other things, e.g. they can provide user authentication, logging or the connection to a database. Most containers (e.g. Tomcat) do multiple of those things (e.g. Tomcat does all I mentioned). Some containers do more then others, e.g. JBoss can do much more than Tomcat.
Trade Off
However, there is a trade off: If you use a simple container (like Tomcat), you need to do a lot of things on you own or by using other Frameworks (like Spring). But if you use a powerful container, you must know the container very well and the chance is high that your application will depend on this concrete container sooner or later.
The point, that using a container is not mandatory. It is a decision. Some people will argue for it, others against it. But depending on the books you read, this decision is already made (e.g. J2EE needs a J2EE container, that's how it works).
The trend (IMHO)
Years ago the trend was to use big and powerful (J2EE) containers which provide as much as possible. IMHO the trend today is to use smaller and light-way solutions. Most developers would prefer to use a Tomcat server instead of a JBoss server today.
Frameworks without containers
While J2EE needs a container, there are other frameworks/technologies which supports the development of web applications without any external container. Such frameworks are Play! or Spark Java.
Note
If you are not familiar with containers and Spring, take care to don't get confused. Most applications you will develop with Spring are web applications which will be deployed to a servlet container. This is very common. But Spring doesn't relay on that. You can also use Spring without such a container, e.g. to develop a desktop application. But if you want to develop a web application, the Java-way is to use a servlet container.
If your application is using servlets, you'll need a container to handle the requests. Tomcat is a very popular choice.
I'll anticipate your next topic to cover with this discussion of "application server" versus "container."
There are two containers. One is Web Container (IIS, Apache) to run Web Applications and another is "Application Container" to run Enterprise Applications.
Web Applications = Apps developed using HTML, XML, CSS and JSPs
Enterprise Applications = Apps developed used JAVA, J2E and Serverlets in addition to HTML and XML.
Related
I have a Spring Boot web application which is currently deployed Google App Engine. Now I am shifted to Docker and want to deploy the docker image of this application on to App Engine.
So far, I could not find any document related to this. Most of the documents explain how to deploy a docker image of Spring boot on Tomcat. Is there any way to achieve this?
First you need App Engine using the flexible environment , if you want deploy by docker image.
Here is the document Building Custom Runtimes.
A custom runtime allows you to use an alternate implementation of any supported App Engine flexible environment language, or to customize a Google-provided one. It also allows you to write code in any other language that can handle incoming HTTP requests (example). With a custom runtime, the App Engine flexible environment provides and manages your scaling, monitoring, and load balancing infrastructure for you, so you can focus on building your application.
In official case they have their sample DockeFile by jetty. But you can ignore the jetty part, just make your spring boot application executable ,and run it.
FROM gcr.io/google-appengine/jetty
ADD test-webapp-1.0-SNAPSHOT.war $JETTY_BASE/webapps/root.war
WORKDIR $JETTY_BASE
RUN java -jar $JETTY_HOME/start.jar --approve-all-licenses --add-to-startd=jmx,stats,hawtio
&& chown -R jetty:jetty $JETTY_BASE
Hopefully this helps:
https://github.com/GoogleCloudPlatform/getting-started-java/tree/master/helloworld-springboot
One compelling benefit with Docker containers is that, when the containers works on one runtime (e.g. Tomcat), it should be relatively straighttforward to swap in a different runtime (e.g. App Engine).
NB App Engine Flexible is the specific service that you want. It is similar to App Engine Standard but it schedules containers for you.
The primarily requirement for a container (image) to work with App Engine Flexible is that the container expose an HTTP endpoint on port 8080. As long as your container meets this obligation, you can run anything within it.
Our application are built on Spring boot, the app will be packaged to a war file and ran with java -jar xx.war -Dspring.profile=xxx. Generally the latest war package will served by a static web server like nginx.
Now we want to know if we can add auto-update for the application.
I have googled, and people suggested to use the Application server which support hot deployment, however we use spring boot as shown above.
I have thought to start a new thread once my application started, then check update and download the latest package. But I have to terminate the current application to start the new one since they use the same port, and if close the current app, the update thread will be terminated too.
So how to you handle this problem?
In my opinion that should be managed by some higher order dev-ops level orchestration system not by either the app nor its container. The decision to replace an app should not be at the dev-ops level and not the app level
One major advantage of spring-boot is the inversion of the traditional application-web-container to web-app model. As such the web container is usually (and best practice with Spring boot) built within the app itself. Hence it is fully self contained and crucially immutable. It therefore should not be the role of the app-web-container/web-app to replace either part-of or all-of itself.
Of course you can do whatever you like but you might find that the solution is not easy because it is not convention to do it in this way.
Which is good in production environment? Individual embedded tomcat for each app or one tomcat for many apps?
The idea of making micro services is mainly to build services that are developed/ deployed/scaled independently. When you try to deploy multiple microservices inside a same container/jvm then you may not be able to leverage all these benefits. Also you CI/CD/integration testing may be hard. Try using embedded containers or container technologies like Docker which ensures complete isolation of the microservices.
The decision also depends on what is the deployment environment of yours. If its cloud going for Docker would be a good idea
I'm having trouble undrstanding the difference about both platforms?
Both seem to offer an environment for deploying and managing applications.
First I thought app servers use OSGi under the hood, I don't think so now but I see large AS (jboss, glassfish, websphere, etc) use OSGi.
What's the big picture?
Thank you
There is (to some extend) an overload of the term "application".
OSGi is a runtime environment (and development model) for modular Java applications. The term "application" in this case can be really, really low level. For example, an application server can be considered such an "application".
Application servers are also a runtime environment (and development model) for Java applications. However, the term "application" in this case typically refers to a higher level application type (eg., web applications). Application servers typically include a rich set of higher functionality and programming APIs for building web applications (Servlets), persisting data into databases (JPA) and clustering capabilities. Most application servers these days are composed of modules (eg., core, servlet engine, EJB container, etc.). Some application servers use OSGi under the covers. Others have their own modular runtime environment which also offers OSGi capabilities.
But it's also possible to develop higher level applications (such as web applications) directly using only OSGi runtime environment. However, an OSGi framework itself does not include any of the additional functionality. It has to be assembled yourself. There are some "distributions" that include a framework and several modules.
We are developing a open source trading platform based on Springframework and Hibernate http://code.google.com/p/algo-trader/ and http://www.algotrader.ch. The application consists of a trading framework and several strategies that can be started independently. So far, these different parts have been running in separate JVM's communicating through RMI and JMS.
To avoid unnecessary serialization and network overhead we would like to run the entire application within some sort of container (potentially an application server). We do however have the requirement, that the individual parts of the application can be deployed, started and stopped independently.
We have looked into OSGi, but a lot of the libraries that we use are not OSGi ready yet, so this is not currently an option. Also please note, there is no web-GUI in our application.
Any suggestions on this?
Thanks
Andy
If OSGI is not an option then functionality can be broken into smaller units and then deploy them as utility jar, if deployed as utility jar they can be managed independently.
For application server I feel either glassfish or Jboss will be a good option considering they are open source and free.
Though at a later point in time you can check with Weblogic (Dev free).
So in your case you would like to break the static data configuration(Counterparty, Currencies), Dealing(Pricing, Quoting, Booking) as two separate feature.
For your choose of an application server i advise you Jboss and specially in his version 7.1 which is faster and more stable!