© 1998 Symantec Corporation
All rights reserved.
 |
|
The Journey to Reliable Distributed Applications July 27, 1998 Client: Symantec Corp. Upstream Analyst: John R. Rymer
Executive Summary
for Commercial Distributed Systems Java is no longer just a language to make eye candy for Web browsers. Java has become the focal point for construction of applications that break down the limits of today's business automation, making applications that directly represent business activities. We now take for granted the ability to tap databases that run somewhere across a network. We also assume the Internet's worldwide reach into a growing number of homes and business establishments. However, these advances are just the beginning of a broader movement to network-based applications that make possible direct interactions with customers and suppliers. Coming are distributed applications that are flexible enough to adapt to changing business requirements. The real potential of Java in the enterprise is to balance the cost-efficiencies of electronic commerce with the personal and flexible services customers demand. Java occupies a central position in the movement to widespread distributed
systems. The term distributed systems includes Web-enabled (HTML)
applications, Web-based (IIOP, etc.) applications, multitier client/server
applications, and new agent-based applications. Java on the middle tier
is being used to support each of these twists on distributed systems. Java
offers several features that are essential to creation of any and all of
these distributed architectures.
Java began its move into enterprise systems during 1998, as early adopters began building server-side code with the language. Still, there are many factors that could impede Java's path into enterprise systems. At the top of this list is the uncertainty created by Sun's battles with Microsoft over the definition of a Java platform. Will Java be just a language, as Microsoft insists it will be? Or will Java be a broad language and platform to support portable, distributed applications, as Sun insists it will be? The most likely outcome is that there will be a single Java language and many Java platforms. Users will have a choice among deployment platforms for their Java applications. The only unknown is how portable and interoperable these platforms will be. Java's performance is another perceived reason to delay adopting the technology. In fact, the Java language and the tools that support it are maturing as the basis for enterprise applications. Still, Java might not advance quickly enough on all fronts to support the scalable performance and reliability required in enterprise computing. The result could be slower progress of the language in creation of serious applications. These uncertainties will determine only how and when Java becomes a
tool for enterprise development. Java's future in the enterprise is assured
by the groundswell of interest in the language among developers of all
stripes--and the demonstrable benefits of the language in distributed applications.
Java's role is becoming clear as the first intrepid users push beyond Java
applets and build business logic that runs on servers.
Java's Point of Entry: Middle Tier Applications Pundits who portray Java as a replacement for the flawed technologies of the past are selling religion, not solutions. Neither the Java language nor the nascent Java platforms are ready to replace CICS, Tuxedo, SQL, and other the other war-horses of enterprise business systems. Java's point of entry into enterprise systems will be as a technology that extends and integrates existing applications, not as a replacement.
Figure 1: The Role of Java Servers in Enterprise Applications. Java will be employed to extend, integrate, and even repair existing applications. The Java server will also be the primary request-handling service in the architecture. Java's dynamic nature makes it ideal for servicing a wide variety of unpredictable requests from users. Java's ability to support a wide variety of user interfaces will also be a benefit.. As illustrated in Figure 1, Java application logic deployed on a middle-tier application server can extend and integrate core business applications, databases, and other "back-end" systems. Java middle tier servers will eliminate two sources of pain in enterprise systems today. First, most organizations are struggling to overcome the barriers between their accounting, customer records, inventory, sales, and other core business systems. The barriers between these systems exist because the applications were built at separate times by separate teams and often with different technologies. Second, organizations are struggling to use the Internet's worldwide
reach to speed interactions with business partners and streamline transactions
with customers. The struggle is marrying the Web's stateless pages with
record-oriented, secure business systems. Java will address both of these
issues. The early users of Java in the enterprise have already taken this
approach.
Role #1: Brokering user requests for services received via Internet protocols (often from the Internet itself). In most cases, the user requests are simple, but satisfying those requests is not. In the Giga Information Group example, requests are expressed as search criteria, some of which is provided by the user and some of which is part of a predefined profile. Giga supports a wide range of content searching and categorization options. The combination of application functions required to satisfy each request is unpredictable. The Java server parses the requests and invokes the required services. Role #2: Managing the invocation of application functions and the retrieval of information in response to user requests. Simple user requests require complex actions by databases and other back-end systems. In the case of Fidelity's new customer account application, a customer might have to tap a half-dozen mainframe applications to obtain the desired information. The Java server in the Fidelity application runs a set of rules that mask this complexity from the user, while maintaining security and data integrity. Role #3: Running business logic that either performs calculations, integrates information, or executes business rules and policies. The scope of this logic is much more limited than, say, the logic in an accounting application. These examples contain many familiar concepts. Middle-tier logic is the hallmark of three-tier architectures. Many companies use the Internet to access business systems. Java in the enterprise embraces these concepts, but adds new wrinkles, as well. First, Java's ability to load classes and components on the fly makes it flexible enough to cope with fluid application demands. At the same time, Java tools and IDEs will give developers the option of compiling static elements of their applications to obtain faster performance. Second, Java is simpler than the other major languages used to build middle-tier application logic. Java's automatic memory management and simplified structure (no pointers) have made it twice as productive as C++ in many shops. Still, Java has semantic power that rivals C++. Where does Java go from its beachhead on middle tier servers? Java will adopt a central role in corporate information processing. First, developers will use Java to build larger and more complex middle-tier applications than is typical today. Next, developers will begin to use Java to manage data on the middle tier, in coordination with production databases. Finally, database developers will begin to use Java to write stored procedures. The availability of Java for creation of logic on all tiers of an enterprise environment will give development shops leverage of their skills that they don't enjoy today. Today, most shops have at least three groups of specialists, each of which works with a different language or tool. Most development shops build client code with one language (often Microsoft Visual Basic), build databases and database procedures using a second language (usually a SQL variant), and build middle-tier logic using a third tool (often C++). Maintaining these three separate skill categories is more expensive than it is to develop a staff with one set of language skills that is applicable to all tiers in an enterprise architecture. The Enterprise Java Beans APIs will key Java's evolution as a language
for both middle tier logic and for database processing. This evolution
will unfold during the next two years, but corporate development shops
will get started when the first products supporting middle tier logic creation
appear during 1998.
The Java Technology Supports
Java's journey into all tiers of enterprise computing will take time because the technology carries so many new concepts with it. Java incorporates the ideas about modular software components and distributed systems of the last 10 years. Java anticipates systems and applications based on software components distributed across networks working in constantly changing relationships. These concepts are evident in the Java language itself. The Java language is based on objects and interfaces, classes and inheritance, and incorporates memory management features to support dynamic, object-oriented systems. (See Figure 2.) Objects and Interfaces. The core structure in the Java language is the object, which encapsulates data, or variables, and methods, or procedures that perform operations on or with that data. Java objects are called classes. A class has a well-defined interface that is a contract to perform a given set of operations on its variables when called upon to do so. This interface hides the class's implementation, meaning that clients can use a class without having knowledge of how that class is implemented. Strong interfaces promote what Meilir Page-Jones called low coupling, or interdependence of classes (The Practical Guide to Structured Systems Design, Prentice-Hall Inc., 1988). Systems with low coupling will operate more efficiently and promote reuse to a greater extent than systems with highly interdependent classes or modules. Classes and Inheritance. A Java class is a template for instances created by applications to perform work. The class definition lays out the variables and methods all instances of that class will have. In addition, Java allows developers to create a new (child) class by inheriting the definition of one other (parent) class, and adding either methods or variables to the parent class's definition. The result is consistency and productivity. Dynamic Object System Features. The Java language has several
features that make dynamic, distributed object systems more
practical to build than they have been using C++ and other languages.
The central problem in distributed systems is that the development team
doesn't control all of the system resources (memory, etc.), and may not
control all of the classes used in a given application.
The Java technology also includes a component model that extends its benefits in the enterprise. Java components that run on clients are called JavaBeans, and are exactly like Microsoft's ActiveX Controls. Server-side Java components are called Enterprise Java Beans. Java Beans (components) are different from Java objects (classes) in
three primary ways.
Components and Interfaces  Figure
3: Components and Interfaces. The illustration describes
the variables and the methods of a component that calculates discounts.
The interface, made from the methods of the component, is shown at the
right of the illustration.
components have interfaces, and these interfaces make it possible to use the components in a number of different applications. Take, for example, a Java component that calculates the discounts, based on the company's policies. An order-processing client would call upon the discounting component to calculate the discount available to a customer for a given order. A marketing client would call upon the discounting component to help in creating new promotional programs. A production planning client would call upon the discounting component to help forecast demand. (See Figure 3.) The discounting component addresses a single set of closely related tasks, rather than a collection of diverse tasks. Page-Jones calls this characteristic of software modules cohesion (in this case, functional cohesion). Strong cohesion between Java Beans promotes low coupling, contributing to efficient design and strong reuse. Good cohesion also ensures that developers will link components only in semantically consistent ways, eliminating many bugs. (For instance, the discounting component is irrelevant to a component that manages personnel records.) The Java Beans architecture, thus, promotes low coupling and high cohesion in software designs. This makes it practical for skilled programmers to build components for use by business domain experts. JavaBeans allows development shops to reduce costs in three ways. First,
JavaBeans designed for reuse will cut the amount of code that developers
must write to build an application. Visualize a Java enterprise component
as an engine that performs work when called upon to do so. The engine can
be used and reused to build a number of applications, eliminating the need
for each project team to build the equivalent functionality. Customization
of components using properties will make components useful in a number
of applications.
How JavaBeans Aid Maintenance
Figure 4: Dynamic Components Aid Maintenance. The figure shows the three primary ways that JavaBeans can reduce the cost and complexity of maintenance. 1. A developer installs a new version of an existing component to expand the order management functions. The execution environment allows both versions to run if required to support applications dependent on the first version of the order component. 2. A developer installs a new, faster implementation of the pricing component. The interface to the component remains the same. 3. A developer adds a new discount-calculating component to the environment. Second, JavaBeans will reduce the need for expensive skilled programmers to build some applications. Developers will be given a palette of components, and simple scripting tools to link together components to obtain the desired behavior. This technique will be applicable to both user interfaces and to server-side functions. Enterprise Java Beans will help to deliver this vision by providing conventions for server-side components from many vendors. Third, Java Beans will reduce the costs of changing applications to meet new business requirements. Today, much of the business logic in an application runs on the client. Developers must update and recompile all clients to make changes to the business logic. By concentrating business logic on servers, developers can reduce the cost and complexity of making these changes. (See Figure 4.) Java's ability to load classes and components on the fly supports this approach, but JavaBeans make it practical. Java's dynamic processing model is well suited to this vision of distributed applications. Java allows classes and components to be loaded on the fly in response to requests. Java applets, which are dynamically downloaded clients, were the first manifestation of this design. However, the same principle will allow developers to design Java servers that select from a range of functions and behaviors to respond to requests for service. In enterprise Java, requests, responses, and components can be put in motion as needed to support the user requirements. For example, a client request for information about the affect of recent discount policies on sales might cause a special analysis tool to be returned to that user, along with links to the discount component to obtain the most recent status information. The user would then have the option to explore the discount data for trends and indicators. No other language supports behavior this dynamic and responsive. Platform Requirements for Java in the Enterprise The emergence and evolution of Java platforms incorporating these services will be a crucial indicator of Java's readiness for many enterprises. Since Java burst on the scene in 1995, much has been made about its readiness for use in enterprise applications. Most of the discussion has concerned the language itself. However, without Java platforms, Java was impractical for all but the most skilled, most adventuresome enterprises. Until 1998, Java platforms were incomplete and immature. Sun's new Enterprise JavaBeans specification provides the catalyst to remove this limitation. The Java technology encompasses both a programming language for creating application code and a platform upon which to run that code. The split between the Java language and the Java platforms is the source of great and unnecessary confusion about Java. There will be many platforms for Java applications in the enterprise during the next several years. The Java platforms from Sun, IBM, Oracle, and Netscape are likely to be similar as a consequence of the cooperative work by these companies. However, IBM, Oracle, Sun, and Netscape won't provide exactly the same platforms for Java applications. Microsoft will promote Windows as a platform for Java applications. BEA Systems, Persistence Software, WebLogic, Novera, NetDynamics, and many others will also participate in this market with still different ideas about the functions that a Java platform should offer. The need for vendors to compete will promote diversity in Java application
platforms. Given this expected diversity, developers will face two questions:
Enterprise JavaBeans Essentials
How can I ensure that Java code built to run on one platform will be
interoperable with code running on a different platform?
The EJB APIs separate the creation of component content from the platform services required to support components, stripping away a great deal of systems programming that otherwise would be required. Java platforms will automate the low-level system details, freeing application developers to call the services needed to accomplish their business purpose. EJBs will also foster interoperability between different systems. The rich range of Java platforms available ensures that most corporations will install more than one platform to support their applications. The EJB interfaces will provide a single set of programming semantics and messaging conventions to link these diverse systems. Indeed, by wrapping non-Java systems to look like EJBs, organizations can include their legacy systems in their Java enterprise frameworks, as well. Microsoft is pursuing exactly the same goals for Java as Sun (and the same profile of services) with its Distributed Network Architecture (DNA). DNA is based on 32-bit Windows APIs and application services including the Microsoft Transaction Server (MTS) and Microsoft Message Queues (MS MQ). Microsoft has begun to expose DNA through Java APIs. The trend reinforces the conclusion that one way or another, the vision of distributed components for enterprise Java will come to pass. Tools Requirements for Java in the Enterprise Java has also been impractical for most enterprise development until now because the available development tools fell short. Symantec's Café, Microsoft's Visual J++, and other early tools were aimed at creating applets to run inside browsers. These tools provided few of the features that enterprise developers needed to build complete applications; features such as database access, code partitioning, and source code management. In addition, the first tools were adaptations of products used to build client/server applications. This, too, is changing, as vendors begin to address the highly distributed and modular nature of Java applications. To be fair, the tools vendors had to wait for Sun and its Java allies to complete several key pieces of Java platform technologies. The most important of these was the Java Database Connectivity (JDBC) API, which gave developers a way to read and write records stored in relational databases. With JDBC completed, tools vendors pushed ahead creating graphical tools that make interaction with databases straightforward. Enterprise Java Beans will add still other data-integration options to the picture, including the automatic synchronization of Java objects with relational tables. Several vendors implement mapping today, including Persistence Software with its PowerTier EJB, Sun with its Java Blend technology, and Thought Inc. (CocoBase). Oracle and IBM will also offer Java-to-relational mapping approaches. However, the tools also must evolve to support the unique requirements of the distributed applications Java supports. When Java burst onto the scene, the two biggest categories of programming tools were client/server products (such as PowerBuilder) and developer workbenches (such as Microsoft's Visual C++). Client/server tools are used to build form-based user interfaces and bind them to databases. Workbenches are used to write all manner of code, much of it quite complex. Java tools for the enterprise will follow these basic product profiles,
but add several additional features. These include the following.
Ideal Java Development Environment
Figure 6: Ideal Java Development Environment. The ideal Java development environment for the enterprise will build on basic Java programming with graphical development and assembly tools, testing and deployment features, and component management facilities. In addition, in this emerging field, no vendor has a monopoly on good ideas. Tools vendors with extension APIs and partnership programs will ensure that developers will have the ability to employ third party products in conjunction with their development environment of choice. Third party tools will contribute in modeling, component reuse, and other disciplines. Performance and Optimization. Java performance is complex because of the language's roots in interpreted systems. The Java Virtual Machine interpreter gives the language its tremendous flexibility, but is also slower by nature than compiled code. Tools vendors have to rise to the challenge of making Java fast as well as flexible. Dynamic, or just-in-time, compilers such as those of Symantec that compile Java byte codes on the fly have proven an effective technique for speeding Java performance. Native code compilers and optimizing techniques will also play a big role in server-side Java, as developers seek to squeeze the last nanosecond of speed from their code. In addition, profilers and other utilities that help developers design fast code, will be essential. Component Development. Java tools must allow developers to deliver applications in the form of components. During the next 18 months, most of the emphasis in Java tools will be on products that help programmers build components. However, in the long run, tools that allow business analysts, systems analysts, Web developers, and even skilled end users to assemble components to create applications will be just as important. There are many more professionals capable of assembling business applications by linking and scripting the behavior of prebuilt components than there are skilled programmers capable of building components. Only by moving to component assembly will organizations be able to meet their escalating demands for new software. (Figure 10 shows the division of labor made possible by component software.) If the goal of component development and assembly is to be realized, organizations will need Java tools that help coordinate component creation across separate developers or teams of developers with source code and component repositories. Experience indicates that components built in isolation are difficult to lash together to create new applications. Also, organizations will increasingly be able to buy software components such as the discounting server discussed earlier on the open market. Component software will have a big effect on developer productivity and software costs if organizations can reuse components in more than one application, whether those components were built by internal staff or purchased from a vendor. The heart of component management and reuse is repository technology. Repositories store the critical information about the designs, interfaces, and uses of components. This is the crucial information required to support component reuse. Distributed Debugging. Enterprise Java applications will demand distributed debugging to account for their heavy use of networks. Distributed debugging will allow developers to test and debug their applications in either simulated or live conditions. The debugger must give the developer fine control over the scope of debugging and provide features like breakpoints and augmented identification of errors. Java provides the basic technical features for dynamic systems. However, tools vendors will have to build deployment frameworks that make dynamic systems practical. Deployment frameworks automate the organization and installation of collections of components, and then help the developers change those systems over time without breaking existing applications. Operational Management. Distributed applications have always been riskier than centralized applications because they have more potential points of failure and because failures are difficult to fix. Java applications will be no exception. To mitigate these risks, development tools must make it possible for developers to generate code that is "instrumented" for operational management. Instrumented code can be monitored and even controlled by external management agents, which is a requirement in enterprise systems. The previously discussed repository technology will provide an essential foundation for these functions. Operational management tools will rely on repositories for basic information about components, as well as readings on their status. The first Java development tools were primarily designed to allow text coding and basic debugging. However, enterprise Java developers won't be able to live by coding tools alone. The ideal Java tool for the enterprise will provide a Java development environment, but also graphical tools to raise productivity, testing and deployment tools, and component management features. The ideal tool will also be open, via extension APIs and partnerships with vendors of complementary tools. (See Figure 6.). Java Performance in Enterprise Applications Much has been written about the performance (or lack thereof) of Java
applets, but these analyses do not indicate how well Java will perform
in the database applications used by enterprises. As the pioneering enterprise
Java developers report their findings, the picture of Java performance
in the enterprise is becoming clearer. Java performance will be determined
by several factors, including but not limited to them the efficiency of
Java Virtual Machines and compilers. Indeed, performance will often be
a function of the developer's application design. The performance of Java
applications will be determined by five factors
Interpretive vs. Compiled Code  Figure
7: Compiled vs. Interpreted Code. A key determinant of
performance in Java applications is the use of interpreted code. Interpreted
code runs more slowly than compiled code, but it is much more flexible
and portable than compiled code. Developers must manage this tradeoff to
build fast applications. Fortunately, dynamic compilers ease the tradeoff
by preserving most of the flexibility of interpreted code while improving
execution speeds to equal compiled code.
Factor #1: Inefficient Designs and Implementations. First, no language ensures that developers will design and write fast performing application code, and Java is no exception. Developers can write slow Java code just as easily as they can write plodding C++ code. A common problem is dead code, or functions that run but are never used in an application. Dead code slows overall performance. In addition, Java applications can be slowed by overuse of network and disk input-output operations. Factor #2: Multithreading. Java's integral multithreading can improve performance. Multithreaded code will allow developers to accomplish more than one task simultaneously, improving throughput. However, developers must carefully test multithreaded code to detect and eliminate locking deadlocks, which will kill an application performance. Factor #3: Tradeoff Between Interpreted and Compiled Java. Java
performance will be a function of how the developer manages the choice
between the flexibility of interpreted code and the speed of compiled code.
A completely interpreted application will pose performance challenges.
A completely compiled application will sacrifice the complete flexibility
of Java's dynamic
Performance: Java vs. C++
Figure 8: Performance of Java vs. Performance of C++. NC World's tests of Java and C++ illuminate the real differences between Java and C++ performance by comparing not only compiled C++ to interpreted Java, but also compiled C++ to dynamically compiled Java (Java/JIT). The authors of the tests pronounced dynamically compiled Java and compiled C++ equal or equivalent on most operations. processing model. Ultimately, most enterprise applications will employ both compiled Java and interpreted Java. (See Figure 7.) The need to manage the divide between interpreted and compiled code in Java has given rise to a variety of new compilers and other optimizing utilities. Dynamic, or "just-in-time," compilers have allowed Java programmers to make great strides toward eliminating the distinction between interpreted and compiled code by compiling Java byte codes as needed to speed performance. A recent set of tests published in NC World showed that Java with a just-in-time compiler ran as fast as compiled C++ on most of a series of operations. In the one dynamic operation tested (virtual member method call with runtime type identification), Java with a JIT was much faster than C++. In these tests, interpreted Java was three times or more slow than C++. (See Figure 8.) The tests employed Symantec's JIT compiler. Factor #4: Java Automatic Memory Management. The overhead of Java's automatic memory management, also known as "garbage collection," will inevitably slow performance. NC World gauged the impact on performance of garbage collection by allocating and freeing 10 million 32-bit integers first in C++ and then in Java. The operations required twice as much time in Java as in C++ during the test. The difference was 0.7 seconds, a price most developers with C++ experience are willing to pay to eliminate dreaded memory leaks. Factor #5: Java Virtual Machine Performance. The performance of the JVMs themselves is a prime determinant of an application's speed. The newest JVMs are much faster than the first JVMs available. These improvements will continue. The Impact of EJB and Internet Standards Enterprise Java Beans is the latest in a series of Java standards that are both far ranging and diverse. Sun Microsystems, from Java's beginnings, has tried to design standards for Java development that will ensure the absolute portability of Java code. Sun has created these standards with the cooperation and support of IBM, Oracle, Symantec, Netscape, Sybase, BEA Systems, and many other companies. Understandably, Sun and its partners have expended a great deal of effort seeking to keep the promise that Java code written once will run anywhere even as the Java technology changes and expands. As the range of standards for Java systems grows, absolute portability becomes difficult to maintain, and will require creativity and single-mindedness of Sun. These difficulties will be compounded by divergence in HTML and other World Wide Web standards that are an essential part of many Java applications. The primary reason for this state of affairs is natural industry competition. Java technology is evolving toward the vision of dynamic cooperating components. However, a variety of vendors have different ideas about how this vision should be implemented. The competitive battles over systems architecture between Sun and Microsoft are the tip of the iceberg. In addition, Oracle is fighting to maintain a central position for its database servers in Java applications. Oracle's Java implementations will add proprietary content to achieve this goal. IBM and BEA Systems are battling over transactional systems and middleware for Java, and each will create extensions to the EJB standards to showcase its distinctive product features. And so on. (See Figure 9.) The result of industry competition has been and will be variations on
Sun's Java standards that compromise portability. The question is: Must
Java be absolutely portable for the technology to succeed? The answer is,
"No." There are two reasons. First, Java may never be absolutely portable,
but it is and will be highly portable. In addition, Java technology implementations
will be highly interoperable. Object-oriented interfaces are at the core
of the Java technology, and this foundation will make possible the interworking
of different Java technology implementations. In enterprise systems, interoperability
(interworking) between the products of different vendors and among different
applications is more important than code portability. Every major survey
of corporate IT requirements highlights the need to weave disparate systems
and applications together to integrate business functions for market efficiency
and effectiveness. The Java technology is in the right place at the right
time in this regard.
Emerging Java Domains  Figure
9: Emerging Vendor Java Domains. IBM, Sun, and Microsoft
are creating their own Java platforms and interfaces, each of which will
be different enough to impede absolute portability of application code.
The figure shows at the bottom the major product categories that compose
a complete system architecture. IBM and Microsoft have complete coverage
of these categories today, and will use Java to enhance their respective
market positions. Sun lacks only a DBMS and applications. At the right
of the figure are the major computing platforms. IBM has coverage of its
own platforms, of Windows NT, and Sun's Java Platform. Sun covers Solaris
and the Java Platform. Microsoft covers Windows only. This picture is the
inevitable result of competition. However, Java's object-oriented features
will ensure strong interoperability, which is more important in enterprise
systems than pure portability.
The historical analog for Java is the SQL language. All relational database vendors add proprietary extensions to standard SQL. However, developers can achieve a high degree of portability by avoiding those extensions. Certainly, SQL is much more portable than the proprietary data definition and manipulation languages that preceded it. In addition, developers have strong mechanisms now to integrate their application code with various SQL databases. Second, standards like EJB will help bring into focus crucial middle tier platform technology that today is in a state of anarchy. Developers have a wide variety of middleware and application server technologies and products to choose from today, many from small companies that enterprise user view as being more risky than IBM, Oracle, Microsoft, BEA and other established vendors. EJB, JDBC, and related enterprise standards will provide a common set of architectural concepts for the industry to rally around, just as SQL did during the early 1980s. The result during SQL's evolution during the '80s was to provide a dominant architecture for data management accessible to clients. The result with the Java technology will be to provide a dominant architecture for distributed application logic and services. Vendors of enterprise Java tools will play a pivotal role in the maturation of these standards. In the same way that the first client/server tools shielded developers from differences between SQL implementations, enterprise Java development environments will make it possible for developers to target different Java server platforms with a single source code base or even the same components. Organizational and Skills Prerequisites Like any other information technology, Java alone won't guarantee a successful application. Most development organizations must learn new skills and adopt new procedures to get the most benefit from the technology. Successful Java development requires three design skills in three areas:
object-oriented code, multithreaded code, and distributed programs.
Appropriate development procedures and organizations are related to skills. The early users of Java have found that the technology is well suited to a modular approach to development. The most expert developers can create software components that less-skilled professionals can then "wire together" to build applications. The discounting component that was cited earlier in this paper is an example. The developer that builds the component can expose key "properties," or parameters governing its use. The rate of discount to be applied to a given operation might be one. By exposing this property, the developer makes it possible to modify the discount rates to meet new needs through a simple form, called a property sheet. Furthermore, the developer of Java components can make it possible to
modify a component without having access to that component's source code.
This characteristic of Java components makes it possible for the source
code of an application to evolve independently of the customization and
configuration of that source code. The result
Java Component Hierarchy
Figure 10: Java Component Hierarchy. Java, with its component interfaces, allows development organizations to specialize, putting programmers to work building a hierarchy of software modules from which applications can then be made. Applications require many levels of components, ranging from those that provide access to database operations, messaging and other systems facilities to those that govern a user interface. The figure describes one scheme for organizing this specialization. A small number of systems programmers build core systems components. Systems and business analysts create components that perform business domain functions, and skilled users employ scripting to assemble and tailor these components to particular application needs. will be a big win for maintenance. Every time an organization installs a new version of an application, it will not have to reimplement all of its customization code for that application. Rather, the externally managed properties will be applied to the new source code (provided the interfaces remain stable). The Java component interfaces ensure that Java and scripting languages will be complementary. Java is best for building rigorous programmatic structures, while scripts are best for building simple structures and for wiring together components using their exposed properties. The modularity that Java encourages specialization within development
organizations. (See Figure 10.)
Next Steps Most corporate development shops have begun the move from so-called two-tier client/server systems to more aggressive distributed designs. There are and will be many struggles in this evolution, as organizations seek a balance between their existing skills and systems and the promising new business opportunities afforded by the Internet. One way or another, Java will be a foundation of these new systems. Some organizations have the experience to put Java to work building
substantial distributed applications right now. However, most should move
more slowly, starting by assessing their skills and architectures, launching
pilots that use Java to extend internal Web sites, and then applying what
they learn to make more aggressive use of the technology. Mastery comes
with experience and experience with Java should start now.
|
 |
Figure
2: Language Comparison. The
Java language is designed to support distributed dynamic object systems.
The language's heritage shows in this comparison with the C++ language
and Microsoft's Visual Basic language. The roots of each of these languages
are also important to understand. Java was designed originally for interactive
television systems, and then adapted to the World Wide Web. C++ is an object-oriented
extension of the C language, and used primarily for systems programming.
Visual Basic was designed to ease the creation of forms-based Windows desktop
applications, and has been extended to address network resources. Each
language has its primary purpose, and is most valuable when used for that
purpose.
