Showing posts with label OSGI. Show all posts
Showing posts with label OSGI. Show all posts

Sunday, November 6, 2016

Tiniest Module Container (Serialization)

This post builds on previous posts:
Today we have a look at a Java concept that we will make extensive use of during the development of this project:


Serialization in Java

Serialization is a built-in Java concept that allows us to save (persist) the state of a Java object (instance) to a Stream. In our example, we save it to the hard drive as a file.



Implementation

The concept is relatively easy to implement, all you have to do is to add
implements java.io.Serializable to your class definition.

Be aware that you need to do this for all of your classes that might end up being persistable properties!

I wrote a utility class that contains the code needed to effectuate the persisting and loading of an instance's state:

The Serializer



/**
 * @author      Michael Appelt 
 * @version     0.1 Initial          
 * @since       0.1  
 * @copyright   2016/2017 Michael Appelt        
 */
package appiappelt.util;

import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.ObjectInput;
import java.io.ObjectInputStream;
import java.io.ObjectOutput;
import java.io.ObjectOutputStream;
import java.io.OutputStream;
import java.io.Serializable;

import appiappelt.shell.Shell;

public class Serializer {

 /**
  * Persist state to disk
  * @throws IOException 
  */
 public static void persist(Object obj) throws IOException {
  if (obj instanceof Serializable) {
      String className = obj.getClass().getName();
             className = className.replace('.', '_');
      OutputStream file = new FileOutputStream(Shell.getCurrentDir()+File.separatorChar+className+".dat");
      OutputStream buffer = new BufferedOutputStream(file);
      ObjectOutput output = new ObjectOutputStream(buffer);
      output.writeObject(obj); 
      output.close();   
  }
 }
 
 /**
  *  Load persisted state
  * @param  obj - The object wanting its persistent state
  * @return a new object representing the loaded state. do remember to copy properties
  * @throws IOException
  * @throws ClassNotFoundException
  */
 public static Object loadState(Object obj) throws IOException, ClassNotFoundException {
  if (obj instanceof Serializable) {
       String className = obj.getClass().getName();
       className = className.replace('.', '_');
       InputStream file = new FileInputStream(Shell.getCurrentDir()+File.separatorChar+className+".dat");
       InputStream buffer = new BufferedInputStream(file);
       ObjectInput input = new ObjectInputStream (buffer);
       obj = input.readObject();
       input.close();
  } else {
       return null;
  }
  return obj;
 }
}
The File name is composed of the current directory String* (operating System independent I hope), the class name ('.' replaced by '_') and a ".dat" as the file type.

*I want that the state is saved within the directory "where the Shell is running". We will "parameterize" this at a later stage.

The loading of the state is nothing else but reading the state out of the File Stream and assigning it to the receiving object instance.



Application

You can see the usage of the Serializer in the JUnit test method below:


Let's unwrap the code above:

  1. We first instantiate a Shell object and add a "test Module" to it.
  2. Using the Serializer, we serialize the collection (a Hashtable) that contains all Modules belonging to the Shell.
  3. We instantiate a new Shell object, load the state that we persisted in 2. and "enumerate" through the collection of Modules, printing to screen the instance's names.
Shell obj instance and Shell newobj instance are now in an identical state with regards to the Module collection and other serializable properties.



Conclusion

With this post, I demonstrated the concept of Java's object serialization to you. We are now able to persist and load state, which is one of the core concepts needed for our Tiniest Module Container to work. 

Stay put for more ... and yes, you will be able to access/download all of the implementation code once the project is finished.

Monday, October 24, 2016

Tiniest Module Container (Module handling)

I introduced the Tiniest Module Container (TMC) in my previous post: Introduction of Tiniest Module Container

Let me remind you what TMC is: It is an application shell that carries the Modules (a Java construct that has a defined purpose, a defined and unique set of functionality) that make up the total functionality of the application within itself. We use the concept of a customized Class loader and persistent state to achieve this.

Illustration

I extended the illustration from my previous post:

We can say the following about the design:
  • The Shell has a customized Classloader
  • The Shell has a collection of Modules (code and instantiated objects)
  • The Shell has a collection of Interfaces (interface objects that point towards one Module)
  • A Module is installed into a Shell: The customized Classloader reads JAR files containing the Module code, loads these into the application (JVM), stores the code (String) in a Module collection and saves the Shell's persistent state containing the ingested code. The JAR file of the installed Module is deleted.
  • The Shell's persistent state can contain application parameters and many more attributes (operation).
  • A previously installed Module will be instantiated at the Shell's instantiation (start-up / initialization). 
  • One Interface Object is instantiated for each Module, other Modules (application code) evoke functionality of the Module through it. 

Process flows

So far we have discovered two process flows, one for installation, and one for initialization:

Below you will find a draft version of the Instantiation Process Flow. I might employ a slightly different organization/strategy once I start to implement it but for the moment these steps seem reasonable.

Draft Instantiation Process Flow:

Conclusion

I do not want to overwhelm or bore the reader with too much detail. I think that the explanation above describes an aspect of the idea and points into the direction that I want to go with this.

My next post will take a closer look at Java's Serialization Concept

Saturday, October 15, 2016

Introduction of the Tiniest Module Container

Introduction

I have worked many years building Java Applications in all sorts of environments, using different tools and standards . As many of the modern platforms, libraries, services and standards available, OSGI is a very useful construct to plug modules (collection of libraries) together to create a homogenous Java application.  I remember a project I participated in that took place about 4 years ago where I had to integrate web server, database, GUI, printing and other kinds of functionality into one single OSGI container. To be honest, it felt often like being inside somebody else's nightmare. I had to combine compounds of libraries that worked well on its own but clashed with another compound if unified within one OSGI container. I succeeded at the end resolving the hundreds of Class loading errors, sometimes having to rebuild libraries according to my own needs. I am optimistically hopeful though that today this is probably not necessary anymore and assembling modules in the latest OSGI containers is a piece of cake.

I do like slim designs, thin layers, software without weight. There is therefore not much inspiration within me to use the often bulky platforms and standards for my own, private work. My experience is that things get in my way and I can not always implement what I need to do quickly and easily. But the idea of OSGI is a good one and reminds me of a construct I created more than 15 years ago

Tiniest module container

The idea of this container is to be a shell that carries the code that makes it an application. It does this with the use of the concept called "persistent state". New functionality modules are installed within it and the maintenance (updates) of these modules happens automatically, almost seamlessly.

Let's look at a tiny overview diagram:


Java is an absolute gem because it gives a software engineer fine tuned extension possibilities like no other implementation language I know. The key to making this concept work is the ability to implement a customized Class loader for the Shell (application).

Got the idea yet? I will develop this further in one of my next post, which will include a Class Diagram and some Process Flow.

The explanation of the Tiniest Module Container continues here: Tiniest Module Container (Module handling)