Web service protocol stack

Where to find the service? Universal Discover Description and Integration UDDI

How do you describe a web service? Web service Description Language WSDL

How do you call this service? Simple Object Access Protocol SOAP

How does the data get across (format)? XML, XML Schema

How does the transport take place? HTTP, SMTP

The Web service protocol stack is an evolving set of protocols used to define, discover, and implement Web services. The core protocol stack consists of four layers:

Service Transport: This layer is responsible for transporting messages between applications.

Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible

Exchange Protocol (BEEP).

XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end.

Currently, this includes XML-RPC and SOAP.

Service Description: This layer is responsible for describing the public interface to a specific Web service.

Currently, service description is handled via the WSDL.

Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. 
Currently, service discovery is handled via the UDDI.

Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol stack includes a whole zoo of newer, evolving protocols.

These include

• ·         WSFL (Web Services Flow Language),
• ·         SOAP-DSIG (SOAP Security Extensions: Digital Signature),
• ·         USML (UDDI Search Markup Language).

 For an overview of these protocols, check out Pavel Kulchenko's article, Web Services Acronyms, Demystified, on XML.com.

Fortunately, you do not need to understand the full protocol stack to get started with Web services. Assuming you already know the basics of HTTP, it is best to start at the XML

Messaging layer and work your way up.

RESTful vs SOAP

Both RESTful web series and SOAP web service can operate cross platform they are architecturally different to each other

	RESTful web services	SOAP web services
Simplicity and easiness	·         REST is more simple and easy to use than SOAP. ·         REST language is based on use of nouns and verbs (better readability)
Protocol for producing or consuming web services	·         REST uses HTTP	·         SOAP uses XML.
Protocol Support	·         Transport protocol specific. ·         Supports only HTTP or HTTPS protocols.	·         Transport protocol neutral ·         Supports multiple protocols like HTTP(S), TCP, UDP, SMTP, Messaging, etc.
Lightweight	·         REST is lightweight as compared to SOAP and preferred choice in        mobile devices and PDA’s. ·         REST does not need XML parsing, no message header (to and from), hence less bandwidth
Format	·         REST supports different format like  Text, JSON, XML	·         SOAP only supports XML.
	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()	·         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.
Caching reads	·         REST based reads can be cached. ·         Performs and scales better.	·         SOAP based reads cannot be cached.
error handling	·         requires HTTP error handling	·         can have user defined error
	·         REST only supports synchronous message because of its reliance of HTTP and HTTPS. ·         The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.	·         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.
ACID	·         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 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.
retry logic	·         REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.	·         The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries.

HashSet vs TreeSet

HashSet	TreeSet
Hash set allow null object HashSet<String> hs =new HashSet<String>(); hs.add(null) //runs fine	Tress set will not allow null object .if you try to add null value it will be throw null pointer exception TreeSet<String> ts =new TreeSet<String>(); ts.add(null) //throw null pointer exception
class offers constant time performance for the basic operations (add, remove, contains and size).	guarantees log(n) time cost for the basic operations (add, remove and contains)
it does not guarantee that the order of elements will remain constant over time	guarantees that elements of set will be sorted (ascending, natural, or the one specified by you via its constructor)
iteration performance depends on the initial capacity and the load factor of the HashSet.	doesn't offer any tuning parameters for iteration performance
It's quite safe to accept default load factor but you may want to specify an initial capacity that's about twice the size to which you expect the set to grow.	offers a few handy methods to deal with the ordered set like first(), last(), headSet(), and tailSet() etc

Important points:

·         Both guarantee duplicate-free collection of elements

·         It is generally faster to add elements to the HashSet and then convert the collection to a TreeSet for a duplicate-free sorted traversal.

·         None of these implementation are synchronized. That is if multiple threads access a set concurrently, and at least one of the threads modifies the set, it must be synchronized externally.

·         LinkedHashSet is in some sense intermediate between HashSet and TreeSet. Implemented as a hash table with a linked list running through it, however it provides insertion-ordered iteration which is not same as sorted traversal guaranteed by TreeSet.

null in Sortedset

We think that null is allowed for a Set.
So why does the following code:

SortedSet<Integer> set = new TreeSet<Integer>(); 

set.add(null); 

set.add(1);  //--->Line indicated by exception 

Gives the following exception?

Exception in thread "main" java.lang.NullPointerException at
java.lang.Integer.compareTo(Unknown Source) at
java.lang.Integer.compareTo(Unknown Source) at
java.util.TreeMap.put(Unknown Source) at
java.util.TreeSet.add(Unknown Source)

Yes, we can use null. But we will have to provide our own Comparator to handle the case when null is compared to any other contents of our set.

With natural ordering applied, Java objects do not know how to compare themselves to null.

Inversely, null doesn't know how to compare itself with any object as we cannot call null.compareTo(object).

An example implementation of such a "null-safe" Comparator can be found in the apache commons-collections library. Check out the NullComparator. We could use it as such:

@SuppressWarnings("unchecked")

SortedSet<Integer> set = new TreeSet<Integer>(new NullComparator());  

set.add(null);  

set.add(1);

Load multiple contexts into spring

How do you load more than one context?

There are a couple of ways to do this.

web.xml contextConfigLocation

Your first option is to load them all into your Web application context via the ContextConfigLocation element. You’re already going to have your primary applicationContext here, assuming you’re writing a web application. All you need to do is put some white space between the declaration of the next context.

<context-param>
    <param-name>
                     contextConfigLocation
    </param-name>
    <param-value>
                    applicationContext1.xml
                    applicationContext2.xml
    </param-value>
</context-param>

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>


The above uses carriage returns. Alternatively, you could just put in a space.


<context-param>
    <param-name>
        contextConfigLocation
    </param-name>
    <param-value>
        applicationContext1.xml applicationContext2.xml
    </param-value>
</context-param>

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

applicationContext.xml     import resource

Your other option is to just add your primary applicationContext.xml to the web.xml and then use import statements in that primary context.
In applicationContext.xml you might have…


<!-- hibernate configuration and mappings -->
<import resource="applicationContext-hibernate.xml"/>

<!-- ldap -->
<import resource="applicationContext-ldap.xml"/>

<!-- aspects -->
<import resource="applicationContext-aspects.xml"/>


Which strategy should you use?

I always prefer to load up via web.xml This allows me to keep all contexts isolated from each other. With tests, we can load just the contexts that we need to run those tests. This makes development more modular too as components stay loosely coupled, so that in the future I can extract a package or vertical layer and move it to its own module.
If you are loading contexts into a non-web application, I would use the import resource.
Any benefits to going with the application context import method over the web.xml contextConfigLocation?