The metadata page provides an endpoint “/metadata?xsd=1” to expose all custom types(operations+types within ServiceModel project/dll).
which is the easiest way to add in the metadata page dynamic/runtime endpoint(s) returning only (a set of) types (for example with no operations) or, even better, one for any specific type?
The metadata page doesn’t support this but you can try creating a custom Service that returns the XSD string in XsdUtils.GetXsd(operationType).
that works perfectly!
Now I noticed an unexpected behavior:
if I use different ns for different types using the DataContract Name Attribute and those types have been used within a given operation, the “/metadata?xsd=1” endpoint will not contains the schema for those types, only the import node with the correct ns.Instead if I use a single ns for all operations and types, types will be included as expected.
The wsdl instead contains the definition of all those types among with the operations.
Everything at runtime works, also using SOAPUI.
I wonder why those types are missing form the “/metadata?xsd=1” enpoint output.
I’d strongly recommend that all DTO’s share a single xml namespace. I’d say the issue is that .NET’s XsdDataContractExporter being used to generate the XSD’s are not grouping them in the same schema set, do these types appear when you use a different number, e.g /metadata?xsd=3
Yes I read about the single ns rule. So I did for operations. Types are provided by our customer, they want to use their ns. From a logical point of view makes sense: the service has its own version(reflected by operations ns) while types (biz entiies) have a separate versionig(ns). A service may evolves due to operation changes while the types remain the same.
What do you think about it?
I’ll try to check the extra numbers supplied through the xsd qs parameter.
I’ll do extra check, but it seems soapui and “vs add service reference” both work as long as operations are in the same ns also if types are not.
I’d treat XML namespaces as an invisible implementation detail and stick to a single namespace. Maintaining multiple XML namespaces is the kind of unnecessary artificial complexity why SOAP/WSDL/XSD is failing against simpler formats like JSON, i.e. additional effort that adds unnecessary complexity/institutional knowledge, friction, brittleness, potential failure points for no additional value.
I’d strive to keep clean models that can be easily translated into and from a programming language type system (i.e. without additional annotations/manual parsing/translation mapping/etc) and avoid any unnecessary effort/friction/failures.
I understand your point and, generally speaking I agree too, but the question here is about a customer request to have the service exposing types with different ns. What could be the consequence of that? Which kind of issue I’m going through?
Changing namespaces causes runtime exceptions (hard to find interop issues), it could also break client proxy generation. I’ve avoided using multiple XML namespaces back for reasons above since 2008 so they’re ultimately untested and highly discouraged.
Thanks a lot to clarify it. Do you have any links/reference/case study that I can share with our customers in case they still have doubts?
BTW I use the a global custom ns for all custom types sa you suggest in the Wiki. But all my response dtos are implementing IHaveResponseStatus so SS ResponseStatus type will be used among my types: that lead to have an additional type/ns. Is that in conflict with your rule “all dtos should share same ns”?
No I don’t have any case studies against XML namespaces - I’ve previously listed some general disadvantages of SOAP from my interview on InfoQ.
Ideally you’d just stick with the ServiceStack XML namespace, but you can change the XML Namespace used by setting Config.WsdlServiceNamespace which will do a string replace of ServiceStack’s XML namespace with the one provided in the generated WSDL.