Why in some projects people use Spring with Application Server?
I see someone questions when people using spring with Application Server.
Spring has implementation of your needs (Security, Data, Cloud ...). And those needs work perfectly on a Web Container (Tomcat, Jetty ...), right?
What are the benefits of using Spring with Tomcat or a WildFly, for example?
I've heard that Application Server supports a much larger load than Web Container, Myth, or Truth?
Related
I know this question might sound stupid but for me it's new. I have developed a simple Spring Boot Application, provide some backend APIs, running on localhost. I have also bought an webhosting server with my own domain, let's say: www.my-domain.com. Right now in the my-domain.com I just have some simple html code. And what I want to do is having the spring boot application running also under this domain.
Is it possible then? If yes can anyone point me to some references please?. If no, what do I need to run an Java Application under my own domain?
Thank you very much!
You need to run the Spring boot application on the server, then you need to configure your web server (nginx/apache), configure Spring API path and port on the web server, and the traffic will go into your application.
How can I deploy a play 2.1 web application to oracle weblogic 10.3?
Weblogic is running on windows server 2008 r2.
My application has web socket and I undersand that there are problems with them on deployment.
Edit:
I understand that servlet 3.0 does not support web sockets. If so, what does Play run on its own server?
Play isn't a Java EE framework. It doesn't use servlets and doesn't natively deploy to an application server. Instead, it brings its own full stack. You just run your application standalone, without any external application server. (It's quite common to put your Play application behind a load balancing webserver, but that's not the point right now.)
While there exists a plugin that lets you bundle up your Play application into a war, I'm not sure it'll do much good in your case. It's not tested on WebLogic. Also, and that's the more fundamental problem: if I'm not mistaken, WebLogic 10.3 only supports servlet specification 2.5, while Websockets are only available starting with servlet 3.1. So what you're planning won't work, regardless of Play.
Edit:
Regarding your edit: There still seems to be a misconception here. Play is not a Java EE framework. It does not use servlets. It does not package its application up as wars, and it does not need an application server for deployment. Play comes with its own webserver, which is based on Netty. This built-in webserver supports Websockets and all of Plays features.
And I checked the source of the play2-war-plugin, and it looks like Servlet 3.1 is not (yet) supported. Same goes for Websockets.
To summarize: No, at this moment, it is not possible to write a Play 2 application that uses Websockets and deploy it to a servlet 3.1 container.
In play1.x, we can package the project to a war, by using play warhowever Play 2.x doesn't allow that. You could use external plugins https://github.com/dlecan/play2-war-plugin to package your apps into standard WAR packages from Play framework 2.
I am a little confused about the roles of a java application server and its differences from a web server.
I found many sites explaining the same difference between the two but not to my satisfaction.
So please explain me about the two following cases:-
1)App. Server and its difference with web server:
From these two links:
Difference between an application server and a servlet container?
What is the difference between application server and web server?
web server: It handles everything through http protocol by accepting requests from clients and sending
responses to them with the help of its servlet container(e.g Apache Tomcat)
App. Server: An application server supports the whole of JavaEE like JMS,JPA,RPC etc.
Now what I am confused with is that how can I use a lot of JavaEE APIs like JMS,JPA etc. with my Tomcat
by adding their jar files in my web application ?
Does that mean that if I use an appliation server I don't have to add those jar files?(I don't think so)
2)The roles of an appl. server (This is very important to me)
From Wikipedia
http://en.wikipedia.org/wiki/Application_Server
An application server provides services such as security,transaction support etc.
"The term is often used for web servers which support the JavaEE" -- It sounds like if we add the required jar files of JavaEE APIs a web server becomes an appl. server.What about it.
Now my question is how an application server performs the tasks of security control or transaction management by itself ?
E.g. in my web application using Spring framework I am providing security by using spring-security and transaction management by using #Transactional annotation and all those things you know.
So does the appl. server have anything to do with my security or transaction management or it has its own ways ?
Forgive my ignorance.
Using Spring, you're in fact embedding some kind of Java EE container inside your application. But even when using Spring, if you need JTA support (because you need distributed XA transactions), you'll need to use an additional transaction manager. If you need JMS, you'll need to install an additional JMS broker. If you need connection pooling, you'll need to use an additional connection pool. Sometimes it's as simple as adding additional jars to the classpath and properties or XML files. Sometimes it's harder.
A Java EE app server comes with everything bundled. You have less flexibility, but you don't need to install, configure and make everything work by yourself.
When you use the Java EE framework, that is a specification. So the application server, if it is Java EE compliant, needs to implement this. So once it is implemented the specification, then it will address Security,transaction etc because it is mentioned in the spec. So it is a contract. Whereas, in a web server, it will just pull out your static resource. There is no need for handling other stuff.
In case of the Spring framework, the framework knows how to handle transaction, security etc. So particularly the developer need not look into these aspects which are implemented by the Application Server in the other scenario.
how an application server performs the tasks of security control or transaction management by itself
It is rather the specification that address these issues, not the application server. So, the duty of the app server is to implement these.
So, if your application is Java EE compliant, then these areas will be addressed and the implementation would have been done by the app server.
May be this is oversimplification,
A web server is basically a HTTP server serving contents over http protocol. So a web server is simply about serving the contents over http protocol. A typical example would be Apache web server. This is simply a file server.
Now the question is where does the web server gets the contents from ? Possible sources are
Static contents (the contents like images/css etc) which are not generated on request but statically served.
Dynamic contents: Simply put, the contents to be served are generated upon the user request.
For the static contents, the web server does not need anything as it simply reads the file and serves it.
For dynamic contents, the web server might need help of additional components which will generate the contents to be served.
Here the Application Server comes into picture.
Now these additional components referred earlier, might interact with database or some other system etc.
In a web environment where your website is exposed to huge number of users (intended/unintended), you need typical services like transaction/security/concurrency etc. so that the user get expected responses and do not see inconsistencies in the behavior of the application.
An application server has inbuilt abilities to manage transaction/security/concurrency/resource management. generally these are referred as Managed services and environment offered by them is called Managed Environment where these basic services are managed by the application server and programmer does not have be bother for them.
Application Server needs web servers or we can say Web servers use Application server's services to generate dynamic contents.
For example, JBoss uses Tomcat as inbuilt web server. Whereas web logic has its own web server. Tomcat again can be called as application server (in principle) as it also offers managed environment for servlets (it manages concurrency and instance pool of servlets/JSPs ).
Coming your your example of Spring:
An Application server will come inbuilt with transaction/security etc whether you need it or not. The Spring offers a very nice way handling this. Spring has all these things BUT you use what you need. Not just these, but just a Java Web Sever like Tomcat is sufficient to build a full fledged services that needs an application server.
I am trying to understand the difference between a full fledged application server (e.g. Weblogic, JBoss etc.) and a servlet container (Tomcat, Jetty etc.).
How do they differ and when to use which?
Thanks,
A servlet-container supports only the servlet API (including JSP, JSTL).
An application server supports the whole JavaEE - EJB, JMS, CDI, JTA, the servlet API (including JSP, JSTL), etc.
It is possible to run most of the JavaEE technologies on a servlet-container, but you have to install a standalone implementation of the particular technology.
Broadly speaking, a servlet container restricts itself more or less to the implementation of the J2EE Servlet specification. Also, it's focus is on the runtime environment and not so much on providing additional tools.
In contrast, a full fledged application server implements the whole J2EE stack; plus it comes with all the enterprisey tools and integration possibilities. An application server usually has advanced administration interfaces, it supports clustering and other features used mostly in high-end systems development.
For a beginner, it's probably better to stay with a simple servlet container, since the learning curve there is much less steep.
Edit
#Apache Fan: It depends on the specifics of your situation like existing systems and future plans among other things. I don't think a generic flowchart approach is applicable here.
Platform selection is usually done by weighing specific requirements against first-hand knowledge of systems under consideration.
However the question gives no clues as to what the evaluation criteria are. Should it be open source? Is around-the-clock vendor support necessary? What kind of an enterprise environment should the system integrate with? Are licencing fees an issue? Any must-have technologies or tools? Etc.
Without knowing the above it's pretty much shooting in the dark.
Basically an application server in Java EE context is a software installed on a server and that implements one Java EE specification (Java EE 7 for example). That means such software (application server) must be able to run Java EE application.
Java EE defines 4 domains, the so called containers:
Applet container,
Application client container,
Web container, and
EJB container.
Two containers are part of the application server (EJB and Web container) and two others are part of the client-computer.
JBoss and Weblogic are application servers, Tomcat and Jetty are web container. That's why JBoss and Weblogic can deal with more technologies than a Web container. Application server can manage EJB.
Servlet container is not the appropriate expression to qualified Tomcat and Jetty because it is more restrictive. Tomcat can also execute JSP and JSF, not only Servlets.
afaik, websphere and jboss are fully compliant j2ee-server that can run beyond servlets, like EJB, whereas Tomcat is just a servlet container and you can't run EJBs on it.
In Layman terms :
A web Server means: Handling HTTP requests (usually from browsers).
A Servlet Container (e.g. Tomcat) means: It can handle servlets & JSP.
An Application Server (e.g. GlassFish) means: *It can manage Java EE applications (usually both servlet/JSP and EJBs).
For a beginner, it's probably better to stay with a simple servlet container.
I am trying to understand how to manage (scale/start/stop/upgrade) webservices written using Spring WS/REST. If you typically deploy a web application on tomcat, you can easily stop it, restart it. If I deploy Spring WS, will they be deployed in similar fashion to webapp? Would they be accessible as individual applications in tomcat (or any WS container) admin page?