Thread per request or connection has been introduced in order to maximize the system resource and provide responsiveness to users which single thread is not capable. Thread per request or connection architecture will create a thread for each request from a client. In other words, server can create a number of threads as per request. The only limitation is software and hardware capacity. Thread per request is one among thread in distributed systems architecture. This architecture is coming with advantages and disadvantages.
Single thread server is one among concurrency architecture in distributed systems. It is the early stage of distributed systems development. Its footprint is very small and easy to develop. Single thread has an ability to handle only one user a time. The other users must wait in queue until the working user finished his or her task.
If we consider about CPU and I/O usage, single thread is not fully utilized because while CPU is busy I/O usually is free and vice versa.
- Straight forward
- Easy to develop
- Waste time. CPU and I/O are not fully utilized
- User unsatisfactory because user may wait for getting services
- May be not exists in real world distributed systems application
One challenge in distributed systems is concurrency. Without supporting multithread, distributed systems is almost meaningless as it needs to support multiple users. It is typical in distributed systems to have tasks that are partly CPU intensive and partly I/O bound. Generating database query, rendering an image, etc are examples of CPU intensive. Sending files or requests over the network are I/O intensive related to Socket, RMI, etc.
Now we will lookup 3 main architectures that thread impact the performance of distributed systems.
- Single thread
- Thread per request or connection
- Thread pool
Parallel and Distributed computing can be confused. This article will show you the simplest way to identify.
- Shared memory system
- Multiprocessor (multiple processors share a single bus and memory unit)
- Symmetric Multiprocessing (SMP) supports in Operating System
- Much simpler than distributed system
- Limited scalability
Designing the distributed systems does not come for free. Some challenges need to be overcome in order to get the ideal systems. The challenges in distributed systems are:
- Resilience to failure
Java RMI is powerful middleware that replaces raw request/reply method as UDP and TCP. The core technology to make it works is Stub and Skeleton function. Stub is located on the client side while Skeleton is located on server side. The role of stub and skeleton is to do marshalling and unmarshalling meaning that it will squash the argument and return value of a method to be a standard format for storing in a file or transferring over the network. Without Stub and Skeleton, java RMI cannot work.
Note on Stub and Skel files (Skeleton)
- Java JDK 1.6 does not require to have Stub and Skeleton file (Skel for short) as it takes advantage of reflection to accomplish the task
- Java JDK 1.5, it requires only Stub file at the client. To generate stub file:
PowerServer_Stub.classwill be generated
- Java JDK prior to 1.4 (not quite sure), it requires both Stub and Skel files
rmic -vcompat PowerServer
PowerServer_Skel.classwill be generated
There is a tricky in getting Java RMI works and runs. First, you need to understand the Overview of Java RMI and know how to implement it. Java RMI relies on 3 components–client, server and registry service.
Note: This article refers to the code developed in How to Implement Java RMI.
There are 2 ways to deal with registry service.
rmiregistrycommand in Dos prompt or Console if it is not created in the code
- Create RMI registry service in the code
Registry registry = LocateRegistry.createRegistry(1099);
- It needs interface class(
IPower.java) created in Step 1 of How to Implement Java RMI article
- It also needs interface class (
- Be sure that you pointed to the right server’s registry service
Implement Java RMI could be ever easier if you follow my rule strictly. You need to understand Java RMI Overview before you can catch the code.
According to the above figure, there are 4 steps need to be involved in Java RMI development. I will give you an example of creating Java RMI application dealing with Fibonacci and Factorial calculation using badly recursive algorithm. These two methods will be available for invocation at the server side. I will call the server program as PowerServer and client program as PowerClient.
Java RMI or Remote Method Invocation is an example of Remote Procedure Call (RPC) enabling client program to locate the server object and remotely invoke the methods from server through server’s stub and skeleton function. Java RMI is usually referred to Distributed Object rather than RPC. This is because Java natively is object oriented programming. So we say object as a whole. Moreover, RPC somehow is mentioned to procedural programming.
In practice, the terms marshalling and serialization are used interchangeably to describe the process of squashing data types into a well-defined intermediate format that is suitable for transmission on a network or for storage in a file. You might be familiar with Remote Procedure Call (RPC) as the core stub function needs to marshal the argument and return value of a method before they are actually transmitted over the network.
This article, I will show you with an example of marshalling and unmarshalling a Java object. Be reminded that:
- Not all data types can be serialized
- User-defined class must implement
- Attempt to marshal or serialize a non-serializable object will throw an Exception in Java