• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

General Question about Webservice development approaches (axis2)

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
    Posts: 20
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic