incubator-sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Sling Website > Architecture
Date Mon, 16 Nov 2009 13:13:00 GMT
<html>
<head>
    <base href="http://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/1519/1/1/_/styles/combined.css?spaceKey=SLINGxSITE&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background-color: white" bgcolor="white">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
     <h2><a href="http://cwiki.apache.org/confluence/display/SLINGxSITE/Architecture">Architecture</a></h2>
     <h4>Page <b>edited</b> by             <a href="http://cwiki.apache.org/confluence/display/~fmeschbe">Felix
Meschberger</a>
    </h4>
     
          <br/>
     <div class="notificationGreySide">
         <h1><a name="Architecture-ArchitectureofSling"></a>Architecture
of Sling</h1>

<p>The following is a short list of high-lights of Sling:</p>

<ul>
	<li><b><a href="#Architecture-OSGi">OSGi</a></b> &#8212;
The Sling application is built as a series of OSGi bundles and makes heavy use of a number
of OSGi core and compendium services</li>
	<li><b><a href="#Architecture-SlingAPI">Sling API</a></b> &#8212;
To implement Content based Web Applications with Sling, an API has been defined, which extends
the Servlet API and provides more functionality to work on the content</li>
	<li><b><a href="#Architecture-RequestProcessing">Request Processing</a></b>
&#8212; Sling takes a unique approach to handling requests in that a request URL is first
resolved to a resource and only based on the resource then select the actual servlet or script
to handle the request.</li>
	<li><b><a href="#Architecture-Resources">Resources</a></b>
&#8212; The central mantra of Sling is the <b>Resource</b>, which represents
the resource addressed by any request URL. It is the resource, which is first resolved when
handling a request. Based on the resource, a first servlet or script is then looked up to
actually handle the request.</li>
	<li><b><a href="#Architecture-ServletsandScripts">Servlets and Scripts</a></b>
&#8212; Servlets and Scripts are handled uniformly in that they are represented as resources
themselves and are accessible by a resource path.</li>
	<li><b><a href="#Architecture-Launchpad">Launchpad</a></b>
&#8212; 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.</li>
</ul>


<p>The following sections elaborate on each of these high-lights.</p>

<h2><a name="Architecture-OSGi"></a>OSGi</h2>

<p><a href="http://www.osgi.org" rel="nofollow">OSGi</a> is a consortium
which developped a specification to build modular and extensible applications. We are mainly
dealing 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, which extend the functionality of the OSGi Framework.</p>

<h3><a name="Architecture-OSGiFramework"></a>OSGi Framework</h3>

<p>The OSGi Framework is made up of three layers &#8211; Module, Lifecycle, and
Services &#8211; which define how extensible applications are built and deployed. The
responsibilities of the layers are:</p>

<ul>
	<li><b>Module</b> &#8212; Defines how a module, or a <em>Bundle</em>
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 &#8211; <tt>Export-Package</tt>
&#8211; and what a bundle requires to be operative &#8211; <tt>Import-Package</tt>
and <tt>Require-Bundle</tt>.</li>
	<li><b>Lifecycle</b> &#8212; The lifecycle layer defines the states
a bundle may be in and describes the state changes. By providing a class, which implements
the <tt>BundleActivator</tt> interface and which is named in the <tt>Bundle-Activator</tt>
manifest header, a bundle may hook into the lifecycle process when the bundle is started and
stopped.</li>
	<li><b>Services</b> &#8212; For the application to be able to interact,
the OSGi Core Specification defines the service layer, which describes a registry for services,
which may be shared.</li>
</ul>



<h3><a name="Architecture-CompendiumServices"></a>Compendium Services</h3>

<p>Based on the OSGi Framework specification, the Compendium Services specification
defines a (growing) number of extension services, which may be used by applications for various
tasks. Of these Compendium Services, Sling is using just a small number:</p>

<ul>
	<li><b>Log Service</b> &#8212; Sling comes with its own implementation
of the OSGi Log Service specification. The respective bundle not only provides this implementation,
it also exports the SLF4J, Log4J and Commons Logging APIs for Sling application to perform
logging.</li>
	<li><b>Http Service</b> &#8212; To hook into a servlet container to
provide the Web Application Framework mechanism Sling is leveraging the OSGi Http Service.</li>
	<li><b>Configuration Admin Service</b> &#8212; To simplify configuration
of services in Sling, the OSGi Configuraiton Admin service is used. This provides a uniform
API to configure services and to build configuration management agents.</li>
	<li><b>Metatype Service</b> &#8212; The OSGi Metatype Service defines
a way to describe the data types. Sling uses this service to describe the configurations which
may be created using the Configuration Admin Service. These meta type descriptions are used
by configuraiton management agents to present to user interface to manage the configurations.</li>
	<li><b>Event Admin Service</b> &#8212; To dispatch events for scheduling
of tasks, Sling is using the OSGi EventAdmin service.</li>
	<li><b>Declarative Services</b> &#8212; One of the most important (besides
the Log Service) services used by Sling is the Declarative Services Specification. This specification
defines how to declaratively create components and services and have the Declaratvie Services
runtime actually manage the lifecycle, configuration and references of components.</li>
</ul>



<h2><a name="Architecture-SlingAPI"></a>Sling API</h2>

<p>The Sling API is an extension to the Servlet API which provides more functionality
to interact with the Sling framework and also to extend Sling itself and to implement Sling
applications.</p>

<p>See the <a href="/confluence/display/SLINGxSITE/Sling+API" title="Sling API">Sling
API</a> page for more information.</p>


<h2><a name="Architecture-RequestProcessing"></a>Request Processing</h2>

