|SOAP Web Services
||RESTfull Web Services
|The SOAP WS supports both remote procedure call (i.e. RPC) and message oriented middle-ware (MOM) integration styles.
||The Restful Web Service supports only RPC integration style.
|The SOAP WS is transport protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP SMTP, etc.
||The REST is transport protocol specific. Supports only HTTP or HTTPS protocols.
|The SOAP WS permits only XML data format. You define operations, which tunnels through the POST. The focus is on accessing the named operations and exposing the application logic as a service.
||The REST permits multiple data formats like XML, JSON data, text, HTML, etc. Any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE Web operations. The focus is on accessing the named resources and exposing the data as a service. REST has AJAX support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create, Read, Update, and Delete) operations.GET – represent()POST – acceptRepresention()
PUT – storeRepresention()
DELETE – removeRepresention()
|SOAP based reads cannot be cached.
||REST based reads can be cached. Performs and scales better.
|SOAP WS supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc.
||The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.
|The SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.
||The REST supports transactions, but it is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.
|The SOAP has success or retries logic built in and provides end-to-end reliability even through SOAP intermediaries.
||REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.
Other Useful links:
Click here to know more about webservices
Click here to know more about RESTfull web services.
Click here for Web services Question and Answers.
Click here to know how to create a SOAP web service.
Click here to know how to write web service client suing java.
REST is a “Representational state transfer” and it is firstly introduced by Roy Fielding (Fielding is one of the principal authors of the HTTP specification and a co-founder of the Apache HTTP Server project) in his 2000 doctoral dissertation.
REST-style services (i.e., RESTful services) adhere to a set of constraints and architectural principles that include the following:
- RESTful services are stateless. As Fielding writes in Section 5.1.3 of his thesis, “each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.”
- RESTful services have a uniform interface. This constraint is usually taken to mean that the only allowed operations are the HTTP operations: GET, POST, PUT, and DELETE.
- REST-based architectures are built from resources (pieces of information) that are uniquely identified by URIs. For example, in a RESTful purchasing system, each purchase order has a unique URI.
REST components manipulate resources by exchanging representations of the resources. For example, a purchase order resource can be represented by an XML document. Within a RESTful purchasing system, a purchase order might be updated by posting an XML document containing the changed purchase order to its URI
Servlet is a Java class used to extend the capabilities of servers that host applications accessed via a request-response programming model. Although servlets can respond to any type of request(like HTTP, FTP), they are commonly used to extend the applications hosted by Web servers.
Servlets runs at Server side typically Web Server or Application server, and respond to request by giving the response to user after processing the request…… More
In J2EE, application modules are packaged as EAR, JAR and WAR based on their functionality.
Each type of file (.jar, .war, .ear) is processed uniquely by application servers, servlet containers, EJB containers, etc
Jar file (file with a .jar extension) is the normal Java Application archive and intended to hold generic libraries of Java classes, resources, auxiliary files, etc
This can be added in classpath for compilation and to run java program. Generally in web applications we keep these files in lib directory of the application.
Ex: ojdbc14.jar – This contains all the classes to connect the oracle database
Servlet-api.jar – contains servlet related classes
Web modules which contains Servlet class files,JSP Files,supporting files, GIF and HTML files are packaged as JAR file with .war( web archive) extension
War files (files with a .war extension) are intended to contain complete Web applications. In this context, a Web application is defined as a single group of files, classes, resources, .jar files that can be packaged and accessed as one servlet context.
All above files(.jar and .war) are packaged as JAR file with .ear ( enterprise archive) extension and deployed into Application Server.
Ear files (files with a .ear extension) are intended to contain complete enterprise applications. In this context, an enterprise application is defined as a collection of .jar files, resources, classes, and multiple Web application.
Servlet is faster in execution as every jsp is changed on converted to servlet before starting the execution. Thus the server need to spend some time to convent a JSP file to servlet at it’s first time execution. But developing a jsp is very easy when compared to servlet.
Every time before executing a jsp & server searches for related servlet file. If it existsWhen ever we send a request to the JSP file it checks the servlet representing the JSP file. Then the web container runs the jsp compiler that generates the servlet code
then start the execution of that servlet otherwise server creates servlet files for those jsps first and then execution takes place
It is possible to share the same object of stateless session bean by multiple clients.
A Server maintains a pool of objects in case of stateless session bean. And every When ever we send a request to the JSP file it checks the servlet representing the JSP file. Then the web container runs the jsp compiler that generates the servlet code
time for a request it uses one of the pool of objects which is free at that time. The server gets back that object in to the pool only after the client work on that object is Directoryover [ client says that by invoking ejbremove() method]
After the client release that object, the server may used the same object to handle another client request, thus the same object to handle another client request. Thus the same object of stateless session can be shared by multiple clients But sharing the same object for multiple clients is not possible in case of state full session bean. Here server should maintain an object for every clients to handle / maintain the state of that object.
As such there is no limit on the amount of information that can be saved in a Session Object. Only the RAM available on the server machine is the limitation. The only limit is the Session ID length(Identifier) , which should not exceed more than 4K. If the data to be store is very huge, then it’s preferred to save it to a temporary file onto hard disk, rather than saving it in session. Internally if the amount of data being saved in Session exceeds the predefined limit, most of the servers write it to a temporary cache on Hard disk.
There are couple of Methods. Firstly servers like JRun and others provide separate logs where all your Print requests will print their data into. For example requests to System.out. and System.err go to different log files. If this features is not available or you want to maintain logs separately for each module then you can create a static class called “LogWriter” and call the method inside the try catch loop. The print method in Log Writer will be writing to a custom defined Log File.
LogWriter.print(“Debug : The following error occurred at function …. ‘)
Also Inprise JBuilder supports Servlet Debugging. Please refer to JBuilder documentation for details.
Just as a Cautionary note, from your Servlets, never call System.exit(0). The results might be unpredictable. Might close down the entire Server. The Best way is to catch the Exception and either send resultant Error Page to the Browser or Write to a Log file and inform user about the Error.
Server Side push is useful when data needs to change regularly on the clients application or browser , without intervention from client. Standard examples might include apps like Stock’s Tracker, Current News etc. As such server cannot connect to client’s application automatically. The mechanism used is, when client first connects to Server, (Either through login etc..), then Server keeps the TCP/IP connection open.
It’s not always possible or feasible to keep the connection to Server open. So another method used is, to use the standard HTTP protocols ways of refreshing the page, which is normally supported by all browsers.
<META HTTP-EQUIV=”Refresh” CONTENT=”5;URL=/servlet/stockquotes/”>
This will refresh the page in the browser automatically and loads the new data every 5 seconds.