The TPF Super Web Server Solution
Position TPF as the very high volume web server solution by capitalizing on TPF's industrial strength qualities. Establish synergy with other IBM web offerings in order to Provide a comprehensive, cost effective, solution to the problem of explosive Internet growth.
As we speak the Internet is undergoing a transition from a passive to an active (interactive) environment. The majority of web servers today contend with mostly read only access to static data. As traffic becomes interactive the current stateless operation of the Internet is less viable. As complexity in the interaction with the end user increases the need for persistence will increase. As network bandwidth problems are resolved (direct digital connections) the volumes per site will increase. Volume will drive profitability in web serving. In a free access model, analogous to the TV networks (ABC, NBC, etc.), revenue is driven by paid advertising which is in turn driven by market share. In the pay-as-you-go model (HBO, etc.) the cost per use will be fractions of a cent and profit margins small, again demanding volume to be successful.
Such scenarios will drive Internet players to industrial strength computing platforms. TPF with web server capabilities can be a formidable player in large scale environments. TPF should not be a ubiquitous web server used by thousands of web sites, but focused capability based upon the needs of existing TPF users and new users with large scale requirements.
Many TPF customers have already connected their existing systems to the Internet. This has required interim servers that either converted current bit streams (screen scrape) or used some sort of generalized data stream. This has worked admirably in most cases but has some inherent drawbacks. First is the fragile data problem. A lot of cycles are spent interpreting data that may change in format from time to time. The intermediate servers also can cause performance bottlenecks and or management problems as their numbers grow. Nothing beats locality to data. Worse is the duplication of effort; cycles spent in TPF to format data only to be sent to another server that must reconstruct it anyway. The cycles here at tier two are better spent adding business value, not acting as a Pasteur protocol converter for TPF.
Conversion of existing text traffic to HTML would allow the use of a NC as an alternative to an IWS. This may indeed be looked upon as another dumb terminal, but it is a dumb terminal with graphic capabilities. This would allow existing applications to work with ANY browser enabled client (IWS, NC, PIM, etc.).
Graphics (pictures) and various forms of static information (terms and conditions, help screens, etc.) can now be stored, in ASCIT, directly on TPF to augment existing text streams. Quite sophisticated presentations can now be achieved on what remains basically a two tiered (dumb terminal to server) model.
A web server gives TPF the capability to store and serve up Java applets. This can be useful in two or three tiered architectures as a way to hide TPF particulars behind a Java interface. One of the most annoying problems in TPF customer sites is the passing of data between disparate systems. Data structures are inherently fragile and small changes continuously cause problems on both sides of a connection. Attempts at generalized data streams (EDI, EDIFACT, etc.) have helped but often become quite involved themselves. An alternative is to have each platform responsible for its own data structures and hide them from others. TPF could pass Java applets that are specifically constructed to decode specific data structures. The applets would be cached at the client (no performance impacts) and only updated as the data structure itself changed. The applet would only expose methods for getting at the data, not the data itself. Further, the applet could use more direct socket-to-socket calls with TPF to avoid HTTP/ HTML overhead. In other words, with applets it is not necessary to change all current output to HTML. Merely add some welcome, security and informational web pages that cause the necessary applets to traverse the connection. The applets would talk across sockets to existing applications and allow them to keep their current data formats. This approach should work with end users (browsers) and interim (tier two) servers that have business logic dependent on TPF data.
Sending applets that implement a socket connection to TPF and hide the data representation from the rest of the client architecture is a great first step. However there remains nonstandard code at both ends of the network. Eventually one would want this arrangement to give way to standard solutions such as RMI (remote method invocation for Java) and IIOP (Internet Inter-ORB Protocol). This would allow Java and C++ client code to talk directly to TPF applications without specific knowledge of network protocols. topography, etc. With IIOP, an Object Request Broker (ORB) can be used to simplify application design and enable some transaction semantics. This would be a large step in removing all awareness of TPF from client code and network management.
To learn more To learn more, contact the TPF Client Executive at 1 888 759-8888 Pin 1142911 or 1 914 433-6511. You may call an IBM marketing representative or call IBM DIRECT at 1 800 IBM-G11l, in the United States and Canada, or IBM FAX at 1 800 IBM-4FAX or 1 4·15 855-4329.