james wrote: > I do not really understand how .Net web services are more complicated > and inefficient than COM+. In COM+ ADO I have to fully type cast a > Record Set to another Record set, which I check against the Business > Model again before passing to the caller as a referenced disconnected > record set. Not to mention that for every com app running I loose at > least 3 threads in the CPU Queue when nothing at all is happening.
> With .Net Web Services I fill a dataset and serialize it to the outgoing > XML Data Stream. For inbound messages I de-serialize the inbound XML First of all, James, let me define what I mean when I use the terms COM+ and Web Services. COM+ is a technology that allows me to package components together to be treated as a unit for the purposes of administration, role-based security application, transaction management and specification of activation and pooling methods. Web Services is a means for me to deploy an interface so that disparate platforms can communicate with my business functionality using an XML-based interface. I really came across in my last post as comparing the two. I'm not. What I did was to try to say that web services doesn't provide any of what I would use COM+ for. Later in the post I threw in a rant about why I really am not fond of Web Services. So, just to clarify, my point is that Web Services do not provide any of the tools that I mentioned as a definition of COM+. 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. 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. 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. -- Steve Johnson =================================== 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
