Pacific Connection(英語)

Big Blue Sips Java From a Big Cup

Which company has more than 3,000 developers working full time on Java? And a full suite of Java applications? And an ongoing effort in Japan to speed Java execution? And has ported the Java virtual machine to more platforms than anyone else? And is working with some 300 universities to get Java courses on the books?

IBM may not be the first company that comes to mind when you think about Java, but "Big Blue" has embraced that language with an enthusiasm and R&D investment that few companies can match. IBM was one of the first to license Java technology and has since ported it to everything from web servers on up to minicomputers and mainframes. The company has put most of its efforts not into applets but into running Java on servers. While that's not what James Gosling and company had in mind when Sun first developed the language, the strategy makes sense for a company with so many hardware architectures. For IBM, Java has become that Holy Grail of development environments, a language that theoretically frees programmers from concerns over operating systems and processor architecture. The company has thus accepted as a tenet of religious faith Sun's Java mantra: "Write once, run anywhere." For IBM, anywhere means on an NT server, on an AIX, Solaris, or other UNIX environment, on mid-range systems like the AS/400, or even on a System 390 mainframe. To make this happen, IBM has worked hard to develop Java Virtual Machines, just-in-time compiler technology, and direct execution technology across its platforms.

"Java has fundamentally transformed the way we think about our software portfolio by providing a uniform programming model for application development," said Jason Woodard, product manager for Java Technical Marketing at IBM. "IBM was one of the first companies to recognize the potential of Java technology on the server. We were one of the first licensees of Java. We adopted it when it was primarily thought of as a client-based environment. And of course, it is still an important client technology, both in the context of browsers and for thin client architectures. But it was a couple of years ago that we started working on Java servlets and Enterprise JavaBeans as a way of writing core business logic across application servers."

IBM uses the term "E-business" (which it claims to have invented) to describe the breadth of applications Java can produce. The term broadly refers to any application that runs a business in a distributed environment. Areas of focus include managing the supply chain that tracks products from manufacturer to distributor to retailer, as well as customer relationship management--the business of keeping customers happy when the customer representative is not a person, but a machine.

A virtual Java laboratory

IBM's work in Java is widespread, with work done at three U.S. locations, in Austin, Texas; Raleigh, North Carolina (an area known as the Research Triangle); and Toronto. The company does Java compiler optimization work in Tokyo and Virtual Machine development at its Java Technology Center in Hursley, England. IBM also has a satellite group in Cupertino, Calif., that works directly with Sun and other Silicon Valley partners. "Software development at IBM is a great virtual organization," said Woodard. He himself lives in New York, with a virtual office in California

IBM begins its Java development the way everybody else does, by licensing the base Java Development Kit from Sun and taking on the hardware vendors' role of porting the Java Virtual Machine to its platforms--work done in the Hursley laboratory. IBM offers its own application development environment, called VisualAge, with an emphasis on enterprise application, as well as its own Java application server, WebSphere, which comes bundled with three software configurations. IBM has also put its JDK-like Java compiler, Jikes, into the public domain, as well as the source code.

IBM also collaborated with Sun on Enterprise JavaBean (EJB), which provides a component model for developing transactional applications. The API includes the core common business objects--invoices, customers, packages, order forms--that tend to be re-implemented from one application to another.

"For example, a bank might incorporate an EJB that acts as a teller," said Woodard. "Whenever you click on the web site or stick your bank card into a slot, a teller bean is kicked off that's analogous to your session, with another set of beans analogous to account objects." The teller bean pulls up a customer's account by instantiating an account bean with his name in it. "The magic of this approach is that the application server takes care of figuring out what that bean is, what its properties are, and how to retrieve it. At the object level it takes care of handling your request for retrieving $200 out of an automatic teller machine, making sure that the money in fact was paid out and that the transaction was credited to your account. That is, either the transaction happened and your account is updated, or the transaction was aborted and your account is not updated."

Woodard points out that coordinating these kind of cause-and-effect transactions are a fundamental requirement for enterprise systems. And IBM has done a lot of that. The company's high end WebSphere enterprise product is used in more than 50 percent of web-based brokerage transactions on the Internet, with customers including Fidelity and Charles Schwab. Woodard says IBM has a lot of experience with its hardware handling an estimated 20 billion transactions a day.

IBM is also working on a number of vertical components for specific business applications. One effort, called the San Francisco Project, will create components like order, inventory, and warehouse management software that vendors can use to create vertical business applications. "These are applications smaller than say, a Peoplesoft, and are targeted to specific markets. The components give our partners the ability to customize their applications extremely rapidly. For example, we have components that provide double-byte character support, as well as currency conversion into yen." Woodard claims that this component effort has reduced development time by 40 to 50 percent.

Customer examples scarce

