Back to Basics for Sun Software (Continued)
Practical Web Services
Q: How do you view the integration of Java with Web services?
Fowler: We've looked at the application server and how people use application servers and Web servers in real markets, and have found that current app-server technologies are not aimed at what most people want to do. A large segment of developers want to develop presentation logic and database-connectivity logic but don't necessarily need all the elements of EJBs. And there's no reason why this needs to be so expensive or complicated.
So in our strategies around the app server and the Web-services developer pack, which is priced aggressively, the capabilities match what people want. For example, in the app-server space, most people are not developing EJBs that use RMI over IIOP; they're using SOAP over HTTP. So we focused on the elements of technology that optimize for that path and provide the programming context for that path. And we have world-class Web benchmarks, even with the free app server that we bundle with a platform and make available everywhere, because we believe that's what most developers will develop on.
Over time, these strategies will effect a change and a real upgrade for developer capability. You can call it an app server, but when you look at the Web-services developer pack and what we have focused on in pricing and performance optimization, it will be quite a different developer proposition. You'll see a lot of stuff around that technology for us—Web services "in the practical," as I call it. People will develop Web services for lots of applications—not just high-end, transactional applications.
Q: But isn't the high end where all the Web services standards activity is focused?
Fowler: The transport-layer standards such as SOAP are mainly in place. Web-services standards around issues such as orchestration will be interesting, but I am skeptical about some of the more complex Web services standards. I see a lot of those as being OMG 2, and I think we'll look at those and say they were a waste of time. Lower-level standards around basic security and transport layers—connectivity issues—are the ones that are extremely useful.
The more important problems that people need to solve involve data formats. People have figured out ways, by hook or by crook, to solve transport problems. The much harder problem is [exchanging] semantic and industry-specific data. That's why we emphasize ebXML and OASIS, and we have Jon Bosak leading the UBL (Universal Business Language) effort, which is the attempt to bring EDI capability into the Web services world. One of the things we've discovered is that, despite all the press about Web services, most business-to-business transactions—around 90 percent—are still getting done using EDI only.
People have legacy systems developed using EDI, and that's how they do their work, and that's not going to change anytime soon. If you want to create a large impact for Web services in terms of the business community and the world, you've got to make sure that Web services and EDI intersect and conform. We're spending a lot of energy on that.
With XML, we ended up with a base description of a container and an encapsulation format, but that's not the big value to the client. If you want to realize a long-term impact for business, the economy, and development, you must look at the data format problem.
Q: How does that relate to interoperability between J2EE and .NET? Gartner says that 70 percent to 80 percent of enterprise shops will be running both platforms within the next few years.
Fowler: Again, transport-layer interoperability is pretty well done. Today, people can develop Web services applications that interoperate between different vendors, which is a huge step forward from anything that went before.
The next thing is to focus on the data formats, and that won't be in Microsoft's control because it involves EDI and organizations [such as] the United Nations and OASIS. The key to [interoperability] is that it won't depend on vendor participation as much as customer participation. If you look at the Liberty Alliance, the important players are Visa, American Express, Wells Fargo, and United Airlines. It is not Sun. We helped get the group started, but the first thing we did was get these other companies involved. That's because we think with federated identity, [user companies] are the ones with the customer information, and they ought to have the major view on this.
When we look forward to Web-services standards, the ideal scenario encompasses much more customer participation in articulating those things. And customer participation will drive us vendors to make sure our applications support their interoperability standards.
Q: It sounds as if you're pulling back a little in terms of the higher-level Web services protocols.
Fowler: There are standards battles around the high-level stuff, but I don't know how relevant they will be in the long term. In how many implementations will these complex protocols show up? What do they do to create pervasive value for customers? Obviously, we have people at Sun concentrating and working on those, but I don't think that's where the rubber will meet the road five years from now. Instead, we'll talk about whether we got our act together on data formats. We'll talk about whether we got ubiquitous distribution of secure transport standards so everyone interoperates.
Q: The question of enterprise application integration (EAI) remains a challenge—translating between proprietary methods for going from one data system to another. The Java Community Process has standards for adapters, but how does that fit with Web services?
Fowler: If you look at Web services in the ultimate—if everyone wrote to common schema and common transport—EAI in that mode goes away. You don't need it. But the world is more complicated than that. In the world of computing, you only add things. And so I think that for many years to come, there will be an EAI market that will involve adapting legacy systems and legacy business logic, and I believe that Web services will most commonly be the interchange point.
Our point of view on this is: Why is it so expensive and so complicated? We are going down the track of providing tools that let you build your own connectors rapidly—unlike in today's EAI market, where, for example, you write a check to an EAI vendor and it's not clear which of you owns the connector. You can call the vendor back and keep paying. That is just a bunch of malarkey. There is an economic-disruption possibility here, where you're providing the connector builder. The enterprise developer can map a legacy system to Web services relatively easily, and everyone's golden.
Eventually, as more things go to Web services, you won't need this anymore. The connector is a message bus for standard Web services rather than some branded piece of technology. It will take a long time, but I think today's EAI market is a bit artificial.
Back to top
|