There was a time when all a new development project required was a program compiler and an operating system, particularly when the operating system was a complete, integrated solution like OS/400. The language was RPG, the database was built-in, and there was a rich set of operating system functions available to support virtually any application need.
But the face of development is changing, and now you are told that in order to produce an application, you will need something called an application server. It seems that if you desire to use Java as a development language and if you desire to use the facilities of a browser interface, the capabilities provided with the base operating system may not provide everything you need to get the job done.
Not only will this application server cost money, but you will also need to make a choice between a bunch of available offerings, either for the iSeries or for another platform. There are a number of differences in price and feature set between the offerings, and you should consider carefully which server you want to use to develop with.
In this article, I will describe what an application server is, starting with the basic set of services it supplies. I will spend a bit of time discussing the three major offerings available for the iSeries and will finish up with a discussion of some of the important considerations involved when selecting such a critical component of your IT infrastructure.
A New Way to Compute
With the proliferation of the Web, now there’s a new and consistent way of communicating with software users: the browser interface. Browsers tend to not be platform-specific. Users with Linux or AIX or Sun or Macintosh or Windows workstations now can access the same application, in substantially the same way, provided that the application sticks to the standard protocol (HTTP) and the standard markup language (HTML). Sure, there are minor platform differences to be accounted for, but they’re nothing like the differences between a Windows dialog, a 5250 display, and a 3270 display.
TCP/IP networking was a simple solution initially designed to address the problem of connecting more than two computers together in a single network. It had its limits, and for years, the industry tried to develop and roll out much more complex, and admittedly elegant, network protocol solutions. In the end, TCP/IP beat them all, despite its limitations. With TCP/IP, there is now the Internet and large, high-speed corporate
networks, all of which work with the same protocols and can work together when necessary.
RPG is a great programming language—but, then again, so is COBOL and so is C. What you use simply depends on the project at hand and your point of view at the time. Each language has its pluses and minuses, but in the end, they all simply provide a means of syntactically describing the actions a particular piece of software should take.
Then, along came Java. Object orientation (OO) showed up on the scene long ago, but none of the languages that supported it really sprouted legs. Java seemed, finally, to be a language solution that would bring the promise of OO to the mass market and also solve some of the problems inherent in other languages, such as the issues with pointers in the C language. The application server brings these technologies of the Web, TCP/IP networks, and Java together in a way that makes it practical to use them.
Where the Application Server Fits
Figure 1 is a block diagram showing how the application server fits within the overall server architecture. Application software draws from the set of services and tools built into the application server in order to accomplish its desired outcome.
An application server is middleware in the truest sense of the word. It doesn’t interface with the system hardware, nor does it interface with the user. Its purpose is to make the job of developing and delivering the application simpler and more cost-effective. Application servers do not provide a means of communicating with the user (the browser and HTTP server), nor do they offer a means of managing data (a database), nor do they provide the Java execution environment. Each of those functions must be supplied separately. While that may seem terribly complicated, in some cases, it allows the selection of best-of-breed products. OS/400 is somewhat unique in the market, in that those sorts of functions are supplied as part of the operating system.
HTTP server software is the mechanism for communicating with the browser software on a user’s desktop. HTTP servers do offer mechanisms that support application development, such as CGI, along with a variety of product-specific programming interfaces. Direct development of an application within the HTTP server is certainly a possibility, but it could be very painful for all but the most rudimentary applications.
Some services offered by an application server are part of the overall Java standard. These include the ability to deliver Java servlets and JavaServer Pages (JSPs). Another capability showing up in recent application server versions is support for the Enterprise JavaBean (EJB) component architecture defined in the Java 2, Enterprise Edition (J2EE) specification. Other pieces of the J2EE specification, such as Java Transaction API (JTA) and the Java Message Service (JMS), are beginning to show up as well.
A vendor would have a difficult time differentiating an application server product from other vendors’ offerings if support for the Java specification was all the software had to offer. Among the features offered by the various vendors is support for other popular middleware products like messaging services, along with libraries of routines and components ready for integration into your application.
For the iSeries, there are three commercially available application server choices: BEA’s WebLogic, IBM’s WebSphere, and HP Bluestone Software’s Total-e-Server. A number of application servers have been developed using pure Java, so beyond the commercial offerings, I’ve heard stories of success from several sources in getting servers—other than the aforementioned three—to work. However, the vendors of those products are not yet supporting OS/400 officially. (Read “Tomcat for OS/400: An Open Source Web Application Server,” in the December 2000 issue of MC, at www.midrangecomputing.com/mc.)
BEA WebLogic
BEA’s WebLogic (www.bea.com) server is currently the market leader across all the platforms it serves. IBM’s WebSphere seems to be catching up fast, but BEA still has the title. Given the position WebLogic has in the market, there should be plenty of market support and talent available for any size project.
Now at Version 5.1, WebLogic is known to be a leader in specification compliance and performance. Depending on configuration, it may also be more cost effective than some of its competitors. BEA counts among its customers high-volume sites like Amazon.com and ESPN.com, though I don’t believe iSeries hardware is a part of either of those two implementations.
Part of the WebLogic package is an extensive management capability. The Web- based management console supplies a way to look into the ongoing operation of the server with tools that monitor resource usage, view log messages, and manage server operations like startup and shutdown. The administration part of the console supports the configuration of server attributes and manages execution resources like EJBs.
Clustering is another feature available with WebLogic. Not to be confused with the hardware clustering and high-availability support available for the iSeries, this clustering support works at the network level and operates with a set of independent servers. Such support, when used in conjunction with other high-availability options, could make for a very dependable application environment.
IBM WebSphere
IBM’s WebSphere (www.ibm.com/websphere) is gaining ground on BEA for the top spot in the application server market. In fact, a recent report did put IBM at the front, though the data was based on a management survey, not on sales data.
IBM packages WebSphere in three versions: Standard Edition, Advanced Edition, and Enterprise Edition. The primary differences between the versions are the available features. For example, the Standard version does not include support for EJBs, though it will manage JSPs and servlets. The Standard Edition is shipped with OS/400 at no additional charge; it simply must be installed and configured. WebSphere Advanced Edition is available for OS/400 at an additional charge. The Enterprise Edition is not currently available for the platform.
Version 3.5 of the Advanced Edition brought with it extensive support for XML. WebSphere’s XML document services bring a consistent way of interchanging data between existing and new application systems. XML could be big part of the computing future, and WebSphere can provide a platform for getting started.
WebSphere, too, has a management facility. Its browser-based interface allows the management of execution resources and the server itself. A connection to IBM’s Tivoli management infrastructure is available for needs beyond those the Web interface offers.
Part of the functionality of the Advanced Edition is the ability to create and manage transactions. Web-based applications are unique in that they are nonpersistent. That is, as a user visits different pages of the application, the server has no intrinsic knowledge about the user, such as where he’s been or what he is after. In the traditional OS/400 world, there is the concept of a job. A user may traverse a number of screens within the job, but all of the user’s actions are contained, and programs take advantage of that fact. WebSphere, as well as other application servers, bring the concept of transaction persistence—the ability to manage a complete unit of application work—to Web application development. There are ways to do Web transactional processing without an application server, but they tend to be non-trivial to develop and implement. The application server is certainly a simpler way to satisfy the need.
IBM offers a number of application offerings that operate with and within WebSphere. For example, WebSphere Commerce Server supplies much of the functionality necessary to implement a B2C Web application.
HP Bluestone Total-e-Server
Total-e-Server (www.bluestone.com) is one of the servers advertised to be built using pure Java. This fact allowed the product to operate on OS/400 as well as any other platform that had the appropriate Java Runtime Environment (JRE). Recently, Hewlett-Packard purchased Bluestone. HP did not have a competitive application server offering of its own, and I suspect that purchasing Bluestone was the simplest way to get into the market. Interestingly enough, since the HP purchase, OS/400 has been removed from the supported platform list in the Total-e-Server literature. However, if it is truly pure Java, it should still be an option.
Total-e-Server touts many of the same features as WebLogic and WebSphere, including a management console, XML support, clustering, and application management. Beyond those features, it also includes a number of tools directed at the developer. A tool called Visual XML allows developers to browse available databases, create document type definitions (DTDs), and bind data elements from within the databases to Java applications. Another tool that’s included with the package is one that Bluestone calls J2EE Developer. With it, a programmer can create and manage EJB components and develop persistent transactions with those components.
Other Necessary Pieces
Beyond security mechanisms built into the application server, both WebSphere and WebLogic will connect to a Lightweight Directory Access Protocol (LDAP) server. (See “Resource Management the Directory Way,” MC, February 2001.) An LDAP server supplies the mechanism by which security can be established for an application and for the server. By defining users and resources to the directory, and by establishing the relationship between them, an application can determine who has authority to access particular portions of the application and authority to access the data underlying the application. Application servers installed on iSeries systems can either use the LDAP server built into OS/400 or use a server located on another system.
Another significant aspect of Web application security is the protection of information as it flows between the server and the browser. This need is typically addressed by the exchange of digital certificates and the initiation of a Secure Sockets Layer (SSL) conversation. Application servers typically provide a certificate authentication mechanism and will integrate with the SSL support in the underlying HTTP server.
Application servers require both a JRE and an HTTP server to operate. Again, there is an advantage with OS/400 in that these services are included as a part of the operating system; this is not necessarily the case with other platforms. Most of the application server products will work with most popular HTTP servers. JREs (formerly known as the Java Virtual Machine, or JVM) are based on the Java specification, so as long as the JRE supports the level of the Java (such as 1.2) specified by the application server, you should be good to go.
For platforms other than iSeries, vendors often ship a JRE and an HTTP server with the application server. By far, the most popular HTTP server is the Apache server, and IBM has announced that Apache will be the HTTP component of WebSphere. Apache is just coming to OS/400, and PTFs are already available to use it with WebSphere.
Development Considerations
Developing an application using an application server is a new experience for many programmers. Properly developed, an application should be able to operate without alteration on any hardware platform that the application server supports. The key word here
is should. All too often, platform-specific pieces creep into applications, and changing platforms becomes difficult, if not impossible. You should plan for a platform change during development if a future change is anticipated at all.
While software written for a particular application server may port easily to the same server running on another platform, it may not port easily to another application server. Each vendor adds its own unique APIs to an application server, beyond the APIs called for in the Java specification. Development done with these server-specific interfaces may be a bit faster and may solve some distinct problems, but the resulting software may be tied to a specific vendor and product. Such development may not be a bad thing, but it is something that should be given deliberate consideration.
Making the Choice
Figure 2 (page 40) contains a list of features one should consider when selecting an application server. Most of the servers on the market will address each item in the list, to some extent, but some may have differences that affect your decision. For example, on platforms other than iSeries, it may be important that the application server connect to a specific database product.
Consider, too, any expected changes in user delivery that you may find necessary. A prime example of such a change today is the use of wireless devices. New application software will likely need to communicate with wireless devices like cell phones and personal digital assistants (PDAs) in addition to a traditional browser, and some sort of intrinsic support for them in the application server will be a good thing.
Other selection factors to consider include the levels of Java specification support and what pieces of the “alphabet soup” you will need or want for your application in the future. Figure 3 (page 41) is a list of a number of the acronyms you will likely run into when evaluating products.
Don’t discount the “free” solutions. Each of the three commercial products that I’ve covered bundles facilities for using J2EE technologies, but open source versions of those facilities can be added to any one of those products. (Read “Open Source WebOS,” in the November 2000 issue of MC, at www.midrangecomputing.com/mc.)
The Microsoft Factor
So far, this discussion has centered on Java application servers. Recently, Microsoft settled its long-running licensing battle with Sun, and in doing so, chose to remove any intrinsic support for Java from Windows. Instead, Microsoft launched its Microsoft .NET series of products, based on its Component Object Model (COM) architecture. The programming language for Microsoft .NET will be a new offering from Microsoft called C# (pronounced C sharp), a language similar to Java but with a decidedly Windows twist to it.
Microsoft .NET will offer the same sort of services and components that the Java application servers do, except that the resulting applications will operate only on the Windows platform. For some applications, that may be an acceptable limitation—though the extended scalability available with other, non-Intel hardware platforms may be a deciding factor.
In the end, the standardization that Java is bringing to development is a good thing. As programmers, we can now train developers in a common fashion while utilizing their skills across a number of application development problems. Today’s application servers bring with them a potential for software portability that’s never been seen before.
Applications can be delivered to wider audiences, on scalable platforms, with an ease not seen in the past. By taking some care in the selection of an application server and by taking some care with the development of the software that runs on it, you will have a flexible, manageable, and powerful way to deliver good software.
REFERENCES AND RELATED MATERIALS
• BEA Systems home page: www.bea.com
• HP Bluestone Software home page: www.bluestone.com
• IBM’s WebSphere home page: www.ibm.com/websphere
• “Resource Management the Directory Way,” Randy Dufault, MC, February 2001
• “Web application servers power e-commerce,” Paul Ferrill, Network World, September 25, 2000, www.nwfusion.com/research/2000/0925bg2.html Figure 1: The application server is true middleware, existing between the application and other services on the platform.
• Platform the server operates on
• Supported HTTP servers
• Supported databases
• Supported client systems (e.g., browser, wireless)
• Datastream and protocol support (e.g., HTTP, XML, WML)
• Security and directory support
• Transaction-management support
• Fault-tolerance capabilities
• Clustering support
Figure 2: There are a number of basic capabilities to be considered when selecting an application server.
CORBA Common Object Request Broker Architecture DOM Document Object Model (part of XML)
DTD (XML) document type definition EJB Enterprise JavaBean
J2EE Java 2, Enterprise Edition
JAR Java ARchive (file)
JDBC Java Database Connectivity JMS Java Message Service
JNDI Java Naming and Directory Interface JRE Java Runtime Environment JSP JavaServer Page
JTA Java Transaction API
JTS Java Transaction Service LDAP Lightweight Directory Access Protocol WML Wireless Markup Language
XML Extensible Markup Language
XSL Extensible Stylesheet Language
Figure 3: Evaluating an application server requires a fair amount of “alphabet soup” decoding.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online