Welcome to the second installment of the monthly eDBA column where we explore and investigate the skills required of DBAs as their companies move from traditional business models to become e-businesses. Many new technologies will be encountered by organizations as they morph into e-businesses. Some of these technologies are obvious such as connectivity, networking, and basic web skills. But some are brand new and will impact the way in which an eDBA performs her job.

In this column and next month’s column I will discuss two of these new technologies and the impact of each on the eDBA. This month we discuss Java: next month, XML. Neither of these columns will provide an in-depth tutorial on the subject. Instead, I will provide an introduction to the subject for those new to the topic, and then describe why an eDBA will need to know about the topic and how it will impact their job.

What is Java?

Java is an object-oriented programming language. Originally developed by Sun Microsystems, Java was modeled after, and most closely resembles, C++. But it requires a smaller footprint and eliminates some of the more complex features of C++ (e.g. pointer management). The predominant benefit of the Java programming language is portability. It enables developers to write a program once and run it on any platform, regardless of hardware or operating system.

An additional capability of Java is its suitability for enabling animation for and interaction with web pages. Using HTML, developers can run Java programs, called applets, over the web. But Java is a completely different language than HTML, and it does not replace HTML. Java applets are automatically downloaded and executed by users as they surf the web. But keep in mind that even though web interaction is one of its most touted features, Java is a fully functional programming language that can be used for developing general-purpose programs, independent from the web.

What makes Java special is its multi-platform design. In theory, regardless of the actual machine and operating system that you are using, a Java program should be able to run on it. Many possible benefits accrue because Java enables developers to write an application once and then distribute it to be run on any platform. These benefits can include reduced development and maintenance costs, lower systems management costs, and more flexible hardware and software configurations.

So, to summarize, the major qualities of Java are:

• its similarity to other popular languages
• its ability to enable web interaction
• its ability to enable executable web content
• its ability to run on multiple platforms

Why is Java Important to an eDBA?

As your organization moves to the web, Java will gain popularity. Indeed, the growth of Java usage in recent years is almost mirroring the growth of e-business.

So Java will be used to write web applications.  And those web applications will need to access data. Which is invariably stored in a relational database. And, as DBAs, we know that when programs meet data that is when the opportunity for most performance problems is introduced. So, if Java is used to develop web-based applications that access relational data, eDBAs will need to understand Java.

There is another reason why Java is a popular choice for web-based applications. Java can enhance application availability. And, as we learned in the first installment of this column, availability is of paramount importance to web-based applications. How can Java improve availability?

Java is a late-binding language. After a Java program is developed, it is compiled. But the compiler output is not pure executable code. Instead, the compiler produces Java bytecodes. This is what enables Java to be so portable from platform to platform. The Java bytecodes are interpreted by a Java Virtual Machine (JVM). Each platform has its own JVM.

The availability aspect comes into play based on how code changes are introduced. Java code changes can be deployed as components, while the application is running. So, you do not need to stop the application in order to introduce code changes. The code changes can be downloaded over the web as needed. In this way, Java can enhance availability. Additionally, Java simplifies complicated turnover procedures and the distribution and management of DLL files required of client/server applications.

How Will Java Impact the Job of the eDBA?

One of the traditional roles of the DBA is to monitor and manage the performance of database access. With Java, performance can be a problem. Remember that Java is interpreted at run time. A Java program, therefore, is usually slower than an equivalent traditional, compiled program.

Just In Time (JIT) compiler technology is available to enable Java to run faster. Using a JIT compiler, bytecodes are interpreted into machine language just before they are executed on the platform of choice. This can enhance the performance of a Java program. But a JIT compiler does not deliver the speed of a compiled program. The JIT compiler is still an interpretive process and performance may still be a problem.

Another approach is a High Performance Java (HPJ) compiler. The HPJ compiler turns bytecodes into true load modules. It avoids the overhead of interpreting Java bytecodes at runtime. But not all Java implementations provide support JIT or HPJ compilers.

As an eDBA, you need to be aware of the different compilation options, and provide guidelines for the development staff as to which to use based on the availability of the technology, the performance requirements of the application, and the suitability of each technique to your shop.

Additionally, eDBAs will need to know how to access databases using Java. There are two options:

• JDBC
• SQLJ

