Basic Concepts of Messaging System

JMS (Java Messaging System) was developed to cater the need of flexible integration design among various application or within application components.

In simple Java application, if we need to integrate one component/application with other, we have to have the reference of target with source. It means that one object must be aware about other object. It results into a tight coupling. It can be made flexible further by using different patterns like Factory, Service Locators and Directories but still objects used to be aware about each other type with a defined integration protocol like method signature. Now when architects want more flexibility, where one object is completely unaware about existence of other object and can simply say that I need this type of message. This is an ultimate flexibility in integration.

This type of flexible integration can be achieved using a messaging based simple design in java.  If we want to achieve this in Simple Java implementation, we can make a Message broker kind of component. This component can provide following facilities: 
  1. Any object can register with it as message producer by specifying a specific type of message, which can be a plain string. Message broker will maintain an internal data structure to keep track of such message producers corresponding to their message types.  
  2. Any object can register with message broker as message consumer. It will also specify a type of message for which it is interested to consume the message. Message broker will maintain an internal data structure to keep track of all message consumers corresponding to message types for which these wants the messages. 
  3. Now whenever any message producer produce a message, it calls message broker API and hand over the new message to it. Message broker knows the type of message, so it searches all the message consumers registered for this message type, iterate over this list and hand over the message to each consumer. 

Basics of Java Class Loader

Java class loader is an interesting concept of Java Runtime. We know that in Java,  every executable code is stored  in .java files which are compiled to .class files. These class files are stored in file system  in plain directory structure or in jar files or probably using some other medium. When any java program runs, it needs the definition of referred class files to execute this code at runtime. Here comes the role of Java Class Loader. Whenever Java runtime needs any class file, it calls a component of Java runtime called class loader to load the desired class. Default class loaders of Java i.e. Bootstrap and System Class Loader has the logic to search for the class file in JVM and in  directories and jars included in classpath respectively. It assumes that if Java program is referring to java.lang.Object, then the definition of this class must  be somewhere on  classpath in  java/lang/Object.class hierarchy. So by default, it has the logic to search in directories and jars. Once it finds the class file, it loads it in memory, store it with in memory cache for future reference and return to the runtime. So class loader search for the class files only once, and stores it in memory data structure to be utilized on future calls. Java classes loaded from default class loader are considered as trusted classes and hence these have the access to all core classes of java library itself.

Now Java provide enough flexibility to users applications to define their own custom class loaders, which can extend the default class loaders, and can add custom logic; like to load the classes from a  network location or from database and so on. Working of class loaders generally used to be like; a custom class loader first ask the parent default class loader of Java runtime to load the requested class. If default class loader is unable to find the class, then extended class loader proceed to load that class using its specific loading algorithm.