3.2. The Internet
C evolved
from a systems language built to create operating systems. It's a systems
programming language. C, and the C++ follow-up language, didn't creep into the
enterprise until later. Unlike C++, a very early target for Java was mobile
computing, and it evolved very quickly to encompass Internet applications for the
enterprise. You can easily see Sun's intentions in four primary places:
Java included convenience features to make applications programming
easier. Java added garbage collection and memory management, so
application developers wouldn't have to deal with these issues. Java included
first-class strings, so the platform, rather than the programmer, could deal
with moving the individual bytes around. A systems language might want
more control.
Java's vision for enterprise computing was centered on the Internet. Java
built in several libraries that greatly simplified enterprise computing and the
growing language always kept the Internet as a central focus. Early APIs
enabled everything from communications protocols like TCP/IP sockets to
the applet framework that allowed embedded applications in a browser.
Java's fathers keenly moved to improve simplicity, at the price of low-level
flexibility. For example, though C++ could touch any byte in the system,
they knew that the C++ applications community struggled with pointer
arithmetic.
Very early, Java was targeted at mobile applications , but Sun saw an
opportunity to topple Microsoft. Sun took the opportunity, extending the
primary focus of Java into the Internet.
Remember this: client/server computing made it very difficult to deploy
applications. Thousands of Windows clients, and a di
For whatever reason, applets faded into the background. But Java is a surprisingly
nimble beast, at times. In the halls of Netscape, server-side Java emerged. Servlets
(a term originally coined by O'Reilly) made server-driven Internet applications
available to application developers. Sun capitalized on this movement quickly with
a standard, and an open source implementation of a servlet engine called Tomcat .
Servlets solved many of the problems of CGI-based applications, and enterprise
developers had a new way to deliver applications to a desktop. The vision of an
application in a browser remained, but the view logic had moved from client to
server.
The server would build dynamic content and serve it to the client. Ironically, this
"new" model was little more than a glorified green screen that you might find on a
mainframe terminal or emulator. It did have some important subtle advantages:
While green screens were stodgy and old, the Internet was cool and new.
Users knew how to use them because they had the Internet at home. They
liked to use the new systems as much as developers liked to build them.
Browsers lacked the raw productivity of keyboard-driven interfaces, but it
was much easier to train users on them. The user interfaces provided several
subtle enhancements, like navigating through links instead of typing menu
choices.
The server-
side development environments were much more productive than
their mainframe counterparts. Development environments, often Windows
clients, were much cheaper.
Java's client-side development stagnated. Swing has long been criticized for
providing a poor user experience, but the real limitations lie in the learning curves
and ultimately the productivity of developers that must grab it by the throat and
shake to merely coax a minimal application out of it.
But Java's emphasis quickly moved wholly to the server side, where it remains
today. Java Server Pages (JSP) continued the evolution, making it easier for
traditional designers to play a role in the development of web applications. More
As the emphasis in Java shifted from the client to the server (Figure 3-2),
enterprise integration became more important. Here, the partnership of IBM,
Oracle, BEA, Borland, Sun, and others paid huge dividends. They enabled Java
connectivity to databases, transaction engines, messaging systems, and any other
enterprise system that required a Java connection. The combination of vendor
cooperation and support drove cooperation in standards and proliferation of useful
connectors that we've never seen before. Java proved to be a good integration
platform. Because of the backing of all the heavyweights, Java also became a very
safe solution.
Figure 3-2. Java's focus shifted from the client to the server over time
[*][*]
Dates taken from "The Java Platform, Five Years in Review";
© 1994-2005 Sun
Microsystems, Inc.
Java remains a good language for enterprise integration projects, because of the
high number of frameworks that solve so many of the critical problems, like
distributed transaction processing. Static typing is much more important for
problems on a massive scale, since such problems are harder to test, bugs become
more expensive. Relative to C++, in this space, the speed of authoring is more
important than the speed of execution, because most execution time is spent inside
of the various enterprise transaction, database, and networking libraries.
3.3.1. Moving Forward
Today, Java can talk to just about any enterprise system that's important to you.
Beyond integration, Java now provides excellent facilities for mapping object-
oriented models to relational databases. You can do distributed coordination of
transactions, and manage massive messaging systems with first-class rules engines
and workflow. You can reach beyond Java into C++ using a native wrapper called
member. Erik once kayaked with Bruce, barely living to tell the tale.
What do you
like best about
Java?
EH: It has lots of built-in capabilities and a
cornucopia of third-party (meaning open
source for me) libraries.
What don't you
like?
EH: I sympathize with newcomers to the Java
"platform." We all know Java the language is
pretty easy to grasp, and that makes it seem
like it won't be too hard, but in reality, you
cannot build even the most trivial utility in
Java without a pretty hefty learning curve.
CLASSPATH gets us all, for example; even
the "experts." To really do something useful
you have to learn tons moreAnt, servlet
containers, JMS, JDBC, and a zillion other
things. It scares me just to think of this
massive beast I've somehow spent the last five
years of my life on.
How does Java
hold you back?
EH: I don't feel held back with it personally,
but I often feel that it takes more time than it
should to accomplish a particular task.
What would
prompt (or did
prompt) you to