While IBM's Java push is ongoing on several fronts, actual applications showing the full potential of IBM's Java framework are harder to find. Woodard named three banks: PMC Bank in the U.S , Canadian Imperial, and Banco de Brasil, as well as Electric Boat, a division of General Dynamics, which is using Java on the plant floor for processing work orders. "The first phase of implementation is to extend the existing process," said Woodard. "The next phase is to extend Java applications out to their suppliers, and eventually to customers. Ultimately the technology will fundamentally change the way they think about ship building because they can integrate their supply chain in a way they couldn't do with their existing application. It's not just a matter of wrappering existing applications, although that might be the first step. Java is a way of extending and changing the way you think about doing business."

The scarcity of referenceable customers that show the full extent of IBM's Java strategy is not surprising. Companies are loathe to tamper with basic infrastructure applications like order processing, figuring that if the system isn't broken, then don't fix it. "Out customers have beaten that principle into our heads," Woodard said.

Microsoft not amused

IBM's embrace of Java has inevitably added further strain to its relationship with Microsoft. The companies have already gone head to head over desktop and PC-server operating systems, with IBM's OS/2 losing out to Microsoft's Windows NT. Meanwhile, Microsoft has viewed Java and its run-anywhere philosophy as a direct threat to its Windows franchise. While Microsoft did a solid job integrating Java into its Visual Studio environment, the company has not supported the latest version of the language and its overall Java support is reportedly in doubt.

Given this friction, IBM's Java effort makes it a not-so-friendly hardware partner. In an October 1997 e-mail revealed during the Microsoft trial, Bill Gates wrote: ''Overall we will never have the same relationship with IBM that we have with Compaq, Dell and even HP because of their software ambitions. I could deal with this just fine if they weren't such rabid JAVA backers . . . We can't do public things with them when the whole IBM message seems to be 'JAVA will save the world. Do what SUN tells you and get rid of mainframes and everything else including Microsoft using JAVA.''

And while IBM's Java effort certainly puts the company in the Sun camp, thathasn't eliminated all friction between the those two companies either. Last year, Sun's Scott McNealy declared that there are three technology companies left in the computer world: Intel, Microsoft and Sun.'' John Swainson, general manager of one of IBM's software divisions, replied that IBM has more patents in a year than Sun has had in its history. And back in 1996 when McNealy first saw a Java demonstration, he wrote: ''Charge! Kill H-P, IBM, MSFT [Microsoft] and Apple all at once.'' Of course, e-mail thoughts are different than public ones and times do change. These days, McNealy would probably narrow his list down to two, sparing IBM and Apple from his virtual sword.

A Conversation with Jason Woodard, product manager, Java Technical Marketing at IBM

Jason Woodard is the technical lead for IBM's Java marketing team, the focal point for IBM's work on Enterprise JavaBeans technology and the man responsible for company's competitive positioning on Java issues. He helped develop IBM's first corporate website, as well as the site for the Atlanta Olympics Games. Before joining IBM, he was a technical associate at AT&T Bell Laboratories. Woodard holds a degree in technology and society from Princeton University.

