Summary
It's probably easier to ignore some of the mess behind us.
Advertisement
Web Services confuse me. I've been trying to wrap my head around the concept for a little while now and, as hard as I've tried, I still don't get it. It's not the technology mind you. I've built a couple of SOAP services that are in production. I like the idea that you and I can speak to each other without getting into long and arduous discussions about endianess, implementation languages and the like. What I'm having a hard time groking is all the stuff being piled atop what was a very simple and useful concept. Doing so seems to creating the perception that you can build whole systems like this.
It seems to me that we're in the process of crafting yet another technology that doesn't do a whole lot to advance the state of the practice of system development. As far as I can tell we're going to end up with a bunch of systems hooked together with stiff interfaces, communicating with a seriously inefficient syntax, and doing very little to make sure the systems behind these interfaces are any more reliable or cheaper to run. It's almost like we've agreed that we're going to use grounded plugs for everything (good) but we suffer from more or less routine blackouts (crashes), it costs $2000 per kilowatt (large IT staffs), and we have to take turn the generators on and off every night to clean out the kruft (nightly maintenance).
In addition to all of that I'm starting to hear rumblings of context free software again (remember Taligent?). RDF, ontology's, service discovery and semantic negotiation. Honestly, does anyone actually believe in a world where some chunk of code I write is going to look up a vendor of exotic chemicals, automatically negotiate terms of the purchase and place a $50k order? Without some human intervention? Do we really have to spend any real cycles on building what is in effect a personal shopper? Does anyone really expect the check signers to spend the very serious dollars it's going to take to craft useful abstractions which, in the end, removes the need for a phone call that everyone is going to make anyway?
Like I said, Web Services confuse me. I'm sure the proponents of all of these technologies could articulate incredibly compelling "if only" sorts of rationales. Maybe they would even make sense in some parallel universe. But if I look back and compare what I recall from then to what I see now, all I see are the same promises and world visions that have come and gone for decades. What I don't see is anyone looking back and noticing fat assed, incredibly coupled, unchohesive systems that are outrageously expensive to run and realizing we're not doing a great deal to address all of that.
Maybe we should take a break from looking forward. At least for awhile. Reduce our "technical debt" (love that term). Perhaps we'd end up having more fun in the end. Imagine how much easier it could be to get funding for a brand new, extremely cool project when the check signers didn't have to balance paying for that and paying huge sums just to keep the previous cool thing up and running.
<p>I do not understand why the SOAP stuff has to be so complicated. Looking ahead or behind, or down at your feet, I think that complicated or complex syntax things end up fading away.
<p>I see that Java is getting more and more popular and C++ less and less. I always thought C++ was a hard way to do something simple and never even pursued it much except to get a few open source programs to compile.</p>
<p>The markup languages html and xml are simple and still around as compared to sgml their complicated grandfather. </p>
<p>Do you reckon that SOAP will get wrapped up by something the average guy can program? Like java does with its xml parser engine? </p>
I do not understand why the SOAP stuff has to be so complicated. Looking ahead or behind, or down at your feet, I think that complicated or complex syntax things end up fading away.
I see that Java is getting more and more popular and C++ less and less. I always thought C++ was a hard way to do something simple and never even pursued it much except to get a few open source programs to compile.
The markup languages html and xml are simple and still around as compared to sgml their complicated grandfather.
Do you reckon that SOAP will get wrapped up by something the average guy can program? Like java does with its xml parser engine?
Consider this: many IT organizations have lots of internally deployed websites and VB programs with absolutely no API at all. I know this is a problem in tiny small businesses when they bring in contractors to write some code, the contractor keeps the source, and then someone else has to show up to add functionality and must scrape the screen and click the buttons programmatically. I know this happens in large corporations when one department controls a particular function and another wants to access it.
Web Services are just a new face for the UNIX idea that programs ought to be able to invoke other programs. The technical details are unfortunately overcomplex, the standards are bad and vague, and the details are overcomplicated. The important thing, though, is the cultural implication that developers sitting in VB.NET will by default be writing code that can be invoked and introspected by others, later.
You may think SOAP is overcomplex and grotty now, but if you are ever called in to help with a maintenance project where an entire business-critical function was put on a web page, the site was laid out using Fireworks and Dreamweaver, with automatic javascript and PHP code inserted for flavor, and there is no documentation, you would wish that you could at least invoke the thing without emulating IE 6/win. That is the power of SOAP.
I think soap is way complex. Please, just XML of http. But the idea of combining an application server and web server makes a lot of sense if you are doing web based stuff from the start.
We've always had application servers of some sort. We called them applications and built in threading models, async IO, event delivery etc.
Adding the web stuff is a win if you are doing web apps. Something like resin or tomcat are even somewhat useful if you aren't doing web stuff.
It'd be nice for once if the technology exceeded the hype instead of the hype exceeding the technology. There's a long list of good technologies that did not meet the expectations of hyped promises and that in turn affected the adoption of what might have been a decent new idea.
And the flip side, how many times do we ride the hype bell curve before we realize that dollars should be appropriated according to the realistic usefulness of the technology and not the recongized impact of the hype.
For what it is intended, Web services works well. On that note, I am curious if XSL is a sleeper technology that has avoided the hype bell curve? Should it be hyped more than it is?
Previous Topic
