I just saw some code where a web service operation is invoked by means of doing an HTTP Post whereby the HTTP headers and soap envelope are constructed manually and pushed through a socket to the endpoint.
Can anyone tell me what are the disadvantages of doing this as opposed to doing something like Service.create ???
There is (usually) not right or wrong, because in some cases, may they be rare, there may be justification for using a specific solution to a problem.
If you consider sending a SOAP request by sending a string of characters over a socket, you will have the following consequences:
More code to write
This will also mean more code to test and more code to maintain.
The solution does not require special knowledge about some web service stack or such, albeit there is a slight feeling of reinventing the wheel.
However, there may be circumstances, such as a special environment (cellphone, for instance), where there are restrictions on the libraries and frameworks that can be used.
A non-standard solution
Using an existing standard, like JAX-WS, has the advantage of it being a standard.
If someone knows how to develop, for instance, JAX-WS web services, it will be relatively easy to switch to another web service stack adhering to the standard.
Understanding a non-standard solution will, most likely, require more effort.
I am sure there are additional things that can be considered, but I think this will give you a hint.
1. Suppose my company A (provider) (too good to be true ) and another company B (consumer) choose to do web service using SOAP over JMS.
2. When A recieve SOAP Message from B, it can simply POST to another company C as it is (with or with additional SOAP Message manipulation)
using either URL/Apache Client OR JAX-RPC/JAX-WS client API.
Would URL or Apache Client not enough?
This is like replacing the hard-coded SOAP message with a ready SOAP Message from JMS Queue.