Doing Business with Enterprise JavaBeans
March 24, 1999 Doing Business with Enterprise JavaBeans by George Reese Most people familiar with Java have encountered its standard component model for client-side objects, JavaBeans. Through a simple programming contract, you can build Java components that others can employ in diverse applications using standard Java IDEs. Although nothing restricts you from developing "server-side" components, like business objects using the JavaBeans specification, you will find yourself limited to a single virtual machine environment. JavaBeans does not provide direct support for components that need to operate in a distributed, persistent, and secure environment. Because business objects need such an environment, Sun and its partners created a component model built around these needs: Enterprise JavaBeans (EJB). We will explore the special needs of an enterprise computing environment and how the EJB specification attempts to meet these needs.
Enterprise computingThe term "enterprise computing" is definitely one of today's busiest buzzwords. When you hear it used, chances are it is being misused. Enterprise computing is not simply business computing; it is not even mission-critical business computing. Specifically, it is computing that uses technology as a strategic tool for modeling a business. It encompasses both mission-critical and mundane applications. In particular, enterprise computing unifies all kinds of business applications under a single model.
Any enterprise computing solution must focus on modeling business concepts without imposing restrictions on business processes. For example, you do not want your business software to dictate that your worldwide offices operate in English. You may choose English for other non-technical reasons, but you should never let technology drive business processes. Thus the key to proper business modeling is to capture your business concepts in reusable, re-packageable components. These components must meet the following requirements:
EJB rolesTo some degree, the EJB component model enables you to build enterprise components that meet all of these requirements. Before assessing its suitability to the task, however, we should briefly review Enterprise JavaBeans. While you can find the specification on the EJB site, it is terse and a bit difficult to follow.The specification first identifies different roles in the business component world. The key roles are as follows:
The current specification focuses almost entirely on the work of the EJB provider. As a business object developer, the provider is you. Every other role makes use of the business objects you develop. Of those roles, only the container is of interest in this article. The container is the place where your business objects live. It thus manages the key functions of an enterprise component such as security and persistence.
Types of beansEnterprise JavaBeans basically break down along two lines: persistent and transient beans. A persistent EJB is one whose state is retained across application instances. A large percentage of your business objects will likely be persistent. The EJB specification calls these business objects "entity beans." An entity bean is shared across multiple client applications. For example, a single savings account entity bean may be referenced simultaneously by an ATM machine and a Web client.The EJB specification calls transient business objects "session beans." They come in two flavors: stateful and stateless. A stateful session bean shares values between two method calls. If you set an attribute in a stateful session bean by calling one method and then call a second method, that attribute will still be set to the value you assigned it. A stateless session bean, on the other hand, does not maintain any state information across method calls. Both kinds of session beans have a one-to-one relationship with a client. If, for example, we had a login session bean, the ATM machine would reference a different login session bean from the Web client.
|
Page 1 of 2
This article was originally published on March 24, 1999