Welcome!

Related Topics: Websphere

Websphere: Article

Birth of a Platform: Interview with Don Ferguson

Birth of a Platform: Interview with Don Ferguson

Jack and Pat Martin, editors of WebSphere Developer's Journal, recently sat down with Don Ferguson, "the Father of WebSphere," to talk about its history and his view of WebSphere's future.

Editor's note: We would like to make a special note that Don is very modest about this "Father" title and, as a matter of fact, avoids claiming this title because so many people have provided leadership and insights.

Next month, the interview continues when Don Ferguson discusses how business partners will collaborate in the future using WebSphere and some of the deficiencies in WSDL that need to be standardized to make the dream come true.

WSDJ: What was the genesis of WebSphere?

DF: What is now WebSphere started as Component Broker about 6 years ago. I had been leading a research team, working with IBM Hursley, that was proposing and prototyping a CORBA/OO transaction server called OATM. OATM provided database and application integration, workload management, high availability, etc. I had presented the ideas around the company on several occasions.

One day, my manager, Nagui Halim, and another senior researcher, Mark Wegman, came to me and said, "Get in the car." We went to Somers to meet with Robert LeBlanc, who was the executive in charge of our CORBA/C++ projects. He offered me the job of lead architect for the efforts. He made me an offer I could not refuse.

At the same time, there was another Research Division project, called the Web Object Manager (WOM), that was working on dynamic, personalized Web/HTML front-ends. We had done some work in OATM on dynamic HTML generation, but WOM was more carefully thought through.

Many ideas from WOM charted a direction for Portal, Personalization, and the Web Container in WebSphere. Component Broker defined much of what is the EJB Container and WebSphere's overall approach to workload balancing, server groups, system management, etc.

Several key executives saw the opportunity and vision of what we were doing in CB and WOM, and supported us. The executives that have sponsored WebSphere include Robert LeBlanc, now GM of Tivoli; Steve Mills; John Swainson; Danny Sabbah, VP of WebSphere Development; and Ambuj Goyal, then a VP in Research. They hung tough through some really hard times and that's why WebSphere is what it is today.

WSDJ: What was your initial vision?

DF: The real origins of WebSphere go a bit farther back. Research started some work on scalable, clustered UNIX systems. I proposed a project focusing on CICS/6000 and MQ on the clustered systems. The project started out as a systems management project, and we selected C++ and CORBA to implement our ideas. The implementation we selected was an IBM product called SOM/DSOM that IBM Austin was developing.

The Research team discovered that 80% of the work we did turned out to be reusable frameworks for building distributed OO applications; only 20% of the stuff was CICS-specific or system management-specific. Some examples of functions we implemented included container management persistence for objects, an interceptor pattern that mixed object services into each of the deployed classes, and automatically generated Web front ends from meta data, kind of like JSPs.

One day a customer was coming to Watson and I was asked to think about the customer's problem and give a presentation. Irving Wladawsky-Berger, vice president of technology/strategy, gave me this customer's problem. He was hosting the customer visit. And I thought about it, and put it into what we were doing with system management. The business problem was just a different style of application, and what we were doing was generally applicable to application integration, multi-tier technology, and multi-channel support.

After the presentation, we started working on that problem with the customer.

LeBlanc had heard about the customer work and had Nagui and Mark bring me up to Somers. He said, "Listen, you're in charge now, come back to me in a couple of weeks with a solution for what we should be doing." I said, "I obviously needed to think about it."

So I thought about it and scheduled a conference call with him to discuss specific concerns and what I thought we needed to do. I wanted to bring up some issues, "Well, you know my wife is going to have our first child in a month, and now is not the time for a major career decision." He said don't worry about it. My daughter was born during the first month of the project. Being a father was a good way to put things in perspective; there have been some rocky times on the CB/WebSphere evolution.

I find a couple of things to be amusing: the number of people who have been identified as the "Father of WebSphere," and the concept that innovation occurs as a single effort.

There were two types of people who supported CB, WOM, and WebSphere. The first was the executive sponsorship. Revenue commitments were overlooked for the vision. That?s not usual business at IBM. They made a bet on the future of the company. That took guts.

Second was the technical engineering group. That included Tony Storey. He and I put together the initial proposal for OATS/OATM (Object Application Transaction System). Much of that research went into WebSphere. Rob High, now lead architect of WebSphere Application Server, made sure I didn't make any mistakes. Rob was also the driving force behind much of the Component Broker and WebSphere designs, as well as CORBA, EJB, and J2EE standards. Eric Herness was the lead architect for the enterprise extension to WebSphere and one of the people who helped invent our Managed Object Framework.

