Several patterns exist for generating primary keys for your EJB application. This month I'll provide a pattern for generating PKs that's scalable, generic, and portable.

CORBA's new Interoperable Naming Service (INS) introduces three features that combine to help manage your computing environment and integrate it better with the Internet and your corporate intranet as well. These features:

This month's EJB Home was originally a presentation at JC2 in Santa Clara, California, in September. For those of you who couldn't make the session, I thought it would be beneficial to transcribe it here and relay an experience in the successful implementation of an EJB application using XP.

Real-Time (RT) systems are, in the temporal sense, predictable. They're not necessarily fast, though many are; they don't necessarily deal with high throughput, though many do. Their defining characteristic is their temporal predictability. They run glamorous, high-risk, high-speed applications such as fly-by-wire airplane and missile controls, military data collection and display, and manufacturing process control, but they also run more mundane applications such as e-commerce transaction systems and materials-handling facilities.

Many of you have been developing EJB applications since the 1.0 version of the specification. In the EJB 1.1 specification the approach toward EJB exception handling has changed slightly regarding the exceptions and transaction management responsibilities between bean providers and container vendors.

The extensive suite of Object Management Group (OMG) standards will, ultimately, unify computing from analysis and design through development, deployment, runtime and support.

It wasn't long ago that many developers didn't know what an application server did. These days it's become part of our common vocabulary. The main reason for this shift has been the rapid growth in the importance of the Internet as a platform for business applications. Without application servers the Internet would be a much less exciting place. This article shows how these vital pieces of the Internet infrastructure have evolved and explores where they're headed.

The buzz at JavaOne 2000, in my opinion, was definitely the solidification of Java in the wireless market. As radio host for SYS-CON Radio at JavaOne, I had the pleasure of interviewing CEOs and CTOs of leading application server vendors. Many of them focused, not on J2EE support, but on how their products are providing wireless solutions.

Separating presentation and logic when building server-side Web-based applications allows you to generate Web pages with dynamic content easier and faster. It also enables Web designers who aren't especially experienced in application development to easily change the appearance of a Web page. For Web sites with information content that needs to change frequently, this advantage means that the update cycle can occur much more rapidly...thus bringing new information to Web site visitors faster.

The Internet originally interconnected a small number of computers at universities and research labs. It was used to share resources and to send e-mail - an incidental application that over time grew into one of the major uses of the network. Everyone knew everyone else, and security was far from the priority that it is today. All this has now changed.…

I'd like this month to offer some editorial thoughts on the e-commerce market for EJB solutions - but first let me just say 'Happy Birthday' to the EJB Home column and briefly recap the articles that have appeared here over the past year.…

Persistence Software, Inc., recently released the latest version of its EJB server, PowerTier 6. It's a little different from your run-of-the-mill EJB servers, though. This JavaOne 2000 special-edition issue of EJB Home will enlighten you about PowerPage, a hot feature that will put PowerTier 6 on every EJB evaluator's radar!

Developing distributed applications, in contrast to developing traditional single-process applications, requires a completely different level of monitoring and diagnostic support. In this article I'll discuss how to monitor and diagnose distributed applications based on the CORBA standard.

Discussion groups have recently been abuzz with talk of "coarse-grained entity beans" - a slight misnomer deriving, I suspect, from the addition of mandatory entity beans in EJB 1.1. This month I'll examine the finer points of the Enterprise JavaBeans specification regarding coarse-grained entities, as well as my own, and provide an example for you - with plenty of comments to provide food for thought when you tackle the challenge yourself.

OMG members met in Denver, Colorado, the week of March 6-10, 2000. In this column I'll summarize as many of the various efforts that progressed as space permits.

As much as I hate to admit it, Microsoft was a pioneer in server-side component architectures. Its COM/DCOM (Distributed Component Object Model) server-side component model for building and deploying components in the Microsoft Transaction Server (MTS) environment already had applications in production by the time the Enterprise JavaBeans specification was publicly released in March 1998.

Many three-tier applications built using various middleware products ultimately fail in production due to a lack of scalability, flexibility or reliability. This can trigger a need to migrate an application from one middleware product to another. In this article we'll discuss a process for porting servers between CORBA and EJB middleware implementations.

