Sarbanes Oxley Compliance Journal

Jacques Martin

Subscribe to Jacques Martin: eMailAlertsEmail Alerts
Get Jacques Martin: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Birth of a Platform: Interview with Don Ferguson"The Father of WebSphere" - Part three of a three-part series

Birth of a Platform: Interview with Don Ferguson"The Father of WebSphere" - Part three of a three-part series

In the final part of our interview with Don Ferguson, Don talks about the future of WebSphere

WSDJ: What is your vision for the future of WebSphere?
DF: Our current focus is on implementing Web services and simplifying their development. WSFL and tools support for visually and dynamically building new Web services. Business rules support customizing the behavior of existing Web services.

The next big things will be support for better, dynamic binding between a service requester and the multiple implementations that are available. The binding process will be able to consider "quality of service," "price," "reputation," and other extensions available that describe how the supplier implements the services and its operations. Finally, technology like WSFL and dynamic binding will drive the definition of a "business transaction" specification and service. This will support robust, long-running, and complex multi-party business transactions. This service will include support for compensation and information versioning.

The final element of Phase II is multiprotocol support. When people think of Web services they have a tendency to think of WSDL on top of SOAP on top of HTTP. Our model for Web ser-vices is effectively WSDL. We support multiple binding and formats for WSDL interactions. These include SOAP/HTTP, RMI/IIOP and distributed EJBs, and JMS/MQ. We expect other protocols and formats beneath the WSDL abstraction. This allows the programmers to think in terms of Web services, but have the middleware provide optimizations to improve perfor-mance and robustness.

WSDJ: PHASE III will be?
DF:

    1. Multiparty flow monitoring and runtime correction
    2. Improved support for rules
    3. Portable definitions of service flows 4. Business transactions
    5. Runtime monitoring, service level agreements
    6. Multiparty process support

Danny Sabbah once said something about our various business gateway products. He said, stop talking about gateways; there's no inside/outside. That assertion was confusing implementation with concept, but the concept is true. Enterprises will use the Web service model for application integration. This will initially occur within the enterprise, which is one reason we focus on optimized protocols in addition to HTTP. Enterprises will incrementally expand to using Web services for integrating their internal business processes with those of their partners. Thus, both internal and external applications will appear as Web services available on an integration service bus.

One element of the next big wave will be coalitions and partnerships agreeing on a set of business processes and hosting them in something resembling a utility model in the network. The individual corporations in the partnerships and coalitions plug into the hosted processes by wrapping their internal business process and applications with WSDL interfaces. When you think about what enterprises do with their IT technology, it's been a consistent attempt to make it easier for employees, partners, and customers to electronically interact with the systems and to develop new processes more rapidly.

The companies have gone through a set of phases: Phase I was: I fill out a paper form and mail it to you. This might be a purchase order, for example. You respond with mail.

Phase II is: I give you a little browser interface that allows you to fill out the form electronically and then submit it to me. You can also check on the status through the browser interface.

In a B2B scenario, someone sends an e-mail to a purchasing agent in his or her company, who turns around and uses a Web browser to submit the form to the supplier. This is one step in the purchasing process in the enterprise.

Well, why is it like that? Why do we need the Web browser interface? Well that's kind of nutty. Why don't they fill out the Web form on an application in their enterprise to produce a message that goes into their purchasing system and process? The process can directly send the request to the supplier's system. There is no reason to use a human, the purchasing agent, to perform the application integration step that links the two enterprises.

People have the tendency to use new age terms like "Virtual Enterprise" to describe Web services and B2B. For me, it is not that revolutionary. It's no different than what people are doing today. It doesn't change the way people do things; it just makes things faster. It goes from paper, to phone calls to Web pages to messaging.

In terms of enablement, Web services and standards allow people to make decisions about virtual partnerships in a much shorter period of time because it gets the infrastructure out of the way of execution. Once that happens that drives utilities in the market space.

WSDJ: Give us an example of "utility."
DF: If you and I are exchanging messages, someone is going to have to audit them. Otherwise we'd end up in court. So there'd be an audit utility. When you and I bind together, part of what is in the binding extensions is information about who we agree is going to be the auditor. This is a simple example of a utility function in the network.

So logically, I'm talking to you, but physically, we're sending messages to a third party, who is putting them in a log, authenticating them, etc. The utilities may be hosting the flows (processes) to which we have agreed. If we have agreed on a short-duration business partnership, we cannot afford a delay in setting up an infrastructure to host our collaborative processes. So we will express the collaborative flows and their performance requirements in Web services standards (e.g. WSFL, Web services Service Level Agreements) and contract with a utility to host them. The in-network flows use Web services to drive our internal applications and business processes.

Today, people produce "content" and they put it on a network. In the B2B utility model, people define processes and get network utilities to host them.

To do these partnerships there may be a physical infrastructure side of things; we may need somebody to set up a warehouse for us and to set up an inventory management. Instead of doing that in-house, we'll go and contract with somebody to do it. Hosting the Web service definition of business processes is the electronic processing equivalent of contracting for physical infrastructure services.

From a business perspective, if an industrial engineer looked at this kind of thing, and he drew pictures, he'd see a component model. In our economy there is a trucking company, and people who make things. From an engineering point of view or a manufacturing point of view, it's a component model. With Web services, there's now a component model on the Internet that's getting near to the point where it can mirror the model of the economy. And because of that, it allows people to make changes in the way that they do business electronically - much more quickly and efficiently. I see the Internet and e-business, whatever the heck that means, becoming something that mirrors much more closely the physical mechanisms of business. It's a much better electronic representation of how things work physically and how they interact and combine to implement business solutions. I hear a lot of people whining about the economy, "Oh we're in a recession, blah, blah." The thing that determines the wealth of the society is productivity, because you can print all the money you want but you have to make more goods for a fixed expenditure of energy. I think we're on the verge of an electronic revolution of sorts in productivity. While there may be a slowdown now, we are on the verge of a potential burst of productivity improvements through Web services and the Internet.

