Tuesday, October 10, 2017

Liferay 7 / DXP Modularity Introduction

Nagul Meera Mahankali

Liferay 7 /DXP is new release from Liferay Inc. Liferay 7 / DXP came up with new architecture based development that is OSGi.

As we know OSGi (Open Services Gateway Initiative) is Dynamic Component Development for Java platform. Its modular framework, where we can compose the application into several module and the modules communicate each other. Liferay 7 / DXP have OSGi support so we can develop liferay applications as OSGi modules. Modularity is interesting feature and have many capabilities to make application into several modules.

Follow the bellow articles to know more about OSGi

http://www.liferaysavvy.com/2015/12/open-services-gateway-initiative-osgi.html

http://www.liferaysavvy.com/2016/11/open-source-gateway-initiative-osgi.html

http://www.liferaysavvy.com/2016/11/access-felix-gogo-shell-in-liferay-7.html

http://www.liferaysavvy.com/2017/08/osgi-architecture.html

http://www.liferaysavvy.com/2016/10/apache-felix-introduction.html

Interesting features of OSGi

Reduce the complexity and make the application sampler

Easy Deployment of applications

Reasonability of the components and modules

Easy version management

Cross platform support we can run anywhere

Widely used platform now a days.

When we consider all above interesting features OSGi promising platform to deliver many interesting capabilities.

Liferay 7 / DXP have used OSGi modularity features to build and develop the Liferay 7/ DXPApplications.

OSGi specification available in two popular implementations such as Apache Felix and Eclipse Equinox.

http://www.liferaysavvy.com/2016/10/apache-felix-introduction.html

http://www.liferaysavvy.com/2016/11/access-felix-gogo-shell-in-liferay-7.html

Liferay 7 have used both implementation capabilities to strengthen the Liferay Modular Application development.

Traditional Web application development have application servers, which runs the web applications. It means, we will develop applications based on web application standards using some J2EE Web application frameworks. We will package these applications as WAR files and deploy into the Application Servers. This is basic web application development and runs the applications.

Whereas OSGi environment have OSGi container to run the OSGi applications.
OSGi applications can call it as OSGi bundles. OSGi bundles is JAR file, which consist of Java and other configuration files. These bundle developments follow the OSGi specification so that it can run in OSGi containers.

When we are talking about OSGi bundles, we use Component terminology many times. Component is piece of code, which runs independently and deliver some reusable feature or task.

OSGi application composed of several components and these components are talk each other and all together deliver complex feature or task.

We package the group of components as bundle. Bundles is an OSGi application based on OSGi specification and runs in OSGi containers. Interesting feature of OSGi is application composed into small components.

OSGi have other interesting artifact called OSGi Service Registry, which manage the component and its service registration and manage the references. OSGi component dependency management controlled via OSGi service registry. OSGi service registry implemented by OSGi Declarative Services and shorty we call it as DS.

http://www.liferaysavvy.com/2017/09/osgi-declarative-services-ds.html

http://www.liferaysavvy.com/2017/10/differences-between-liferay-7-dxp-and.html

We also have other implementation called Apache Blueprint, which is similar to DS.

http://www.liferaysavvy.com/2017/10/apache-blueprint-introduction.html

Liferay 7 /DXP can use both implementation while develop Liferay Application Modules.

Structure of OSGi Module

As per OSGi module development, we have following pieces in the application.

Service API: Service API bundles container the all service interfaces

Service Provider: Service provider bundles provide the implementation for the interfaces which definer in the Service API

Service Client: It will consume the component services.

http://www.liferaysavvy.com/2017/08/osgi-dependency-management.html

http://www.liferaysavvy.com/2017/09/osgi-dependency-management-example.html

Liferay 7 / DXP module development follows the same structure while developing the Liferay 7/DXP application bundles.

Structure of a Modular App in Liferay 7 / DXP

As per OSGi, we can break the application into several bundles. Same way Liferay 7 / DXP have several bundles/modules.

The following are important parts or bundles in the Liferay 7 / DXP module development.

API

API contains all interfaces java classes. It is separated from implementation bundle.

Service

Contains the service (business logic) and persistence implementations.

Web

Web contains the presentation layer files such as HTML, JSP, CSS and JavaScript files.

Test

Contains the tests. These are not included in the app for production.

Liferay Modular Architecture

Picture source form Liferay.com

