WSDJ: What's your view on Portal Server?
DF: Portal Server is the most significant enhancement to the WebSphere family in a long time. It's a great product.

WSDJ: What are the most significant points about Web-Sphere Portal Server?
DF: The first clever decision was to base it on the Portlet concept from the Apache Jetspeed project. The reason for that is if you are a portal and you cannot be transparently and independently extended by someone who wants to provide content, you're not going to be much of a portal. The Portlet model gave people an open way of adding elements to portal pages. Every other vendor's approach was proprietary. So the open-source Portlet concept actually built a community. People were contributing Portlets to the open-source portal server and WPS allowed a community to build up around Portlets. Portal servers have a tendency to be a "content drags product" sale. People will say "I need these 27 Portlets or things - if you support them, I'll buy your portal."

They really don't make a decision of which portal server is the best one. What are the things I need and which portal supports them? The openness of the Portlet model and WPS builds the content up. This is a big transformation of the way we do business in the Software Group. In the past we'd come in and say, "Look, we have the best product," and then we'd tell people to put their applications on the product. And now with the Portlet models, the nonvisual work we are doing in application integration and B2B and the CrossWorlds acquisition, we have the most complete set of front-end and back-end components running on our middleware products. Portal Server provides the customized, personalized workspace people need to integrate with a rich, complete set of applications. Portal complements our application integration and ISV partners, allowing us to provide all of the parts.

For example, we have great products to do application integration in WebSphere and MQ System Integrator. We have business-process templates that implement supply-chain management and other business processes through CrossWorlds. We have Portlets that provide end-user interfaces to the processes and applications. All a customer or integrator needs to do is a little bit of customization - select an application adapter, maybe add a step in a business-process template, and they have a working solution. And by the way, it all runs on WebSphere message middleware products: MQ, MQ System Integrator, MQ Workflow, and DB2. We support other databases and messaging products, but the story is really powerful when they all come together.

The portal team has been hugely successful in building a community of Portlet developers. Larry Bowden, VP Portal Solutions Software Group, and Carol Jones, chief architect of Portal Server, can flip through pages of available Portlets.

WSDJ: What is WebSphere, what is your synopsis?
DF: The standard answer after this is, "Gee, I was hoping you could tell me." WebSphere is a context-sensitive noun. Meaning, it is the server and all the other things that make it up and extend it.

When we say "WebSphere," we have a tendency to mix two terms. Sometimes with "WebSphere," we mean the Application Server and some of the Enterprise Extensions. And the other times we say "WebSphere," we mean the platform and all of the things that work together, like Commerce, Portal Server, Edge Server, and Business Integrator.

WebSphere is a family of products and a set of standards for doing application integration by supporting the development of new applications and integrating them with business logic and existing applications. WSDJ: Initially, what did the first "WebSphere" customer look like?
DF: What this customer wanted to do was put an integration server in that supported their channels at contact time. The integration server had basic components that wrapped and encapsulated the existing applications and transformed them into a neutral model. If you were programming at this level all you needed to know was how to use a component, a service. You didn't need to know how to talk to CICS, how to talk to IMS or DB2. So it broke programming into two clear skills: people who know how to talk to CICS to produce components and people who know how to use services. We sometimes called this, "the lipstick on the pig layer." It didn't transform what you had, but made it modern and accessible to people through a common approach.

Other programmers did composite services that aggregated basic components. When you think about it, all the people downstream want to think in terms of portfolios and customers. They don't want to think in terms of customer in CICS and customer in IMS and customer in DB2.

We used to call these composites the IBM management objects because they didn't have a lot of implementation. If you asked them a question, "What's the checking balance?", they would just delegate it down to a basic component, so they didn't know how to do anything; they told everyone else what to do.

Then programmers built a process layer on top of the composites. The processes were CRM applications or account management, and used the composite services in their implementations.

With OO people at the time, there would be blood on the floor about what was a verb and what was a noun. The process layer implemented the verbs and the composites implemented the nouns.

The enterprise wanted to put channels in front of the processes and top-level composites. They wanted to do a plug-in to make them available for the Web and make another plug-in available for an analyst's database client. That was the basic problem.