The Internet is going to mirror the economy. It'll allow the economy to run much faster and more efficiently and it will have as much an impact on productivity as the industrial revolution did. Productivity is going to continue to go up.

It's almost a complete revolution of the way we've done things in the past, Information technology was hard and complicated, so people had to adjust their world model. They had to change the way they thought about the world, so it mapped the way computing works. With WSFL, Web services, portability, services in the network, utilities, it's actually changing. So they're thinking now, the IT infrastructure model is the way the economy works. They don't have to warp the way they do things to match it to IT - that's the big change.

People use wacky words for this sort of thing like "e-Utility" and "virtual enterprise," but it's just photons flowing faster, yet doing the same thing. Shipping is a utility; communication is a utility; warehouses are utilities. All that is happening now is there are electronic components that you can use to customize the way that you do IT. To map the way the world works instead of vice versa. That's without a doubt a big concept.

WSDJ: How do you see WebSphere playing in the pervasive market, now and in the next 24 months?
DF: We're seeing an evolution. WebSphere Portal and WES have been very good products for delivering, for lack of a better term, Web pages to pervasive devices. When we think about pervasive devices a very common mode of usage is something like this - I'm going to fill out a form and then submit it. Something is going to happen on the server. For example, I'm going to fill out a form and I'm going to tell you the stocks I'm interested in and I'm going to submit it. It's going to send some kind of spooky message and I'm going to get a form back that will show me the values. Everyplace and Portal are products that will do that, which is information delivered via a Web browser on the pervasive devices.

That model works, but as pervasive devices get more complex, it's not a great model. So we're doing something, as are others, to develop what we think of as a hybrid-client model. You can envision a world that is a little bit of WebSphere, a little bit of WebSphere Application Server, a little bit of DB2 Everyplace, and a very lightweight MQ footprint on the device. The applications run locally and they use Web services to interact with logic on the network. It's like a portal concept, only from the client side - my device becomes my portal. It will show me my stock prices instead of my filling out a Web form, sending it out and the Web site remembering what my stock portfolio is, and then me polling it periodically. The knowledge of what's in my portfolio is in two places. It's in my financial company, but it's also on my device.

WSDJ: Would that push the future toward CE compared to Palm technology?
DF: A Palm Pilot today has more processing power in main memory than the first IBM mainframe I used. I think you may be missing the extent to which what we think of as server-side middleware can scale down to for pervasive devices. We used to run CICS on mainframes that are almost as powerful as Palms are now. It doesn't mean we're going to do that in the future, because the device is not dedicated to transaction processing. We have to get the footprint down. You can produce packages of our middleware that are down in the 100s of KB in footprint. When you think of Palm devices with 8MB of memory, when we put a middleware footprint that totals 1MB, we're in business and we are there. So we think of it as a hybrid model. There's lots of information on your device. You're using Web services to interact with business logic that is on the network.

Instead of going up to a server for all information, you're saying, "please give me the page with all my Portlets in it," and my device renders it. The Portlets are going to run on the device and make the calls up, "please give me the information," and light up the display.

No one is shipping this now. The point that I'm making is that the "operating system" is not the issue. What we need is middleware on the devices because that's what the application developers see.

When you hear "middleware on the device" it sort of sounds like, "Well yeah, IBM is trying to drive more business." We're above petty mundane things like that. It's more about the fact that sites need to develop applications and functions that can run anywhere in the call chain: client, in-network content servers, edge server, etc. You want a common model for developing business functions. Some people are going to run that on WebSphere on 390 and some people might want to run that on an edge server in a provider network. Some people might want to run it in the Web front end and some people might want to run it on their client devices.

When you think about a portal, it's a mix of things. It's what the enterprise wants you to see, and it's what you want to see. Well, if I want to see something from this company, why do I go back to the enterprise and have them aggregate it? What I want to do is get my Portlets from the enterprise as well as "punch out" to other portals directly from my device workspace.

It's not so much middleware on the pervasive device that is the key thing. What's really important is having a common programming model that allows people to develop components that can run and deploy in multiple places in the end-to-end network. The client device is just one endpoint. Again, this sounds like spooky stuff, but we'll use common sense and there will be some stuff you'll never run on a mobile device or on a mainframe.

Pervasive devices are going to move from just browser pages that rely on data centralization and sending forms back and forth to actually being devices that run some of these Web services and use other ones on the network.

Supporting middleware and Web services on end-user devices enables two things that are critical to pervasive. One, it's much more efficient in terms of communication just to send the stock prices and information than to send the HTML pages that have the stock prices in them.

The second is, it supports what we think of as sporadically connected behavior. For example, I can manipulate information on my personal device, like my expense accounts, and then just ship them off and get the exceptions shipped back to me. This can occur during periods when I am connected to the network.

In essence we've always had this concept in WebSphere, of business logic as services independent of channel. People build a Web front end to channel independent logic. The presentation layer calls the business function through a command abstraction, "Run this command." Then people said, "Well if I have that clean a separation, I can move some of my display functions and JSPs out into edge servers in the DMZ." Then they can move them out into the edge server. Then they can move them out into the servers in a content distribution network. Now why don't I just go all the way and put them on the end device?

In essence, this is what we're seeing. Since we had that clean separation between business logic and presentation, people are taking the person-facing front end, the thing that's really personal, and putting it on the end device. Then, since you've got the command abstraction behavior for calling business logic, you can go use Web services and go asynchronous with the command model

That's where I see the pervasive world going.

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.

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.