I am planning to design an application which will require both web server and application server (Java EE based). Modern application servers like Weblogic, Websphere, JBOSS can provide support for both application server and web server. However I have seen many applications where the deployment architecture provides a segregation of web server and application server as a separate entity.
I would like to know:
What is the architectural benefit of segregating the web server and app server as a separate entity?
e.g. Assuming we are going to use weblogic as a web sever and app server do you think if there is any concern for large applications?
There is several resons to use a dedicated web server for static content:
In most case a web server is already present infront of the application server (reverce proxy), it is needed if the app server is clustered. So as it is already present.
If the static content is important (size and trafic), puting it in web server allow to scall the content and the application separeatly.
Historicly pure Java app server was slower that native web server, now NIO allow the same access to system call sending file directly to a socket without going back and forward between system and user mode.
So I think you should start with the contend delivered by the app server and complexify the system if it help you to solve issues you actualy enconter.
Related
I would like to know if there is any difference in hosting REST web service APIs in a web server or application server, is there any reason one is preferred over the other?
So i think you are confused about what are application servers and web servers.
Application Server is the name of a machine/server which is running any application used by an organization and it depends of any other servers to run the application functionalities correctly, like Database Servers, Caching Servers and other kind of servers.
Web server is a software which puts an application online for being accessed by clients through the web.
An application server commonly has a web server running inside it, as part of a stack needed to run the application in the server, like libraries and other sofwares need to execute the application objective.
So you can run a REST api inside of an application server with help of the web server application.
Some examples of web servers are Apache, Nginx, LightHttpd, etc.
Our lab has a single machine that is open to http connections from outside. However, this machine is quite weak (little memory, slow CPU). We have other machines that are much stronger, but they are behind a firewall and cannot be accessed from outside the lab.
I am writing a GWT app whose server is very demanding. Is it possible to install the server on a strong computer, and the client on the weak compuer, and have them connect using RPC? I assume it requires some changes in the web.xml file, but what exactly?
Theoretically I can just wrap the demanding part in a separate TCP/IP server, and have the GWT server contact it, but I would like to know if it is possible to do directly in GWT.
The GWT client is downloaded from the server and runs inside a Web browser as javascript code. I don't quite understand what part of the GWT app you would want to run on a separate server.
If your GWT servlet (the RPC service implementation) is accessing external resources, like a database or Web services, you could move those resources to a separate server.
Another option is to install a reverse proxy on the "weak" server that would forward specific requests to a stronger server behind the firewall. The proxying could be done by Apache (httpd) on the "weak" server (using mod_proxy). Then Tomcat would only need to be installed on the stronger machine, and would take care of most of the processing.
I have tried to do this but was only successful in splitting a GWT project into 3 parts (Client, RPC, Server) as eclipse projects. In the end you are going to end up with 1 big WAR file and it'll be deployed in one place (unless someone else was successful at really separating the code.)
A solution you can do is to set up another server that will do all the server side processing (your strong machine) and have the GWT servlets act like a proxy. They accept the requests from the client and forward the data to another server for processing. Then wait for the response.
How you do it is up to you. You could use web-services, direct socket connection, JMS ..etc.
Depends on your setup.
GWT ACRIS- Please see this link.
EJB - One approach could be to keep business objects in remote machines as EJBs and your servlets accessing them over RMI/JNDI.
Spring - Another simple way to do it is with Spring Remoting. See this link.
I have a Java desktop application, which needs to be updated with data from a web server continuously.
Since the desktop application could be used in a mobile environment (e.g. on a laptop with a 3G modem), there is no way to connect with it through the client's IP address.
What is the 'best practice' on pushing data to a [mobile] client from a server?
I have heard that Comet is a new emerging technology, does something similar exist for desktop (non-browser) applications?
By the way, what is the most mature technology for doing that in a web browser client? Comet, HTML5 or anything else?
Comet really has nothing to do with the web aside from it's use of HTTP. The client (web page or desktop application) simply opens an HTTP connection, and it's up to the server to keep it open until it has something to tell the client. If/When the http connection times out on either end, the client simply makes another HTTP call to the same endpoint.
Is an application server something like an additional layer of application servicing above a web server?
Does an application server always have a web server as its core?
What is the difference?
No,Application server does not contain web server...
Read following articles...
http://www.answers.com/topic/application-server
http://download.oracle.com/docs/cd/E19159-01/819-3671/ablat/index.html
Basically:
After the Web exploded in the mid-1990s, application servers became Web based.
Also following shows the difference between web server, web container and application server...
Difference between a Web Server, Web Container, and an Application Server
A Web Server is a server capable of receiving HTTP requests, interpreting them, processing the corresponding HTTP Responses and sending them to the appropriate clients (Web Browsers). Example: Apache Web Server. Read more about Web Servers and their working>>
A Web Container is a J2EE compliant implementation which provides an environment for the Servlets and JSPs to run. Putting it differently we can say that a Web Container is combination of a Servlet Engine and a JSP Engine. If an HTTP Request refers to a Web Component (typically a Servlet or a JSP) then the request is forwarded to the Web Container and the result of the request is sent back to Web Server, which uses that result to prepare the HTTP Response for the particular HTTP Request. Example: Tomcat is a typical Web Container. A typical setup would be to have Apache HTTP Server as the Web Server and Tomcat as the Web Container.
An Application Server is a complete server which provides an environment for running the business components (EJBs, ADF BCs, etc.) in addition to providing the capabilities of a Web Container as well as of a Web Server. Example: Bea WebLogic, IBM WebSphere, Oracle
Application Server, etc.
Actually, with the explosion of the web, and in particular "web services", all modern App Servers can also function as Web Servers. For example, the current version of Tomcat includes built-in Web Server functionality so you no longer must run a separate Apache HTTP server. In the past, running separate dedicated Web Servers such as Apache was preferable since the App Server was optimized for App Server rather than for Web Server, processing; but the performance of App Servers as Web Servers has improved such that any remaining performance difference is irrelevant - and certainly does not justify the expense of running separate servers.
Today, the major difference is that an App Server is designed to support programming languages such as Java or, on the .net platform, C# - as well as to provide an underlying infrastructure that includes automatic fault-tolerance, session mgmt, transaction mgmt, multi-threading - and everything else required to build scalable enterprise applications. Current Web Servers are designed to support languages such as Ruby, PHP, Python and Perl - and lack the built-in infrastructure of an App Server.
However, the distinction between App Servers and Web Servers is blurring and will continue to do so as "Web Services" becomes ever-more popular and languages such as Ruby mature and therefore require Web Servers to provide much of the same underlying infrastructure as today's App Servers. In the end, the primary difference will be (not yet): if you want to develop the back-end (cloud) layer of your application employing Java or C#, employ an App Server; if you want to develop your application employing Ruby, PHP or Perl, employ a Web Server.
While a Web server mainly deals with
sending HTML for display in a Web
browser, an application server
provides access to business logic for
use by client application programs.
Read App server, Web server: What's the difference?
Hosting an application on a web application server e.g. JBoss automatically brings in lots of app server specific functionalities with it e.g. security, clustering & load balancing etc. I have a situation where I have to develop a server app with which, legacy apps can talk to over TCP/IP socket as well as be highly available. Initially, I had though of using JBoss app server to leverage its clustering support for HA. However, I am not sure whether it would be possible to connect to a JBoss web app using pure TCP/IP sockets from both java and non-java apps.
What is the best way to achieve this without using web service or Http approach?
UPDATE: I am specially interested to know how legacy apps will connect to the hosted web app through TCP/IP socket.
A really simple solution to bridge the two worlds would be to add a simple Java server which maps the old TCP/IP requests to HTTP requests. This is probably a pretty braindead task, so this "server" will be simple to write and maintain. Also, this server won't need as much power since it just accepts and forwards connections (no business logic or DB code).
On the JBoss server, you develop like you normally would. The legacy apps connect to the little bridge server which passes the requests on to JBoss and translate the result back.
This ensures that you're building for the future: When new apps are developed, they can connect directly to JBoss and use all the great HTTP features.
There's no reason why you can't open up a normal socket in (say) a servlet application hosted in JBoss.
You can then get a byte stream from this. The headache is then to decide on a platform-independent representation of your messages, such that your client end can format and send such that the JBoss-hosted end can read. But it's all perfectly feasible.
I would implement a very simple http (1.0) client.