wood burning stoves 2.0*
The moose likes Web Services and the fly likes General Question about Webservice development approaches (axis2) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "General Question about Webservice development approaches (axis2)" Watch "General Question about Webservice development approaches (axis2)" New topic
Author

General Question about Webservice development approaches (axis2)

Dennis Korbar
Greenhorn

Joined: Jan 14, 2009
Posts: 20
Hello,

I recently started to learn a bit about webservices (axis2), so far it has been working fine, for new projects that is...
I was wondering how I should implement a webservice in a large j2ee application that has already been running for quite some time.
What is a clean way to get access to the projects infrastructure (DAOs etc) from the webservice?

Dennis
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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.
    Dennis Korbar
    Greenhorn

    Joined: Jan 14, 2009
    Posts: 20
    Hey,

    sorry for the late reply! Thanks for all the information, I'll have to read a bit into this, it seems that it is more complicated then I thought. ;-)

    Greetings
    Dennis
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
     
    subject: General Question about Webservice development approaches (axis2)