Now - when I comsume this Web service I get access to all the classes within the project but in a limited context (only access to their default constructors). But, the only namespace that is returned by the schema in Studio .NET is the obvious namespace given to the Web service by Studio .NET when I register it as a Web reference. It doesn't carry any of the namespaces of the classes over to the consumer of the Web service.
1st Question: Is there any way to carry these namespaces over for ease of use by the consumer so that they can logically use this code?
2nd Question: Knowing that I need to carry these classes and complex types over to the consumer so they can deal with this data, is this the right way to go about coding this Web service.
NOTES ABOUT THE QUESTIONS:
A couple of notes that have been talked about on other forums:
1.) I read a number of books on Web services and not many provide in-depth analysis at complex data typed Web services. Any direction in reading would be helpful. Also, keep in mind that the data being passed is public and the authentication and authorization isn't a very big deal.
2.) I know that you shouldn't assume that the consumer will be using a certain type of language (i.e. .NET) to consume the service. But, since the output is well formed and I am happy with that, I will be reusing this service in a larger application many times over and building it in Studio.NET. The main reason I ask this is b/c I want to recreate these namespaces for logical reuse in my and other Studio .NET consumers' code.
3.) I have a feeling that the way to do this is using attributes to shape the output of the Web service call but I am not sure how.
Any help would be GREATLY appreciated!
When a Web method specifies complex data types for parameters and/or return values, these types are serialized as part of the SOAP request/response as appropriate. A client-side Web service proxy is generated from the WSDL contract for the service, and this proxy includes types generated from those described by XML schema. When invoking the service, the proxy uses these types to serialize parameters to each method, and deserialize return values.
These types are merely stateful objects that should be populated for serialization, thus only public members (exposed by the service) are exposed, and only the default constructor available. Any internal functionality of the type is not applicable to serialization between client and service.
Regarding namespaces, you may be confusing .NET namespaces that define logical organization of types, with XML namespaces. Complex types exposed by a Web method take on the XML namespace of the service by default, as identified by the WebServiceAttribute. The .NET component namespace of the type is unrelated to this XML serialization.
It is possible to customize serialization, including modifying the XML namespace or the schema definition for complex types. You can specify a unique namespace for each method using WebMethodAttribute. You can also apply XML attributes (such as XmlElementAttribute, XmlXmlElementAttribute) to each parameter and return type to control how elements are mapped to schema types, how they are named, among other specifics.
This was first published in May 2004