An IBMer since 1987, Don Ferguson has led research and development efforts in the areas of operating system performance, database tuning, scaleable distributed transaction processing, object transaction monitors, and Web application servers. In 1993, Don was made chief architect for IBM Component Broker and the WebSphere line. Don is also IBM's contributor to the definitions of Enterprise JavaBean and Java 2 Enterprise Edition.

Don holds a Ph.D. in computer science from Columbia University. His Ph.D. applied concepts and algorithms from economics to resource management problems in distributed systems and computer networks. This included work on multi-system load balancing, data replication, and file placement and network flow control. Don was also the program chair for the First International Conference on Information and Computational Economies in 1998.

Don holds approximately a dozen granted or pending U.S. and international patents and has authored more than 24 technical publications. In 1998, Don was named an IBM Distinguished Engineer, IBM's highest technical position. Don is also a member of the IBM Academy of Technology.

In this interview, Don shares his thoughts on the new features in WebSphere Application Server 3.5.

Advisor: What is the overall vision and value proposition for WebSphere?

Ferguson: When I was building Web-based business systems, before we had things like WebSphere and component broker, I was spending 85 to 90 percent of my time designing and developing the infrastructure. WebSphere lets people focus on the application business logic and worry less about how a distributed system is bound together, handling recovery, doing basic system administration, etc.

Every direct customer IBM has is doing some kind of Web e-business front end with business integration on the back end. They're creating new applications and trying to integrate those applications with some kind of existing business logic. Between the runtime support and the application development tool, WebSphere does a pretty good job of automating the foundation and letting people focus on the business logic and the scripting. I think that's where the value is.

It also picks up some of its value through integration with other products like MQ System Integrator for doing some of the intra-enterprise application integration, or Domino or MQ Workflow if you have business process automation you want to do. A lot of what we do with WebSphere is remove or diminish the complexity that's required to build an application, using disciplines like workflow, application connectors, and presentation front ends.

Advisor: Who are the target users?

Ferguson: A lot of what we're doing with WebSphere, in terms of target customers, is direct sales to business and enterprises that are doing application development. That's IBM's traditional middleware sales market.

Advisor: What big changes are part of 3.5?

Ferguson: The main change is the move to JDK 1.2. Before that, we were at 1.1.8, depending on which platform you're on. We have a slightly different philosophy than some of the other vendors. IBM puts a lot of effort into making sure we have a reliable, scalable, high performance JVM, and we build our infrastructure on top of that. So, we're typically a little later with the latest and greatest JDK support. But, when we ship on a JDK, it's much more stable and it has much better performance than the products that get out there first. That's the big change. We also focused on improving the usability of the systems administration and systems management solution.

Advisor: Is that very different from 3.02?

Ferguson: Well, the concepts are the same. When you talk about systems management, you can look at it in two ways. The first is in terms of the disciplines you support. Our systems management supports Define, Configure, Operate, and Monitor for both the applications and the application servers themselves.

We also do single point of management and single system image. Single point of management means you can manage a remote system from the Admin Console from anywhere in a WebSphere network. So, it's like remote local support for managing individual systems or applications.

Single system image involves a model and a clone. You can define, configure, operate, and monitor the model. Those are, roughly speaking, abstract definitions. Then there's an Admin operation called cloning, which makes a concrete instance of a model on a specific server. Operations you perform on the model are reflected down to the clone. A trivial example would be a four-machine cluster -- if you have a simple configuration -- you can define one model and make a clone of it on each machine. You can also balance workload across the clones.

So, in general, the WebSphere admin capabilities are pretty powerful. But, not everybody starts building a four- or eight-machine cluster on day one. We put some usability enhancements in there to make it easier to get started with simple configurations. Then, we went through and did some human factor stuff. So, for example, in places where you need a directory, instead making you type in the path to the directory, there's a selection capability. The fundamental concepts haven't changed much. What we offered in 3.02 was powerful, but it was like giving people a nuclear weapon.

Advisor: Are there improvements in the install process?

