Author: ieb
Date: Mon Jan 21 15:41:20 2013
New Revision: 1436426
URL: http://svn.apache.org/viewvc?rev=1436426&view=rev
Log:
Fixed some formatting and a link.
Modified:
sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext
Modified:
sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext
URL:
http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext?rev=1436426&r1=1436425&r2=1436426&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext
(original)
+++ sling/site/trunk/content/documentation/the-sling-engine/architecture.mdtext
Mon Jan 21 15:41:20 2013
@@ -3,23 +3,23 @@ Title: Architecture
The following is a short list of high-lights of Sling:
* *[OSGi]({{ refs.-osgi.path }})* --- The Sling application is built as a
series of OSGi bundles and makes heavy use of a number of OSGi core and
compendium services.
-* *[#Sling API]({{ refs.-sling-api.path }})* --- To implement content based
Web applications with Sling, an API has been defined, this extends the Servlet
API and provides more functionality to work on the content.
-* *[#Request Processing]({{ refs.-request-processing.path }})* --- Sling takes
a unique approach to handling requests in that a request URL is first resolved
to a resource, then based on the resource (and only the resource) it selects
the actual servlet or script to handle the request.
-* *[#Resources]({{ refs.-resources.path }})* --- The central mantra of Sling
is the *Resource*, which represents the resource addressed by any request URL.
It is the resource that is first resolved when handling a request. Based on the
resource, a first servlet or script is then accessed to actually handle the
request.
-* *[#Servlets and Scripts]({{ refs.-servlets-and-scripts.path }})* ---
Servlets and Scripts are handled uniformly in that they are represented as
resources themselves and are accessible by a resource path.
-* *[#Launchpad]({{ refs.-launchpad.path }})* --- Sling uses a very thin
launcher to integrate with an existing servlet container, launching Sling as a
Web application or providing a main class to represent a standalone Java
application.
+* *[Sling API]({{ refs.-sling-api.path }})* --- To implement content based Web
applications with Sling, an API has been defined, this extends the Servlet API
and provides more functionality to work on the content.
+* *[Request Processing]({{ refs.-request-processing.path }})* --- Sling takes
a unique approach to handling requests in that a request URL is first resolved
to a resource, then based on the resource (and only the resource) it selects
the actual servlet or script to handle the request.
+* *[Resources]({{ refs.-resources.path }})* --- The central mantra of Sling is
the *Resource*, which represents the resource addressed by any request URL. It
is the resource that is first resolved when handling a request. Based on the
resource, a first servlet or script is then accessed to actually handle the
request.
+* *[Servlets and Scripts]({{ refs.-servlets-and-scripts.path }})* --- Servlets
and Scripts are handled uniformly in that they are represented as resources
themselves and are accessible by a resource path.
+* *[Launchpad]({{ refs.-launchpad.path }})* --- Sling uses a very thin
launcher to integrate with an existing servlet container, launching Sling as a
Web application or providing a main class to represent a standalone Java
application.
The following sections elaborate on each of these highlights.
## OSGi
-[OSGi]({{ refs.http://www.osgi.org.path }}) is a consortium that has developed
a specification to build modular and extensible applications. This offers
[various benefits|http://www.osgi.org/About/WhyOSGi]. We deal mainly with two
parts of the specifications: The Core Specification, which defines the OSGi
Framework and Core Services, and the Compendium Services Specification, which
defines a host of services that extend the functionality of the OSGi Framework.
+[OSGi](http://www.osgi.org) is a consortium that has developed a specification
to build modular and extensible applications. This offers [various
benefits](http://www.osgi.org/About/WhyOSGi). We deal mainly with two parts of
the specifications: The Core Specification, which defines the OSGi Framework
and Core Services, and the Compendium Services Specification, which defines a
host of services that extend the functionality of the OSGi Framework.
### OSGi Framework
The OSGi Framework is made up of three layers -- Module, Lifecycle, and
Services -- that define how extensible applications are built and deployed. The
responsibilities of the layers are:
-* *Module* --- Defines how a module, or a *Bundle* in OSGi-speak, 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 which define what a bundle
provides -- `Export-Package` -- and what a bundle requires to be operative --
`Import-Package` and `Require-Bundle`.
+* *Module* --- Defines how a module, or a *Bundle* in OSGi-speak, 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 which define what a bundle
provides `Export-Package` and what a bundle requires to be operative
`Import-Package` and `Require-Bundle`.
* *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.
* *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.
