About Dispatcher

Posted on by Prahlad Dutta
Dispatcher is Adobe Experience Manager’s caching and/or load balancing tool. Using AEM’s Dispatcher also helps to protect your AEM server from attack. Therefore, you can increase the security of your AEM instance by using the Dispatcher in conjunction with an enterprise-class web server.

  • Caching: It is used to cache as much content as possible in the form of a static website, which helps to reduce the continuous calling for generating content when website data is dynamic.
  • Load-balancing:  If there are multiple cq instances configured with a dispatcher, the dispatcher can do a load-balancing and if there is too much load on any cq instance, it can relay the request to another less busy instance.    
Dispatcher uses the following method for content caching:
  • Content Updates invalidates those pages whose content has been updated and replaces it with new content.
  • Auto-invalidation automatically invalidates the content parts which are out of date – without physically deleting any files.
How dispatcher performs load-balancing?
  • Performance Statics: Dispatcher keeps statistics on how fast each instance of cq is responding to a particular url. Based on those metrics, dispatcher determines which instance of cq will fetch the quickest response for any request and relays the request to that cq instance
  • Sticky Connections: when a user session is established, then all incoming requests from that user should be served by the same cq instance, because other cq instances cannot recognize the user session and generate personalized pages for him. Dispatcher makes sure all requests for user session are served from the same cq instance..
  • Increase fail-safe coverage: If the Dispatcher does not receive responses from an instance, it will automatically relay requests to one of the other instance.

OSGI

Posted on by Prahlad Dutta
The OSGi Alliance, formerly known as the Open Services Gateway initiative. The OSGi specification describes a modular system and a service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments. Applications or components, coming in the form of bundles for deployment, can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot; management of Java packages/classes is specified in great detail. Application life cycle management is implemented via APIs that allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly.

Architecture

OSGi (Open Service Gateway Initiative) is a Java framework for developing and deploying modular software programs and libraries. Each bundle is a tightly coupled, dynamically loadable collection of classes, jars, and configuration files that explicitly declare their external dependencies (if any).
The framework is conceptually divided into the following areas:

Bundles
Bundles are normal JAR components with extra manifest headers.
Services
The services layer connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java interfaces (POJIs) or plain old Java objects (POJOs).
Services Registry
The application programming interface for management services (ServiceRegistration, ServiceTracker and serviceReference)
Life-Cycle
The application programming interface for life cycle management (install, start, stop, update, and uninstall) for bundles.
Modules
The layer that defines encapsulation and declaration of dependencies (how a bundle can import and export code).
Security
The layer that handles the security aspects by limiting bundle functionality to pre-defined capabilities.
Execution Environment
Defines what methods and classes are available in a specific platform.

    Difference between osgi service and component in AEM

    Posted on by Prahlad Dutta

    OSGi Component

    If we want any object to be managed by the OSGi container, we should declare it as a component. Using annotations, we could make a POJO a OSGi component by annotating it with @Component. With this, we will get the ability to start, stop and configure the component using the felix web console. All objects managed by OSGi container are components. we qualify components as services. This means that all services are components but not vice-versa.
    OSGi Service

    OSGi components can be made as OSGi service by marking it with @Service annotation. When we mark a component as service, we can this service from other osgi components. Components can call (using container injection – @Reference) other services but not components. In other words, a component cannot be injected into another component / service. Only services can be injected into another component.


    OSGi Component Vs Service
    • All objects managed by OSGi container are components. we can qualify components as services. This means that all services are components but not vice-versa.
    • Components can call (using container injection – @Reference) other services but not components. In other words, a component cannot be injected into another component / service. Only services can be injected into another component.