Liferay 7/DXP have several layers in the architecture like Liferay Core, Foundation, and Web experience, Collaboration, Forms & Workflows and Independent Apps.

Liferay Core

Liferay Core consist of all core APIs and Liferay Kernel. Its basic components which will used by all other modules or layers in the Liferay portal.

Foundation

This layer consist of Liferay building blocks implementation such as Users, Roles, Groups, Themes and Permission System.

Applications Layer

Liferay application layer separated with different group of modules and these all are independent apps separated from Liferay Core and Foundation. It uses the both Liferay Core and Foundation layer APIs and Its independent modules.

Liferay core and Foundation layers are packaged as WAR file deployed in the traditional application layer. Usually all these APIs and Implementations available in ROOT directory that deployed in Application server deployment directory.

Liferay independent Apps are made it as OSGi bundles, deployed in the OSGi container. All liferay bundles are found in OSGi directory of Liferay portal.

Liferay have provides the gateway which communicate with Liferay Core and Foundation layer to fulfill liferay application features.

Liferay 7 /DXP still support the plugins development and its deployment. This is a reason still we can see traditional application server. Liferay older versions migration to Liferay 7 / DXP possible through to keep traditional application server in the Liferay 7/DXP.

To customize or develop new features in Liferay 7/DXP, Developer follows the OSGi modularity specification to develop Liferay 7 / DXP apps.

Now all liferay applications possible through the OSGi bundles. Still some of the limitations for Liferay Themes, so we follows the Web based development for themes. Portlets, hooks can make it as OSGi bundles and themes can make it as WARs. Liferay 7 / DXP still support Plugins SDK so that we can develop liferay applications as plugin wars.

Liferay 7 / DXP suggested using OSGi Declarative Services (DS) framework to develop Liferay 7 application bundles. We can use Apache Blueprint framework as well.

Liferay have used Apache Gogo shell Command Line Interface to manage bundles, its means Activate/Deactivate Start/Stop bundles in the OSGi container. Bundles lifecycle controlled via Apache Gogo shell.

Interesting point is, we can disable/ enable Liferay features through Apache Gogo shell and we do not need to un-deploy or remove bundle from OSGi container. Just we can deactivate or activate is enough.

Liferay have provided good tools to develop Liferay 7/DXP modules. Follow the below articles to know more about Liferay 7/DXP Module Development. Follow below link to find more details about Liferay Application Development Tools

http://www.liferaysavvy.com/2017/10/liferay-7dxp-development-options.html

Author

Meera Prince

Liferay Contributor of the Year 2016
Liferay Top Contributor Award Winner 2015

Liferay Contributor of the Year 2014

Liferay Top Contributor Award Winner 2013

http://www.liferaysavvy.com

Saturday, October 7, 2017

Apache Blueprint Introduction

Nagul Meera Mahankali

Apache Blueprint is container specification, which defines the dependency injection for OSGi. It is a dependency injection framework for OSGi bundle development.

Liferay 7/DXP came up with OSGi support. We can use Apache Blueprint framework to develop Liferay Application OSGi bundles. We can use either OSGi Declarative Services (DS) or Apache Blueprint to develop Liferay bundles. This article gives basic idea of Apache Blueprint framework.

We already know Declarative Services in OSGi. Apache Blueprint is similar to DS. Blueprint is enable component services make it available and unavailable at any point of time. Apache Blueprint based on OSGi Compendium R4.2 specifications.

Apache Blueprint is container specification based on OSGi extender pattern. Extender pattern is very used pattern in OSGi environment to extend semantics of bundle by adding new MANIFEST headers. To add addition features to existing bundle nature, we will use OSGi extender pattern. Best example is OSGi Declarative Services. OSGi Declarative Services used extender pattern so that it will provide dynamic nature to the components and it services.

Apache Blueprint is used extender pattern as well. Apache Blue print extender bundles monitor the bundles state in the framework and perform the action on behalf of the bundle based on their actual state.

Extender bundle is responsible to identify the bundle is blueprint bundle or not, once the bundle activated the OSGi container. Extender bundle will look for the Blueprint xml files in the bundle. If any bundle have Blueprint xml files then it will treat bundle as blue print framework bundle. Usually blueprint xml files located in the fixed location in the place OSGI-INF/blueprint/ directory or are specified explicitly in the Bundle-Blueprint manifest header.

Once bundle is blueprint bundle, then it will create the Blueprint container for the bundle and it is responsible for following actions. These actions are similar to Spring Framework Dependency Injection. If we are familiar with Spring framework then it will be easy to understand OSGi dependency Injection through Blueprint framework.