Some of the things that got added as we moved beyond this type of problem was the concept of ISV applications. The big difference between Component Broker and EJB/J2EE is the packaging model. In J2EE, you could now package an application and deploy it. The story we had up until J2EE had been very focused on intraenterprise IT development and system integrators. J2EE enabled ISVs by giving a packaging model. The big insight into J2EE was how to package all of this together in a way that it could be deployed and then extended.

WSDJ: Did you use EJBs for that?
DF: Well, we use J2EE because in addition to deploying business logic you wanted to deploy servlets, JSPs, and data definitions. Then when you really think about it, part of what portal does is it puts a registration layer between the display layer and the business logic layer. This allows administrators to register a new Portlet for new business logic, and configuration can determine which channels and users will see the application portal.

So what the Portlet concept adds is that you don't really need to extensively modify a configurations. The Portlet registers with the portal and becomes visible to users based on device types and roles.

And the next big insight was the Flow Composition insight. In the past, people actually wrote code for sequencing calls to existing objects and services; that is, building the process layer. But, since these composites all have well-defined interfaces, now with the Web services abstraction, you can actually build the processes visually through flow charts- type models. It becomes much more meaningful to people who aren't programmers.

WSDJ: What is the WebSphere approach to Web services?
DF: Historically, WebSphere applications focused on providing users with access to enterprise applications. People came in through Web browsers and used person-facing applications. The Web service support in Web-Sphere allows program-to-program interactions over the Internet and internal networks. This allows companies to directly link business processes, removing steps in which people "manually" use Web browser-based applications to exchange information.

WSDJ: How is Web-Sphere influencing wireless application development?
DF: There are two main influences. First, we're producing small versions of WebSphere and J2EE that run on wireless devices. These support applications that use micro-browsers and forms to support interaction with local applications and data, as well as with Web services accessible over the network. Second, Web-Sphere has always had support for building server-side applications that supported access from wireless devices. We have functions in WebSphere Everyplace, Portal Server, Transcoding Publisher, and our application development tools for simplifying the task of developing an application that supports user access from multiple device types.

WSDJ: Where do you see WebSphere and Web services going in the next couple of years?
DF: The next year is pretty well mapped out. It's continued leadership in standards and more of them. I think that as far as standards are concerned, you're only seeing the very beginning. There are lots of them teed up. There is Web Services Flow Language (WSFL). When you think about it, that's a very powerful concept. SOAP and WSDL are about, "Here's my service." But if you want to make new ser-vices from existing ones, you have to write code. WSFL is a modeling language. It's an excellent language for taking existing services and scripting them together to produce a new Web service.

WSDJ: Why is that a proper concept?
DF: One, it allows you to build development tools that bring the flow-chart skills and business analyst folks into Web services development. It makes it more accessible.

The second one is that it allows ad hoc business integration. If some companies want to run a promotion for six months, WSFL lowers the bar for designing the common processes that support the promotion. Instead of setting up task forces and contracting with companies to develop custom business logic, everyone's going to look at the WSFL diagrams and say, "Yep, that's exactly how a car company, an airplane company, and a hotel company are going to run a promotion for Web site." It lowers the cycle time between concept and partnership. The partnership exists electronically. It's easy collaboration.

The final one, which is very powerful, is to use WSFL for "application portability." The definitions of the processes become portable between middleware and companies, moving the portability up from the details of J2EE and into a higher layer based on WSDL, Web services, and WSFL.

There are two things that have been key to the success of J2EE. One is application portability. The second is interoperability. With Web services, you're no longer worried about the details of the Java code, but what you are worried about is does everyone support Web services flow? Does everybody support Web choreography; do they support SOAP, do they support WSDL?

WSDJ: What are some of the deficiencies in WSDL (Web Services Description Language)?
DF: There is the concept of binding extensions to add additional information, but it isn't codified. So it's enabled but not standardized. For example, you'd want to say that if you invoke these operations you must use a digital signature-based signing and the certificate must come from one of these two certificate holders.

How do you express something like, "I support this operation but don't send it to me directly, send it through an intermediary?" So for services you need extensions to WSDL. WSDL de-fines the interface. We need some standard sets of extensions to document how transactions work, what is required for security, etc. This stuff is coming in 2002.

Next month, Don looks at the future of WebSphere and plans for it down the road.