[...]
> Now, to clarify my disdain for Web Services and claim that
> they are inefficient. You said it yourself when you said,
> "...I fill a dataset and serialize it to the outgoing XML
> Data Stream". There is the single greatest problem with Web
> Services, IMO. XML. I'm sure you are aware of what a CPU hog
> it is to turn binary data into an XML text representation.
> Not only do you turn a few bytes of binary into many bytes of
> text, but you also add (by my experience) somewhere in the
> neighborhood of 80-90% overhead for tags. Also, you now have
> to parse back through that fat block of text to make binary
> sense of it once again. Now, given an existing binary data
> structure, why in the world would I work the hell out of my
> servers' CPUs to turn this into XML?
> Why would I not utilize the binary serialization built into
> the CLR and just write a custom dispatcher? That's exactly
> what we do now.
> We have a custom dispatcher that deserializes the
> binary-serialized parameters and passes them into the
> specified business object. The dispatcher is very simple
> and, once written, works everywhere.
I read this with a big smile on my face. It's exactly how I look
at the current implementation of webservices (which are nice idea
nonentheless, just not suitable for a lot of situations). XML is great
if you want interoperability between different type of systems since it
defines a general format for ascii based data which was in the old days
placed in text files in directories. However if you just have an
application sitting on 2 1U boxes in the same 19" rack, why on earth
would you set up the communication between the processes on both boxes
via xml? No-one wants SqlServer's TDS to be replaced by XML for the same
reason :)
Besides that, webservices in .NET are set up really bad. Here's
an example why I think that. Consider an object which is serializable to
XML using the SOAP formatter. However this is not what's going to happen
if you return such an object from a [WebMethod] marked method. Instead,
the XmlSerializer is first serializing the object to XML. This is done
using an utterly slow, FILE based approach. The XML constructed by
XmlSerializer is then serialized into SOAP. Do you want that? I don't
think a lot of webservice using people want that. A lot just want to
connect to the .NET webservice from their .NET client and choose
webservices over remoting because VS.NET makes it so 'easy' to develop a
webservice.
Now, if a webservice just would skip the XmlSerializer
alltogether and just would serialize the object into SOAP using the SOAP
formatter, IF you for example define that with a setting, it would
already be a lot better. However, now, the XmlSerializer is severily
broken (no cyclic references, no interface based member parameters etc.)
and implementing IXmlSerializable is not going to help due to hardcoded
codepaths in the XmlSerializer.
But it would be even better if VS.NET would have the same
support for raw remoting as it has for webservices. Then I think a lot
of people would opt for remoting over webservices, however now remoting
is something which seems to be 'low level' or 'too difficult', while it
would be the better choice for developers in a lot of situations.
> This is all just my view, of course. I see advantages to Web
> Services and XML, but I really think we need to think about
> appropriate application of these technologies rather than to
> jump on the bandwagon. IMO, the only problem Web Services
> solves is to provide a communication mechanism between
> disparate platforms. If you don't have disparate platforms
> communicating with your business components,
> *don't* use Web Services because all you're doing is
> introducing profitless overhead. Same goes for XML in my
> view. All too many developers these days are just throwing
> Web Services and XML into their apps and blindly believing
> that they are solving problems.
indeed. In fact, throwing in XML can create more problems due to
the often horrible code you have to write to interpret XML constructs or
when you write xml constructs. Example: the code to add a node like
this: <myNode attrib1="some value"
attrib2="someothervalue">lalala</myNode> is very complex and very
unusual. (create a node with a doc, however this doesn't add the node to
the doc, which requires yet another call etc.)
> I'm aware that MS touts Web Services as the next cure for
> world hunger. I'm well aware that they would have us move
> our middle tiers completely to Web Services. Respectfully, I
> think they're wrong.
the concept itself isn't wrong though. In fact, if you look at
the n-tier idea, an abstract definition for a tier which in fact
provides a service to the tier(s) on top of it, is realizable with a
webservice. Or better: via a 'service' somewhere on a reachable server.
Now, this 'service' can be implemented in various ways, and the only one
which gets a lot of airtime (and the proper tools unfortunately) is the
webservice. Which is of course sad.
FB
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
