Lesson 5	Separating business logic and system services
Objective	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.

Business logic
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.

System Services

In a Java EE 8 transactiona environment, in order 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 infrastructure services, 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: In Java EE 8, marshalling is the process of transforming Java objects into a format suitable for transmission or storage, commonly XML or JSON, often facilitated by technologies like JAXB or JSON-B. Conversely, un-marshalling is the reverse process of converting data from these formats back into Java objects within the Java EE application. This mechanism is crucial for data exchange in web services, data persistence, and communication between different layers of an enterprise application.
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.

Shower Analogy
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.

Event Management, Concurrency, Transaction, Multi-threading, LifeCycle, Security, Resource Pooling, Naming, Persistence — The diagram above represents the "components of a distributed object system" framework or "middleware architecture", often found in systems like Enterprise JavaBeans (EJB) or CORBA. Below is a description of the individual components:
**Center:**
Remote Object

Represents the **core business logic object** that resides remotely.

Clients interact with it as if it were local, but the communication occurs over the network.

This abstraction allows for **distributed computing**.

Middle Layer Surrounding the Remote Object:
These components provide services or infrastructure support to the remote object:

**Event Management**

Handles events or notifications between distributed components.

Often part of **publish-subscribe** or **observer patterns**.

**Persistence**

Provides mechanisms for **saving and retrieving object state**.

Often implemented using databases or file systems.

**Naming**

Allows clients to locate remote objects using a **naming or directory service**.

Examples: JNDI in Java, or a CORBA naming service.

**Resource Pooling**

Manages shared resources efficiently by **pooling** them (e.g., database connections, threads).

Improves **performance** and **scalability**.

**Security**

Ensures **authentication, authorization, encryption**, and **data integrity**.

Protects the remote object and communication between components.

**Lifecycle**

Manages the **creation, activation, passivation, and destruction** of remote objects.

Handles object state transitions.

**Multithreading**

Enables **concurrent processing** of client requests to the remote object.

Supports scalability and responsiveness.

**Transaction**

Supports **atomic, consistent, isolated, and durable (ACID)** transactions.

Ensures reliable changes to persistent states.

**Concurrency**

Controls **simultaneous access** to remote objects to avoid race conditions.

Often involves locking or synchronization strategies.

**Bottom:** **Network**

Underlying communication infrastructure.

Facilitates **remote method invocation (RMI)** or **messaging protocols**.

Enables connectivity between distributed components.

This model abstracts the complexities of a distributed system so that developers can focus on business logic while relying on middleware to manage the technical plumbing. Let me know if you'd like an example with a specific technology like EJB, RMI, or CORBA.

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.