So you come up with ideas and hand them off to IBM's product development groups? We do. Sometimes we bring things
to the product teams, sometimes we go to open-source groups like Apache and Tomcat, or we'll go to standards bodies with ideas if that's the right thing to do. There's a whole bunch of places we go to determine if it's a product that's needed or something much bigger that's needed for our customers. I love it when a customer come back and says "That's what I wanted." As I tell my team, you strike out a lot in this line of work, but we seem to be pretty good at this.
All the work [IBM's] doing around Web services standards and all the Web services toolkits that go up on alphaWorks comes from us. The Web services collaborations we do across the industry are done by my folks or in conjunction with product folks from other IBM teams. What does IBM's Emerging Internet Technology group do?
Well, I've been the guy out on the edge of things who gets to spend a lot of time with customers. They tell me their business problems as opposed to their software problems. I started this group about five years ago, and it's to fill in the gaps at IBM by figuring out the things we can do to help customers through technology or standards or partnerships or anything else. Should companies that are researching or implementing more traditional Web services also start thinking about wireless Web services as well?
I think it's a good time to start kicking the tires. We started working on Web services two years ago, and we're already getting the important things in place like security. I think we're starting to prove that Web services in a server-side architecture make sense, but it's going to be year or longer before thousands of Web services show up. So it's not so much that we're saying that we need to push [wireless Web services] out the door, but we're finding that customers are saying they like Web services and they like using their middleware assets in ways they couldn't use them before, so now they want to experiment with other devices. Give me an example of what you envision for wireless Web services.
I think what customers would like to do is have easy, client-side Web services so they can more closely monitor what's going on in particular parts of their companies, say in an inventory system. We've been doing those things in a client-server, component model, and it was always brittle. It's difficult to think of a client side model hooking up to servers, but Web services have kind of broken through that.
Let's bring that forward. Why can't I now present on a small, wireless client what I can present on a big one? If I have a client that's monitoring widgets of some type, I may want to take that information into a Web service and build that into a portal, but if I'm on a smaller client I may want that same basic capability, but want only critical information. What work needs to be done in the area?
Top priorities is how small is too small for a [wireless Web services development] toolkit? What kind of functionality do people want when they think about building Web services on these devices? It's not the type of toolkit you put together for a server. We're going to put some things up on alphaWorks so we can get an idea about things like how much RAM is acceptable for what they want to do. It also comes back to the open standards. How can we extend what's been done with SOAP and security to wireless devices? How far away are you from posting a wireless Web services toolkit on the alphaWorks Web site?
A couple months... I'm a big fan of getting some toolkits up online and work with early adopters, and then coming back and asking what do we need to do. It'll have plenty of holes at first, like Web services, but we'll grow it from there. What kinds of companies should be interested in Web services?
I think it'll be industries like health care, travel, and insurance, where there are a lot of field workers in different types of roles and responsibilities. We're hearing from those industries because they look at wireless devices as extensions of the enterprise. If their users are on the road with a wireless device, when they get back into the office they need a bigger picture. So it's an extension as opposed to a replacement.
I'd have people looking at the current standards, and at the apps themselves. What's the relevant info I'll need? What are the scenarios I'd be using this in? Maybe we don't need compression for the XML pieces we want to bring down to the device, or maybe we do. Is connectivity an issue?
You bet. A company can start implementing the content piece, but getting SOAP messages into wireless [devices] and making it a good, solid connection is a problem. So with the verboseness of XML, should it be compressed? What about standards and security? Some of the folks we're talking with use 802.11-compliant devices, so speed might not be an issue, but we need to think about a broad range of circumstances.