Preface

A few years ago, before J2EE (Java 2 Platform, Enterprise Edition) became such a dominant platform for building enterprise systems and long before Web services became central to the IT^[1] strategy of every small and big company, I was tasked with helping a small company use one of our products more effectively. This company, which must remain unnamed for reasons of privacy and professional conduct, was setting up an infrastructure for creation of a dynamic and collaborative community of businesses so that their people and systems could exchange digital content and information over the Internet in the most appropriate, secure and timely manner. Our sales and marketing department did a good job in convincing them that our soon to be released product, let us call it ProdX, was built to satisfy exactly the same requirements. After numerous technical meetings and the promise of premium customer status, free technical support, training and unrestricted access to the development team, they agreed to use ProdX.

^[1] IT, or Information Technology, is usually referred to the technologies for processing, storing and transporting information in digital form.

ProdX was built and promoted as a Java-based middleware product suite with a strong and unique security architecture for allowing companies to do business over the Internet. However, few people outside the security development team, a sub-team of the overall ProdX development group, understood this architecture well and even fewer knew how to use its APIs effectively or how to set it up for data center operations. Developers, managers and operations staff of the customer company had numerous meetings, conference calls and e-mail exchanges, either through me or directly with the security development team. And still, they did not feel comfortable.

At that time, security wasn't the focus of my primary job and I must confess that I was also having difficulty in comprehending certain aspects of ProdX in the context of its use. Watching these interactions, it became obvious to me that the security team had a sound cryptographic background and were deeply involved in developing state of the art security theory and standards, but had little appreciation of the fact that our customers were more interested in having their developers know what APIs to use, how, when and where to use them and having their operations people know how to work out step-by-step processes and procedures for routine and emergency operations. Eventually, they did get what they wanted and were able to go live with ProdX. However, we all felt that the whole thing took a lot more time and attention than required.

Since then I have spent a lot more time working with J2EE-based products and Web services infrastructure software. As an architect, I have also participated in the development of Java standards for Web services, reviewed many software products in these areas and interacted with many customer organizations and listened to their security, performance and other concerns. In the meantime, the Java platform, its security architecture and APIs have continuously evolved and matured. However, none of this has eliminated the gap between what is available and what is in use.

I attribute this to many factors. The reality is that some of the technology is new and, at times, quite complex. At the same time, the changing ways of using the Internet for business-critical operations and the increased threat of a security breach have kept practitioners on their toes. This constant churn at both ends has kept the gap alive and kicking. It is the aim of this book to narrow this gap, at least in the area of J2EE-based Web applications.