Originally posted by Arjun Reddy:
I am planning to implement web services (Producing and Consuming) both Top down and Bottom up.
This seems like you are looking for a more tool-driven (
IDE) approach which neither
J2EE Web Services or
SOA Using Java Web Services will deliver. If anything most web service "enthusiasts" will recommend a more hands on/down in the dirt approach because wizards will often hide details that are pertinent to achieve understanding.
Which really brings me to the core question: Why are you interested in
SOAP web services
now?
The main driver behind current interest is SOAP web services is often the continued buzz about SOA. If that is is your main impetus skip the fiddling with APIs and IDEs and go straight to learning about SOA.
SOA in Practice doesn't depend on web services at all. Thomas Erl's
SOA Principles of Service Design and
Service-Oriented Architecture: Concepts, Technology, and Design deal with SOAP but at least deal with it on a level that goes beyond - i.e. there is information that is independent of SOAP and retains some value even in a post-SOAP era.
If application access over the web is your main goal then you may want to skip SOAP for now (and only do as much as you have to) and focus more on the more web-oriented
RESTful Web Services which are getting technical support now. They are not a silver bullet - however they utilize the web more effectively compared to SOAP web services. The downside is that RESTful development usually requires "an adjustment in developer thinking" which cannot be gained from fiddling with IDEs and APIs.
If interoperation between .NET and Java
right now is your goal, you are pretty much stuck with SOAP web services - at this point it is difficult to predict when that will change. The knowledge contained in
J2EE Web Services or
SOA Using Java Web Services is pretty detailed - however this type of knowledge is essential when diagnosing why some SOAP web service clients and services have interoperability problems.
If you are simply looking for "some type of interoperability" then it can be difficult to choose an optimal approach. Many choose SOAP because of the convenient code generators. Then again, if SOAP is so great why doesn't it have "top dog" status over at a place like
Amazon Web Services?
RESTful HTTP web services vs. Big Web Services (SOAP/WSDL)
