how to return xml document from a web service

[R.A.]

Hi,

I have an web service method that accept an xml document and returns a
different xml document.

Based on the input xml I fill a dataset with information from a database.
If the dataset has rows then I need to return those rows to the consumer.
I can't tell if the consumer of the web service will use .Net or maybe java.
1) If the web service method returns a Dataset then the consumer will get
information on the Dataset. What if the consumer has no knowledge what a
Dataset is at all (for example jave)? I know that the datase is returned in
xml represantation - but how will the consumer deal with the data to extract
the rows returned by the dataset?
2) For resone explained in section 1, I chose to return an xml document.
When I use the dataset.writexml (...) it writes only thetables rows
information and doesn't write the xml header. Am I to use XmlDocument to
construct the xml and write to it the datase and then send it as a string
back to the consumer? How can I tell the consumer where is the xsd for this
xml document?
3) How do I pass an XmlDocument to a web service method?

Which of the following will best fit the web service consumer?

XmlDocument webservice method (XmlDocument my xml)
XmlDocument webservice method (string my xml)
Dataset webservice method (Dataset my xml)
Dataset webservice method (string my xml)
string webservice method (XmlDocument my xml)
string webservice method (string my xml)


Thanks

 

[Dan Rogers]

Hi,

One thing to think about is separating the way you think about programming
methods from the wire transport. Specifically, the strongly typed XML
document governed by a schema is something that is readily mapped to the
wire. Working with XML as the data type in your method calls, however is
not only unnecessary, but difficult and error prone.

The easiest way to return well formed XML documents on the wire is to make
a class on the ASP.NET side (or CLR side) and then take those class types
as input arguments, and return classes as output types. Inside of your web
method, feel free to implement your data access logic any way you want, but
in the case of repeating elements, simply copy these to arrays or
collections that are contained within your return class instances.

An easy way to do this is to define your interface in schema first. This
way you can quickly drive agreement as to what the on the wire contract
needs to look like. If you are careful to follow cross-platform guidelines
such as those published in the WS-I.org basic profile, your .NET types will
readily map to the on the wire XML types, and then be easily consumed by
other tool sets, be they Java, PERL, or other language based.

Tools are then your friend for translating the schema contract into .NET
implementations. Tools such as XSD.exe, XsdObjectGen.exe or a number of
third party commercial tools that work with Visual Studio.NET help you take
the schema defined contracts and create class implementations that readily
and reliably transofrm to the correct XML on the wire.

Another great way to start is to simply deinfe your types as compound
classes - and limit your member types to known cross platform capable data
types (DataSet is not one of them). The trick is to avoid types that are
not found in the intersection of the types supported natively in your
favorite tools. or instance, in the set of Java, XSD XML Schema) and java,
restricting your data definitions to fields of types ( dateTime, double,
float, int, enum and string, and avoiding schema constucts such as
nillable, union, unnamed groups) and building your compound types form
these (yes, repeating elements that contain these types are allowed) - you
assure an automatic mapping between tools such as Visual Studio.NET and
java tools such as Systinet, BEA and Websphere. A rule of thumb to
consider is to avoid hand coding XML - this is error prone and requires a
great deal of testing and rework to get right if all parties involved have
to verify their implementations. For schema, a good rule of thumb is that
if you can define it simply versus with some complex but cool schema
construct, side towards the simple an inelegant approach - these have
broader tool support.

I hope this helps

Dan Rogers
Microsoft Corporation
--------------------

 

[R.A.]

Thanks for the information.

I was thinking on the following web method

string MyWebMethod (string inputXml)
{
validate the inputXml against a schema
process the information
return outputXml
}

Both consumer and provider have to validate the xml they recieve with the
same schema located at a known url.
Would that be a good approach? The schema contains simple data such as
string, int, dateTime


Thanks

 

[Keith Chadwick]

I am doing something similar and keeping it to strick xml, for fetching your
xml you can do something like the following (example in VB)

public function fetchData(byval parameter1 as string, byval otherparam as
string) as xmldocument

dim xmlRsltDoc as New XmlDocument
' do your stuff
' if dealing with SQL server then use the for xml clause to get properly
formatted xml from your db
' populate your xml document
' your xml doc can have a pointer to a schema if you choose and should

return xmlRsltDoc

end function

As for passing a xml document into a web service I agree with the previous
post you need to be carefull with regards to the formatting of the xml
document. I would pass it down as string then place within a xmldocument
within your web service then do what you need to do.

Cheers

 

[Dan Rogers]

Hi,

What you are thinking is something that many start out doing. I don't
personally find it helpful for three reasons:

The first is a loose coupling concern. Since one cannot distinguish a
method signature from any other signature (string foo(string input)) - they
all look alike and you end up giving no guidance to the sender/caller as to
what specific XML you expect. This may seem advantageous at first, but you
will find that what people consider to be XML varies widely - and since you
then take on the responsibility for processing anything someone sends you,
it gets tough. $$$ for debugging is far more likely with this approach.
If you have a schema that defines what you expect, why not just declare the
return as being the proper class and input being a strongly typed list of
schema governed class definitions?

The second issue with this approach is that XML is not a string. Sure,
mapping characters that include angle brackets and slashes may seem to
appear like XML when printed, but you'll find that the character sets
supported by various languages/libraries string classes and the character
sets allowed/supported in XML are not 100% mapable. Better to use an
XMLNode as input or output in this case if you choose to work with raw XML
on the wire.

The third is stability. As a potentiall calling party, I am always
concerned when I see this kind of interface - there is no version
management possible with this interface, so what do I have to guarantee
that a change in the service implementation over time won't make my
perfectly valid XML stream (mapped to strings) usable if you change what
schema classes you expect?

Think about defining your message set in WSDL to remedy these issues, and
specify the methods you expect to provide by referencing strongly defined
message types that directly reference schema. There are tools out there
(such as WSDL.exe) that can help you take a set of XML definitions and
create web service implementations in ASP.NET - and hand coding a WSDL to
define your contract definition isn't an unusual starting approach.

As for wanting to validate against a schema, you can use a Web Service
Extension to easily put a DOM based or XmlValidatingReader in front of the
methods you are exposing. The advantage of this approach is that it is
modular, lets you turn the validation on and off, and still doesn't make
the interface so loose that you can't derive what you expect from the
method signature.

I hope this helps

Dan
--------------------