Addressing Java's Challenges
Easier Development Tools
Phipps: To address the need for ease of development, we have seen vendors such as BEA turning almost into tools vendors. A couple of the companies at the table have set up open source initiatives. I've seen some companies claiming to have plug-in architectures. It seems to me that the diversity of approaches is going to stand in the way of ease of use.
Benfield: Our CEO was the founder of PowerSoft, so Silverstream can speak to that issue. Our target market is the typical business developer who looks at J2EE and can't understand it. Even the tools that have come out from some of the vendors around the table are geared toward making Java-centered developers' lives easier. For Java to explode to the level that we're talking about with Microsoft, it has to be made much easier.
But it's not just making the Java pieces easier; it's also making the higher-level business functionality easier—a development environment where I can program with Java but I can also do content and personalization. We see Web services enabling what we call massive integration. That means we're integrating many more systems, and because of the network effect, I need the ability to write these things ten times faster than I do today.
Shelton: We fundamentally agree. Borland has owned the ease-of-use story around development for longer than Microsoft has. In the Java community, this is a major focus of work for us. While Borland isn't a platform vendor, we stand in the middle of all of you to try to make sure the developer can develop applications that run on every one of your platform stacks. Our ambition is to bring J2EE to the masses—to help Java developers do their tasks more easily, but also to bring it to a larger audience.
The challenge for the industry is vendor initiatives that are stack-based, focused on proprietary lock-in around particular products and solutions. As an industry we need to be talking about open standards between us so that a company like Borland can build a set of tools that will allow customers to deploy to anybody's app server.
Chappell: The problem of providing productivity tools is not the biggest problem that needs to be solved. That's going to happen organically just as it always has. The market will decide what the best productivity tool will be. I think the biggest problem that needs to be solved is what's the fabric that connects all the end points together, not how do you build the end points.
Farrell: I think that tools are critical, and that this is where we lose to Microsoft. The people building the Microsoft tools don't care about the run time. They're out to win the tools market. They have wizards that make things easier for the mythical IT manager who sits down and builds an application in 15 minutes. To broaden the J2EE market, we need to make it simpler than we have with IDEs like JBuilder and JDeveloper. Standardizing on a tool will never happen, though. That's where everyone's distinct.
Shelton: The good news is that we've already standardized on tools. Gartner reported yesterday that two tools are used by 80 percent of all enterprise developers—half IBM and half Borland JBuilder.
Chappell: The trouble is, though, you have to get Microsoft in there somehow. You can't have a standard without them.
Farrell: What's more important are runtime standards, like the new JSRs [Java specification requests] from BEA and Sun for how you describe the metadata. Then it's up to the different vendors how to manipulate that. I don't think you can standardize on a tool, but we do have to standardize on the metadata.
Standards for Integration
Phipps: I wonder if it's the case that J2EE is so well defined that the only way forward for app servers in differentiating their products is to do things that either break the standard or lock in the customer. Is that the only way we're going to see a rich application-server market, or is there some other path forward?
Renaud: The bottom line—and this reasoning applies to Web services and to tools—is that we have to stick together. We have to make sure there are standard runtime environments that tools can target and standard programming models people can write to, be it EJBs or Java Web services. Standards have to remain at the center of everything. Application servers will see new functionality being added with things like portlets that go beyond the traditional role of the app server but become a sine qua non for application platforms moving forward.
Integration is another example, and again standards are going to cause the revolution. It's going to move to Web services, to JCA, and to whatever orchestration protocols get standardized by the W3C [World Wide Web Consortium] and the JCP [Java Community Process]. We'll see the vendors that have been able to offer compelling application platforms implement those standards in tools on top of those platforms. It's going to take a while, but there's no stopping the wave. It's going to be standards all the way.
Phipps: Is it bad news for the EAI [enterprise application integration] vendors?
Pepper: Maybe. They've been doing application integration in a proprietary way for a while. They're moving toward Web services integration, but application-server vendors and CORBA vendors have an advantage coming from a distributed-computing background. J2EE can't exist in isolation in some organizations; it has to become part of an integrated enterprise. For that, you need a single platform that can encompass many middleware technologies, provide unified messaging and transactional security, and be able to expose that as Web services that can integrate with other application assets. It's a big challenge.
Jespersen: EAI vendors in the past were characterized by a proprietary message bus, and then they had to go out and shop themselves to all the major application vendors and get them to create a proprietary adapter that would fit their message bus. JCA is one way of addressing that, but I think Web services will be much more widely adopted as the language used for integration. Some EAI vendors are going to have to find new lines of work.
McGovern: JCA doesn't have the bandwidth and the strength to be a strong integration solution. Web services will be very positive because it will allow different platforms to integrate easily. Why is Microsoft pushing .Net and Web services so hard? Because it's an easy way to get CIOs to play in the enterprise-level Java and Unix environments. I mean, what we should be doing is rejecting Web services if we want make it more difficult for Microsoft to deploy .Net into large enterprises. I'm joking of course.
Chappell: JCA and Web services are equally valid technologies for doing integration. They both have their place, and are gaining traction with the application vendors. JCA is great back-end technology that an application can use to plug into a J2EE-based infrastructure. Web services are really all about the interfaces across corporate borders and between technologies like .Net and J2EE.
The thing that is interesting is not just the technology, but the fact that it's going to change the business models of people that made all their money on custom adapters. New vendors will come into play. Existing packaged-app vendors will provide their own JCA adapters. That's going to significantly change the business model of this whole thing and drive the prices down.
Walicki: These technologies are not mutually exclusive. You're right that the pressure is on EAI vendors, but it's not going to be a binary switch. For a long time, we'll see a duality of technologies, especially when it comes to integrating with legacy and providing a robust, complete system.
Pepper: For customers like Boeing—with supply-chain integration with 75,000 suppliers and application integration across the company—JCA 1.0 as part of J2EE today doesn't cut it. They also can't wait for JCA 1.5 that's going to be part of J2EE 1.4, or JCA 2.0 that's going to be part of J2EE 1.5. This is where we differ with BEA. You can't just see these ERP [enterprise resource planning] programs as databases and use some sort of adapter to connect to them. You have to be able to do a much tighter integration with the back-end database. That's where EAI vendors will continue to have an advantage for the time being, until the Web services technology catches up with the ability to do a much tighter integration.
Renaud: I agree that JCA 1.0 isn't it, but 1.5 is getting closer and 2.0 will certainly be there. What's important is the standard. People can't afford to have custom-made adapters for everything. JCA, for all its limitations, is seeing a lot of adoption. We've seen PeopleSoft jump on board. Siebel is aggressively supporting it. SAP has stated that it would support it. That's a lot of momentum right there. In terms of timing, is it going to be one year or two years? I don't know, but what's important is that dynamic standardization in application integration is just inevitable.
Mitu: We see the same thing in terms of our customers pushing for standardization. JCA is one of the standards for which they look to us for tooling and support. However, it is true that standardization drives us toward commoditization and we make less money the more standard app servers are widely adopted. The challenge then is to innovate new technologies that add value on top of the standard base. You see it from all of us; there's a base offering that's built around the standards, and then we start having add-ons that enhance that value. Eventually, those add-ons are going to make it into standards.
Prospects for Interoperability
Phipps: This is described as the "standards elevator." Standardization doesn't lead to commoditization; it leads to faster innovation. Open source does the same thing. But there's still one vendor in the marketplace that chooses to innovate without sharing. I wonder how you believe the companies in the J2EE community should regard that. Should they interoperate? Should they stonewall?
Shelton: It's a little disingenuous to accuse Microsoft of not implementing any of the standards. Their more common behavior is to implement standards and then extend them. Microsoft has been relatively forthcoming—especially for Microsoft—in working with the Web services community, outside of the Java community, to make integration happen.
The concern we should have is that as a single company driving a set of technologies, they're able to move much more quickly than we as a community can move. One of the things that I've been struck by in our conversation today is that there's a lot we agree on. If only this same level of agreement would happen in the standards meetings, we'd be able to move much more quickly.
Phipps: How do people see the J2EE marketplace evolving with such a loud single voice coming from the enemy camp? Will we be able to create the unity of standardization Ted is calling for?
Walicki: Customers expect us to, and it's up to us to play it smartly and achieve that goal, or go down in flames. Otherwise, we'll repeat the Unix-ification of the world that we struggled with before. Interoperability actually matters. The WSI [Web Services Interoperability] consortium is a good vehicle for forcing that discussion.
Pepper: I remember the DCOM-COM-CORBA wars, and this is exactly the same. There needs to be a level of interop around Web services. We've got to embrace and defuse Microsoft's charge, and be open with them as much as possible.
Shelton: I wouldn't use Simon's rhetoric in describing Microsoft as an "enemy," because a lot of us work closely with Microsoft and see them as a partner. But I do think there's an important role that we as a Java community need to play beyond making the technology work together, which is to promote the right marketing message. Sun did a great job in the early years in promoting a common Java community message, and now we need to make sure the rest of us work together to promote the fact that Java is going to work great with .Net. In fact, Java is the way to do the server side of .Net.
Benfield: For the first time since we started, we're able to go into an all-Microsoft shop and sell them software, because our integration product works extremely well and it's very easy to use. We walk in the door and show them an application that interacts with BizTalk and does Web services. They're not thinking of it as bringing J2EE infrastructure into the organization.
Renaud: It's imperative that we hold Microsoft accountable for interoperating with our stuff. We need to both make sure that we interoperate so we continue our hold on the server, and we need to make sure that we innovate so that we go after their developers with tools that are standards based, easy to use, and of high quality. I'm glad to know that Silverstream has had success. I encourage you to take the innovations you've put into your tool, submit it to the JCP or the W3C. Let's get all this stuff out there so we can have everybody work together to provide the best value to the customer. Microsoft isn't the devil, but we need to hold them to the fire and insist that they interoperate.
Advancing the Java Standard
Shelton: That's also a challenge within the Java community. Putting source code out into the marketplace and not submitting what you do to a standards organization is not driving innovation or helping the community work together. It's fragmenting the community. We don't need IBM to go its own way with Java and leave the rest of us to go our own way. Then you end up with exactly what Microsoft wants—a fragmented Java marketplace.
Phipps: Ted may be referring to the Standard Widget Toolkit (SWT) component of IBM's tools. Why did IBM decide to create a toolkit that doesn't interoperate with standard Java?
Mitu: We did that to allow tool vendors to create platform-specific applications that perform and behave closely to the platform they're going to get deployed on. Eclipse supports two major platforms—Windows and Linux. SWT allows you to do that. Having said that, I do believe we need to drive toward common standard. But it is incorrect to say that IBM is going its own way.
Shelton: So does that mean that we'll see IBM leading an effort to talk about how to improve Swing?
Mitu: I agree that we need to work toward standardization. Eclipse was started by IBM, but is now managed by a consortium. Borland is also on the Eclipse board. You have as much of a vote in what is happening to Eclipse as IBM does. That's how Eclipse will move forward and become a standard.
Shelton: Borland joined the Eclipse board as part of our support for the Linux platform. We've supported the larger goal of creating a tool-integration strategy around open standards since the beginning of our tools business. But our complaint with SWT and with the way that Eclipse was introduced into the marketplace was that it was presented—SWT specifically—as a Java technology without having been presented to the JCP, which IBM is a participant in. We thought that was the proper forum to say that Swing doesn't do the things we need it to do and let's go fix it together as a community.
Phipps: According to James Gosling, we looked at the things IBM did in SWT some time ago and decided not to do them because it would mean that Swing would work only on a couple of platforms. Yes, there are things that need fixing in Swing, but SWT is a discredited approach. It strikes me that the best place to fix it is in the JCP.
Mitu: The point is that SWT is in Eclipse, which is an open source process that is managed by a board of directors in which IBM has one vote alongside everybody else.
Pepper: This applies to other companies as well. Iona for one looks forward to BEA launching its Cajun technology in the JCP.
Renaud: We're very happy to contribute all of the innovations that we've done with that. Absolutely.
Phipps: The fact that the JCP has now embraced open source [licensing] means we're going to see more diverse contributions from more players that will settle some of the discussions here. There's really no barrier anymore to anyone participating.
|