JAX-RPC vs JAX-WS

Comparison between JAX-RPC and JAX-WS
Functionlity	JAX-RPC	JAX-WS
SOAP 1.2	JAX-RPC and JAX-WS support SOAP 1.1	JAX-WS also supports SOAP 1.2.
HTTP Binding	JAX-RPC ignored the HTTP binding.	The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-WS adds support for it.
WS-I's Basic Profiles	JAX-RPC supports WS-I's Basic Profile (BP) version 1.0.	JAX-WS supports BP 1.1. (WS-I is the web services interoperability organization.)
New Java features	JAX-RPC maps to Java 1.4.	JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
Annotation Supports	JAX-RPC does not support annotation.	JAX-WS features a collection of annotations to be used to define Web Service endpoints and Web Service clients.This simplifies development a lot, since the developer adds annotations to the implementation classes instead of writing a lot of descriptors.
The data mapping model	JAX-RPC has its own data mapping model, which covers about 90% of all schema types. Those that it does not cover are mapped to javax.xml.soap.SOAPElement.	JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas
The interface mapping model	JAX-WS's basic interface mapping model is not extensively different from JAX-RPC's	JAX-WS's model introduces asynchronous functionality.
The dynamic programming model	JAX-RPC does not have dynamic server model.	It introduces message-oriented and dynamic asynchronous functionalities. JAX-WS also adds a dynamic server model
MTOM (Message Transmission Optimization Mechanism)	JAX-RPC does not support MTOM	JAX-WS, via JAXB, adds support for MTOM. MTOM can send and receive binary data optimally without incurring the cost of data encoding to ensure the data is included in the XML document.
The handler model	JAX-RPC handlers rely on SAAJ 1.2.	JAX-WS handlers rely on the new SAAJ 1.3 specification.

SOAP vs REST

Comparison between SOAP and REST

Functionlity	REST	SOAP
API Flexibility & Simplicity	REST methodology is to write Web services using an interface that is already well known and widely used: the URI.	SOAP, on the other hand, requires specific knowledge of a new XML specification, and most developers will need a SOAP toolkit to form requests and parse the results.
Bandwidth Usage	In RESTful interface requests and responses can be short.	SOAP requires an XML wrapper around every request and response.
Security	REST calls also go over HTTP or HTTPS, but with REST the administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request. No Security related API available, only security related stuff is handling the data over https.	A typical SOAP request, on the other hand, will use POST to communicate with a given service. Has WS-Security api to extend security and encrypt the flow of data to and from the webservice.
Data Transfer	Data that needs to be secure should never be sent as parameters in URIs. And large amounts of data, like that in detailed purchase orders (POs), can quickly become cumbersome or even out of bounds within a URI.	SOAP can transport your all text and BINaries without a glitch.
Type Handling	Incase of HTTP based APIs the return value needs to be de-serialized from XML, and then type-casted.	SOAP provides relatively stronger typing since it has a fixed set of supported data types. It therefore guarantees that a return value will be available directly in the corresponding native type in a particular platform.
Caching	Since HTTP based / Rest-ful APIs can be consumed using simple GET requests, intermediate proxy servers / reverse-proxies can cache their response very easily.	On the other hand, SOAP requests use POST and require a complex XML request to be created which makes response-caching difficult.
Transactions	Rest doesn't support trasaction.	SOAP and WS-* supports transaction.
Metadata	There is no direct way in REST to generating client from server-side-generated metadata.	In SOAP with WSDL we can generate the client proxies.
effort and understanding	while HTTP based or REST based APIs require greater implementation effort on the server side.	it requires greater implementation effort and understanding on the client side
Handle Request	Uses the existing Get and Post to handle client requests.	Uses standard WSDL to handle client requests.
Protocol Used	REST works on HTTP/SSL only.	SOAP/WSDL is the gateway technology to enable interoperability, works both over HTTP and other protocols.
Communication Type	REST communication style is synchronous.	SOAP communication style is, synchronous and asynchronous, bulk transfer and reliable message delivery.
Schema support	Challenging to identify and locate resources.	Predefined xml schema definition.
Javascript Support	Javascript or any other technology that understands HTTP can be used to invoke Rest webservice.	We cannot invoke soap webservice using javascript.
Parsing of Data	Client needs to write some additional code to parse the incoming Java object, since there is no WSDL that can be used to readily parse the incoming object.	Parsing of data is handled based on WSDL that is exposed to the client.
Data Flow	REST is a free form of data flow.	SOAP is a standard data flow, which has a predefined standard that can be used by different languages or different kind of clients.
Performance	Better performance when compared to SOAP.	SOAP has little less performance than REST since it has to parse XML data. But, it mainly depends on the app server’s speed to parse the data and not solely on technology.
Summary	Rest should be used only if the webservice is handling simple input and output like sending user and password to login a user and there is no Java object that has multiple fields.	SOAP is used when there are complex objects like payments object to be exposed, because client stubs can be built easily using WSDL and there is no need of human readable documentation.

Difference between request scopes

<%= request.getAttribute("method") %> - 12

coz. request object will call the getAttribute method and get the exact value.

${requestScope.method } - 12

request scope same as above, it will get the value from the requestScope map.

${pageContext.request.method} - POST/GET

page context will give the request object and .method will define wht sort of request is it.