The following is more personal opinion - not hard fact:
Originally posted by vijaya bacina:
1)does we write clients to access already developed webservices or we develop webservices?
With todays tools a web service developer would
primarily work on the server side, i.e. develop web services. However, the best web services are the ones that are the most interoperable - so a web service developer needs to have a good understanding of the potential client side technologies that may access the web service. The aim of the
WS-I Basic Profile (BP) is to define a good level of interoperability - however its just a fact of life that some clients do not even have the level of capability defined in a BP. So you need to know what kind of SOAP constructs your potential clients can consume.
In applications that use earlier incarnations of SOAP stacks (SOAP Application libraries) the web service developer may need to work on the client side because the client is manipulating SOAP messages "manually" rather than using a generated stub.
What is less clear, is whether a web service developer gets to develop the actual
service portion. Web service technologies are primarily "interfacing" technologies. Development of a business services requires quite a different skill set because you are dealing with business processes and business rules. Future Web service technologies are going to enhance how these business processes running within different services interact with one another but they don't help you identify, define and structure business processes.
Originally posted by vijaya bacina:
2)does we write SOAP requests or WSDL documents in real time or by using tools we generate those docs?
Tools can take a programmatic structure and transform into a WSDL, however that can create SOAP messages that some clients may have difficulties processing. However a Web Service Developer who is developing an interoperable web service will focus primarily on the data that needs to be transferred - and then define a WSDL (potentially with an WSDL authoring/verification tool) that the server side tool has no trouble interpreting to create the server side artifacts AND the same WSDL will result in SOAP messages that respective clients have no problems consuming (or have not trouble using the WSDL to create their client side artifacts).