Enterprise computing has a reputation for complexity and, for the uninitiated, is often surrounded by a shroud of mystery. Here are some reasons enterprise computing can seem intimidating:
Enterprise computing usually takes place in a heterogeneous network: one in which the computers range from large mainframes and supercomputers down to PCs (including both top-of-the-line 64-bit processors and outdated 386’s). The computers were purchased at different times from a variety of different vendors and run two or three or more different operating systems. The only common denominator is that all the computers in the network speak the same fundamental network protocol (usually TCP/IP).
A variety of server applications run on top of the heterogeneous network hardware. An enterprise might have database software from three different companies, each of which defines different, incompatible extensions.
Enterprise computing involves the use of many different network protocols and standards. Some standards overlap in small or significant ways. Many have been extended in various vendor-specific, nonstandard ways. Some are quite old and use a vocabulary and terminology that dates back to an earlier era of computing. This creates a confusing alphabet soup of acronyms.
Enterprise computing has only recently emerged as an integrated discipline of its own. Although today enterprise development models are becoming more cohesive and encompassing, many enterprises are still left with lots of “legacy systems” that are aggregated in an ad hoc way.
Enterprise programmers, like many of us in the high-tech world, tend to make their work seem more complicated than it actually is. This is a natural human tendency -- to be part of the “in” group and keep outsiders out -- but this seems somehow magnified within the computer industry.
Java helps to alleviate these intimidating aspects of enterprise computing. First, since Java is platform-independent, the heterogeneous nature of the network ceases to be an issue. Second, the Java Enterprise APIs form a single, standard layer on top of various proprietary or vendor-enhanced APIs. For example, the JDBC API provides a single, standard, consistent way to interact with a relational database server, regardless of the database vendor and of the underlying network protocol the database server uses to communicate with clients. Finally, recall that many enterprise protocols and standards were developed before the days of object-oriented programming. The object-oriented power and elegance of the Java language allow the Java Enterprise APIs to be simpler, easier to use, and easier to understand than the non-Java APIs upon which they are layered.
The messages you should take away from this discussion are:
Enterprise computing is for everyone.
Any programmer can write distributed applications using the Java Enterprise APIs.
With that said, it is important to understand that distributed computing actually is somewhat more complicated than nondistributed computing. Just as using threads in a program introduces complexities that don’t exist in single-threaded programs, using network services in a program introduces complexities that don’t exist in programs that run entirely on one computer. While multithreaded programs have to deal with the issues of thread synchronization and deadlock, distributed applications have to deal with the possibilities of network failure and the complexities of distributed transaction processing. Do not fear, however: the complexities of distributed computing aren’t overwhelming, and, with a little study, any programmer can master them.