Help coderanch get a
new server
by contributing to the fundraiser
  • 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 ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

JAX_WS RI 2.1 indirect endpoint interface exception

Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have endpoint interface. Can I implement it with some abstract class and the use a child of this abstract class as the official endpoint interface implementation (and put it in jax-ws)?

Posts: 2968
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You shouldn't, even if you can.

Inheritance is an Object-Oriented concept that has no place in Service-Orientation. If you have some kind of utility functionality that you wish to reuse simply encapsulate that in an appropriate set of classes and instantiate them as necessary and delegate to them in your various service implementations. Services do not support inheritance or polymorphism even if the language they are implemented in does.
SOA Principles of Service Design

Thomas Erl p. 459 wrote:Due to the emphasis on individual service autonomy and reduced inter-service coupling, inheritance between services is generally discouraged within service orientation. And because services do not formally implement each other, they are not required to establish "is-a" relationships.

The fact that WSDL 2.0 actually supports interface inheritance could actually backfire because a service's dependency on the interface is a form of tight coupling that reduces service autonomy.

Thomas Erl p. 464 wrote:The closest thing to polymorphism that can be realized in support of service-orientation is the consistent functional expression of service contracts, as per the Standardized Service Contract principle. This typically results in in similar or identically named capabilities across numerous services. (The consistent use of standardized, verb-based, CRUD-style operations within entity services is an example of this.)

The fact that you are seeking to abstract or standardize service contracts based on Java (endpoint) interfaces is another cause for concern. This hints that you are intending to systematically create service contracts through Code-to-WSDL generation.

Thomas Erl pp. 174-175 wrote:However, many service contracts for Web Services in particular have been derived from existing solution logic. ... this dependency of the contract upon its underlying logic is referred to as contract-to-logic coupling. ... 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 the long-term evolution of the service. ... Services with contract-to-logic coupling will tend to have increased levels of technology, functional, and implementation coupling.

The problem with these negative forms of coupling is that it is much more likely that implementation details of your service will leak into your service contract:
  • contract-to-logic - i.e. details of your solution logic implementation
  • contract-to-functional - i.e. service capabilities specifically designed in support of a body of functionality that exists outside of the service boundary expose details of the solution implementation of that larger body of functionality
  • contract-to-implementation - i.e. details of your implementation environment (e.g. Java-isms appearing in the service contract)
  • contract-to-technology - use of non-industry standard communication technologies (e.g. RMI over IIOP, DCOM communication protocol, etc.)

  • This is problematic as this gives the service consumer an opportunity (or even forces it) to form dependencies on these leaked implementation details making future changes of these details inside the service difficult or even impossible. In the case of contract-to-technology or contract-to-implementation coupling it could even prevent a service consumer from using a service if it doesn't use the implementation environment and/or (non-industry standard) communication technology that the service is based on.

    The only form of service coupling that is encouraged is logic-to-contract coupling as it positions the service contract as a relatively independent part of the service architecture - this maximizes the freedom with which the service can be evolved over time. This is why contract first (WSDL-to-code) should always be preferred over contract last (Code-to-WSDL) development when an entire portfolio of services is developed.

    Creativity is allowing yourself to make mistakes; art is knowing which ones to keep. Keep this tiny ad:
    We need your help - Coderanch server fundraiser
      Bookmark Topic Watch Topic
    • New Topic