Jason McGee and Michael Fraenkel have been the lead architects and programmers for our Web front end and getting XML supported. Rob Will, Carol Jones, Martin Nally, Scott Rich, and Timo Salo drove the application development tool design and implementation. The AD tool support we have is one of the best-loved functions of WebSphere. Graham Dixon of Transarc, a company owned by IBM and Jerry Cuomo in Raleigh, also made profound technical impact. Each of these people, and Jim Rayfield from Research on OATM, has as good a claim as "Father of WebSphere" as anyone.

I've never seen anything like this team in my life. I would go online at 3 a.m. 'cause I couldn't sleep and I'd be getting e-mail about some problems we had in the test scenario or bring-up. On Sundays too! I continue to wonder what we did to get these people and hundreds of others to do this? Two thoughts come to mind.

They believed they were the best and they wanted to show everyone they are the best. And the second thing is, I would routinely go and talk to them and say that the fate of the IBM Corporation is in our hands. If WebSphere doesn't succeed IBM will not succeed. We have lots of other products; hardware, transaction processing, and e-business, but they believed, and literally just killed themselves. In spite of the fact that, in terms of the overall expenditure of the corporation, this wasn't a big project ... but so much was hinging on its success.

WSDJ: When did it hit Gerstner?s radar?

DF: I heard from him a couple of times - the first, a visit he made to Research when we were part way into Component Broker. Research management selected one project to show him. So we had a private review to explain what we were doing. I was all dressed up in a suit for the presentation. A peer razzed me about wearing a suit. I told him I only wear a suit for the chairman of IBM and Swiss bankers. Gerstner made a remark about the suit, "From now on just wear it for the Swiss bankers."

I was impressed that Gerstner was so quickly able to understand the value of the solution. Gerstner had been a customer of IBM and understood what we were doing right away. When I explained to him the business problem we were trying to solve, he understood the business case immediately

WSDJ: What was the business problem you were solving?

DF: The problem that the customer came to us with was what is called a stovepipe problem in large corporations. They had a bunch of disconnected systems that were vertically integrated from presentation down to data and business logic. There was no horizontal application integration, however. These stovepipes got built up through mergers and acquisitions, and individual line of business solution development. These systems didn't integrate data, business logic, or presentation. If you went into a call center, what you would actually see was a PC running terminal emulators to all these applications. The users would hot key back and forth and read their manuals. Basically, the end users were doing the application integration.

The customer had written a bunch of utilities that read the data from all these stovepipe applications. They sucked it out on tapes and brought in external sources of information so that they could get marketing information. They put it all into one big database. Then they would run analytics to clean and merge the information so they could make decisions on direct-marketing campaigns.

They would do a tradeoff of costs of running the mailing campaign to the probability of generating new business. It was done in a very ad hoc way. This, in essence, is what the information integration and business intelligence functions in the Data Management side of IBM do today. A lot of what has gone on with Content Manager and DB2 solves these problems.

The problem that this corporation had was twofold. First, the campaign was channel-specific. The direct-mail piece went to the customer with an 800 number to call back. If the customer went directly into a bank branch, they were told to go home and dial the 800 number. There was no way to handle it. The goal was to get the campaign serviceable over multiple channels. No matter how the customer contacted them, the information could be received and updated in the operational systems.

Second, the business wanted to do just-in-time application integration: the extract, clean, and merge process took several weeks or months. So by the time the person was actually contacted by the company, the world had changed quite a bit. The person might have already opened a portfolio account or the balances may have changed. What the company originally wanted to do for them might also have changed.

The business wanted the customer contact to bootstrap up a new version of the person, to pull together all the informations' current values. There may also have been some business-policy changes. So, the business wanted to pull the new information and policy together, and at contact time do a last-minute optimization. So the customer could be offered say, a gold-status account based on the current account information, as opposed to what was in the original mailing.

WSDJ: So, it was done to support direct marketing?

DF: It was more. That was the initial business problem that the enterprise had. It also was call center support, branch manager support, etc. It's not that surprising because when you would talk about the technology and show people this stuff and what it would look like, they would say "YES, if we could rebuild our infrastructure, this is the way we would do it."

