If I had six hours to chop down a tree, I d spend the first four sharpening the axe.
Java, a technology created by Sun Microsystems, should be the ideal partner for Web services. In addition to having much in common, they complement each other. One could even say that they are synergistic. One could go on to claim that Java applets were a kind of precursor to today s XML Web services. It is worth noting that Java applets are defined as being small applications that are delivered over the Web. The similarity of this definition to the one for Web services is inescapable and irresistible. But there are also some obvious and fundamental differences between these two highly Web-centric methodologies.
Java applet methodology, which predates XML by 2 to 3 years , is not XML-based in any way or shape. On the other hand, applets, though they do not deal in HTML, are inextricably associated with HTML because they can be invoked via the HTML <applet> tag. Java applets are a mechanism to add dynamism and flair to HTML Web pages. In this context, there is also an interesting and profound difference as to what actually gets delivered across the Web in the case of these two methodologies. With Java applets, the actual and complete Java mini-application is delivered to the invoker of the applet, which typically is an HTML Web page being rendered by a Web browser. The applet will then be executed within the Web browser s Java Virtual Machine (JVM).
In marked contrast to applets, Web services use the remote execution model. The application software is not sent to the invoker. Instead, the invoker gets back the results of the remotely executed Web service. Despite these basic differences, one should be able to readily perceive and appreciate the commonality of the motives involved. Both of these methodologies set out to exploit the Web as an unparalleled and universal mechanism for delivering application functionality in an object-oriented manner. Object orientation is another big and important feature that Java and Web services have in common. Just as object-based modularity is a defining attribute of Web services, Java is innately object oriented.
The other major attribute that they are said to have in common is platform independence. There is, however, a beguiling but key difference as to the connotation of platform independence in relation of these two methodologies ”and ironically it is this discrepancy in meaning that makes Java so important and enticing when it comes to Web services. In the context of Web services, platform independence, as discussed in Chapters 1 and 3, means that Web services are not specific to a particular platform (or for that matter programming language). Web services can be implemented on any platform, and Web services running on any platform can be readily invoked and exploited by applications running on any platform. But Web services “ related platform independence does not mean that Web services are portable across platforms. This lack of portability is the crux of the issue here.
A Web service, unless it is written in C, C++, or Java, will typically be restricted to a particular platform ”for example, Windows, an IBM mainframe running MVS, an AS/400 with OS/400, or a Sun server running Solaris. Let s start off by looking at Web services developed with any of Microsoft s popular software development tools, such as the current flagship offering, Microsoft Visual Studio .NET 2003. As shown in Chapter 3, software developed with such Microsoft tools, including all of those that fall under the .NET umbrella, can be deployed only (per Microsoft) on Windows platforms.
A similar platform dependency would also be true if one wrote a Web service in PL/I to run on an IBM mainframe or in RPG to run on an AS/ 400. Though one could persuasively argue that any piece of software, given enough effort, could be reengineered to work on any platform, the rub, as ever, is the exact scope of the effort, both in terms of time and money. Software ports, as anybody who has been involved with them will testify, usually with a shudder, are never as straightforward as they first appear.
Even C and C++ applications are portable only at the source-code level. They need to be compiled and linked on each new platform that they need to be executed upon. Software written in Java, in marked contrast, is portable across all of today s popular computing platforms in compiled binary form (i.e., in object-code form) as well as in source-code form. Hence, Java s famous, trademark catchphrase: write once, run anywhere . With Java, platform independence does mean bona fide, cross-platform software portability.
Hence, a Web service developed in Java could in theory be effortlessly moved from one platform to another without any need for recompilation, let alone any rework of the code. This portability is the key value proposition vis--vis Java and Web services, though some would rightly point out that such portability, though invariably assured, may in some cases still require some amount of tweaking, not to mention diligent testing. Figure 6.1 sets out to highlight how platform independence in the case of Web services is markedly different from what Java means by that expression, and why Java s flavor of platform independence can be very important when considering the use of Web services for mission-critical, enterprise-class application scenarios.
Ensuring that one has the option of being able to readily port enterprise-class, production-level software from one platform to another is no longer a frivolous indulgence or an uncalled-for affectation. It can actually be advantageous for career advancement. The dynamics, politics, economies, and viability of enterprise computing platforms are in a state of unprecedented flux. The remorseless, unending security attacks on Windows, prompted by the steady stream of software holes being routinely discovered in Windows software, including in the supposedly trustworthy Windows Server 2003, persist in undermining the credibility of Windows as a true, enterprise-class platform for any mission-critical-related applications. At the same time, partly in response, the popularity of and acclaim for Linux continues to grow, with Sun now promoting a Java/Linux-based desktop and Office alternative to Windows. The fundamental economics of the hardware platforms are also changing ”markedly for the better.
Thanks to the vicious battle for market leadership between Sun and IBM, the pricing of UNIX servers, across the board from the utilitarian low end to the ultra -sophisticated high end, is in a steep downward spiral. From a true, total cost of ownership standpoint, especially when one factors in the potential lost opportunity costs of security breaches or system crashes, today s UNIX servers stack up extremely favorably against multiprocessor WinTel platforms. Mainframes and AS/400s (now referred to as iSeries machines) are also more affordable and cost competitive than ever before. Moreover, true to IBM s unstinted commitment to Linux, these proven, mission-critical servers support Linux, as well as Java, alongside the proprietary operating systems. In reality, if an enterprise has a need for a large number of Linux servers, then one of IBM s new mainframes (e.g., z800) might in practice be the optimum solution. Given these dynamics, not striving for software portability, especially in the realm of Web services, could prove to be short-sighted and career limiting.
The bottom line here is that a Web service s security, scalability, performance, and availability characteristics can be profoundly impacted by the platform on which it is running, as was discussed at length in Chapter 3 relative to Web services that might be deployed on Windows servers. Given this, there will be many scenarios in which an enterprise wishing to make use of a Web service from an external organization will want to have that Web service running on a particular platform. In some cases the enterprise may actually want to acquire the Web service and bring it in house so that it can run on a server of its choice, behind its firewall. Such attempts will be thwarted by platform-specific Web services. Hence, the motivation to have Java-based, cross-platform Web services.
Java, as patently testified by the java.sun.com URL for its home site, is not an industry standard in the conventional sense. Sun, at least for the time being, controls the Java specification and the Java trademarks, including the well-known steaming cup of coffee logo and administers compliance testing. In December 1999, Sun somewhat surprisingly backed away from its previous work to make Java, or to be more precise, Java 2, into a genuine, vendor-neutral standard in conjunction with the European Computer Manufacturers Association (ECMA) ”a recognized and respected standards body in Europe.
Despite Sun s ongoing stewardship of Java, it is still accepted by a very large segment of the computer industry, including the influential open-software advocate, the Apache Software Foundation, as a de facto industry standard. To be fair to Sun, it does have an egalitarian, open -to-all, low-cost (i.e., free for individuals) mechanism known as the Java Community Process (JCP), whereby developers and Java licensees can participate in the evolution of Java. Visit http://jcp.org/en/home/index for details on the JCP. In addition, though many think of enterprise Java in terms of high-profile Java application servers such as IBM s WebSphere, BEA s WebLogic, Oracle s 9i, and Sun s ONE, there are at least two mature, no-cost, widely used, open-source Java application servers: Apache s Tomcat and JBoss. In addition, and to afford further legitimacy to this Java freeware concept, Sun provides an entry-level version of its Sun ONE Application Server 7, known as the platform edition, for free in parallel to the no-cost Java reference implementations available from java.sun.com. Thus, in effect, Java is to application development and deployment what Linux is to operating systems.
So all in all, though Java is not a true standard, it certainly acts and quacks like one. Consequently, those who endorse and actually license Java technology from Sun read like the Who s Who of the computer industry ”with Microsoft being the one conspicuous, but obvious, exception. The major industry luminaries that are actively behind Java include IBM, Oracle, SAP, BEA, H-P, Borland, Macromedia, NEC, Nokia, Hitachi, and Fujitsu. Given this huge backing, Java is obviously a credible, worthy, and formidable competitor to Microsoft s .NET. Figure 6.2 shows how the significance of Java as a server-side IT technology has a direct correlation to a company s size .
When it comes to Java and Web services, the battle lines in relation to .NET get drawn along these lines:
Cross-platform portability against Windows-specific solutions
Open standards versus proprietary
No danger of vendor lock-in (given that Java solutions are available from multiple sources) as opposed to being always dependent on Microsoft
Free (e.g., Tomcat, JBoss, or Sun s ONE 7 platform edition on a Linux server) versus the inevitable cost of a Microsoft server solution
Industrial strength as opposed to departmental
UNIX (as in Sun) against Windows
IBM against Microsoft
Resource hog versus lean and mean
Good for selling more hardware against scalability
Microsoft versus the rest