Just posted a new episode on the software reuse podcast series on specific design techniques when building reusable services for your SOA initiatives. This short audio episode covers building services code first – i.e. take existing components, implementations and expose them as service capabilities.
Most development environments provide tools for generating WSDL contracts using annotations or platform-specific tools. Existing classes can be easily exposed as service endpoints. Method signatures become web service operations and method parameters become service parameters. This saves time and effort for the immediate term.
From a service-orientation standpoint however, this approach has significant disadvantages:
- tools that enable contract generation out of the box often have the risk of introducing platform-specific attributes, service implementation semantics that inhibit interoperability and consequently the reuse potential.
- The implementation contract could also have identifiers (database primary key field for instance) or implementation specific attributes (connection parameter to a proprietary system) that will needlessly couple consumers with a specific implementation.
- This approach also challenges the provider’s ability to honor SLA policy requirements such as authentication/encryption etc.
- Service capabilities also run the risk of not reuse entity definitions – business data model entities that will effectively decouple the service contract with the implementation
- Adding to above is the risk of exposing inconsistent error handling, error messaging, error reporting that will be apparent to your consumers. Not to mention it makes it harder for the provider to support several different overlapping implementations!
The next episode will cover the rationale and advantages for pursuing a contract first approach. Enjoy!