Is Java going to be the language of choice for anything that pertains to IBM and business applications?
Absolutely. And we're not alone. Gartner Group is predicting that over 70 percent of enterprise development will take place in Java by the year 2002. Java has not only been one of the most rapidly adopted technologies in the history of IT, it has become completely central to the way companies are thinking about their application development.
What was the hole that Sun filled?
From a technical standpoint, there's not a lot that's fundamentally new in Java. Garbage collection, virtual machines and late binding have all been around for a long time. It's the particular combination of these technologies in the right place at the right time--or maybe since Sun was aiming for set top boxes, it was the wrong place at the right time--that catalyzed this wholesale adoption of the technology.
Aside from any technical superiority, Java has addressed one of the primary challenges of the enterprise business IT community, which is the spiraling costs of creating, maintaining and deploying applications. Java insulates the developer from a lot of the churn that happens underneath in operating systems and hardware platforms and application software. It has enabled companies to accelerate their move to the Internet.
Why has Java become IBM's universal language? Why not C++?
C++ certainly achieved widespread use. But C++ has a rather messy heritage with C because vendors didn't work to standardize on APIs across platforms. C++ may be a portable language in theory but it is not a coherent development environment in the way Java is. By "coherent," I mean I have some confidence that an application will be portable and interoperable in diverse environments.
Some complain Java's "write once" is a useful fiction, especially on some more obscure hardware environments.
"Write once, run anywhere" is a noble ideal. We are a lot closer to it than we've ever been, and it's certainly something we continue to strive for. We increasingly understand that Java's benefits in speeding time to market and reducing the cost of maintaining code are significant, whether you achieve 100 percent portability or not. So it's still the goal that drives the industry.
So Java applications are still easier to tweak than to rewrite from scratch?
Exactly. Any degree of reusability that you get is good. 99.44% pure is a whole lot better than impure.
Are you saying that reusability on the Java side is far better than reusability on the C++ side?
As a matter of practice, yes it is. With Java, you have a virtual machine that isolates you from the specific functionality of the hardware platform and operating system. Whereas with C++, you're writing directly to an operating system. For example, the Win32 interface is a C++ set of APIs. So unless you are going to port, effectively, all of Windows to another platform, you don't get any portability with C++.
You put a lot of emphasis on the server side. Do applets still have a place?
Applets definitely have a place, primarily in a thin client world.
Aren't thin clients another over-promised technology?
I agree, and am careful to use the term thin client in the architectural sense and not necessarily in a physical sense. You can run a thin client architecture over what are in fact fat windows clients. By developing applications that fit in browsers, you are achieving the benefits of thin client design for that application. Deployment costs drop to close to zero. The maintenance costs are low because your business logic is centered on the server where you have a fair degree of control. You get the benefits of this architecture without requiring you to realize Scott McNealy's or Larry Ellison's vision of a terminal--that is, a terminal that you can walk up to anywhere and slide a smart card into.
That said, IBM is the largest vendor of network computers. We sell them primarily in applications where you have single-function work going on.
So for IBM, the emphasis is less on the user interface, and more on back office processing?
Yes, and we're moving from a mode where you are just wrappering existing applications. That's an important thing to do, but we're seeing a lot of customers develop new business logic in Java. They are taking the applications that run their enterprise and writing them in such a way that they fit in this distributed architecture. The applications are written in Java and connected via the Internet.
If Java becomes the new business language, will its growth be slowed by a shortage of Java programmers?
There is a shortage in the sense that Java developers are highly in demand. IBM has worked with about 300 universities to help them get Java into their curriculum. We have an academic program, a speaker program, we send kits of materials, software, and we have a whole website dedicated to Java developers in schools.
What's the biggest stumbling block for experienced developers
C++ developers have an easier time, of course, because the syntax and command structure is similar. The biggest hurdle is in getting an object-oriented mind set. It's a bigger leap for Cobol and RBG developers--people with traditional functional programming skills.
Is Java a better distributed environment?
I think so because it was designed from the ground up with the Internet in mind, and it comes in a couple of flavors. One is the fact that it supports the Internet protocols out of the box--TCP/IP. To get an HTML page using HTTP is a one line piece of code in Java, whereas in C++ you'd be writing sockets and parsing stuff. Java is also a better distributed language because it has security built in. One of the fundamental design goals of the Java platform was to provide an environment where someone can run a piece of totally arbitrary untrusted code. This whole Java sandbox architecture, this whole virtual machine architecture was designed for that.
Is execution speed a problem, especially in transaction environments?
Java performance has improved by several orders of magnitude in the last couple of years. It is still something that keeps us up every night. We have our team in Tokyo working on this, and we've got a team in Haifa, Israel working on garbage collection. We have a team in our Watson Research Center working on some threading issues with Java, and a team in Austin [Texas] working on SMP scalability for Java. It's an area of intense focus.
With our customers, we are getting to the point where Java performance is no longer an inhibitor. That's our goal--to get Java to where it is good enough that it is no longer an issue. There's always going true that a language providing a higher level of abstraction is going to be slower in some absolute sense, the same way that C++ is slower in an absolute sense than C, which in turn is slower than assembler. You used to write little subroutines in assembler if you really needed the speed, but people rarely do that any more. And we're going to get to that point with Java, I believe.
Because hardware speed is unnecessary?
Right. Moore's Law will help us. [Moore's law holds that computation speed doubles every 18 months.]
What about Java in a distributed environment. Where does CORBA fit in?
IBM was one of the founders of the OMG [Object Management Group] and has been committed to CORBA technology from the start. There are similarities between distributed development in Java and distributed development in a CORBA-type environment using C++ or another language. One of the things that the Enterprise JavaBean specification does is provide for EJB components to communicate with each other over IIOP, the CORBA protocol for interoperability. When you have components that communicate over IIOP they are interoperable with each other. So you have Enterprise JavaBeans able to communicate with CORBA components in a distributed system.
What's nice about doing this in Java is that you don't have to worry about IDL or any kind of intermediate language to create these applications. You have very tight bindings between Java and all the CORBA infrastructure and the CORBA world. The application server itself is effectively the ORB [object request broker], which is an extremely powerful notion. It means that the complexity of writing distributed applications using the CORBA paradigm is greatly reduced, and yet you don't sacrifice the ability to interoperate with this world.
Are you implementing Jini?
We are looking very seriously at Jini technology. We do have an evaluation license of Jini, and it's something that we believe has a great deal of promise, particularly in the area of network devices. I think that we're going to see a lot of improvement in Jini in the sense of scalability and security, and there are a lot of areas that have yet to be flushed out in the Jini vision.
Microsoft maintains that NT will scale to become the enterprise operating system of choice. If NT runs anywhere, then Java doesn't have to.
That assertion runs counter to everything we see in our customer environments, which is that computing is fundamentally heterogeneous. Not only because customers have an installed base, but because there will always be a need to develop applications independent of the underlying hardware and operating systems. There's a real need to separate your development decision from your deployment decision. Today, NT is fundamentally dependent on the Intel architecture--hardware that is fundamentally dependent not scalable. Companies cannot afford to wait until NT grows up. They have to act now, and the way do that is to take the technologies that are out there--the hardware platforms and operating systems--that are scalable, that run their businesses today.