Pragmatic Software Design

Posted an episode on the disadvantages of pursuing a code-first approach to building service capabilities at the reuse podcast series:


Download file

Episode Highlights:
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:

1. 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.
2. 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.
3. This approach also challenges the provider's ability to honor SLA policy requirements such as authentication/encryption etc.
4. 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
5. 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!