Component-Based Distributed Computing

What is component-based distributed computing and why is it so important? This is an excellent question to answer before going much further. The first question to answer is "W hat is a component and what value do components offer to enterprise application developers? "

Quick Software Component Refresher

When we talk about a component, what are we referring to? We could say that an EJB is a component. We could also call a Java class a component. Trying to come up with a single definition of a component that everyone in the software community would agree on would be pretty tough. For years , software developers and architects all over the world have attempted to describe what a component is. In 1996, the European Workshop on Component-Oriented Programming (ECOOP) came up with this definition:

"A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties."

Notice there was no mention of Java or EJB in the definition. That's because the concept of a component has been around longer than Java. Although Java supports the idea of components, it sure didn't invent them. There are really three important features to take away from the previous component definition:

• Specified interfaces

• Explicit dependencies

• Deployment capabilities

A component generally provides one or more business services to its clients . A client could be a GUI interface (Web-based or otherwise ) or in many cases, another component. The services that a component can offer could be as simple as returning the e-mail address for a customer to as complicated as calculating the shipping charges for an order being shipped to Berchtesgaden. No matter what services the component provides, it provides them through a publicly specified interface. This means that a client who interacts with a component is not shown the internals of the component, but only the result of the request that the client made on the component. This is sometimes also referred to as encapsulation .

A component usually has operations ( methods ), properties (state), and some type of events (possibly asynchronous notifications) that it generates. A good component will hide the details of how it maintains its internal state from the client. This helps to decouple the client from the component. For example, if the logic of how a component calculated the shipping charges changed, the client would not care as long as it still provided the same interface and charged the correct amount. Whether the amount was calculated by the Shipping component or the Shipping component communicated across the network to a legacy system to get the amount, the client shouldn't care.

You can think of the public interfaces that the component provides to a client as a contract between the client and the component. The component is saying, "I'll calculate the amount to ship the order, if you'll give me the order ID so I can look at the weight of what you are shipping." The set of interfaces a component exposes to a client is what makes up the contract between the client and the component. This is sometimes referred to as the component interface .

The next concept that is important from the definition is that a component may have dependencies on another component to complete its business services. These dependencies should be explicit and documented. In our example, the Shipping component that calls on the mainframe system to calculate the amount to ship the order depends on the mainframe application. It has a dependency on it. Without that mainframe system being able to provide the amount, the Shipping component would have to inform the customer that it can't complete the order at this time, and that can mean loss of revenue to the business. There's nothing incorrect or wrong about having these dependencies between components as long as everyone understands them. Having components depend on other components is very normal in an enterprise application. They just need to be comprehensible and cohesive. By understanding the dependencies, you are able to quickly determine which other components are affected when one of the public interfaces needs to change or be removed.

The last concept to take from the definition is the one of deployment. This is a little ambiguous because the definition of deployment has not been given and probably means many different things to different people. Java classes must be deployed. They must be in the correct package and in the system classpath. CORBA classes are deployed, but in an entirely different manner. Nonetheless, a component has some type of deployment that must be performed before its services are made available to clients. With some technologies or architectures, a distinction is made regarding who is responsible for deployment. The original developer is usually the one responsible for deploying a standard Java class, although it sometimes can be part of a much larger deployment. As you'll see in the section "EJB Roles and Their Responsibilities" in Chapter 3, EJB defines the roles and responsibilities for the component provider, deployer, and other necessary roles with the application.

For more on EJB roles and their responsibilities, see "EJB Roles and Their Responsibilities," p. 37 .

Figure 1.2 shows an example of a component that supports all three features that we described.

Figure 1.2. A component has public interfaces and dependencies and can be deployed.

Assembling Components into an Architecture

After you have begun to create individual components, the next step is to assemble them into a larger set of components. This larger set is known as a component architecture. A component architecture usually consists of a set of components and services for building applications and can utilize one or more frameworks. A framework is a library of other components that can be reused throughout multiple applications and save development time by providing proven and tested services and functionality. You might have heard the saying, "Don't reinvent the wheel." That's the purpose of a framework. Many companies are in the business of providing frameworks, but often they are built by the organization building the application.

There are many different styles and classifications of architectures. You can have system architectures, application architectures, network architectures, database architectures, and the list could go on.

If you do a search on the Internet for "What is an architecture?" you will see results ranging from space defense contract information to a hundred different thesis papers describing what the authors' ideas of an architecture are. For our purposes, an architecture is just a set of related components and frameworks that help describe what dependencies exist between the components and how they should react to events during the lifecycle of the application. This is in a sense what the EJB specification describes.