Identify business logic and system service infrastructures
Separating Business Logic and System Services
In the past, when one wrote the code for a remote object, you required the skills related to the business logic as well as the skills
to handle transactions, security, concurrency, and other system concerns.
These skill sets are very different from one another, and it would be more efficient if we could separate the concerns to relieve the programmer from having to wear many hats at the same time.
Let us examine the two areas.
Remote objects provide some business service that is programmed into their methods.
To program the remote object will require specialized knowledge of the business rules applied to the service.
The programmer will, therefore, need to be an expert in the business rules.
For the remote object to provide the services in a reliable secure manner, it must behave appropriately within the system
infrastructure in which it executes. A systems programmer is required to implement these services (often known as "plumbing"),
which include, but are not limited to:
Security : In this course security relates to client access to a remote object only.
Marshalling and un-marshalling
Transaction management: Managing multiple operations in an object such that they all are executed or none are executed. This ensures consistent state of the underlying persistent information.
Concurrency: In multi-threaded systems, an object that could have one or more threads executing its methods and changing its state at the same time is said to be concurrent and to exhibit concurrency.
Multi-threading: Multi-threading is a programming and execution model that allows multiple threads to exist within the context of a single process.
Remote object Lifecycle: The states that an object can be in from its birth to its death.
Persistence: Objects whose state lives beyond the lifetime of the object are known as persistent.
The state is usually stored in a database.
Naming service: An entity that provides a lookup service to enable clients to find specific remote objects.
An analogy to this is that, when you want to take a shower, you need to know where the bathroom is and, once there, you can take a shower without connecting pipes, etc.
In fact, you do not need to understand plumbing at all. However, to install a shower you require a plumber.
In the diagram below I have shown the remote object, which provides some business service, supported by the system infrastructure and the specific services it may provide.
One of the goals of Enterprise JavaBeans is to separate these two concerns,
business logic and
mechanisms for the transmission of data
so that a programmer does not have to play more than one role at a time and thus can focus on one of the two, business logic, or system services.
In the next lesson, you will be introduced to reusable components.