The problem is you need to motivate that kind of investment based on long-term cost reduction. It?s a hard thing to do in an enterprise. We used to call what we were doing "incremental business process in engineering." We'd identify 5 or 10 business problems that they couldn't solve. So we'd incrementally reengineer the business infrastructure by solving the business problems one at a time. That way we could justify the investment based on delta increase in revenues rather than delta decrease in cost. This is one of the scenarios that we had.

WSDJ: What about Flow Composition Modeling (FCM)?

DF: FCM, Flow Composition Modeling, is included in WebSphere 4.2 and our tools. It's the ability to assemble new applications from existing ones and new Web services from existing Web services. We also use it to build application adaptors.

If you wanted to build an operation that checks someone's net worth, you would go to an interface to check the balance of a savings account and then a checking account and write an algorithm. That's part of what integration/adaptation is. We now have a visual builder that allows people with flow chart skills to build these kinds of applications using the Flow Composition Model.

WSDJ: Do they require technical skills?

DF: They probably require more technical skills than they should but a lot less than in previous solutions. We are working on making the tooling much more intuitive and simple.

WSDJ: Do they have to know how to program?

DF: No. The external name for this is Web Services Flow Language. We've been working quietly with some people in the industry to make it another one of the Web services standards. Part of this is just a homogenization and convergence of some things like JCA (Java Connector Architecture) micro-flows, which just shipped.

FCM is one theme about how the message-orientated middleware and the application server-orientated middleware are coming together. The thing that is really powerful about this initiative is that this is another case where a lot of the people I work with have shown real leadership. Java 2 Connector Architecture is pretty much based on something we in IBM called Common Connector Framework. If you looked at the JCA spec and then looked at the Common Connector Framework, you could say they were the same thing.

One of the real insights we had when we started to do WebSphere Business Integrator was the concept of a service-oriented architecture. In WebSphere Business Integrator, if you took a set of interfaces to back-end systems that you built in JCA, you would materialize it as a Web service and so do a WSDL version of its interface. You would use the FCM tools to build the individual adapters, as well as assemble new, higher level services that implemented new functions by calling the adapters. We supported calling the Web services over distributed EJBs, MQ, and HTTP.

What the FCM and WSFL do is allow you to build new services from existing ones so you can basically build a new "Web service" that uses a WSDL interface to a business partner, WSDL interface to perhaps a CICS application, and a WSDL interface to some EJBs.

The first product we are shipping allows you to do that. And so it's a really powerful concept. In addition to current application integration, it allows you to build new components visually from existing ones. It's really got two modes of operation. Mode number one is to build the application that accesses and talks to SAP; mode number two is if you've got a bunch of components already built, you can have some new ones, all it really requires is flow-charting skill.

WSDJ: Are you the lead person on that project?

DF: Well, I set some of the high-level direction, but most of the insight and innovation was done by Mike Starkey, Mike Beisiegel, Frank Leymann, and Marc-Thomas Schmidt, Terry Borden, Tim Holloway, and Vish Narayan. In terms of significant new work, this is probably one of the biggest things we are doing.

WSDJ: What is your view of Visual assembly mechanism?

DF: Visual Assembly Mechanism, when you think about it there are two core tasks people want to perform. The first is that if I have existing components, I want to build new ones from them. The second one is if someone gave me a component, how do I customize it? How do I change its behavior? Today, the way this works is through programming. Developers write new Java code to build new components from existing ones, and modify existing code to tailor a component's behavior. The FCM visual tools are a much simpler and more rapid approach to building new services/components from existing ones. Our next big innovation is support for Business Rule Beans for tailoring the behavior of existing services and components without modifying their source.

WSDJ: Can you explain Business Rule Beans?

DF: Business Rule Beans (BRBeans) allow people to document a service's or component's "trigger points" or "points of variability." Instead of putting policies in the component?s implementation code, you document the trigger points at which policy decisions occur. The trigger points are visually connected to BRBeans that satisfy the trigger points and implement the policy. Without modifying the component's business logic, you can perform deployment and runtime customization of policy decisions through visual tools.

If you have a Web service, or today an EJB, an example might be that you have a method that "adds a line item" to a purchase order. If you have a purchase order component, and add a line item, the implementation is usually a method with embedded business logic that determines whether or not the new line item is valid.

With BRBeans, we tell people to do this method differently. The only thing that is in the add line item method is the mechanics of adding it in. Are you actually adding a PO to a database? It's the physics of setting the line item to point to the purchase order and vice versa.

