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 implementationcontract-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 functionalitycontract-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.
