| Lesson 7 | Object Monitors |
| Objective | Describe how components live inside the containers |
Object Monitors - how components live inside EJB containers
- Tomcat
- Websphere
- WebLogic
Connecting to remote objects
You saw previously that there is a benefit to separating business logic from the plumbing.
The plumbing is similar for each and every remote object, while the business logic is unique.
Thus, in theory, we can create a common structure for the plumbing and have that structure manage the remote object.
Some of the questions we need to consider carefully are:
The plumbing is similar for each and every remote object, while the business logic is unique.
Thus, in theory, we can create a common structure for the plumbing and have that structure manage the remote object.
- What program actually listens on the transport, accepts the message, and passes it to the skeleton?
- What actually executes the remote object and starts the skeleton when required?
- Who is responsible for starting transactions, checking security, etc., if it is not the remote object itself?
- How does the client know where the remote object actually is on the network?
- How does the client get a copy of the stub?
We know that the stub hides location and other details from the client, so the stub must know ahead of time where its remote object is and must be available to the client.
Object Monitor
The common solution to these issues is to break our environment into the Server, the Container, and the Name Server.
Combined, these are known as an Object Monitor. The relationship between the component parts is shown in the MouseOver below:
Combined, these are known as an Object Monitor. The relationship between the component parts is shown in the MouseOver below:
- Server, Responsible for: listening on one or more transports, passing messages, distributed transaction management
- Container, Responsible for: runtime support of remote object instances: skeletons, transactions, security, lifecycle, persistence
- Remote Object, Responsible for: business logic
- Name Service, Responsible for: remote object identity, stub download
Object Monitors Normal Interpretation
Middleware
The object monitor that combines all these parts (except the name service, which is usually separate) is often known as middleware[1].
The name comes from the fact that it is in the middle, between the client and the remote object.
Prior to the advent of objects, they provided mainly transaction support and were called Transaction Monitors, separating the client from a database or another back-end program. In the next lesson, the component parts of an Object Monitor will be introduced.
[1]Middleware: Software systems and utilities that provide a service and sit between the client and backend databases or legacy systems.