Is it certain that to the word communication corresponds a concept that is unique, univocal, rigorously controllable, and transmittable: in a word, communicable? Thus, in accordance with a strange figure of discourse, one must first of all ask oneself whether or not the word or signifier “communication” communicates a determinate content, an identifiable meaning, or a describable value.
Two years ago when the first edition of this book was initially published, Java was attracting unprecedented attention from its early success in bringing dynamic content to web pages. The question “Is Java ready for serious development?” was on everyone’s mind. Presenting pretty pictures is one thing, but supporting the complex needs of enterprise development is very much another thing. Could Java leverage the infrastructure of existing business environments and take it where existing tools could never imagine going?
Today, Java’s power as a server language is taken for granted. Ironically, due to problems with the early versions of the AWT, people tend to question its stability on the client. APIs such as JNDI, the servlet API, the security API, and the suite of APIs collectively known as the Java Enterprise APIs—JDBC, RMI, and Java IDL—together make Java a formidable force on the server. The leap from being a good server development language to being a powerful enterprise development platform, however, is still far.
Unfortunately, the word “enterprise” most certainly does not communicate a determinate content, an identifiable meaning, or a describable value. Just about every technology product aimed at the business customer is sold with the tag—the buzzword—“enterprise.” As with any technology industry buzzword, the marketing people have twisted it and made it into a meaningless term. If you pull the marketing fog away, however, you can find an important concept that the word “enterprise” once captured. Within that meaning, the power of Java is fully realized. Before you get into the heart of Java Enterprise’s capabilities, you should first understand what the term “enterprise” means in the context of enterprise software.
Buried within the term “enterprise” is the idea of a business taken wholistically. An enterprise solution identifies common problem domains within a business and provides a shared infrastructure for solving those problems. If your business is running a bank, your individual branches may have different business cultures, but those cultures do not alter the fact that they all deal with customers and accounts. Looking at this business from an enterprise perspective means abstracting away from irrelevant differences in the way the individual branches do things, and instead approaching the business from their common ground. It does not mean dismissing meaningful distinctions, such as the need for bilingual support in California branches.
Applying this view to software engineering, an enterprise system provides the proper abstractions for business concepts that are constant across a business so that they may be shared by all the different units within the company. In the Internet age, enterprise systems even go beyond sharing those business concepts within the company to sharing them with vendors, clients, and customers. A detailed look at an example of a manufacturing company can better illustrate how to look at a business from the enterprise perspective.
For this example, the hypothetical manufacturing company, Wombles, Inc., makes all sorts of goods—toasters, blenders, tire irons, light bulbs, etc.—and has three major business units: North America, Europe, and Asia-Pacific. The company started out as an American company. As it grew, it acquired two other companies to gain a worldwide presence. All three business units have their own systems and are mostly ignorant about the issues involved in doing business in the other two regions. Marketing, however, has worked hard and successfully at creating a single, world-recognized brand.
As long as each unit works within its own realm, everything runs smoothly. From the perspective of each unit working within its own realm, however, they might as well be three separate companies. Certainly, moving beyond the distinct realms of each business unit in this environment is a formidable task. What do you do if Asia-Pacific runs out of light bulbs but North America experiences a light-bulb glut? What do you do if your distributors want a single interface into your inventory system? What do you do if your customers, who do not care that you are divided into three separate business units, demand direct and immediate online access via the Web?
An enterprise system answers all of these questions. You have one single repository of inventory and pricing information—a single repository that enables the individual business units to customize, but share this pricing information. Your vendors are then presented with a single interface into your inventory management, and web-enabling access to those systems is nothing more than writing Java servlets.
Note
Throughout the book I make reference to software “systems.” With the advent of distributed computing, the terms “system” and “application” have lost any clear definition. For the purposes of this book, when I refer to a system, I am talking about one or more backend processes that support one or more user interfaces. When I talk about an application, it is almost always in reference to one of those user interfaces.
In order to solve enterprise problems, an enterprise system must exhibit certain characteristics. The goal of an enterprise system is simply to be able to represent business concepts to any possible user whether that user is an application within your business, an XML interface for your vendors or clients, or a web interface for your customers. An enterprise system enables you to worry about the specific issue of providing an appropriate window into your business for each audience without duplicating the effort required to capture the rules of your business—the things that never change. An enterprise system must therefore meet these requirements:
- An enterprise system must have minimal proprietary components.
Avoiding proprietary components means, among other things, being platform- and database-independent. You cannot impose technical requirements on your vendors, clients, and customers. Do you think Amazon.com would sell any books if they required all visitors to run MacOS? This requirement, however, goes beyond simple platform requirements for your audiences. It also means being able to integrate new components into the system as technology evolves. It is much harder—and often impossible—to integrate new technologies with closed, proprietary components.
- An enterprise system must be capable of supporting personalized user experience.
Personalized user experience comes in many forms—internationalization, localization, accessibility, personalization, and customization. Meeting this requirement means supporting the creation of user interfaces that can display content tailored to the language and cultural norms of the user interacting with the system. It also means supporting tools on the client that help make an application accessible to users with disabilities. Finally, an enterprise system needs to be able to study the way users interact with it so that it can better support each user’s unique mode of interaction.
- An enterprise system must be the authoritative, shared source for the business concepts it represents.
All applications using concepts common across the business should reference the objects that represent those concepts from the same shared system. This does not mean that they are referencing the exact same processes on exactly the same servers. It means that any given concept has an authoritative location that is transparent to the client from which it can be referenced.
Get Database Programming with JDBC & Java, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
