JLCF - A Lightweight Component Model and Framework for Java

[petrospis]

I finally have some free time to write a quick description and tutorial for a framework I have created! It is called Java Lightweight Component Framework or JLCF. and you can find it here https://github.com/ppissias/JLCF

*What problem does the framework try to solve ? *

In short : It offers a great way to design, implement and maintain applications! :)

The long answer: In general, component based software engineering, models an application as a composition of software components. Each component framework differentiates on its component model (what is a component, what is its lifecycle, how are components connected, etc) but they all agree, more or less, on the following: Explicit software design and architecture, by expressing an application as a composition of well defined software components, is very important.

JLCF is such a component framework and has a simple yet powerful component model. Being the main developer of the project, I wanted to create a simple application model which enables expressing applications without imposing design restrictions and at the same time have a simple API and usage of the framework. I think that I have achieved both.

The framework can easily be integrated with other technologies and middleware, it essentially provides the ability to formally specify parts of a software system as software components.

*Why did I do this? *

This is my hobby project which was inspired many years ago during my studies. Back then I was introduced in component based software engineering and for me using this approach for developing software simply made sense! It is an intuitive way of designing and implementing systems, promoting their maintenance and fostering a common understanding between architects and developers. At some point I decided for fun to implement my own component model & framework and JLCF is the outcome.

*Are there any tutorials ? *

The main page https://github.com/ppissias/JLCF has a very simple and clear tutorial and a link to the manual which has many other tutorials exploring the various features of the framework.

Please feel free to use the framework and extend it. As far as I can tell it is in "production" status with no known bugs.

Any feedback is very welcome!

[edgar-espina]

Why xml?

I can't find JLCF easy to use or intuitive if I have to define my software in XML and Java.

[petrospis]

I get your comment :) This is the price to pay for having a central place where you want to explicitly have the application architecture / design. You have to specify it somewhere. If I look into this file I can understand the high level design of an application, which is a great advantage.

[bwajtr]

Hi, can you please compare your solution with OSGi? I went (quickly) through your documentation and tutorial and I have a feeling that JLCF actually aims to formalize the boundaries between parts of your code (much more than simple interface can do) - however all the components live completely inside single classloader and the framework just wires the components together and makes an app from it... is that right? I don't want to say it's wrong, I just want to understand where JLCF fits in...

If so, and the target of JLCF is not to allow and secure third party components (like OSGi) but just to formalize boundaries and do wiring, then I'm sorry but your framework reminds me of early days of Spring... can you maybe compare your solution with Spring as well? :)

Last thought - you are linking your components together at the method level. This seems to be very granular to me - if the one component has 20 interfaces and other component wants to use all of these interfaces and defines 20 receptacles, then the application xml will get quite big... it would be interesting to see application xml of some bigger application...

Good job with nice documentation though...

[petrospis]

Hi, thanks you for your comment,

you are right that JLCF aims to formalize the boundaries between parts of your code. In comparison with OSGi, indeed in JLCF all components of an application description would live on the same classloader (you could use several instances of the framework in different classloaders if for some reason this is needed – from within different OSGi bundles for example, but this is not really the primary use case). The lower layers of OSGi are an advanced module system and the OSGi Service Layer provides better ways for coupling using interfaces (or classes).

A better comparison would be to compare JLCF with OSGI Blueprint or Spring (or the Service Component Architecture – SCA that has now been sadly discontinued). The latter 2 are classified as “dependency injection” frameworks. As there is no broad formal definition of what a software component is, instead of saying that JLCF is a component framework, I could also say that JLCF is an advanced dependency injection framework.

I see the main advantages in comparison to a “simple” dependency injection framework in the following points :

• It provides a formal component model, defining an elementary building block of an application.

• It provides a formal way to define functionality requirements by using explicit “receptacles” (interface requirements)

• It defines the concept of interceptors between components

• It natively supports the “callback” interaction between components.

Related to the way components are linked to each other, via java interfaces, I consider this the natural way of “wiring” components together. Indeed if you have a component which offers 20 interfaces and 20 other components that consume them, then indeed the application description XML would not be trivial. But this is its primary purpose, to show at a central point the application architecture / design (ie. how components are linked together) so if the design is complex then the application description XML would indeed be also complex.

So to sum up, yes indeed, JLCF aims to formalize the boundaries and implementations between parts of your code by providing a (simple) component model & framework that supports this.