Weaving WebSphere

Development Tools
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times
"Oh what a tangled web we weave, when first we practice to deceive."
--Sir Walter Scott

While the original quote was a moral caution against lying, it's also a pretty good metaphor for what happens when we who were brought up with the IBM midrange platform first start developing Web applications. Replace "deceive" with "Web-enable," and you've got the gist of it. The first thing that happens is that you run up against the term "WebSphere," and life gets really confusing, really quickly.

That's because IBM has decided that it would integrate its software offerings in a move similar to its hardware product line consolidation. Not so long ago (really, just a couple of years ago), WebSphere as a name meant simply the WebSphere Application Server. And believe me, that was complicated enough. However, today the WebSphere umbrella includes so many other things that you can get lost before you even get started.

This column is going to try to make sense of all that. While the focus is going to be primarily on the initial WebSphere Application Server product offering and what it can do for you and your business, I will also touch on some of the many other offerings that fall under the WebSphere name. The WebSphere Application Server is a powerful and fully featured Web application server. Nothing more, nothing less. However, the WebSphere name is currently tied in to a myriad of other things, so it would make sense to sort some of them out.

IBM breaks WebSphere into three basic sections: Foundation and Tools, Reach and User Experience, and Business Integration. While perhaps not the most intuitive of names, the WebSphere family comprises these three categories.

The Foundation and Tools section includes all the products needed to build a Web presence. WebSphere Studio, for instance, is an amalgam of tools, constantly changing, that are designed to help us develop applications. WebSphere Application Server, the granddaddy of the group, is the piece that actually presents your Web applications to the end user. And the WebSphere Host Access group contains Host-on-Demand, IBM's screen scraper technology. With a combination of these, you can build just about any sort of application that you would like, and take advantage of your legacy systems, at least to some point.

The Reach and User Experience category includes IBM's WebSphere Commerce, WebSphere Portal, and WebSphere Pervasive offerings. These are application frameworks designed to help you quickly create business applications. Commerce is designed for Web storefronts, Portal provides tailored Web access for remote users, and Pervasive adds support for alternate interfaces, such as voice and wireless.

Finally, the Business Integration group focuses on integrating business systems, as the name implies. It's all about workflow, collaboration, and electronic interchange, using MQ Series (now dubbed WebSphere MQ), standard data transfer using EDI and XML, and canned connectors to packages such as Ariba and SAP.

Of these three categories, this column will focus most strongly on the Foundation and Tools offerings. That's a measure of my own personal bias; I come from a strong application development background. I assume that you're reading this column because you've got iSeries applications that you need to get to the Web, as opposed to building a Web application from scratch. But even if you are developing an entire system from scratch, if you are using the iSeries as your server, then this column will be a good place for information.

Notice that I qualify the platform. Even though this is MCMagOnline and I assume that you're an iSeries user, that assumption may not necessarily be true. This is the Internet, after all, and you may have gotten here by using a search engine (Google being my personal favorite) to look for anything having to do with WebSphere. That's the additional complexity thrown into the whole subject: Different WebSphere components are targeted to run on different combinations of every IBM platform and several others besides. For example, the original WebSphere product, the WebSphere Application Server, runs on the following operating systems: AIX, HP-UX, Linux, NetWare, OS/2, OS/390, OS/400, Solaris, Windows 2000, Windows NT, and z/OS.

So, when you talk about WebSphere, it's not like talking about MAPICS (or my old friend BPCS). The days of software designed to run solely on the iSeries are numbered, at least at IBM, and so instead you have to understand your deployment options. You can conceivably use WebSphere Portal Server on a Solaris machine to talk to WebSphere Application Server running on a Linux box that uses stored procedures to talk to RPG programs on an iSeries written with WebSphere Studio running on Windows 2000. And at night, the iSeries can use WebSphere MQ to batch data up to your z/OS machine.

Honest.

So what is the right deployment option? More and more, that is going to depend on what your particular needs are. Gone are the days of a simple Token-Ring network of 5250 display stations hooked up to a standalone midrange. Heck, gone are the days of a LAN with PCs running Client Access hooked up to a midrange server. Today, you need to assess your business applications not in terms of number of user profiles, but in terms of "zones of access." Who needs access to this application? The answer to that is going to depend on the application. Is it just internal employees? How about remote or mobile employees? Business partners? Clients and vendors? The general public? And how are they going to access these applications? Client access? Thick clients running on Windows? Web applications running in browsers? Voice or wireless communications? EDI? XML?

As you begin to explore the options, you'll find that different applications will need different forms of access. Even if you're a direct-to-the-public distributor with a full-blown Web storefront, it's unlikely that you're going to want Web access to your general ledger application. So rather than trying to force everything into one model, you'll probably find yourself faced with supporting different interfaces for different systems. The good news is that WebSphere can probably help with just about any of those areas. The bad news is that it's not easy to know which piece of WebSphere to use for which application.

As I said, this column will focus on the Foundation and Tools portion of WebSphere to help you get access to your existing applications and data on your iSeries. But I'll try to incorporate information about other parts of WebSphere as well; this wouldn't be a WebSphere column if it didn't at least acknowledge all those other pieces.

To start with, I will focus specifically on the WebSphere Application Server--what it is, how to get it, how to install it, how to run it, and finally how to use it as part of your overall application deployment strategy. However, feel free to contact us here at MagOnline, and me specifically, to let us know what areas are important to you. That way, this column can best serve your needs.

Joe Pluta is president of Pluta Brothers Design (www.plutabrothers.com) and the author of eDeployment: The Fastest Path to the Web. You can email Joe at This email address is being protected from spambots. You need JavaScript enabled to view it..

BLOG COMMENTS POWERED BY DISQUS