Rants Tagged with “Web Services”
1 (Total Pages: 1/Total Results: 4)
After reading Rocky's blog about DataSets and Web Services, I am afraid that he is falling into the same trap that other's have (including the emminently qualified Tim Ewald) with respect to DataSets. DataSets work well in Web Services but not by default. As I mentioned in:
http://wildermuth.com/content.aspx?id=rantview&rantid=7
The reason I like DataSets across Web Services so much is simple. On my side of the interop wall, I can treat them like a set of data-centric objects. But when I expose them via Web Services, I can treat the entire DataSet as a document. I like doc-literal web services. The magic here lies in the fact that the schema of the DataSet can be simply described with XSD. In fact, for non-typed DataSets that can be described inline with WriteXmlSchema() (so it can be interpreted on the other side of the interop wall).
For typed DataSets it gets even better. An XSD is the source of Typed DataSets, so exposing your XSD to describe your 'document' is a natural way of doing things. In fact, if you're not using ?wsdl for your .NET web services (which you shouldn't!), you can refer to the .xsd to describe the types that your web service expose.
I am passionate about this because creating web services to banty around your business objects is fine, but seems wholly unnecessary. I hope I can get Rocky to see the light.
Addendum:
I love Sahil's discussion of this too:
http://dotnetjunkies.com/WebLog/sahilmalik/archive/2005/01/23/47832.aspx
When I first read the SOAP
specification I could not decide whether it was meant to be a replacement
for DCOM/RPC or whether it was a messaging protocol. I loved the fact that the
ligua franca of SOAP was XML. But at the same time, Section 5 supported
the RPC view of SOAP. Unfortunately this section seemed to just confuse the
issue between the RPC world and the document/literal world.
In a great MSDN
Article, Tim Ewald argues against support for Section 5 support. I guess I
haven't been keeping up, but I am excited to hear that Section 5 support is now
optional in SOAP 1.2 specification. Yeah...but will Section 5 really ever
die?
As I started playing with .NET's Web Services Framework some years back, I
was excited and dishearted at the same time. It supported doc/literal by
default, but it seemed to want to hide the fact we were using XML in any
fashion. How unfortunate.
Tim recently gave a great talk at the Web Services DevCon about this
very issue. Now Tim seems to want to go farther than I would (wanting to deal
with all SOAP messages as XML Streams), but I think he is on the right track.
Instead of creating .NET types (or Java Types for that matter) when defining Web
Services interfaces, I think we should be defining XML Schemas that define the
interface. This would allow us to remember we are dealing with XML without
having to intercept the XML streams directly. It seems to me that the more we
use XML as our Web Service Type System, interoperability between differnet
technologies (e.g. .NET on one end and Apache Axis on the other) becomes less
and less an issue. All the better if the XML documents are well known formats
(e.g. XBRL).
I just attended the second day of Chris Sells' and Tim Ewald's great Web Services DevCon East and had
a great time. Yasser Shohoud gave a
wonderful talk on "The Right Way to Build Web Services". He echoed something I
have been thinking of for some time. Sure, I didn't want to learn how to write
WSDL. At the same time I know that the WSDL that is generated by using the
'?wsdl' syntax of ASP.NET's .asmx files does not let me design the interface
first. I changed my mind and learned to write WSDL. WSDL really isn't too
difficult to write. It is too bad that we cannot disable the ?wsdl syntax and
just use a static WebService.WSDL URL to have our customer's get our WSDL
files.
My natural inclination is still influenced by my days developing COM
components in ATL. I want to define the interface up front like we did with IDL.
In the early days of ATL, I had been doing MFC work and did not want to
hand-code my own IDL either. You would think I would have learned by now that by
starting with interface is the better development model. By writing our own WSDL
we can define our interfaces (both the calling convention and the schema of the
message) and run WSDL.exe to build a skeleton class for us to implement the
service.
Unfortunately .NET just makes it much too simple to annotate the Web
Service's methods with [WebMethod] and let the XML Serialization do all the
rest. I am hoping we all remember the heartache we suffered the first time we
did this in Visual Basic or MFC back in the COM days.
In the end .NET will allow me to get most of the way, I just think those of
us who believe that this is the way to develop Web Services would get on our
SOAP (sic) boxes and yell a bit louder about this.
Why is everyone so down on using DataSets in .NET Web Services? Sure, I’ll
admit that using DataSets directly as Web Service parameters are indeed a
problem. But why throw the baby out with the bath water?
For the uninitiated, DataSets are a problem as Web Service parameters because
XML that is automatically generated as the parameter is a DiffGram of the
DataSet. Unfortunately DiffGrams are simply not interop-friendly. At the end of
the day the obvious use of DataSets in .NET Web Services are simply a bad idea.
But if we deal with DataSets as XML instead of a class to be serialized we
can actually achieve some real benefits. If you have experienced DataSets, you
know that you can specify an .xsd as the schema of the DataSet. What that means
is that you can deliver the contents of the DataSet with relevant schema as an
XML document. Since the resulting XML document can refer to a specific schema,
the consumers of the Web Service (whether they are using Java, WebSphere, or
.NET) will receive a self-describing, strongly typed piece of information.
But how does this work? The trick is wrapping your DataSet in an
XmlDataDocument. By specifying your Web Service method like so:
[WebMethod]
public XmlDocument GetAllTheData()
{
return new XmlDataDocument(yourDataSet);
}
This works because the XmlDataDocument derives from XmlDocument so that the
XmlSerializer serializes it as an XML document. Whether the 'yourDataSet' field
is a TypedDataSet or just a DataSet with an .xsd specified for its schema, the
Web Service will export it as vanilla XML that can be consumed by any number of
clients.