XML file parsing

Instantiate the components

Wiring the component together

Registering the services

Looking up service references

Blueprint XML Configuration

Blueprint framework uses the XML configurations to declare beans and its wiring. Blueprint container read this xml configuration file to instantiate and wiring the beans. Blueprint is top-level xml tag.

The following is basic declaration which specify the blueprint configuration

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
...
</blueprint>

The XML namespace identifies the document as conforming to the Blueprint version 1.0.0. The top-level blueprint element identifies the document as a blueprint module definition.

Bean Declaration

Blueprint uses the bean tag to declare beans. Bean tag have id attribute, which is unique identification for bean.

The following is example of bean declaration.

<?xml version="1.0" encoding="UTF-8"?>
  <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
  <bean id="helloServiceOne"

class="com.liferaysavvy.blueprint.HelloService" />
</blueprint>

Bean Constriction

Blueprint container will look for right constrictor to instantiate the beans. This information provided as bean attributes or its child tags. Instantiation can be happen with the constrictor or factory method. By default, the Blueprint Container uses the number and order of the argument elements in XML to find the right constructor or method.

To help the Blueprint Container pick the right constructor, method, or parameter arrangement, additional attributes, such as index or type, can be specified on the argument element. For example, the type attribute specifies a class name used to match the argument element to a parameter by the exact type.

Beans instantiation with constructor

The following example for bean instantiation with constructor

Java Class

public class HelloService {
    public HelloService(long number) {
    }
}

Blueprint XML configuration

<bean id=" helloServiceOne"

class="com.liferaysavvy.blueprint.HelloService">
  <argument value="1"/>
</bean>

Beans instantiation with factory method.

Bean construction can be happen through the static factory method as well. We will use bean factory-method attribute so that Blueprint container identify it and it will instantiate bean by using factory method.

The following is example for Beans instantiation with factory method.

Java Class

public class StaticHelloServiceFactory {
    public static HelloService createHelloService(long number) {
        return new HelloService(number);
    }
}

Blueprint XML configuration

<bean id="helloServiceTwo"

class="com.liferaysavvy.blueprint.StaticHelloServiceFactory"

factory-method="createHelloService">
  <argument value="2"/>
</bean>

Bean Properties

Blueprint have property tag to provide additional configuration to the bean and the container will use it whenever bean required.

The following is example to access and declare the properties for the beans.

Java class

public class HelloService {
    public HelloService(long number) {
    }
    public String getMessage() {
    }
}

Blueprint XML configuration

<bean id="helloServiceOne"

class="com.liferaysavvy.blueprint.HelloService">
  <argument value="1"/>
  <property name="message" value="Hi I am Hello Service"/>
</bean>

Bean Wiring

Sometimes one bean dependence on other bean. We should wire the bean into the current bean. Property injection is used for wiring beans together. In the following example, helloServiceOne is injected with a DependencyService bean.

Java Classes

public class HelloService {
    public HelloService() {

    }
    public void setDependencyService (Currency currency) {
    }
}

public class DependencyService  {
    public DependencyService () {
    }
}

Blueprint XML configuration

<bean id="helloServiceOne"

class="com.liferaysavvy.blueprint.HelloService">
  <property name="dependencyService" ref="dependencyService" />
  </bean>
  <bean id="dependencyService"

class="com.liferaysavvy.blueprint.DependencyService" />

Services

Blueprint framework provide the configuration to register service in OSGi service registry. Blueprint xml have service tag it will register the declared services. Service implementation will be referred through ref attribute.

Service Interface

Service Interface container set of services and its simple java interface.

public interface HelloService {

    public String sayHello();
}

Service Implementation

Service implementation provided the implementation to the service interface.

public class HelloServiceImpl implements HelloService {
    public HelloServiceImpl () {
    }
    public void sayHello() {
    }
}

Blueprint XML configuration

<service id="helloServiceOne" ref="helloServiceImpl"

interface="com.liferaysavvy.blueprint.api.HelloService"/>
<bean id="helloServiceImpl"

class="com.liferaysavvy.blueprint.impl.HelloServiceImpl"/>

Without using ref attribute we can also declared service implementation as inline to the service declaration

<service id="helloServiceTwo"

interface="com.liferaysavvy.blueprint.api.HelloService">
<bean class="com.liferaysavvy.blueprint.impl.HelloServiceImpl" />
</service>

