Hi jjouett!
This is the sort of thing that BizTalk does in it's sleep. Granted, it may
be overkill for your particular situation, so here's a bespoke way to do it.
Firstly, you need to decide exactly how different the schemas for the
incoming data are going to be. If they're vastly different, I'd advise
setting up your webservice to take the entire XML document in as a string.
From there, you would have some sort of logic to work out which schema the
document should conform to. You might be able to do this by IP or by making
the sender provide credentials to the webservice.
For each different schema, you'll need an XSLT to map back to your internal
schema.
Load the string into an XMLDocument and process to your internal schema
using the XSLT.
Unfortunately, by using this method, you're losing a lot of your type-safety
as the WSDL won't reflect the underlying datatype requirements (due to the
xml being received as a string).
HTH,
Adam
--
Adam May
Sydney, Australia
MCSD.Net
"jjouett" wrote:
We are starting to setup some Web Services to provide our customers
with a way to programatically interact with our application, and some
of our customers have slightly different requirements in the structure,
format, and representation of the results for common requests. Of
course, we have to comply with their formats, but it seems to be a bit
of overkill to have multiple implementation methods and/or data objects
that represent the different data representation needs when the data
content itself is the same. Is there a standard approach in .NET Web
Services to provide multiple client-facing web service methods that
(somehow) internally map to a single data representation and
implementation method using XSLT or something? If not, is there a
pattern to follow that would hopefully reduce some of the duplication
of effort and error-prone code in mapping different data object
representations ?
Thanks in advance
