Are servlets the only way one can write web applications in Java ?
No. Servlets are just the most convenient way to write a Web application in Java. If you think about it: what is a Web application? Quite simply it is an application that can receive an HTTP request and send back an HTTP response. Common models for achieving this are:
To use some kind of wrapper that invokes a script for each request. This was the first model and has a standard called CGI (Common Gateway Interface). The wrapper in this case is a Web server; or
To have persistent code within such a wrapper that can service HTTP requests (rather than being transient like CGI scripts).
There are variations upon this theme (eg FastCGI for (1)). Servlets are an example of (2). The reason 99% of all Java Web applications and frameworks use servlets is because servlets are standard (they have a specification endorsed by Sun and a reference implementation) and they're so low-level that pretty much whatever you want can be built on top of them.
That servlets are most convenient way to write Web apps in Java is arguable. They certainly have been around for a long time, but there are alternatives; take a look at restlets for example: http://www.restlet.org/
Related
Ok, this is the scenario: I've developed a webapp running Java at backend, everything is working pretty well, but now I have to integrate a PHP module (boss requirement) within the whole system.
So, I need to know if both backends can co-exist in a single application and how can I accomplish that.
Yes, you can do it using GwtPhp.
Unlike most of the other frameworks, GwtPHP is a framework for both client and server part. Server part uses PHP 5 - the most used web scripting language today.
It does not sound as if your boss is being reasonable!
There are some possibilities, though:
You could have the server-side entirely in PHP. Obviously you'd still have Java for the client-side because GWT requires it, but GWT can communicate via HTTP to any type of server using XML. You just can't use GWT's RMI-like interface if it's not a Java server.
Alternatively, you could have a separate PHP layer in your app, and the server-side Java itself can call it using HTTP.
Finally, (and more difficult, and experimental) there is a project to allow PHP to run in a Servlet Container, which may give you the ability to mix Java and php: see http://www.php.net/manual/en/intro.java.php
Two things spring to mind.
1) If the PHP app supports JSONP you could run it on a separate server and interact with it that way.
2) Stick the servlet container behind apache and proxy to the servlet container using something like the AJP connector. This would mean that apache forwards the GWT requests to tomcat/jetty whatever and serves the PHP itself.
currently i have an web app build with Strus2 and Spring (IoC, Transactions), and i want to split this into 2 apps; one client which will contain only the web part and one core services that will be accessed via webservices and/or rmi.
I have a dilemma in what technology should i use for "glue", because i like the fact that webservices can be accessed by any clients (php,.net,...,mobile), but as i understand java rmi is faster then webservices.
I was thinking to expose the functionality via webservices and rmi in the same time... but i do not know how to do that.
Also in my current app i have a ajax action that is executed each second from the client to the server, and in this new configuration i think that there will be some performance penalties due to this.
How should i "attack" this situation ?
Thanks,
but as i understand java rmi is faster then webservices.
Why do you think this? Do you have a citation to bolster this claim?
Both RMI and webservices are using TCP/IP; both incur similar network latency. The former uses Java or CORBA serialization to send messages over the wire; the latter uses either HTTP (for REST) or XML over HTTP (for SOAP or RPC-XML).
The relative speed is far more dependent on what those services are doing and how you code them.
I would prefer a web service because simple and open win. You are restricted to RMI/CORBA clients if you use RMI.
Nice. You are running Spring and you already have all you need. Just throw in a few jars (spring webservices and related jars) and you should be good to go.
Please refer :
http://static.springsource.org/spring/docs/2.5.4/reference/ejb.html
http://static.springsource.org/spring/docs/2.5.4/reference/remoting.html
I understand web service provides all SOAP,WSDL support, and it stands at a higher level than Servlet.But if I just simply wanted to expose a rest api to allow another application(client) to make a few very easy queries which can be done even via web browser.
eg. http://serverIP/getUserInfo/123
where 123 is like user's id. Let's just assume user info is returned as json.
Questions are:
Is there a big difference between implementing it in Servlet and Jersey?
If the client application is written in .net, does that make any difference?
Is it true that jax-ws allows you to specify the MIME type to be json while servlet's client has to parse the result?
From performance perspective, which one is quicker? I noticed that normally, Jersey is meant not to be deployed on Tomcat while Servlet is.
Is there a big difference between implementing it in Servlet and
Jersey?
Jersey is a framework that makes it a lot easier to write Restfull services. It uses the Servlet API, so it abstracts away a lot of the low level stuff.
You have to write a lot more code doing it using only the Servlet API, and the code has to deal with a lot of low level stuff that you can configure in a declarative way using Jersey.
If the client application is written in .net, does that make any
difference?
No
Is it true that jax-ws allows you to specify the MIME type to be json
while servlet's client has to parse the result?
Jersey lets you declare the mime type using annotations, but that's only for convenience, you still have to parse the incoming payload to check for correct mime type.
From performance perspective, which one is quicker?
Depends if you are able to write a faster implementation than the Jersey team. Jersey use servlets as well.
I noticed that normally, Jersey is meant not to be deployed on Tomcat
while Servlet is.
Tomcat is a servlet container. Jersey uses the servlet API to communicate over HTTP. There are web-frameworks that don't use servlets, for instance Play framework.
I'm starting to study GWT now, and have a very general question, I could maybe teach myself with a little more experience, but I don't want to start it wrong, so I decided to ask you.
I always develop using JSF, having separate packages for beans, controllers and managedbeans.
However, as the GWT uses RPC, I will not have managedbeans, right?
So, GWT automatically handles user session for me, or do I have to do it myself?
What is the best package structure for the project?
It is best to use RPC, or create a webservice and access the webservice in GWT?
It's hard to host the application on a tomcat server?
Is there a test saying which server is faster for GWT?
Thank you.
However, as the GWT uses RPC, I will not have managedbeans, right?
True, GWT RPC uses POJOs.
So, GWT automatically handles user session for me, or do I have to do it myself?
GWT is pure AJAX APP - client code (normally) runs in one browser window (similar to gmail) and does not reload the web page. This means that the application state is always there - no need for sessions (as a means of saving state). You still might need sessions for user authentication, but this is usually handled by servlet container.
What is the best package structure for the project?
Three packages: client, server and shared. Client for GWT client code, server for server (also RPC) code and shared for POJOs that are used by both client and server.
It is best to use RPC, or create a webservice and access the webservice in GWT?
Go with GWT-RPC or (better, newer) with RequestFactory.
It's hard to host the application on a tomcat server?
It's straightforward: GWT client code is compiled to JS/html and is hosted as any static content. RPC server code is just Servlets - normal web.xml registration.
Is there a test saying which server is faster for GWT?
No clue, but IMHO does not matter, because most of the latency will come from database and network.
Also have a look at http://code.google.com/p/gwt-platform/
This framework is really great and follow all suggested best practices(e.g. MVP) by google and give you as well great support for gin, gwt dispatcher, website crawling, history with tokens, code splitting via gwt async etc.
If you want to set up a good project structure try to use the maven gwt plugin(http://mojo.codehaus.org/gwt-maven-plugin/) it helps you a lot with setting up an initial structure and manage your build process.
I am about to build a system that will have its own engine, as well as a front end user interface. I would like to decouple these two as much as possible. The engine should be able to accept commands and data, be able to work on this data, and return some result. The jobs for the engine may be long, and the client should have the ability to query the engine at any time for its current status.
A decouple front-end / back-end system is new territory for me and I'm unsure of the best architecture. I want the front end to be web-based. It will send commands to the engine through forms, and will display engine output and current status, all through ajax calls. I will mot likely use a Spring-based web app inside Tomcat.
My question involves the best structure for engine component. These are the possibilities I'm considering:
Implement the engine as a set of threads and data structures within the web app. The advantages here would be a more simple implementation, and messaging between the web app front end and engine would be simple (nothing more than some shared data structures). Disadvantages would be a tight coupling between the front and back ends, reliance on the server container to manage the engine (e.g if the web server or web app crashed, so would the engine).
Implement the back end as a stand alone Java application, and expose its functionality through some service on a TCP port. I like this approach because it's decoupled from the web server. However, I'm not stoked about the amount of low-level networking / communication code required. I would prefer some higher level of message passing that abstracts Sockets etc.
Use an OSGi container like Spring DM server to host both the web app and engine. This approach is nice because the networking code is nonexistent. The engine exposes services to the OSGI container for the web app to consume. The downside here is the learning curve and overhead of a new technology: OSGi. Also, the front and back end remain coupled again which I dont really want. In other words, I couldn't deploy the front end on any old servlet container, it would have to be in the same OSGi container as the engine.
I have a feeling RMI is the way to go here, but again that's a new area of technology for me, and it still doesn't explain how to design the architecture of the underlying systems. What about JMS?
Thank you for any advice.
If you really want to decouple web app and engine,you can also deploy the engine in a different server and expose the API as web service calls (WS-* or REST).
If it's going to be a Web app, there's no need to decouple the processes like there would be if you had a desktop app front end and a server back end. So keep it simple.
The basis I would use (and am using for a project I'm working on currently as it turns out) is this kind of stack:
Spring 3
Web container
Application deployed as a Web application (WAR);
For persistence, either Ibatis (my preferred option) or JPA/Hibernate (if you prefer a more object persistence approach);
Your preferred choice of Web framework. There's no easy answer here and there are dozens to choose from, from the straight templating to the more componentized (JSF, Seam, etc). Tapestry/Wicket look interesting but I'm no expert in either.
A Spring container is entirely capable of launching a series of threads and it's quite common to do so. So what you'll need is a series of components that will simply be your engine. Unless you have a good reason to do otherwise, Spring beans within a Web application context is simple, flexible and powerful.
On the front end it depends on what you want. Straight HTML can be done with any Web framework. Even if decorated by some Javascript. I use jQuery for that kind of thing.
It only gets a little different if you want the front end to look like a desktop app (a so-called "rich" UI). For this you either need to use the Google Web Toolkit ("GWT"), possibly a component Web framework like JSF (although I tend to think these get real messy real fast) or a Javascript framework like ExtJS, SmartClient, YUI or the fairly new Uki.
You'll decouple your UI if you write your back end as services, and establish an XML or JSON message format to pass between client and services.
All the rest of cletus's comments can hold true for the back end, but the client can be blissfully unaware of it. It can even be a .NET implementation for all it cares. The focus is on the use cases and the messages, not the back end implementation.
This can also be useful in those instances when you use a non-HTML based UI (e.g., Flex).