Web Services Development Today
FTPOnline: Are you doing much Web services development?
Lillie: We're quite interested in Web services. As they're being defined, we've tracked the process through the standards definition. We're watching closely what's happening both with Microsoft's and Sun's work in this area. In terms of the client demand for this, it's pretty low at this point. That's probably because companies becoming involved in building Web service apps are doing it for internal use. Most of the apps I know about are behind the firewalls. Those companies are using primarily internal staff to do this, so we haven't seen a demand for external professional services support for these apps yet. We do pitch it.
The long-term vision for Web services is that there will be public directories of available services. But it's pretty clear that security is a major issue for most enterprises, and we don't yet have the technology to provide the security to allow different organizations to utilize these services. Most of the work to date has been simply building the infrastructure.
On the other hand, Web services are so compelling to tie together disparate apps within the enterprise. I see a lot of activity in this area, most being done internally right now.
FTPOnline: So right now, customers are using internal developers to implement Web services?
Lillie: Our experience this far, particularly now when it's [an employer's labor] market, is that it's possible to stockpile talent to be able to take this on. Because the technology is relatively new, organizations can take this time to train their internal staff on it. We're not seeing the kind of urgency we saw with the boom days of the dot-com experience, where companies had a limited period of time to make their mark on the net and had to get up and running before they ran out of capital, to satisfy investors and bring in more capital. There's not that sort of urgency, with respect to Web services.
FTPOnline: Do you see the major software vendors moving to Web services?
Lillie: Web services are an enabling technology. Each organization interested in applying them is left trying to describe what services it's trying to deploy. I'm not sure that, if I were in Siebel's shoes, I wouldn't be puzzled about how I might make my services available to the general population. The issue is more of a definition problem than a question of how you employ the technology to solve the problem. It's a business requirements problem.
For example, we developed a salary-planning intranet app that talked to PeopleSoft, and we had to go into a PeopleSoft database and extract the data we needed. If the roles were reversed, and PeopleSoft were trying to decide what range of data to support on apps out there, the company might be baffled. I'm not surprised to see third-party software developers building products to make big applications' data accessible through Web services. Their orientation is different from the primary manufacturer's orientation.
In any case, we have to wait for the market to come back. That's when this is going to take hold. Meanwhile, the innovation is continuing. In the Java community, these technologies are continuing to evolve, and when the recovery does happen, they'll be ready for prime time. That's what I saw at JavaOne. The emotional tone was dispirited. McNealy got up and said something like, "If you like what you see at the show here, maybe you could buy a Sun server." That was sad.
We're using this time to train up on these tools. When the market does recover, we'll be able to take advantage of them.
Back to top
|