Whatis Enterprise Computing?

Generally an "enterprise application" involves several related systems, which may or may not have been designed together, and is intended to apply "business rules" to develop persistent and consistent reports on "business activities". It will try to provide a somewhat seamless path from initial customer contacts through final activities such as shipping product or receiving payment, and create records of important activities that have occured along this path.

One might think of an organization as having an "enterprise state" at any point in time, and of this state as being changed by various events. So an enterprise application might be thought of as seeing that changes in state are properly made, and properly recorded.

A simple example to keep in mind is that an enterprise application needs to move the state smoothly from "we have product, customer has payment" to the state "we have payment, customer has product". It needs to avoid the two possibilities "we have product and payment, customer has nothing" and "we have nothing, customer has product and payment". Either of those two states might occur temporarily, but if so something would need to be recorded about additional actions needed to produce the proper permanent condition.

In a departure (or a variation) from standard terminology we might use the term "state of the activity" as well as "state of the enterprise" so that the first term considers all of the temporary states that might occur, and the latter term considers only those states that are really a permanent and important part of the history of the enterprise.

We will find that the EJB approach is very nicely designed to distinguish between the two levels of state description.

Enterprise Java Beans

Enterprise Java Beans (EJB) is one portion of a general software system called Java 2 Enterprise Edition (J2EE), which is in turn based upon Java 2 Standard Edition (J2SE), which is what we usually mean when we talk about "java".

The J2SE system contains code in particular for networking, collections, database manipulations, security, and other generally required activities.

The J2EE system contains code for a variety of services that are commonly required in developing enterprise applications.

The EJB system, which is a part of the J2EE system, is particularly intended for dealing with producing and persisting changes in the state of the enterprise.

the Application Server: Components and Containers

The term "component" generally refers to an object (which may contain other objects) which can be packaged and transported individually. It may be developed in independent fashion, subject to contracts for the various interfaces through which it may interact with other components. These interfaces describe "what it can be asked to do" and "what it can ask others to do", along with general requirements for inputs, processing, and outputs, and it is intended that various implementations of the same component might be produced by many "component producers".

In the Java world those components are often called "beans", in which the term is meant in part to convey a sort of isolation produced by the "shell" of a bean which hides its interior construction.

In my own "Patterns-of-Protocols" terminology there is a "WISE" model, which describes the "world" as consisting of "system" and "environment" communicating through an "interface". A component in EJB is a system with interfaces as described above, using the methods of the Java object to communicate.

The "world" in the previous model consists of everything that might affect the behavior of the system, the system is the part you can control, and the environment is the part you cannot control (or perhaps better said you can control only by passing requests through the interface - and you must realize that the requests will be honored only if they are in accordance with existing contracts).

You also realize that the environment "controls" the system only through requests passed from it to the system through interfaces, which also must behave in accordance with a contract.

A very simple illustration of this is a thermostat, in which changes in environment temperature make a wire in the thermostat expand or contract, and this interface "query" makes the thermostat produce a current in wires that go to a heating system.

In the setting of EJB "the world" is represented by a "container" into which one or more components are placed. So we have a structure as far as an application server is concerned of "components placed into containers". There may be a number of containers, and each may contain a number of components.

the Application: Customers, Clients and Containers

Of course our company itself exists in a larger world, in particular in a world that contains "customers" who wish to "do business" with the company, and this business will be done in accordance with general rules agreed to by the customer and the company.

In terms of the WISE model we might view this situation as the "world" of some particular "business", in which the Customer represents the environment and the company represents the system (of course the customer may see things in the other way but is typically less formal about matters).

In most modern business computing we add an additional layer of "middleware". My term for this additional layer is the "client". The term "portal" is often used for this part of a design.

The idea is that the client should not be connected directly to a container, since the contract would typically be too inflexible. The "client" and the "customer" communicate through a more informal arrangment, which in particular provides for quite a bit of flexibility in presentation for customer queries and client replies. The client of course is going to turn a query from customer to client into a request from client to container, and turn a container reply into a customer reply.

This approach exemplifies the traditional "presentation-business-data" separation of activitites. It also allows us to readily produce clients as components themselves.

In the J2EE/EJB model typically the customer is represented by a browser or a graphical application, the client is represented by a servlet (perhaps itself derived from a "Java Server Page", which on its "customer" side knows the type of presentation your company desires for its external interface, and on its "container" sides knows the details of the contracts, the container is provided by the producer of the application server you are using, and the component may be something provided by a vendor which understands the business you are in.

The overall communication is illustrated in EJB objects.

the contracts

The client-container contract generally says that the client will contact a "home" object probably through a naming service such as JNDI and be delivered a "remote" object through which it can communicate with the component.

The component-container contract says that the container will automatically take care of a number of services that are required in all enterprise applications.

Specifically (the terminology is not standard, it is my simplification of reality:-) the services that the container provides can be classified as

Persistence

arranges for the data in the component to be stored and retrieved automatically from a database specified as part of installation of the component into the container.

Queuing

arranges for queuing of objects in pools so that objects can be reused by multiple clients as required.

Referencing

arranges for referencing objects through a naming service where names are specified in the configuration upon installation, which in turn allows independently developed components to communicate even though they were not using the same names when created.

Security

allows the coordination of security for component methods with the security that is available on the particular platform.

Transactions

arranges for transactions with databases and other components.

Implementation of contracts

When a component is installed its methods are "wrapped" as methods of the "remote" interface, to have the same signature but additional activities to implement any/all of the required services.

Enterprise and Activity states

To complete our capsule view of EJB you should be aware that there are two different types of bean, one called "Session Bean" and one called "Enterprise Bean". Typically each client is assigned a session bean which acts as a proxy or "front end" for it in accessing enterprise beans. The session bean can be thought of as dealing with the "state of the activity" and the enterprise bean as dealing with the "state of the enterprise". There may be several session beans interacting with a single enterprise bean.

As a simple example you might think of running a cruise line as a business. You might have an enterprise bean that represented a particular cruise on a particular ship (also represented by an enterprise bean). Current activity might involve customers communicating with session beans which represent travel agents, and each of these customers is attempting to book the same cruise.