The interfaces under which a service is registered can be determined by Blueprint using auto-export. The following registers the service under all the bean's interfaces

<service id="helloServiceOne" ref="helloServiceImpl"

auto-export="interfaces" />
<bean id="helloServiceImpl"

class="com.liferaysavvy.blueprint.impl.HelloServiceImpl"/>

Note:

Other values for auto-export are disabled (the default) class-hierarchy and all-classes.

Service Properties

We also configure requires properties for the service using service-properties tag. This service-properties tag contains multiple entry tags to declared properties and it has key and type as attributes. The service property values can be of different types, but only OSGi service property types are permitted: primitives, primitive wrapper classes, collections, or arrays of primitive types.

The following is example for property declaration

<service id="helloService" ref="helloServiceImpl"

autoExport="all-classes">
  <service-properties>
    <entry key="active">
        <value type="java.lang.Boolean">true</value>
    </entry>
    <entry key="message" value="say hi"/>
  </service-properties>

</service>

Service Ranking

When one service have multiple implementation then service ranking used to choose the matching service implementation. The default ranking value is 0. Service ranking is specified using the ranking attributes as follows:

<service id="serviceFive" ref="account" auto-export="all-classes"

  ranking="3" />

Service Reference

Services are found in the OSGi service registry using the reference element from the Blueprint xml file. The following configuration reference tag referencing the HelloService. If this service found in the OSGi registry then it will be set in the HelloServiceClient.

Blueprint Service Reference XML configuration

<bean id="helloworldClient"

class="com.liferaysavvy.blueprint.client.HelloServiceClient">
  <property name="helloService" ref="helloServiceRef" />
</bean>
<reference id="helloServiceRef"

interface="com.liferaysavvy.blueprint.api.HelloService"/>

Blueprint Implementation Example

Usually OSGi service implementation have their basic bundles. Service API, Service API Provider and Service Client.

Follow below articles

http://www.liferaysavvy.com/2017/09/osgi-dependency-management-example.html

http://www.liferaysavvy.com/2017/09/osgi-bundle-manifest-headers.html

http://www.liferaysavvy.com/2017/09/osgi-declarative-services-detailed.html

http://www.liferaysavvy.com/2017/08/osgi-dependency-management.html

Service API

Service API consist set of services. It means simple interfaces and its abstract methods. These we will make it as bundle. Usually we use export mechanism to make these interfaces available to other bundles.

Hello Service Interface

public interface HelloService {
    public String sayHello();
}

Service API Provider

Service Provider bundle usually implement the services defined in the Service API bundle.

Hello Service Implementation

public class HelloServiceImpl implements HelloService {
    public String sayHello(){ 
    }
}

XML configuration

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<service id="helloServiceOne" ref="helloServiceImpl"

interface="com.liferaysavvy.blueprint.api.HelloService"/>
<bean id="helloServiceImpl"

class="com.liferaysavvy.blueprint.impl.HelloServiceImpl"/>
</blueprint>

Service Client

Service Client is other bundle, which use the services provided by Service Provider bundles.

public class HelloServiceClient {
    HelloService helloService = null;
    public HelloService getHelloService() {
        return helloService
    }
    public HelloService setHelloService(HelloService helloService) {
        this.helloService = helloService;
    }
}

XML configuration

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<bean id="helloworldClient"

class="com.liferaysavvy.blueprint.client.HelloServiceClient">
<property name="helloService" ref="helloServiceRef" />
</bean>
<reference id="helloServiceRef"

interface="com.liferaysavvy.blueprint.api.HelloService"/>
</blueprint>

Author

Meera Prince

Liferay Contributor of the Year 2016
Liferay Top Contributor Award Winner 2015

Liferay Contributor of the Year 2014

Liferay Top Contributor Award Winner 2013

http://www.liferaysavvy.com

Tuesday, October 10, 2017

Liferay 7 / DXP Modularity Introduction

Saturday, October 7, 2017

Apache Blueprint Introduction

Recent Posts

Popular Posts

Blog Archive

Followers

About Me

Total Pageviews

Categories

Find Us On Facebook

Labels

Popular Posts

Tuesday, October 10, 2017

Saturday, October 7, 2017

Recent Posts

Popular Posts

Blog Archive

Followers

About Me

Total Pageviews

Subscribe To

Categories

Find Us On Facebook

Labels

Popular Posts