Middleware for the masses”? How about “open middleware”? (see “Scandalous
Propaganda” by Alan Williamson, Vol. 7, issue 1).
Business people are the biggest polluters of the English language, and
the phrase Web services continues that trend by confusing the World
Wide Web with the Internet. Web services has precious little to do with the
WWW as far as I can tell: the WWW is an application that runs on the Internet
(the “killer app” of the Internet if you will).
With the above points in mind, I would suggest “network objects”, or
“network object framework.” BTW, I enjoy your editorials. You’re able to
see the forest instead of just a lot of trees.
Let me thank you for your very kind e-mail. You’re right…Web services
has a mere foothold in HTTP and that’s only a small part of the story. While
“network objects” is a better name, it’s not as catchy as Web services and
to that end the marketing boys will flounder!
Great editorial. I’m from the old school – learned assembly, Cobol,
and then C. I’ve seen a great deal of change the past 20-plus years. Some
good, some not so good.
My e-mail was prompted by your comment: “At the end of day, as one poster
quite correctly pointed out, we didn’t consciously choose TCP/IP or HTTP.
We chose them because everyone else did. It was the beehive mentality with
respect to technology standards; we just swarmed to the most popular standard.”
I disagree. We may swarm but what makes it the most popular? I may be wrong,
but I think we swarm to what “works” and because it works, it becomes popular.
I think we’ve chased easier ways out at times – jumping for options
that promote code bloat and faster development. And Microsoft has dangled
the carrot in front – showing we can be deceived and/or bought by shiny widgets.
But we have to earn a living and if it means spending more time fixing something
we don’t have control over, eventually, we’ll see the error of our ways and
look for something that works.
True, development has taken on a bit of the VHS versus BETA mentality
due to the Microsoft marketing machine. I admit that I have played with VB,
but look at how it’s changed. I totally agree with your comments about Microsoft
trying to get anyone to think they can be a developer. Many people saw development
as a get rich quick option. But we (the real developers) are not all alike.
I know I’m not as good a developer as some of my past co-workers at WordPerfect
were, but I am much better than some.
Our software world is constantly changing. I don’t think a standard
will win because it’s popular but because it works, which makes it popular.
You and I both use Java. Why? It works.
XML Technology and Rich Browsers
I don’t completely agree with everything that John Zukowski and Vincent
Maciejewski said in their article “Rich User Interfaces” (Vol. 6, issue 12),
apart from the fact that yes, Java is better than HTML for UIs. Personally,
I think Java client-side technology development was ignored for far too long
The one advantage of using applets over JS/HTML is the write once, run
anywhere capabilities, and many of the same arguments for developing client-side
GUIs still use this. That applets could run in either of the two main browsers
(IE, NN) was the big advantage – you had to maintain only one piece of code.
Given that MS is determined to oust Java from its software, this advantage
has dwindled for client-side Java.
When Swing came along you couldn’t use it to develop applets as most
JVMs installed with browsers didn’t support Swing, that is, you couldn’t
leverage all the nice new widgets and were stuck with the boring, old AWT
widget set. The AWT widget set was hardly any richer than those provided
by HTML forms.
The main point is that given the current state of XML technology (XPATH,
SVG, XLINK, XSD, XSLT, XSL) and its future development (XForms/UXL, etc.),
I feel that Java applets are dead. Why? Because today’s browsers are more
standards-compliant and are becoming more capable of handling XML-based technology.
For example, XSD has the model of the data from which a rich browser should
be able to render the appropriate GUI. No need to transfer any GUI-rendering
code to the client as the client intelligently works out the GUI for itself.
Working with Ant
Kudos to Alan Williamson for his editorial (“Back to Work with Ant,”
Vol. 6, issue 12) about the efficiency of lightweight tools such as Ant and
text editors. To my chagrin I work with “gorilla” tools such as JBuilder
and the Rational Suite everyday. I worked with Ant on the last project and
will vouch for the increased productivity, especially for EJB development
where you’re typically utilizing an application server on your local workstation.
However, when attempting to champion this approach, I’m frequently asked
about debugging capabilities. I’ve used JDB in the past, but would admit
that a graphical debugger is very nice.