I work for a company that as a software suite that include a Java-based JAX-WS web service backend and an ASP.NET presentation tier. A client requirement has led to the need to extend the WSDL interface (actually the referenced XML schema) so that this client can add additional properties to the complex types that make up the arguments for several web service methods. That also want the ability to configure these additional fields for presentation in the ASP.NET UI tier. An additional useful bit of information is that wsdl.exe-generated web service client proxies are compiled into the ASP.NET UI tier.

There are 2 main options that we're considering for the approach to implementing the service interface extension mechanism. 

1. Add a collection of name-value pairs to the existing core web service interface types, probably in a type that most web service argument and return complex types extend.  The ASP.NET UI tier would have service client proxies compiled to include this, so no deployment-time replacement of some compiled code in the UI tier would be necessary with this method. Dependency injection will be used to implement customer-specific business logic. 

2. Replace the stock web service endpoint (a simple wrapper for a POJO that implements business logic) with a new web service endpoint that uses the same method interfaces but argument and return complex types are replaced with customer-specific types that extend the original types. This new web service endpoint class could be generated by tools we would provide. The ASP.NET UI tier would not have service client proxies for this new service endpoint, so some effort would be expended on creating a mechanism for customers to generate custom client service proxies and add them to the UI tier at deployment time. Again, dependency injection will be used to implement customer-specific business logic. 

This is essentially a question of whether having strongly-typed service interfaces (WSDL/XSD) is important enough to justify the additional effort required in the user interface tier to deal with a changing service interface. I feel that the loosely typed extensibility mechanism feels hackish, and think that the self-documenting nature of a strongly-typed service interface is a desirable quality, but I'm having trouble justifying the costs to project stakeholders. Any opinions/advice on this?