In many ways a web service isn't that much different than a JSP/servlet from the container perspective:
HTTP Request (with SOAP Request) arrives.A new service instance is created.The service instance processes the SOAP request and returns the SOAP response (payload)The service instance dies.The SOAP response is sent back to the consumer as an HTTP response.
(the main difference being that SOAP web services aren't supposed to use HTTP session data.)
So there is some overlap between how JSP/servlets access the project's resources and how a web service should access them.
There is one major difference however. The result of the HTML output is usually interpreted by fairly adaptable human beings. The SOAP messages are generated and consumed by inflexible software. So it is important that you start by designing a web service contract (WSDL) that is straight-forward from the
consumer perspective.
SOA Principles of Service Design p.175
The most common examples {of contract-to-logic coupling} have been the auto-generation of WSDL definitions using component interfaces as the basis for the contract design, as well as auto-generation of XML Schemas from database tables and other parts of physical data models. In both cases, the design of the resulting service contract is hardwired to the characteristics of its implementation environment. This is an established anti-pattern that shortens the lifespan of the service contract and inhibits long term evolution of the service. Note: Services with contract-to-logic coupling will tend to have increased levels of technology, functional, and implementation coupling.
Your existing
service logic should probably be encapsulated into an
Application Service. To resolve any remaining tension between the "contract coupling" of the web services provider skeleton and the "logic coupling" of the Application Service use a
service façade.