<p>Traditional Web Application framework emply more or less elaborate methods to select
a Servlet or Controller based on the request URL, which in turn tries to load some data (usually
from a database) to act upon and finally to render the result somehow.</p>

<p>Sling turns this processing around in that it places the data to act upon at the
center and consequently uses the request URL to first resolve the data to process. This data
is internally represented as an instance of the <tt>Resource</tt> interface. Based
on this resource as well as the request method and more properties of the request URL a script
or servlet is then selected to handle the request.</p>

<p>See the <a href="/confluence/display/SLINGxSITE/Request+Processing" title="Request
Processing">Request Processing</a> page for more information.</p>


<h2><a name="Architecture-Resources"></a>Resources</h2>


<p>The Resource is one of the central parts of Sling. Extending from JCR's <em>Everything
is Content</em>, Sling assumes <em>Everthing is a Resource</em>. Thus Sling
is maintaining a virtual tree of resources, which is a merger of the actual contents in the
JCR Repository and resources provided by so called resource providers.</p>

<p>Each resource has a path by which it is addressed in the resource tree, a resource
type and some resource metadata (such as file size, last modification time). It is important
to understand, that a <tt>Resource</tt> instance actually is only a handle to
the actual data. By virtue of the <tt>adaptTo(Class&lt;Type&gt;)</tt>
method, a resource may be coerced into another data type, which may then be used while processing
the request. Examples of data types are <tt>javax.jcr.Node</tt> and <tt>java.io.InputStream</tt>.</p>

<p>See the <a href="/confluence/display/SLINGxSITE/Resources" title="Resources">Resources</a>
page for more information.</p>


<h2><a name="Architecture-ServletsandScripts"></a>Servlets and Scripts</h2>

<p>Scripts are usually provides as content in a JCR repository. But since Sling is using
a resource tree, a script actually is represented as a Resource and may be provided from within
a Bundle (by virtue of the bundle resource provider) or even from the platform file system
(by virtue of the file system resource provider).</p>

<p>Accessing scripts in the resource tree, allows for a very easy to understand mapping
from resource type to some script path.</p>

<p>Having found the script resource, we still need access to the appropriate script
language implementation to evaluate the script. To this avail, Sling is making use of the
<tt>Resource.adaptTo(Class&lt;Type&gt;)</tt> method: If a script language
implementation is available for the extension of the script name an adaptor for the script
resource can be found, which handles the evaluation of the script.</p>

<p>Besides scripting languages, such as ECMAScript, Groovy, JSP, Sling also supports
regular servlets. To be able to use servlets for request processing, such servlets must be
registered as OSGi services for the <tt>javax.servlet.Servlet</tt> interface and
provide a number of service registration properties, which are used to use the servlets. In
fact servlets thus registered as OSGi services are mapped into the resource tree by means
of a servlet resource provider. This resource provider mapps the servlets into the resource
tree using the service registration properties to build one or more resource paths for the
servlet.</p>

<p>As a result of mapping servlets into the resource tree and the possibility to adapt
resource to an adaptor data type, scripts and servlets may be handled completely transparently:
The servlet resolver just looks for a resource matching the resource type and adapts the resource
found to <tt>javax.jcr.Servlet</tt>. If the resource happens to be provided by
a servlet resource provider, the adapter is of course the servlet itself. If the resource
happens to be a script, the adapter is a servlet facade which internally calls the script
language implementation to evaluate the script.</p>

<p>See the <a href="/confluence/display/SLINGxSITE/Servlet+Resolution" title="Servlet
Resolution">Servlet Resolution</a> page for more information.</p>



<h2><a name="Architecture-Launchpad"></a>Launchpad</h2>


<p>Sling may be launched as a standalone application using the Sling Application or
as a Web Application running inside any Servlet API 2.4 or newer Servlet Container.</p>

<p>The Sling Application is a standalone Java Application which is really small: Just
the main class and some glue classes. The OSGi framework as well as the OSGi API libraries
are packaged as a JAR file, which is loaded through a custom classloader. This enables to
update the framework and/or OSGi API libraries from within Sling by updating the system bundle.</p>

<p>The Sling Servlet is equally small as the Sling Application. In addition to the Sling
servlet, the Equinox HTTP Servlet is contained in the Sling web application, which provides
the glue between the servlet container and the OSGi framework.</p>

<p>As we have seen, Sling may be launched as a standalone Java Application or as a Web
Application inside any compliant Servlet Container. To hide the differences of the launching
mechanism, Sling internally registers a Servlet with an OSGi <tt>HttpService</tt>.
Depending on the launch method, the following <tt>HttpService</tt> implementations
are used:</p>


<ul>
	<li><b>PAX Web Service</b> - If Sling is launched as a standalone Java
Application, the PAX Web Service bundle is used as the implementation of the OSGi <tt>HttpService</tt>.</li>
	<li><b>Equinox HTTP Servlet</b> - If Sling is launched as a Web Application,
the <a href="http://www.eclipse.org/equinox/server" rel="nofollow">Equinox HTTP Servlet</a>
is used as the OSGi <tt>HttpService</tt> implementation to link the HTTP Servlet
into the Servlet Container through the Sling Servlet.</li>
</ul>



<p>See <a href="/confluence/display/SLINGxSITE/Launch+Sling" title="Launch Sling">Launch
Sling</a> for more information.</p>


     </div>
     <div id="commentsSection" class="wiki-content pageSection">
       <div style="float: right;">
            <a href="http://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
       </div>

       <a href="http://cwiki.apache.org/confluence/display/SLINGxSITE/Architecture">View
Online</a>
       |
       <a href="http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=76156&revisedVersion=7&originalVersion=6">View
Change</a>
              |
       <a href="http://cwiki.apache.org/confluence/display/SLINGxSITE/Architecture?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message