I don't understand which is mostly used in the industry.
THAT is a really good question.
It seems to me that the original technology vision of public web services as SOAP services defined by WSDL and located by UDDI as per the WS-* standards has totally failed to come to pass. These technologies are alive and well inside corporate information systems (current buzzword SOA) but the "yellow pages" full of public SOAP services never appeared.
Instead, the public services such as Google and Amazon emphasize REST style services. The web has a large number of articles contrasting REST and SOAP styles, including mine.
You may have to dig into a particular industry to find out what they are using. There are plenty of people trying to sell this that or the other vision of web services so dig carefully.
Sagar Kale wrote:But in most of the posting they mention webservices or SOA.
If they mention "web services" they are probably simply talking about some specific SOAP web services API that they use for remoting over HTTP. If they already have a number of web services, they probably have a JBOWS (Just a bunch of web services) architecture. When they talk about SOA they are often asking for experience with an entire high-end vendor SOA foundation software package - i.e. they want experience with that package, not just whatever web services API it may happen to be using.
Very job postings mention if they require specific, Axis or Xfire.
From todays perspective those API's would be considered "legacy". The only thing that really transfers between the last generation and current generation SOAP Web services stacks (JAX-WS, Axis2, Apache CXF) are the open technology specifications that they are based on, i.e. XML, XML Namespaces, XML Schema, SOAP 1.1, WSDL 1.1. Also current SOAP Web services stacks support SOAP 1.2 (and to a lesser extent WSDL 2.0) and more up-to-date Attachment (MTOM) and some WS-* specifications (e.g. WS-Addressing).
But there really is no guarantee that existing SOAP installations will necessarily be upgraded to the following generation of technology†. Depending on the context they may move to a XML/HTTP binding, JSON/HTTP binding or RESTful web services technology.
Also if "web services" rather than "service-oriented" is mentioned, I would expect only very occasional "web service" related work and/or "web services" that are a nightmare to maintain because nobody bothered to heed the Service-Orientation Design Principles which still apply even in a non-SOA environment as they simply formulate design principles that apply to distributed computing in general.