We've all heard about the great benefits of distributed computing, especially in the areas of scalability and performance. With Java, implementing a distributed solution has never been easier or more practical. We're given three distributed object options that work quite naturally with Java: namely, Java RMI, CORBA and EJB. The issue that many Java developers face when pondering distributed architectures is whether or not a distributed solution is appropriate for the problem at hand. Often the problem being attacked is one that has been traditionally solved in a nondistributed fashion. One approach for finding distributed solution potential is to look for basic tasks in your software that can be broken out. Once you identify these tasks, all you need is a framework for distributing execution.

When I started working with Java, I mentioned my move to a colleague of mine, a Microsoft devotee. He wasn't willing to move to the Java platform until supporting integrated development environments (IDEs) were as powerful and easy to use as Visual Basic. Although at the time nothing in the Java world was as simple or configurable as Visual Basic, I bit the Java bullet - and the bullet tasted like VisualCafé. Originally from Symantec Corp. (www.symantec.com) but now owned by an independent company created by Warburg, Pincus and BEA Systems, VisualCafé was the closest Java IDE in the industry that could compare to VB, and it remains on the bleeding edge of support for new Java technologies. This month in EJB Home I'll discuss what to look for in an IDE that supports EJB, as well as the support for Enterprise JavaBeans development that has been integrated into the VisualCafé Enterprise Edition for WebLogic.

The recent issuance of an RFP for "Unreliable Multicast" in CORBA got me thinking about the many network semantics available in a combined CORBA/Java environment. There are at least five already, not counting Unreliable Multicast: Java RMI invocations; CORBA synchronous invocations; CORBA asynchronous and messaging-mode invocations; one-way notifications using the CORBA event and notification services; and the Java Messaging Service (JMS). In this column I'll review the basic characteristics of these services side by side. I'm not planning to rate them as "better" or "worse" on any scale - they're more different than better or worse, and you should choose among them based on the requirements of a particular application. The discussion will be confined to invocation semantics. While there are a lot of interesting contrasts between object activation semantics, I'll save that topic for a separate column.

Critically important to the reliability of an application is how software components work together and how resilient they are to change. This article discusses how to perform functional testing on servers in the middle tier of distributed applications. We'll also address key middleware standards from the testing perspective, namely CORBA and Enterprise JavaBeans.

I expect great things from Enterprise JavaBeans this year, one of which is dominating the e-business front as the component model of choice for server-side application development. E-business is multifaceted, encompassing e-commerce (monetary transactions over the Internet), business-to-business solutions and internal Web-based applications that provide flexibility and innovation in the services companies offer. E-business innovation has improved customer care and fostered repeat business for companies like Amazon.com, Dell and numerous online investment sites, to name a few.

There's a lot of action going on with Java servlets. The recent public release of Java Servlet Specification v2.2 by Sun Microsystems enhances the functionality of the programming model and the deployment and runtime infrastructure of servlets, which provides for better packaging, security, distribution and management of servlet-based Web applications. The servlet technology is now a part of the Java 2 Enterprise Edition (J2EE) architecture and is expected to play an important role in the Web/enterprise application server market that has hitherto been dominated by proprietary programming models.

The Enterprise JavaBean specification demonstrates the evolution of distributed objects from middleware to application components. In this article we'll discuss where EJB fits into the distributed object landscape.

Often we think of security as a burden, a time-consuming process that requires us to jump through hoops just to get through a doorway or view a Web page on the company intranet. My first real appreciation for (or frustration with) security came a number of years ago. I was a PowerBuilder consultant in Minneapolis, helping the Federal Reserve Bank build its first-ever client/server application. Each day it was a hassle just to get past the security desk in the lobby, and the bombing of the World Trade Center in New York that year did nothing to ease the pain.

We set out to build a generic framework for creating Java client/server relationships. Our hope was to encapsulate all of the messy details of the relationship, allowing developers writing a client or a server to focus just on their particular application. This would allow our team to swiftly create client/server relationships relying on robust, fully debugged classes to handle communications. We wanted a framework that was simple and easy to use, but flexible enough to handle multiple communications methods.

CORBA - the Common Object Request Broker Architecture - is an open, vendor-independent standard for software interoperability based on object technology. You've used CORBA even if you haven't heard of it by name:

