We are building application based on GIS data. We are planning to use PostGIS for storing GIS data.
We will be having API layer which is in java and which consumes webservices rest/soap.
We also using QGIS as UI frontend.
We need to deploy this application.
Can we use GeoServer for deploying java application. What is performance issue if number of users are more.Can we use REST/SOAP webservices in Geoserver.
Any good link/resource/example would be helpful
Yes you can use GeoServer to deploy your Java application.
GeoServer can be downloaded with 2 main configurations (see http://geoserver.org/release/stable/)
A platform independent binary that comes with Jetty
A WAR file which you can run in your own servlet container (like Tomcat)
You can use a variety of servlet containers (ex: Jetty or Tomcat) to deploy your own Java application along with GeoServer.
GeoServer has a thorough REST interface:
https://docs.geoserver.org/stable/en/user/rest/
GeoServer has many options to optimize performance for a production environment with many users.
See:
https://www.slideshare.net/geosolutions/geoserver-in-production-we-do-it-here-is-how-foss4g-2016
https://geoserver.geo-solutions.it/educational/en/adv_gsconfig/gsproduction.html
Related
I know the question is very general and the answer is too biased to the scale, scope, type, etc. of the the target system. Hence, actually I want to know what is the pros and cons of using various containers such as spring-boot, single-main, karaf, etc. and also when/why I should to use a container for such a system.
In our previous project my colleagues used apacha-karaf but they had a lot of troubles such as building the project, settings to allow components export jmx, poor documentation, etc. with it. Since the current system is a spring-based application maybe using spring-boot makes more sense. Any thoughts?
The main questions you have to ask is what are your requirements regarding:
How many integration (micro?)services you will have to support?
Will you need to support independent configuration of these services?
Will you need to support independent branching/versioning of these services?
Will you need to have "hot deployment" (i.e. deploying/ updating/ re-configuring one does not inherently affects the operation of the others) of these services?
If the answer is yes to all, then you have two main alternatives:
Go the JBoss Fuse way (RedHat branded version of Apache Karaf). This means that each of your integration (micro)services will be an OSGi bundle in Fuse.
Go with a non OSGi container, but in this case in order to satisfy your requirements you need another layer of managing the life-cycle of your services. E.g. you can take a look at Fabric8 (https://fabric8.io/).
This will mean that you will ideally have one (micro)service per Docker container (instead of a micro-service per OSGi bundle) and Fabric8 will provide you will the Web UI (plus many other tools, like Kubernetes commands, maven commands) to manage the deployment of your service to a Docker container. As a result, a service may be using spring boot/ tomcat, another one may be just a jvm standalone process or another one may be an OSGi bundle running inside Karaf container, deployed inside a docker container. So option (1) can also be deployed to option (2).
Depending what path you follow you have to be savvy with different technologies, e.g.:
Fuse: osgi/ Fuse container, camel, maven, ..
Fabric: your on demand container (e.g. spring-boot/ tomcat, java process, Fuse, python process, scala process etc..), Docker, Kubernetes, Fabric8, OpenShift, maven, ..
Hope this help :-)
I use the java dsl of Camel together and deploy it inside apache-karaf wrapped inside a docker container. The key is to use feature descriptors and a maven repository. Then you can create custom distributions of a camel project which are loaded in your karaf distribution. This means you can work towards a really cool microservice approach where services are deployed as individual docker containers.
The biggest difficult was getting the custom distribution of Karaf working. Once that was done the rest was pretty ok. I don't use spring so can't speak about spring-boot.
Inside Karaf/docker you can deploy hawtio and from hawtio do monitoring, see metrics and do all kinds of other stuff. Karaf also has decanter which has a kibana dashboard and alerting feature.
The answer should totally depend on what container technologies you are most familiar with and what you'd like to do with the Camel application.
I think Spring Boot is best when you'd like to create a MSA application with Camel and you are familiar with Spring already. The good news is that Camel now fully supports Spring Boot: http://camel.apache.org/spring-boot.html
On the other hand, if you have a preference to the classical-style standalone approach Karaf would be a rock-solid option since commercial products like JBoss Fuse (https://developers.redhat.com/products/fuse/overview/) use Karaf as the primary container. Plus, if you are an OSGi lover then no doubt you choose Karaf ;-)
Finally, don't forget that you can also run Camel applications on a JEE application container. Basically you can package them as .war and deploy them to any JEE container, but it should be worth noting that WildFly has an extended integration support for Camel: http://wildfly-extras.github.io/wildfly-camel/ With the WildFly-Camel subsystem you can deploy Camel applications as simple .jar as you do on Karaf.
Actually I have the same question, here is my conclusion:
Karaf
pros:
1. OSGI based, hot deploy and support multiple version.
2. Maven support, can continuously deploy from maven repo.
Cons:
1. Legacy jars are not support OSGI, need to recreate the jars
2. Dependency conflicts are really hell.
3. Split functions into bundles, it will take more time to develop and test.
Spring Boot
pros:
1. Spring is like a glue, can integration different libraries easily.
2. Spring boot make it much easier to startup, develop and test efficiently.
3. Spring boot + docker, will make the deployment much easier in cloud environment
cons:
1. If you want to support multiple version at same time, need double your infra.
So my suggestion is to use camel in Spring boot. My architecture design is like Spring Boot + Camel + Docker + Consul + Registrator
In my theory spring boot is capable of running java web application stand-alone. It says it has a own embedded servlet container and can use JNDI itself.
I built a war file before (spring-mvc, security, gradle built), but Spring boot assemble jar file and it runs on any machine which has JVM.
So my question is, if I made a spring boot based web app (contained JSP files & JNDI for looking up datasource), although it has own embedded servlet container and packaged jar file for running standalone, do I still need to package it as WAR file and deploy it in WAS (Websphere Application Server) or servlet containers for any reasons such as performance, stability, scaling-out etc?
WAS is an full blown Java Enterprise Application Server, on the other hand you have Spring that only requires a Servlet Container (Servlets are a part of full JEE).
Servlet Containers are for example: Tomcat, Jetty, but also WAS.
Spring Boot is able to package the complete application TOGETHER with the code of Tomcat in an JAR, so that this jar contains the Servlet Container and your Application.
Do I need a additional WAS for performance, stability, scaling-out etc?
Performance: No - There should be no important performance differerence between Tomcat and WAS when you run a Spring-Application. (Only that Tomcat needs less memory for itsself)
Stability: Tomcat and WAS are both very mature products.
Scaling: You can build a cluster of Tomcats by your own.
The main features of WAS over Tomcat are:
- WAS supports EJB and CDI (Tomcat would need TomEE for this), but Spring will not use it, because it is its one Dependency Injection container
- WAS has more Monitoring features, but this does not matter, because Spring Boot has Actuator
#See Difference between an application server and a servlet container? for more details
Simple answer is No. You do not need any Full blown application servers for any of the reasons that you mentioned (for performance, stability, scaling-out). You can just do fine with tomcat
Edit
Looks like you are using only JNDI feature from the Application server. Do you really need JNDI when you pack your servlet container along with your application ? I don't think so. That days are long gone.
JNDI really shines when you have to move an application between
environments: development to integration to test to production. If you
configure each app server to use the same JNDI name, you can have
different databases in each environment and not have to change your
code. You just pick up the WAR file and drop it in the new
environment.https://stackoverflow.com/a/7760768/6785908
(If you still need JNDI to be used to look up your data source refer: https://stackoverflow.com/a/24944671/6785908).
No, still I do not really see a reason for packaging your application as WAR and deploy it to traditional application server. That being said, if you have some existing infrastructure lying around and you are being forced to deploy to existing WAS (or WebLogic or JBoss any application server for that matter) server, then I rest my case :).
I am trying Java with Spring Framework for my own web project. I've asked some traditional JSP web hosting firms which supports Tomcat and they said they do not support Spring Framework. I am confused about this situation. What is the different requirements between JSP and Spring Framework? I was thinking both of them runs on JVM such as Tomcat and they do not need any difference things. Does Spring Framework need different jar files, or different software on server?
Building a Spring application results in a jar with an embedded webserver (most of the times tomcat, but you can change this in the pom.xml/build.gradle).
I used to host my Spring applications on a VPS or Amazon EC2 instance. Something like that. You can just install Java on it and run your jar. No extra installations of webservers needed.
Ok, let get it straight, just summarizing what have been said:
Use Spring MVC, without spring boot.
Use Spring Boot, and create a war file.
There is scenario in my project where I have to share the data from one project to another both the project are running on different server.
I am using JSF and Spring in my project where spring use only for Data base things.
I want to know there is a any way like cross context to share the data or context of two different server.
I am using tomcat 7.0.67, spring 3.3.0 and jsf 1.2
I have achieve sharing data between to different server using the restful web service
I am new to Orbeon. My company has a requirement to integrate our Spring MVC application with Orbeon. I read many posts about deploying Orbeon and Spring app war files separately but mostly within the same Tomcat container by using crossContext config. Is there a way to have both applications running on separate tomcat servers? If so, are there examples available online?
Orbeon Forms 4.7 will have a built-in embedding solution, see Server-side Form Runner embedding #1808. Until that is done, there is no good solution.