Ferguson: Yes. We consider install part of systems management, which is somewhat paradoxical. But, we put a huge effort into improving the out-of-the-box experience. Install is part of that; so is auto-configuration of a simple system. Most of the changes between 3.0 and 3.5 fall into three categories. The first is general hygiene -- performance and reliability improvements. The second is moving up a JDK level. The third is installability and usability. For instance, for default configurations, we have a one-button install. We don't ask any questions; we just check the pre-reqs.

Advisor: So, if you plan to use Domino as the HTTP server, do you still have to install Domino first?

Ferguson: I believe you can install in any order, but I'm not positive.

Another thing we improved was that, in the Domino case, WebSphere looks for an HTTP server that's compatible, and if it doesn't find one, it tells the administrator, and offers to install IHS. So, if it finds Domino, it accepts it on install. We also added an incremental install feature. For instance, if you have Apache, and then install WebSphere, and install Domino later, you didn't have to reinstall WebSphere, you can incrementally install the WebSphere plug-in for Domino. That was an option we supported in 3.02, but it didn't work with some Web servers -- so that's one of the install scenarios we're improving. You can change something without having to reinstall the galaxy.

That's part of basic product maturity, detecting all the orders in which people install things and fixing them. It's definitely a focus in 3.5.

Advisor: What Domino integration features can we expect to see?

Ferguson: We're working on security features for integrating WebSphere and Domino. For example, we can go to the Domino Name & Address Book, which is LDAP compliant, for security. We're also working on Single Sign On between WebSphere and Domino. WebSphere and Domino security will use the same cryptographic security mechanism, so you'll only need to sign onto one of them for HTTP access. For example, if you have servlets and JSPs in WebSphere, and you do some HTTP generation through Domino, you only have to sign on once.

This is in 3.5, but will be improved in an upgrade. It's complete in 3.5, but the mechanism for distributing the shared key isn't integrated with systems management. Right now, you have to use a key distribution utility -- that's what's missing in 3.5.

Advisor: How does the actual Single Sign On mechanism work?

Ferguson: The key handles cryptographic security. We use a security system called lightweight third-party authentication. The token is generated by security and encrypted. Both Domino and WebSphere can decrypt it with a shared key and agree that it's a valid time-stamped token. So it's just passed back and forth from the client to the server on request.

Advisor: Is it implemented as a browser cookie?

Ferguson: Yes.

Advisor: So, if the user has the cookie option turned off in their browser, they'd just have to reauthenticate?

Ferguson: Yes.

Some of the other things we're doing have to do with connection pooling and connection management. We're doing this underneath what used to be the Notes Object Interface (NOI), so you can have a multi-threaded application server that connects to Domino databases. We handle connection pooling and security delegation on that connection. If you come in through WebSphere and run a JSP or a servlet, we flow security information over the NOI connection. Notes security takes over once you're inside Notes.

Advisor: Then you also handle the per-thread initialization?

Ferguson: Yes, we've done some cleanup there so WebSphere can manage a thread pool and access Domino more efficiently.

Advisor: In other words, someone who's writing a servlet or EJB that uses the Domino objects doesn't have to worry about the thread initialization and termination that Domino currently requires?

Ferguson: Right. We do this kind of thing with a range of products that work with WebSphere, so this is just some work we've been doing to make it more transparent.

The Notes Object Interface is inherently a client interface and you're running in a multi-threaded server, so this just makes it more transparent. We're doing some work to get better integration between Domino Workflow and WebSphere, and between agents in Domino and WebSphere. Agents will be able to call EJBs to trigger business logic. We're also doing some work with Domino Workflow so you can drive WebSphere business logic activities as part of a Domino Workflow process. We're doing the same thing with MQ Workflow and general workflow.

Advisor: You referred briefly to IBM's use of JDKs with WebSphere being a differentiator between it and other competing products. What are some other differentiators?

Ferguson: The systems management is a differentiator -- not so much the usability, but the capability. As far as I can tell, none of our competitors support the model-clone capability. They have rudimentary workload management support. But, configuring groups of application servers on the same physical machine -- that's a very difficult process.

Advisor: Is it fair to characterize that as a configuration inheritance mechanism?

