Patterns are expert solutions - recurring designs that have proven effective over time. This month's article will provide you with a bit more detail on the subject. When applying patterns to the presentation tier, we address the following: Pre- and postprocessing of a request and/or response Request handling, navigation, and dispatch View preparation and creation Application partitioning

Many new J2EE developers get caught up in focusing on the details and nuances of servlets and JSPs and, as a result, may not learn how to leverage JavaScript. Some may even dismiss it as too much hassle, given cross-browser compatibility issues.

For the past few years I've participated in several projects to update existing Java applications. While working on those projects I often wanted to be able to add new functionality to a class without recompiling it Some of the reasons for this were: I didn't have the right to access or modify a class's source file if, for example, the class was developed by a tier supplier. The class was used in many distributed sites and the new functionality was useful for a small number of sites only.

Most developers build J2EE applications using their own security mechanism. This causes problems when other applications are introduced, because more logons have to be remembered and users have to physically log on multiple times to use different Web applications. A single sign-on allows a user to logon once and have transparent access to all the applications within a domain. In Part 1 we explain what a single sign-on is and how it works, enabling you to implement a single sign-on solution. In Part 2, we'll implement a single sign-on solution for standalone and Web-based applications.

In the beginning there were servlets, and it was good. They were much better than the alternatives, and allowed for scalable, robust Web development. But there was trouble in paradise. Web development partitioned itself into two camps: art school dropouts (invariably Macintosh users) who could create the beautiful look and feel for the Web application, and the Java developers who made it work. The guys in the basement handcrafted the beautiful HTML and passed it to the developers who had to incorporate it into the dynamic content of the Web site. For the developers, it was a thankless, tedious job, inserting all that beautiful HTML into the Java code. But you drank lots of coffee and lived through it.

There are many facets to J2EE Web application development. It's a powerful platform that offers a variety of possibilities and capabilities, with many different approaches and models of development available. This is both a strength and, for newcomers to the platform, an Achilles' heel. In this installment of Journeyman J2EE, we look at the many sides of J2EE development with a focus on the diversity, dichotomy, and divided opinions that can challenge even experienced developers, but especially newcomers. Consider these some warning signs on the road to J2EE.

As the EJB 2.0 specification has entered its final stage, many companies are in the process of building server-side J2EE applications. The final draft of the specification has made container-managed persistence (CMP) of entity beans complete and more powerful.

Patterns are expert solutions - recurring designs that have proven effective over time. This month's article will provide you with a bit more detail on the subject.

Welcome to the first installment of Journeyman J2EE. I'm honored to present this new bi-monthly column of ruminations and reactions as I, like so many of you, make my foray through the vast world of J2EE application development and deployment. But this isn't intended just for newbie J2EE developers. On the contrary, I hope to also share tips and techniques of value to experienced JSP/servlet developers.

Over the last two decades rules have become an increasingly important part of the information technology landscape. In fact, deductive rules have been applied to databases since the inception of SQL and form the basis of policy management and decision making at most corporations. However, the rules are changing. A newer reactive rules solution based on events, conditions, and action (ECA) has come to the foreground.

Welcome to the first installment of the 'Core J2EE Patterns' column by the Sun Java Center (www. sun.com/service/sunps/jdc ). Every other month, we (Deepak Alur, Danny Malks, myself, and other architects from the Sun Java Center) will discuss various topics from our book, Core J2EE Patterns, Best Practices and Strategies (Alur, Crupi, Malks, Prentice Hall/Sun Press, 2001). These topics include each of the 15 J2EE patterns in our catalog, design strategies, bad practices, refactorings and pattern-driven design in the Java 2 Platform, Enterprise Edition (J2EE).

The story so far: In Part 1 (JDJ Vol. 6, issue 4), I covered servlets and gave a practical demonstration of how a basic access control mechanism for intranet applications could be built using Servlet Session Tracking and HTTP Authentication. In Part 2 (Vol. 6, issue 5), I introduced a couple of applets into the architecture and showed how a communication channel could be established between the applets and servlets that comprised the application.

If you are currently looking for alternatives to JSP and you're tired of reinventing the wheel each time, then this article can provide you with the solutions you need to build your Web applications. We'll explore what it's like to develop a Web application using a couple of popular tools that are available today - and I'll use examples to show what it's like to use these technologies on a daily basis.

Many J2EE 1.2-based applications and components are emerging in the marketplace as the J2EE platform matures. Application portability is one of the most important benefits offered by the J2EE platform. Through the J2EE Java Pet Store sample application, the J2EE Blueprints team has developed a set of best practices for ensuring application portability across J2EE-compatible application servers.

J2EE applications are becoming the norm rather than the exception in today's distributed computing environment. But organizations are still facing the same issues with this technology set that they did with application models of yesteryear - how to ensure that they can scale quickly, respond dynamically, and maintain flexibility as their business environment changes.

Java Servlets and JavaServer Pages (JSP) threaten to collapse out there in the mud houses of server land. Developers succumb to the temptation to muddle their pages with complex business logic, and to fill behemoth proprietary libraries with data and subsystem access routines. We find stronger solutions in EJB-based architectures than in fattened JSPs, but molding existing sites into EJB-centric designs strikes most of us as a daunting and expensive task.

Last month in JDJ (Vol. 6, issue 5) we looked at the Java 2 Platform, Enterprise Edition (J2EE) connector architecture (JCA) and its common client interface (CCI). To recap, JCA is the part of the J2EE 1.3 specification that facilitates the integration of Java applications with Enterprise Information Systems (EISs). The term EIS refers to a number of systems such as ERP, legacy databases, or transaction processing systems.