JDBC is an API that enables Java to access relational databases. Similar to ODBC, JDBC consists of a set of classes and interfaces that can be used to access relational data. Anyone familiar with application programming and ODBC (or any call-level interface) can get up and running with JDBC fairly quickly. JDBC provides dynamic SQL access to relational databases. The intended benefit of JDBC is to provide vendor-independent connections to relational databases from Java programs. Using JDBC, theoretically at least, you should be able to write an application for one platform, say DB2 for OS/390, and deploy it on other platforms, for example, Oracle8i on Sun Solaris. Simply by using the correct JDBC drivers for the database platform, the application should be portable. Of course, this is in theory. In the real world you need to make sure you do not use any platform-specific extensions or code for this to work.

SQLJ provides embedded static SQL for Java. With SQLJ, a translator must process the Java program. For those of you who are DB2 literate, this is just like precompiling a COBOL program. All database vendors plan to use the same generic translator. The translator strips out the SQL from the Java code so that it can be optimized into a database request module. It also adds Java code to the Java program, replacing the SQL calls. Now the entire program can be compiled into bytecodes, and a bind can be run to create a package for the SQL.

So which should you use? The answer, of course, is “it depends!”  SQLJ has a couple of advantages over JDBC. The first advantage is the potential performance gain that can be achieved using static SQL. This is important for Java because Java has a reputation for being slow. So if the SQL can be optimized prior to runtime, the overall performance of the program should be improved. Additionally, SQLJ is similar to the embedded SQL programs. If your shop uses embedded SQL to access DB2, for example, then SQLJ will be more familiar to your programmers than JDBC. This familiarity could make it easier to train developers to be proficient in SQLJ than in JDBC.

However, you can not use SQLJ to write dynamic SQL. This can be a drawback if you desire the flexibility of dynamic SQL. However, you can use both SQLJ and JDBC calls inside of a single program. Additionally, if your shop uses ODBC for developing programs that access Oracle, for example, then JDBC will be more familiar to your developers than SQLJ.

One final issue for eDBAs confronted with Java at their shop: you will need to have at least a rudimentary understanding of how to read Java code. Most DBAs, at some point in their career, get involved in application tuning, debugging, or designing. Some wise organizations make sure that all application code is submitted to a DBA Design Review process before it is promoted to production status. The design review is performed to make sure that the code is efficient, effective, and properly coded. We all know that application and SQL is the single biggest cause of poor relational performance. In fact, most experts agree that 70% to 80% of poor “relational” performance is caused by poorly written SQL and application logic. So reviewing programs before they are moved to production status is a smart thing to do.

Now, if the code is written in Java, and you, as a DBA do not understand Java, how will you ever be able to provide expert analysis of the code during the review process? And even if you do not conduct DBA Design Reviews, how will you be able to tune the application if you do not at least understand the basics of the code? The answer is -- you can not! So plan on obtaining a basic education in the structure and syntax of Java. You will not need Java knowledge at an expert coding level, but instead at an introductory level so you can read and understand the Java code.

Resistance is Futile

Well, you might argue that portability is not important. I can hear you saying “I’ve never written a program for DB2 on the mainframe and then decided, oh, I think I’d rather run this over on our RS/6000 using Informix on AIX.” Well, you have a point. Portability is a nice-to-have feature for most organizations, not a mandatory one. The portability of Java code helps software vendors more than IT shops. But if software vendors can reduce cost, perhaps your software budget will decrease. Well, you can dream, can’t you?

Another issue that makes portability difficult is SQL itself. If you want to move an application program from one database platform to another, you will usually need to tweak or re-code the SQL statements to ensure efficient performance. Each RDBMS has quirks and features not supported by the other RDBMS products.

But do not get bogged down thinking about Java in terms of portability alone. Java provides more benefit than mere portability. Remember, it is easier to use than other languages, helps to promote application availability, and eases web development. So resisting the Java bandwagon is futile at this point.

Conclusion

Since Java is clearly a part of the future of e-business, eDBAs will need to understand the benefits of Java. But, clearly, that will not be enough for success. You also will need a technological understanding of how Java works and how relational data can be accessed efficiently and effectively using Java.

Beginning to learn Java today is a smart move. One that will pay off in the long-term, or perhaps near-term future!

And remember this column is your column, too! Please feel free to e-mail me with any burning e-business issues you are experiencing in your shop and I’ll try to discuss it in a future column. And please share your successes and failures along the way to becoming an eDBA. By sharing our knowledge we make our jobs easier and our lives simpler.