Helping ordinary people create extraordinary websites!
| |
Helping ordinary people create extraordinary websites! |
Java and SNA: A case studyBy Matt MacKinnon, Adam King, David Kaminsky2003-05-24 
Java and SNA: A case study
This report describes a Java tool kit for CPI-C programmers. As published by Sun Microsytems, Java supports on sockets programs on IP network. We describe a tool kit that allows programmers to write LU6.2 programs in Java. We also include preliminary performance measurements. Intranets are hot. So is good barbecue, and while we know what goes into good barbecue[1], there's a lot of disagreement about what comprises any intranet, let alone a good one. Since an intranet (like barbecue) is likely no better than its components, it's worth investigating what's in one. The word "intranet" is derived from the "Internet," a world-wide collection of interconnected computers. However, an intranet is not merely a collection of interconnected computers--those have existed in enterprises since the 1960s. Some might try to define an intranet by the networking protocol (or simply "protocol ") used to ship information among computers--that is, intranets are networks of computers communicating via the "Internet Protocol" (IP). Such a definition is narrow-minded: networking protocols are rather arcane subjects, left to the domain of a few computer bit-heads; the average computer user doesn't care about how packets are shipped around a network. He does care about applications, since they define how he interacts with his computing environment. The better the applications, the more productive he'll be. He also cares about cost--who doesn't? User productivity is measured by the amount of work each person can complete--in this case by using the applications running on the network. It encompasses such factors as reliability and application "intuitiveness." "Cost" refers not only to the cost of the hardware used to build the network, but also to the cost of operating and servicing the network and the applications running on it. With these factors in mind, we'll define an intranet as a low-cost, high-productivity network environment. It's clear that for user productivity, IP offers great benefits. Web browsers such as Netscape's Navigator (Navigator is a trademark of Netscape Corporation) provide an intuitive, graphical way to locate any resource spread throughout IP networks[2] ; SNA applications often present a character-based interface. Furthermore, relative to SNA, IP is quite easy to install on personal computers, thus lowering costs. However, 70% of business data resides on mainframes and is accessed primarily through SNA, an enterprise-quality, open, networking protocol. The SNA protocol-handling code on most mainframes has been optimized for over a quarter-century and is now lightning fast; the mainframe IP code is still relatively immature and sluggish. So, compared to SNA, IP imposes a large burden on the mainframe and thus increases the cost of productivity. Even when the mainframe's IP code matures, SNA will continue to offer benefits. SNA was designed for stability under heavy network loads; IP collapses meekly under similar circumstances [3] . Compared to IP, SNA's superior reliability characteristics will continue to offer productivity benefits. Furthermore, SNA includes transactional APIs which simplify the development of line-of-business applications. So there will remain a place for both IP and SNA: IP is quite useful for the general Internet, where ease-of-use and ease-of-install are especially important; SNA is preferable in many intranets, where reliability is crucial. In this paper, we'll focus on ways to improve SNA intranets by applying Internet technology. One Internet technology that has garnered much attention lately is Java (a trademark of Sun Microsystems), a network-enabled computing environment developed by Sun Microsystems. Java is a useful technology for two reasons: It is platform-independent, so applications can be written once and run on a variety of computers; and it can be dynamically downloaded--that is, code can reside on a server and flow to the client as needed, thus reducing client-installation costs. However, the Sun developers chose to release Java with IP bindings but without SNA bindings. We have removed this limitation. To improve Java's suitability for enterprise, high-reliability intranets, we've created a Java binding to CPI-C, an open API for SNA's LU6.2. We recognize that the majority of SNA applications use LU2. We chose to do an LU6.2 binding first because it can run on peer workstations, making it a relatively simple learning platform; LU2 requires mainframe interaction, complicating development. With the skills developed during our LU6.2 work, we plan to push forth to other communications protocols. To date, we've implemented the 16 CPI-C calls needed to write the five "classic transactions": Pipeline, Credit Check, Inquiry, File Transfer, and Database Update. Implementing the remaining 31 calls in CPI-C version 1.2 will be straightforward. The remainder of the paper discusses our Java binding to CPI-C, including a discussion of the Java/CPI-C API and the development issues that we encountered. For our development, we used the OS/2 Warp operating systems and the CommServer 4.0 SNA stack and CPI-C API. Some familiarity with Java and CPI-C is assumed. Tutorial Pages: » Java and SNA: A case study » The Java/CPI-C API » Classic Transaction #1: The Pipe » Classic Transaction #5: The Database Update » Native Calls » Diversion: Native Calls and Applets » Performance » CPIC Calls That Have Been Implemented » Conclusions » Footnotes First published by IBM DeveloperWorks
|
 |