Introduction OSGi

1. What is software molecularity?

We have a tendency to use more and more agile methodologies. we use things like scrum,xp and lot of agile methodologies in order to come up with solutions for our customers problems.
What we learning with these methodologies:-
we are breaking our complex code into smaller parts
start building solutions for smaller parts and then cannot design at least everything upfront just like that methodology says so you just start of just doing some stuff and later on you will consider some refactoring.

reconsider some of your architectural decision not all of them but some of them which leads to an interesting development process in which stuff you build like one or two month ago needs to be refactored and some architectural decisions that have been made one or two month ago needed to be reconsidered.

What are normal Trends?

Applications tends to grow bigger and more complex.

Agile development and refactoring have become more common.

Rather than building complex solution we are trying to give solution in iterative manner.
This gives no of challenges that are not unique to agile application.

Challenges -

Dependency Management                                                  Versioning

Maintenance                                                                              Deployement

• Dependecy Management

1. We are using open source frameworks from internate. not only external dependency but dependency of our module like one part is dependent on other part of the application.and also some dependency between those parts as well.when application is in production then dependency management is more interesting on frequent changes.

• Versioning-

Next dependency management the problem with versioning .if some part of your application is more rapidly changing then others ,then you have versioning issue .and also if you are facing external client ,external dependency.then versioning having multiple version of the same functionality at the same time.

• Maintenance -

Maintenance is thinked later but that is the thing we must think at very beginning.
You must think about architecture ,dependency management and versioning.

• Deployment-

Either you are going to deploy entire application or changes that you made.deploy in java with one artifact or we just deploy with some smaller artifacts.

Apps are moving to the Cloud

cloud challenges required not trivial non functional requirements.

1. Zero downtime deployments
2. modular deployments
3. custom specific extensions(SaaS).

Our application becomes more and more complex.

Observations -

Extremely agile (first mover advantage)
Architecture- code base should be able to cope with changes.

Trends- 

Applications tends to grow bigger and more complex
Agile development and refactoring become more conman.

So what are the solutions for all the above problems?
Modularity   is the key thing for designing and maintenance of our problems.

What exactly is modularity?
So we learn in  university:
Promote Cohesion
prevent tight coupling



How to prevent coupling in a code base?

By Dependency injection
Interface and implementation

So interface is a good way to start, separating a contract from implementation.
but how to make sure nobody accidentally uses implementation classes?

That means you have an interface in java and you have public implementation classes .so anybody having access to package can just view your class and then still have your implementation. So how you prevent that.
Implementation hiding.
Interface just to be public but implementation should be private.
An off course in java we don’t have that type of mechanism off course we have private ,public and protected keyword  but you need something else.

                                       Implementation Hiding

What we want to achieve we are trying to picture in below image.


So we have modular thing they have like a public part which exposes some public things mostly interface and they have like a private internal part in which the implementation classes are written.
That how ,the implementation classes  they  implement are not accessible and visible to other modules in the system .

Module A have some public part like interfaces and implementation classes it imports some public part of module B.

In this picture we show implementation hiding things and how do you do that.
How can we have module system like this in java write now.

Ok ,again how to create instance of a hidden class?

MyInterface inctance1= new MyImplimentationClass();

We cannot insatiate myimplimentaion class at it reside in privet part of another module and you do not have access to that implementation class so use something for that.
The one of the thing which we just suggested is
Dependency injection is just a way to do that.
And this is drawing little bit more that an abstract way to use dependency injection. is actually i can use

Middle approach

Service registery approach( you meight recognize this for example RMI application)you have something like registery  in which some part of the application is register implementation and other part of the application do look up of implimentaiton classes.
Now this is the short of that we need .
so we have like a man in the middle which is service registry.and then we have a module A which register an implementation of some sorts using the interface at the service registry.
And  another part of the application in this case module B  can do a look up at service registry i need something of this type and this type being the  interface and now the service registry is looking for and if have an implementation just returns the implementation.
Or if you have more advance system you can leave notification  so as soon as module B express interest in implementation for my interface then the service registry will supply to him as soon as it got an implementation for it in interface class.


Then dependency Injection is short of similar mechanism in order to solve same kind of problem.
So if you start thinking doing real modularity in java then actually two ways when modularity matters.
We have modularity at design time when you thing design of your application
You have splitter you complex problem into multiple smaller parts.
You design such a nice modular application then how you will deploy ?.
so modularity comes in two parts

• Design time modularity
• Run time modularity

So instead of single war file we can have multiple jar files.
Jar files is the unit of run time modularity on the java platform.

Runtime dynamics -
Module versoning
updating Single modules
Intra-module dependency management.

In order to do that we have three things.
Design consequences ----> Architectural focus on modularity
Let's not reinvent the wheel---> High level enterprice API
OSGI is only option --->Run time dynamic module framework

NB- OSGI is the de-facto standard modular system for JAVA
Remember -
modularity is an Architectural principle.
It does not come for free with a framework.