What are the differences between SOAP WS and RESTful WS?


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.

Singleton Design pattern in JAVA


Below class depicts the Singleton design pattern.

SingletonDesignPattern.java

package in.javatutorials;

/**
* @author JavaTutorials
* @version 1.0
*
*/
public final class SingletonDesignPattern {

/**
* make the class object as private as it is
* not used directly out side the class
*/
private static SingletonDesignPattern singletonObj = null;

/**
* make the constructor as private.
* Object cannot be created using the constructor outside of this class.
*/
private SingletonDesignPattern(){

}

/**
* Create the class object if it is null and
*
* @return singletonObj SingletonDesignPattern
*/
public static SingletonDesignPattern getInstance(){
if(singletonObj == null){
singletonObj = new SingletonDesignPattern();
}
return singletonObj;
}

/**
* Take the user name as parameter and return the welcome message
*
* @param userName String
* @return message String
*/
public String getWelcomeInfo(String userName){
String message = null;
//make method access to synchronized to make thread safe
synchronized (SingletonDesignPattern.class) {
System.out.println(“User Name is : ” + userName);
message = “Hello ” + userName + “!!!”;
}
return message;
}
}

 

TestSingleton.java

The main() method of below class will get the single ton object and access the other methods using the same.

package in.javatutorials;

public class TestSingleton {

public static void main(String[] args) {
//Get the singleton object
SingletonDesignPattern singletonObj = SingletonDesignPattern.getInstance();

System.out.println(singletonObj.getWelcomeInfo(“Mallik”));
}

}

Java EE 5 vs Java EE 6


This post visualizes changes between Java EE Standards 5 and 6. The comparison of standards is listed in four sections Web-Services, Web-Container, Enterprise Application technologies and Maintenance. Hope this helps someone.

Web Service related changes

JAVA EE 5 (JSR-244) JAVA EE 6 (JSR-316)
JAX-RPC 1.1 JSR 101 JAX-RPC 1.1
Enterprise Web Services 1.2 JSR 109 Enterprise Web Services 1.3 (new version)
Web Service Metadata 1.0 JSR 181 Web Service Metadata 1.0
Streaming API for XML 1.0 JSR 173 Streaming API for XML 1.0
JAX-WS 2.0  JSR 224 JAX-WS 2.2 (new version)
JAXB 2.0 JSR 222 JAXB 2.2 (new version)
SOAP with Attachments API for Java (SAAJ)JSR 67 Java APIs for XML Messaging 1.3 (new version)spec
new! JAX-RS 1.1 JSR 311
new! Java API for XML Registries (JAXR 1.0)JSR 93

The new redesigned Java API for XML Web Services (JAX-WS) is the base or a middle part of a newly Java EE 6 Web service stack.  The new stack  includes JAX-WS 2.0, JAXB 2.0, and SAAJ 1.3. and is also called “integrated stack”.  JAX-WS was designed to take place of JAX-RPC. Due this also JSR-109 was updated because it describes run time architecture of JEE Web Services Stack. JAXB which provides an easy way to bind an XML schema to java and vice verse, was updated to.

The SOAP with Attachments API for Java (SAAJ) (also known as Java APIs for XML Messaging (JAXM)) provides a standard way to send XML documents over the Internet from the Java platform and was updated slightly containing now other consolidated standard.

New are JAX-RS, which provides support for RESTful Web services and JAXR which enables pull-parsing API for reading and writing XML documents. Also available in Java SE.

Web Applications related changes

JAVA EE 5 JAVA EE 6
JSTL JSR 52 JSTL
JavaServer Faces 1.2 JSR 252 JavaServer Faces 2.0 (new version)
JavaServer Pages 2.1 JSR 245 JavaServer Pages 2.2 /EL 2.2 (new version)
Java Servlet 2.5 JSR 154 Java Servlet 3.0 JSR 315 (new version)
new! Debugging Support for Other Languages 1.0 JSR 45

In Java EE 6 we have updates of all technologies of the Web Container except JSTL. So e.g. Servlet 3.0 improves Servlet concept in pluggability and some ease of development. It’s also introduces Async Servlet, and long waited File Uploading!. Also now configuration can be done by annotations.

New a specification of Debugging Support for Other Languages 1.0
This describes standardized tools for correlating Java virtual machine byte code to source code of languages other than the Java programming language, so it would guarantee debugging possibility of everything what runs is JSR-45 certified container.

Enterprise Technologies changes

JAVA EE 5 JAVA EE 6
Common Annotations JSR 250 Common Annotations
JCA 1.5 JSR 112 JCA 1.6 JSR 322 (new version)
JavaMail 1.4 JavaMail 1.4
JMS 1.1 JSR 914 JMS 1.1
JTA 1.1 JSR 907 JTA 1.1
Enterprise JavaBeans 3.0 JSR 220 Enterprise JavaBeans 3.1 JSR 318
(new version)
JPA 1.0 JSR 220 (together with EJB 3.0) JPA 2.0 JSR 317 (new version)
new! Contexts and Dependency Injection for Java (Web Beans 1.0) JSR 299
new! Dependency Injection for Java 1.0 JSR 330
new! Bean Validation 1.0 JSR 303
new! Managed Beans 1.0 JSR-316

In Enterprise Application section we see some important changes and new specifications. Most famous and important is  JSR-299 Context and Dependency Injection (CDI) which is there to unify the JavaServer Faces-managed bean component model with the Enterprise JavaBeans component model to simplify the programming model and architecture of web-based applications. Look an Weld Framework as reference implementation to this.

The similar sounding Standard Dependency Injection for Java JSR-330 just define a standard and common known DI like in spring and other frameworks. Look at popular Guice DI-Framework from Google which implements JSR-330.

Bean Validation  introduces a very cool annotation based and architecture layer independent Java Bean validation.

There are also some interesting improvements in EJBs. Singleton is a new type and can be only one per container, it is also possible to use @Local Beans (Same VM) without interface. Also JPA 2.0 has advanced query possibilities and validation.

Management Technologies

JAVA EE 5 JAVA EE 6
J2EE Application Deployment 1.2 JSR 88 J2EE Application Deployment 1.2
JavaBeans Activation Framework (JAF) 1.1 JSR 925 JavaBeans Activation Framework (JAF) 1.1
J2EE Management 1.0  JSR 77 J2EE Management 1.1 (new version)
Java Authorization Contract for Containers 1.1 JSR 115 Java Authorization Contract for Containers 1.3(new version)
new! Java Authentication Service Provider Interface for Containers JSR 196
new! [JavaSE] JAXP 1.3 JSR 206
new! [JavaSE] JDBC 4.0 JSR 221
new! [JavaSE] JMX 2.0 JSR 255

Nothing special to mention here.