Last summer, Sun Microsystems released the first public draft of the EJB 2.0 specification with a lot of fanfare. Since then, it's been through a whirlwind of discussion, controversy, and modifications. Yes, modifications. The latest release of the EJB specification is Public Final Draft 2, which was released at the end of April.

XML gets mentioned a lot as an interoperability 'platform.' By itself, of course, XML can't be a platform because it's a document format. It may be flexible, human-readable, dynamic, popular, and cool because it looks a lot like HTML, but it's still just a document format, and there are a lot of differences between a document format and an interoperability platform.

The Java Message Service (JMS) is a specification put forth by Sun to define a common set of APIs and common semantics for messaging-oriented middleware providers. An increasing number of MOM vendors have embraced this specification, and new vendors are building messaging products suitable for doing business-to-business communication across the Internet.

In the March issue of JDJ (Vol. 6, issue 3) we discussed the basics behind J2EE security, including coverage of role-based security for both the Web and EJB tiers. In Part 2, we provide an example of implementing J2EE security in the WebLogic Server.

In Part 1 of this series (JDJ Vol. 6, issue 4) I developed a simple access control mechanism for my application using HTTP authentication and servlets. In my view, servlets have always been underrated as a technology.

Every software system has logging requirements so application processing can be monitored and tracked. Modern distributed systems, which are usually based on application frameworks, require a logging solution that can cope with multiple processes on multiple hosts sending logging information to a single logging service.

The notion of guaranteed delivery of Java Message Service messages has been lightly touched on in other recently published articles on JMS. But what really makes a JMS message 'guaranteed'? Should you just take it on faith, or would you like to know what's behind it?

Any individual piece of computer hardware or software can fail. That's why we back up our hard drives. When the hard drive on my laptop failed last year, the tape backup got me up and running in a few days - the time it took to get a replacement drive and reload my files.

As most of you reading this article know, the application server market is growing and every company, large or small, can visualize the benefits an application server infrastructure could bring to their organization. But why then, even with the vast amount of benefits available, have companies not adopted an application server as the foundation for their organization?

The highly structured nature of applications built using J2EE technologies lends itself well to design patterns for performance optimization. This article examines a number of such patterns and suggests optimal ways of using them to improve latency, throughput, and overall scalability of J2EE applications.

The choices can be overwhelming for a development team embarking on an Enterprise Java project. You've read the books, attended the classes, and now know the individual Java technologies pretty well, but how do you choose between them? Should your project be based on servlets, applets, EJBs, any two, or all three?

The Java 2 Platform, Enterprise Edition (J2EE), defines the standard for developing and deploying multitier enterprise applications. At the core of J2EE architecture are application servers - containers for your J2EE components.

This month's article is the first in a two-part series on J2EE security. In Part 1 we'll discuss basic J2EE security. Part 2 will provide you with a model to set up and deploy a functioning security-enabled application. Resident J2EE security guru, Chris Siemback, has been kind enough to join me in coauthoring this series to contribute in-depth examples of J2EE security at work.

The Java Message Service (JMS) is an enterprise-capable middleware component based on message-oriented middleware (MOM) fundamentals. Since its introduction as a Java software specification in November 1998, vendor implementations have brought JMS forward as a first class, e-business messaging communications platform suitable for exchanging critical business data over the Internet.

As a distributed object technology, CORBA provides tremendous flexibility for implementing robust enterprise information systems composed of distributed components. In large-scale deployment, these components run in multiple servers located in multiple hosts of different operating systems.

In EJB/CORBA integration, complexity can range from simple to complex and depends in part on the direction of the communication. From EJB to CORBA, communication is relatively simple because the EJB bean invokes CORBA as it does any external resource. CORBA-to-EJB communication, however, depends on the application server's support of RMI-IIOP. If the application server doesn't support RMI-IIOP, then it's best to create a wrapper or adapter class that redirects or delegates the function calls from the client via a CORBA servant, which then calls the EJB.

It's a pleasure to be writing this article in the beautiful, high-tech, Mediterranean city of Netanya, Israel. It's the evening after the first day of the workweek here - Sunday, of course - in my current consulting engagement. But working Sundays isn't the only thing I've had to get used to here.

If you were to consider all the surface clutter in my life, you might find it strange to know, deep down inside, I like things simple. I mean really simple, because I'm not very bright and have trouble with basic concepts, like getting out of bed and getting the car pointed in the right direction on Monday mornings.

This article outlines how organizations can build and maintain an integrated system infrastructure to support their business needs using open industry standards, such as CORBA, Java 2 Enterprise Edition (J2EE), and XML. In doing this, they can maximize investments in existing technologies and integrate them in a powerful and flexible way into new e-business systems.

This month in EJB Home I'll show you how to build a message-driven bean. Knowledge of this EJB will enhance your toolkit for developing asynchronous Enterprise Java applications - whether they're mission-critical or not.

Generally it's desirable to deploy the Java server in such a manner that it automatically starts when the computer does, and stops when the computer shuts down. This could be quickly and easily implemented by writing an NT service that communicates with the Java server.

At the enterprise level, building and deploying distributed object-oriented components involves a dizzying number of choices and considerations. In contrast to a single-process monolithic system, distributed computing provides the flexibility to delegate computing processing power to a large number of nodes, allowing us to build highly complex systems. Coupled with this flexibility are issues that arise from a system's distributed nature.

By the time you read this, the J2EE revolution will be gaining significant momentum. Most large companies will have some type of new development around it; many more existing and new e-businesses that leverage this technology will have emerged. Many platform providers will have delivered core J2EE functionality, committed resources to transition to this technology, or made plans to build J2EE-based interfaces to their systems. All systems go.... 'J2EE is ready for the masses' will be the theme for the near term.