Ferguson: You could look at it that way. Look at what [BEA] WebLogic does. It copies files, then modifyies them. WebSphere does a sort of object version of that. It's not just inheritance though because there are overrides on the clones from the model. You inherit changes from the model; but, it isn't inheritance in the object sense.

It's also operational in addition to configuration. So, the methods you dispatch on the model are propagated down to the clone. It's more like an aggregate pattern. The way to look at it from an object point of view is that the model and the clone have the same interface, but every method or instance variable in the model is coded so it understands how to perform an aggregate answer based on all the clones. They're implementing the same interface, but it's not inheritance in the object sense.

Advisor: Let's shift gears for a minute and talk about Enterprise JavaBeans. IBM is placing a fairly strong bet on this technology. Do you agree with that?

Ferguson: Yes, we're placing a strong bet on EJBs, but there are two other technologies we also support as part of our EJB strategy. Most people don't realize that all of our EJBs in WebSphere since 3.0 are also CORBA objects, at least from a usage point of view. So, EJB was the first Java-centric component model we supported, but the plumbing that holds the galaxy together for us is CORBA.

We're also working with service-oriented architectures, the concrete instance of which is SOAP. Toward the end of the year, you'll see something we call an XML component model. You'll be able to define your server-side business logic as either a JavaBean -- not an Enterprise JavaBean -- or a Java class. Or, you could implement it as a set of LotusScript procedures or JavaScript procedures. By providing an XML file, under the covers, we'll run that as a component. It will run as an EJB, but you're not aware of that. It's just a set of procedures you call, or a record that gets stored into and out of the database and passed to the procedure. So it's a way of lowering the conceptual bar for people who want to program either session-style collections of functions or entity-style persistent records with functions that manipulate them. Under the covers, we use things like a container-managed systems and our implicit authorization support.

Advisor: Is it accurate to say that if you're bringing LotusScript and potentially other languages into this model, in the future people will be able to code EJB functionality using non-Java languages?

Ferguson: Yes. I would go even farther than that though. You can sort of do that today if you want to. You should almost think of this XML component in non-Java language as a 4GL for EJBs, which makes it even more declarative than EJBs are today. It's a little more than just non-Java language support for EJBs. It's a higher-level concept that goes on under the covers of EJBs, but requires less understanding of EJB programming.

We're also working with SOAP, and with MQ integration, supporting both synchronous calling and CORBA-style calling of components, messaging to them over HTTP or JMSMQ. So, in addition to driving them synchronously you can drive them asynchronously using a messaging protocol.

Advisor: Given that CORBA is the underlying plumbing here, you're using IIOP everywhere to let everything talk to each other. Is that a performance issue when the HTTP engine and the EJB engine are on the same machine?

Ferguson: No, because in that case, we don't actually use CORBA. There are a few places where we don't use CORBA. One is the way the app server registers with the Web server, it's via this plug-in technology. The call from the plug-in isn't a CORBA call.

Advisor: When a servlet, for example, is using JNDI to rendezvous with an EJB, is that always IIOP?

Ferguson: You can configure it so they're all local calls.

Advisor: How do you do that?

Ferguson: You configure the EJB and the servlet JSP in the same application. In that case, it will always be a local call.

Advisor: So the container and the application server figure that out?

Ferguson: Well, it's really how you configure it. If you look at the Configuration Console, you can see physical machines. Then you can see application server instances on the physical machine. Then you can see application parts installed on the application server. So, suppose I have a machine called Foo and I also have an application server called Inventory on it. I could put some servlets and JSPs in Inventory, and I could put some EJBs in Inventory. In that case, if the JSPs or servlets use EJBs, all the calls are local Java language calls.

Advisor: What else is coming in WebSphere that we should know about?

Ferguson: A big focus is either embedding WebSphere or adding capability on top of it. So we're putting a big effort into selling WebSphere to ISVs for building B2B solutions on top of WebSphere, or building portal solutions on top of WebSphere. We're doing some work in the base of WebSphere to make it a better foundation. Better support for workflow, MQ integration, and application integration, etc.

The other big thrust is to give people a higher level set of "tools" to use -- both ISVs and independent customers -- when they build their apps. The three big elements of that are the WebSphere B2B Integrator, the portal stuff, and the higher level service-oriented architecture. We're actually trying to give customers higher level APIs when they're programming and much higher level base parts they can customize.

