Oracle Product Strategies
Q: How does Oracle's wireless strategy overlap with its application server business?
Christfort: Our Oracle9i application server has built in something called the Wireless Option. It's not an add-on component, but an integral part of the product. It's an option in terms of licensing; you pay for it if you use it.
It's important that the Wireless Option is integrated into our application server. In the beginning of wireless, people were selling wireless middleware boxes and servers as separate things, but we think these should be part of an application server's functions. And most analysts agree that from a technology-strategy perspective, it's the right way to go. That's one reason we've gone, in two years, from competing with 50 companies to competing with just a handful. It's almost impossible now to sell a wireless-only middleware box. Basically, all of those companies are either out of business or heading there.
Q: So the new competitive space is the J2EE app server market? According to analysts, Oracle has made significant progress in that market.
Christfort: We made a determination starting several years ago that this was a market we needed to be strong in. One thing we discovered was that we had too many products in the middle tier. Wireless was one of them, but we also had separate servers for various other functions, and we discovered the whole middle tier of the app server market was fragmented. IBM had also done something they called an app server, but it was really 150 different products.
So we saw an opportunity in being the first to create an integrated app-server product. We could see why many customers would have trouble buying all these components and building them together, because it's not simple. So we did that for them, and then—for our 2.0 app server release—we bought the fastest J2EE engine on the market and integrated it, because we consider that as the commodity part of it.
Q: That was Orion?
Christfort: Yes, Orion, a Swedish company, had a fast J2EE engine. In our first version, we had built our own, but we found out that's not where the competitive market was today. We were better off buying a fast one and then adding the value by integrating all the other stuff, which is not trivial to do. Anyone could have bought an Orion J2EE engine and an Apache Web server, and that would have been faster and certainly cheaper than what we would sell them. But when people did that, they had a problem when they needed enterprise-grade authentication, system management, document management, portal integration, content management, access control, and other functions. So we licensed Apache and bought Orion, and then built all the other stuff on top of it, pre-integrated and ready to install. That was the premise, and it has gone extremely well with buyers.
Q: Likewise, on the development side, your JDeveloper has been well received.
Christfort: Here's the strategy with JDeveloper. We think it's an excellent tool that offers lots of benefits, particularly if you do database-oriented programming. However, we also know that people might have other development environments, so we have a standard J2EE application server that allows you to use our tools or other tools.
Q: And that allows you to play in the big market? The rap against Oracle in the Java market is that it owns its captive database customers but is not fully competitive in the rest of the world.
Christfort: Yes, that's a perception and it's up to us to change that perception. If you have an enterprise requirement, and you're looking to get everything out of the box, pre-integrated, there is no other application server that will do the same job for you. If you go to something like BEA, you'll also have a quick J2EE engine and good basic Web-server functionality. But BEA has virtually nothing for wireless. Or take IBM: It has some wireless components, but they're not integrated. You can't even download the product. It exists as components, and if you want to get the product, you literally depend on IBM consultants to come and install them. The cost of ownership of the IBM product is completely mind-numbing.
Q: What does Oracle Mobile Studio offer the wireless developer?
Christfort: To run mobile applications as elements in your infrastructure, you need a WAP gateway, an SMS gateway, and a voice gateway. What we built was a hosted instance where that infrastructure is already in place. There's a toll-free number where you can dial in and get voice-gateway capability. What you can do now is build an application onto your own app server, then go to the Studio and create a connection between the Studio-hosted infrastructure and the application on your application server. You don't have to install a voice gateway, a WAP gateway, or an SMS gateway. You just leverage all of that in the host node, yet the actual database that you access is inside your own enterprise.
Q: Is that how you think most enterprises will do it?
Christfort: We think it's attractive because enterprises don't like the idea that their databases would reside with a hosted provider. We offer that as well, but the reality is that enterprises prefer the comfort of having their treasured information assets in their own data center. But they're not at all excited about getting into the cost of ownership of running all these gateways.
Q: How do you price the hosted model?
Christfort: First of all, development is free. You get a certain volume of test messages and voice access, but you can do your prototype product and proof of concept totally free. Then when you decide to go live with this model, you have some interesting choices. You can continue in the hosted mode, in which case you pay a hosting fee, which is basically equivalent to the licensing fee of an equivalent amount of AS Wireless Server licenses, plus a small management fee. The hosting price depends on your usage. It's not a simple pricing model, but it also means you pay only for what you use; you don't have any slack capacity. But some enterprises might want a license to run it all in-house. Then you can just buy the licenses and you're ready to go. You will already have been through the proof of concept. You've seen the work. You've justified the project cost.
That's interesting because you have all these wireless service providers with a great ASP offering, but they don't have a shipping product. Then, you have IBM, which has a shipping product but no hosted service. One of our differentiators is that people can use the Studio, get comfortable, even prove it internally, and then have free hands in terms of whether they want to run it inside or continue hosting.
Q: One of the things you seem to be promising with Oracle9iAS Wireless is the ability to have one application-development effort that would abstract to a wide variety of wireless devices. How is that possible given the state of standards today?
Christfort: One of the big barriers to building an application is that you have different evolving standards—you have to build a VoiceXML application, a Palm application, an iPAQ application, a BlackBerry application, a WAP application, an SMS application, and so on. Pretty quickly, you find you're building 10 different applications.
We don't think that makes sense. It's better to abstract it so people build a standard J2EE component that outputs an XML schema, then we take care of the adaptation to the different devices as they evolve. Basically we created an abstract interface—a user-interface mark-up language—and then from there, we translate to the different standards. It's compelling. You can run one application—for example, the e-mail application or calendar application that ships with our app server—and that same code implements a well-formed WAP application and a rich-interface PDA application. You can also call into it with voice recognition or SMS and check your calendar and e-mail. So the same application gets better and better.
Q: Are customers building these kinds of multichannel applications?
Christfort: It's a hard problem to solve, but it's pretty magical. Barclays Bank has millions of users running mobile banking on its server. Barclays took our server and built it for WAP, then came back to us and wanted to know what effort would be involved to build it for PDAs. We told them it was no effort, because it was already done.
However, there are some things you like to do a little differently on PDAs than on phones. That's no problem because we have the capability to alter the application conditionally based on the device. We have switches in our mark-up language that let you tweak the five or 10 percent of the application specific to the device. But you have only one JSP. So the total cost of ownership—of building, deploying, and maintaining all the versions—is as if it were one application.
About the Authors
Dan Ruby is Editorial Director for Java Pro and XML & Web Services Magazine. Reach him at druby@fawcette.com.
Tim Haight is Editor-in-Chief of FTPOnline. Reach him at thaight@fawcette.com.
Back to top
|
Wireless Enterprise Applications
