Separating business logic and system services


	Lesson 5 Objective	Separating business logic and system services Identify business logic and system service infrastructures
		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 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 Marshalling and un-marshalling Transaction management 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 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. Security : In this course security relates to client access to a remote object only. 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. 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 plumbing, so that a programmer does not have to play more than one role at a time and thus can focus on a specialty, business logic, or system services. In the next lesson, you will be introduced to reusable components.