I was asked to stick my neck out and write on the future of Enterprise JavaBeans in year 2000. Just so you know, I was one credit away from a minor in the classics (you know, Greek mythology, ancient Rome and Egypt). However, since I didn't major in this field, nor even minor in it, don't hold me to anything I say for I'm no Oracle at Delphi. I'm just a soothsayer from Boulder, Colorado, and even then I'm only one of many (though most in Boulder foretell fortunes based on constellations, tarot cards or your sign!).

The philosophy behind the Java 2 Enterprise Edition (J2EE) announced at JavaOne in June 1999 is to package the Java 2 platform with a collection of "Enterprise APIs," including Servlet and Java Server Pages (JSP), and an application programming model to define a standard platform upon which enterprise applications can be built. The first public release of the J2EE specification became available in October 1999, and a final draft is expected this month (see http://java.sun.com/ j2ee/).

Last month, in EJB Home, I covered the business advantage of Enterprise JavaBeans' portability from a high level. First I discussed the various types of portability. Then I covered (1) the portability goals the creators of EJB had in mind when developing the specification and (2) how your business can achieve a competitive edge through EJB. This month I'll finish up the discussion of EJB portability from a developer's perspective.

Congratulations! You've just been designated the project manager of your first CORBA project! "Help!" you say? Even though you may not have any CORBA experience at all, you needn't panic. This article describes how you can grab this bull by the horns and guide your project to a successful completion. Not only can you survive your first CORBA project, but you can do everything in your power to make it a success. Luck isn't the missing ingredient — knowledge is.

Today's universities are recognizing the desirability of providing many staff functions for their students through a Web interface. Self-service applications allow students to enroll in courses, manage their personal information and examine their class schedules -and save the university time and expense for staff that would otherwise perform these tasks. In April 1999 New York State's Syracuse University went online to accomplish these activities over the Internet with a self-service application based on Enterprise JavaBeans technology. Here's how it was done.

What's all this hype about portability? Portability has been a hot topic since Java's arrival just a few years ago, so I'm going to devote some space toward understanding portability issues centered around the Enterprise JavaBeans architecture and development. This month I'll discuss the various types of portability and Java's relationship to each; then I'll touch on the portability goals of the EJB specification and where EJB portability lacks maturity (and why not to worry). Next month I'll provide tips on EJB portability as well as code examples depicting how you can help achieve the promise of EJB portability through solid design and coding practices.

The next release of the CORBA specification will be a major one, CORBA 3.0. The last time the major release number was incremented - to CORBA 2.0 - it signified the standardization of interoperability. What's new and different enough in this version for OMG to increment the major release number this time?

Every now and then the computer industry gets swept up in a wave of enthusiasm for some new silver bullet that's apparently going to solve everyone's problems overnight. Actually, these days the wild surges of millennial euphoria seem to come at annual intervals. Usually the technology in question is actually a step forward, able to solve real problems better or faster than was possible before. However, as word spreads about the power of the new technique, some people will inevitably try to apply it to the wrong problems.

To those of you familiar with Enterprise JavaBeans (EJB), deployment descriptors are nothing new. Essentially, a deployment descriptor's purpose is to collect declarative information that can be modified during deployment of an enterprise bean. Deployment descriptors are a key element in the component-based development capabilities of EJB. They allow users to modify, link and deploy EJB in a graphical environment rather than having to perform low-level code changes to reuse a component. The latest public draft of EJB specification 1.1 includes sections on the XML DTD for deployment descriptors, an important step toward enterprise bean portability between EJB servers.

As I sit down to write this article, the hype for Star Wars Episode 1: The Phantom Menace is even greater than the Java industry hype before the release of the Enterprise JavaBeans specification 1.0! I couldn't help including a few references of my own to the beloved trilogy in hopes of adding a little flavor to an otherwise drab topic: persisting data.

What Is RMI? RMI, the acronym for Remote Method Invocation, is part of the core Java API. The central idea behind this technology is the ability to call the methods of a remote object, shielding the programmer from mundane Socket handling while promoting a cleaner software architecture.

Java is the fastest-growing programming language today. The main reason this object-oriented language is so popular is that it's simple, easy to learn and portable.

Developers and managers often think of enterprise applications as insurmountable mountain peaks that only experts can climb. Much like mountain climbing, building a large-scale, enterprise-wide system is a daunting task, not for the faint of heart!