Advisor: Will this also be reflected in VA Java?

Ferguson: Some of it would appear in VA Java, some of it would appear in [WebSphere] Studio.

Advisor: What is the main value proposition of JSPs?

Ferguson: JSPs today are mostly used for markup language result generation. We document something we call the HTTP profile, which is a style of using the programming model. The runtime and tools don't enforce it. It's more of a best practice or recommendation.

Advisor: Would you call it a pattern?

Ferguson: A pattern is another way of looking at it. Basically, the pattern is that an HTTP request, either a POST or a GET, comes in. If it's dynamic content, it's sent to a servlet. The servlet handles parameter validation. It also implements a controller pattern: Is this particular request valid given the current state of the session? So the business logic is controlling whether the request is valid. If the request is valid, it runs a "command" bean -- which is a JavaBean, not an EJB. The command bean can pretty much do anything -- call a CICS transaction, call a method on an EJB, go out and read something from the database, call a stored procedure. There's tooling for generating command beans. A command bean runs and that's what you use to drive your business logic. When the command bean returns, the properties of the command bean are passed to whatever back-end process you need, and the results of the command execution are also stored in the bean, as a separate "result" bean. You pass the result bean to the JSP. After your servlet has done the interaction-driven business logic, it looks at the command bean, checking for a successful result, or failure, or whatever. It determines the JSP to call based on the response. We suggest you pass the command bean calls to the JSP. That generates the results page.

So, we use it as a way of generating the markup language result from the business logic. It's mostly a dynamic page generation mechanism. A lot of people actually use JSPs to generate results other than HTTP, for instance, results for VoiceMLs or wireless phones, etc.

Advisor: Do you see a role for XML there?

Ferguson: Yes, some people generate the XML answer from the JSP, which makes DOM calls or just uses general string manipulation to produce an XML result. The way to think about it is that the answer is going back to something and the format is different depending on what it's going back to. So, developers can write JSPs that are customized for the device that the answer is going back to. That's how they determine what upload string is generating. Some developers only use the JSPs to produce a little bit of XML, and call an XSLT to actually produce the XML. We primarily see developers doing that, or using XSLT in a sort of batch mode to produce a set of pages, and use JSPs or a dynamic mechanism to generate responses from the outputs. They do this because it's a little bit easier to actually drop down and write some code in a JSP than it is in something like XSL.

Think about it as if somebody gave you -- I'm an old mainframe guy -- somebody gave a control block that had the answer in it, and you need to produce an output page. How do you do that? JSPs are a pretty powerful mechanism for doing that. We see a lot people doing it, not in Java for HTML, but for non-HTML, visual, pervasive devices such as phones and PDAs. They're actually also using it for things like sending e-mail. Some people will take the response based on some criteria. For example, the way to respond to person x is to send them e-mail and copy someone else. They format the text in the JSP and call one of the e-mail APIs to send it. It's a very powerful text-generation-from-data language.

Advisor: What is the value proposition for EJBs?

Ferguson: If you're going to run business logic in a server, whether you like it or not, you need a component model that tells the server how to manage the business object. Do you have a single instance for each request? Is this thing thread-safe and can all threads processing this business logic flow through the same instance? Do you want the thing to be saved persistently and restored on the next request? You need a way to specify that control information to a server so it can properly manage the component.

Historically, when people have thought about component models, they've thought about things like the desktop COM component model, Open Doc, or these JavaBean GUIs. There's a similar and somewhat simpler agreement that needs to be reached between the runtime hosting the business logic and the business logic itself. This is not a new concept. For example, if you look at how people program DB2 stored procedures, there's an implied component model there. EJBs make it more declarative. Once you step into an object model, there are some concepts you need to have. So, you need a component model and EJB is a pretty pervasive one. We use that as the component model for hosting business logic.

As far as the value of EJBs goes, one benefit is obviously portability -- this stuff it amazingly portable. I routinely move business logic between WebSphere and our competitors' products for testing purposes. But, the real value is if you're going to have an application server that's going to host business logic, you need some component model.