Before performing the data changes for adding the line item, the method calls a trigger point to see if this is a valid thing to do. Is the line item valid? Is the resulting state of the PO valid? So programmers and software vendors will ship an application, and they'll ship the default policy and logic through BRBeans configured at trigger points. Then the business professionals and system integrators can use visual tools that answer questions like, "Please show me the rules that are associated with this trigger point." The tools also allow the integrators and business professionals to remove, add, and modify the BRBeans associated with a trigger point. You can also have different rule sets for different periods of time, for example when a marketing campaign is in progress.

If you look at the way this type of rules-based logic works, it has the tendency to follow the template instance pattern. My favorite example, and again this BRBeans stuff comes out of a piece of work we did in research as part of the OATS project, is the following: you could have a policy that a person can?t be a manager if their IQ is above 50. Instead of embedding that in the code in the set methods for IQ, you put a trigger point on the set "IQ" and the set ?manager? methods. The thing that is powerful about that is that you can have the same component in two separate places. So you may say, "Well, actually in this department that rule doesn't apply." So instead of having to have a special version of that component for that department, it's just configuration-based " what does the rule say" You just make a new instance of a BRBean with different values for the constraints and apply it to different components in different parts of the application.

This is an example of intra-entity, crossfield validation. It was on the employee component and constrains two fields: "IQ" and "is manager". The business analyst or integrator sees the set of trigger points through a developer tool. The tool also shows templates for rules and tools for building new rule types and instances. What the analyst wants is a constraint between two fields. So he clicks on "build me new constraint" and what he gets is a new instance of the template and just fills in the fields and values and associates with the trigger point. It?s unlike scripting; it's more and simpler. At a particular point in time, the professional wants to take this rule, this rule, and this rule, make new instances of them, fill in the actual values and fields, and associate them with trigger points. It's a template-based thing.

What we"ve done is eliminated one requirement for going in and taking a look at the code and details of components and requiring programming skill for tailoring applications.

This was first shipped with WebSphere Personalization Server. Part of what we're doing now is completing this because people now have a lot of power to do campaign management with personalization on the Web front end. How do they customize and personalize the business logic within the campaign? Well, now they have rule capabilities. This also extends that capability of rule programming and complements what we have done in the past with Versata.

WSDJ: What do you see happening for the near future?

DF: When I think in terms of the two biggest things that are coming over the next year, I think of two things. The first is Visual Assembly for simplified component and service development. So the WebSphere support for graphical flows and a standard Web service flow language. This, combined with BRBeans will provide simple and powerful application development and customization functions.

The second big thing is multi-channel support. Customers come in on multiple channels. The problem people have had with the stovepipe problem was, in essence, that the application was vertically integrated. It was presentation, business logic, and data. The channel wasn't represented in the application.

There were quite a few things early in WebSphere that enabled multi-channel support. Obviously the Web front end was put in there, but most people don't realize that from the very beginning WebSphere was agnostic to the actual markup language that you used.

So, our Servlet and JSP front-end and tools supported various markups, including PDA and cell phone markup languages as well as voice markup for voice channels. We had support for thin clients; we had an ActiveX-VB bridge; we had a CORBA client. In essence, the middle-tier server supported the business logic in the channel. We documented that as a style of programming. We think of the Web as one channel. You can code your business logic independent of a channel. You can add other channels as needed. There's been a fair amount of stuff we've done to improve that. We've got the multilanguage markup support, Transcoding Publisher, WebSphere Everyplace for mobile devices, and WebSphere Portal Server.

More Stories By Jacques Martin

Jack Martin, editor-in-chief of WebSphere Journal, is cofounder and CEO of Simplex Knowledge Company (publisher of Sarbanes-Oxley Compliance Journal http://www.s-ox.com), an Internet software boutique specializing in WebSphere development. Simplex developed the first remote video transmission system designed specifically for childcare centers, which received worldwide media attention, and the world's first diagnostic quality ultrasound broadcast system. Jack is co-author of Understanding WebSphere, from Prentice Hall.

More Stories By Pat Martin

Patti Martin is cofounder of Simplex Knowledge Company, where she is Vice President of Creative Services. She manages the company's Web servers and oversees Web content and creation. Patti received her education at the New School in New York City and has taken continuing education classes at NYU and the School of Visual Arts.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.