Open Systems Gateway Initiative (OSGI)
OSGi has developed a specification to build modular and extensible applications. The OSGi module system allows building applications as a set of reloadable and strongly encapsulated services. OSGi “bundles” run inside an “OSGi container”, which manages relations among bundles. Again, bundles are simply JAR files that contain extra metadata indicating what services they require and which they provide.
OSGi Framework
The OSGi Framework is made up of three layers that define how extensible applications are built and deployed.
The OSGi Framework is made up of three layers that define how extensible applications are built and deployed.
- Module
- Lifecycle
- Services.
1. Module:
Defines how a module or a Bundle in OSGi is defined. Basically, a bundle is just a plain old JAR file, whose manifest file has some defined entries. These entries identify the bundle with a symbolic name, a version, and more. In addition, there are headers that define what a bundle provides – Export-Package – and what a bundle requires to be operative – Import-Package and Require-Bundle.
Defines how a module or a Bundle in OSGi is defined. Basically, a bundle is just a plain old JAR file, whose manifest file has some defined entries. These entries identify the bundle with a symbolic name, a version, and more. In addition, there are headers that define what a bundle provides – Export-Package – and what a bundle requires to be operative – Import-Package and Require-Bundle.
2.Lifecycle:
The lifecycle layer defines the states a bundle may be in and describes the state changes. By providing a class, which implements the BundleActivator interface and which is named in the Bundle-Activator manifest header, a bundle may hook into the lifecycle process when the bundle is started and stopped.
The lifecycle layer defines the states a bundle may be in and describes the state changes. By providing a class, which implements the BundleActivator interface and which is named in the Bundle-Activator manifest header, a bundle may hook into the lifecycle process when the bundle is started and stopped.
3. Services:
For the application to be able to interact, the OSGi Core Specification defines the service layer. This describes a registry for services, which may be shared.
Sample Manifest information:
For the application to be able to interact, the OSGi Core Specification defines the service layer. This describes a registry for services, which may be shared.
Sample Manifest information:
Export-Package: *
Import-Package: *
Private-Package: *
# Include-Resource:
Bundle-Name: Workflow Purge
Bundle-Description: Allow automatic & scheduled purge of workflows
Bundle-SymbolicName: com.adobe.daycare.workflow.purge
Bundle-Version: 1.7.1
Bundle-Activator: com.adobe.daycare.workflow.purge.Activator
Apache Sling
Apache Sling is a web framework that uses a Java Content Repository, such as Apache Jackrabbit or Adobe CRX to store and manage content. Sling applications use either scripts or Java servlets to process HTTP requests in a RESTful way. The Sling application is built as a series of OSGi bundles and makes heavy use of a number of OSGi services. Being a REST framework, Sling is oriented around resources, which usually map into JCR nodes.
Traditional web applications select processing script based on the URL and then attempt to load data to render a result.
In Apache Sling, request URL is first resolved to a resource, then based on the resource it selects the actual servlet or script to handle the request.
The resource is one of the central parts of Sling. Sling assumes that “Everything is a Resource”. Sling resources usually map to a JCR node.
Every script, servlet, filter, error handler, etc. are available from the ResourceResolver just like normal content providing data to be rendered upon requests, and they are accessible by a resource path.
Using Sling, the type of content to be rendered is not the first processing consideration. Instead, the main consideration is whether the URL resolves to a content object for which a script can then be found to perform the rendering.
In Sling, and therefore also in AEM, the processing is driven by the URL of the HTTP
request. This defines the content to be displayed by the appropriate scripts. To do this, information is extracted from the URL. When the appropriate resource (content node) is located, the resource type is extracted from the resource properties. The sling:resourceType property is a path, which locates the script to be used for rendering the content.
Template:
A Template is used to create a Page and defines which components can be used within the selected scope. A Template is a hierarchy of nodes that has the same structure as the page to be created, but without any actual content. Each Template will present you with a selection of components available for use.
Templates are built up of Components. Components use, and allow access to, Widgets, which are used to author/render content. A Template is the basis of a Page. To create a Page, the Template’s content must be copied (/apps/<application name>/templates/<template name>) to the corresponding position in the site-tree.
Apache Sling
Apache Sling is a web framework that uses a Java Content Repository, such as Apache Jackrabbit or Adobe CRX to store and manage content. Sling applications use either scripts or Java servlets to process HTTP requests in a RESTful way. The Sling application is built as a series of OSGi bundles and makes heavy use of a number of OSGi services. Being a REST framework, Sling is oriented around resources, which usually map into JCR nodes.
Traditional web applications select processing script based on the URL and then attempt to load data to render a result.
In Apache Sling, request URL is first resolved to a resource, then based on the resource it selects the actual servlet or script to handle the request.
The resource is one of the central parts of Sling. Sling assumes that “Everything is a Resource”. Sling resources usually map to a JCR node.
Every script, servlet, filter, error handler, etc. are available from the ResourceResolver just like normal content providing data to be rendered upon requests, and they are accessible by a resource path.
Using Sling, the type of content to be rendered is not the first processing consideration. Instead, the main consideration is whether the URL resolves to a content object for which a script can then be found to perform the rendering.
In Sling, and therefore also in AEM, the processing is driven by the URL of the HTTP
request. This defines the content to be displayed by the appropriate scripts. To do this, information is extracted from the URL. When the appropriate resource (content node) is located, the resource type is extracted from the resource properties. The sling:resourceType property is a path, which locates the script to be used for rendering the content.
Template:
A Template is used to create a Page and defines which components can be used within the selected scope. A Template is a hierarchy of nodes that has the same structure as the page to be created, but without any actual content. Each Template will present you with a selection of components available for use.
Templates are built up of Components. Components use, and allow access to, Widgets, which are used to author/render content. A Template is the basis of a Page. To create a Page, the Template’s content must be copied (/apps/<application name>/templates/<template name>) to the corresponding position in the site-tree.
CRXDE Lite:
CRXDE Lite is embedded into CQ5/CRX and enables you to perform standard development tasks in a Web browser. With CRXDE Lite, you can create and edit files (e.g. JSP, Java, HTML, etc.), folders, Templates, Components, Dialogs, nodes, properties, and bundles; all while logging and integrating with SVN.
CRXDE Lite is recommended when you do not have direct access to the CQ/CRX server, when you develop an application by extending or modifying the out-of-the-box components and Java bundles, or when you do not need a dedicated debugger, code completion and syntax highlighting.
CRXDE Lite is embedded into CQ5/CRX and enables you to perform standard development tasks in a Web browser. With CRXDE Lite, you can create and edit files (e.g. JSP, Java, HTML, etc.), folders, Templates, Components, Dialogs, nodes, properties, and bundles; all while logging and integrating with SVN.
CRXDE Lite is recommended when you do not have direct access to the CQ/CRX server, when you develop an application by extending or modifying the out-of-the-box components and Java bundles, or when you do not need a dedicated debugger, code completion and syntax highlighting.
Page-rendering Component:
Components are modular, re-usable units that implement specific functionality/logic to render the content of your Web site. They have no hidden configuration files, can include other Components, and can run anywhere within CQ5 or in isolation (e.g. portal).
A Component could be described as a collection of scripts (e.g. JSPs, Java servlets, etc.) that completely realize a specific function. More specific, a “Page” Component is typically referenced by a Template.
Components are modular, re-usable units that implement specific functionality/logic to render the content of your Web site. They have no hidden configuration files, can include other Components, and can run anywhere within CQ5 or in isolation (e.g. portal).
A Component could be described as a collection of scripts (e.g. JSPs, Java servlets, etc.) that completely realize a specific function. More specific, a “Page” Component is typically referenced by a Template.
Page:
A Page is where content authors will create and edit the content that will most likely be published and viewed by site visitors. It is an exact copy of the Template from which it was created.
A Page is where content authors will create and edit the content that will most likely be published and viewed by site visitors. It is an exact copy of the Template from which it was created.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.