integrate.xml.svn-base

portal越来越流行了

            portal/framework). In some cases the flow goes in the other
            direction, from container to portal. The nature of a service can be
            viewed as a service made available for the portlet container:
            The container needs it to run, but cannot implement the service
            itself.
          </p>
					<p>
            The Container Service concept makes the portlet container
            independent of portal functions so that it can be used by different
            portals and furthermore new services can be plugged in to get a
            richer portlet container experience. A ContainerServiceEnvironment
            describing all services must be created and passed to the portlet
            environment during initialization.
          </p>
          <p>
            Container Services can be split into two different categories:
            <ul>
              <li>
                <p><b>Mandatory Base Services</b></p>
                <p>ContainerServices that must be provided by the calling party
                so that the portlet container is able to run.</p>
                <ul>
                  <li><b>Information Provider Service:</b> described in the next
                  sub section</li>
								  <li><b>Factory Manager Service:</b> Factory Service enables
                  the portlet container to get implementation objects through a
                  factory concept.</li>
                  <li><b>Log Service:</b> This interface defines a logging
                  facility.</li>
                </ul>
              </li>
              <li>
                <p><b>Optional Base Services</b></p>
                <p>ContainerServices that can be provided by the calling party,
                but the container can run without it.</p>
                <ul>
                  <li><b>Property Manager Service:</b> The implementation of the
                  Property Service interface enables a portal to deal with
                  properties as defined in the JSR 168 specification.</li>
                  <li><b>Dynamic Title Service:</b> Allows to support dynamic
                  titles.</li>
                </ul>
              </li>
            </ul>
          </p>
          
          <subsection name="3.2.1 Information Provider Service">
            <p>
              The Information Provider is a callback mechanism for the portlet
              environment into the calling party (mostly framework), to get hold
              of necessary information that can only be known by the portal,
              like hostname and URL generation. To differentiate between the
              scopes of the requested information, the portlet environment
              defines two interfaces: the DynamicInformationProvider and the
              StaticInformationProvider.
            </p>
            <p>
              The DynamicInformationProvider provides request-based information,
              which changes for each request. Consequently a new
              DynamicInformationProvider needs to be passed to the portlet
              environment for each request. Typical information provided by this
              Information Provider is a URL to a portlet. Additional provider
              interfaces retrieved via getter methods of the
              DynamicInformationProvider are PortletURLProvider and
              PortletActionProvider.
            </p>
            <p>
              The StaticInformationProvider on the other hand provides
              non-request-based information, which is constant across all
              requests. Therefore only one StaticInformationProvider needs to be
              provided to the portlet environment (singleton). Typical
              information provided by this Information Provider is the root
              context of the portal. An additional provider interface retrieved
              via a getter method of the StaticInformationProvider is the
              PortalContextProvider that contains further information about the
              portal, which need to be provided to the portlet.
            </p>
            <p>
              Both Information Providers are not actively passed by the calling
              party to the environment. Instead they are made available to the
              portlet environment through the Container Service mechanism
              described in the next section. Basically, the portlet environment
              asks the calling party for an instance of one of the Information
              Providers and the calling party returns the correct Information
              Provider.
            </p>
          </subsection>
          
          <subsection name="3.3 Portlet Object Model">
						<p>The Portlet Object Model interfaces are defined in the package org.apache.pluto.om. These interfaces should be seen as an internal interface that can be used by other components of the portal. The portlet environment only defines the interfaces that are necessary to execute the object model the portal that uses the portlet environment must implement the object model. </p>
						<p>The object model represents the information available on different levels about portlets and the portlet application, like the deployment descriptors and customization data. </p>
						<p>The following definitions are used to represent the different levels of information:</p>
						<ul>
							<li>
								<p>
									<strong>WebApplicationDefinition</strong> represents the context for the Portlet Application defined in the web.xml deployment descriptor.</p>
							</li>
							<li>
								<p>
									<strong>PortletApplicationDefinition</strong> describes a set (either all or a subset) of portlets that participate all in the same WebApplicationDefinition.</p>
							</li>
							<li>
								<p>
									<strong>PortletApplicationEntity</strong> is an instantiation of a PortletApplicationDefinition that is bound to a portal resource. It contains a set (either all or a subset) of portlets that participate all in the same PortletApplicationDefinition.</p>
							</li>
							<li>
								<p>
									<strong>ServletDefinition</strong> describes the portlet and its initial read-only properties that is not bound to any portal resource.</p>
							</li>
							<li>
								<p>
									<strong>Portlet Definition</strong> basic settings defined in the portlet.xml or set by administrators (read-only for users).</p>
							</li>
							<li>
								<p>
									<strong>Portlet Entity</strong> is a parameterized portlet definition, belonging to a user. </p>
							</li>
							<li>
								<p>
									<strong>Portlet Window</strong> is part of an aggregation tree that contains the portlet markup. The portlet window has navigational state attached to it.<!--&#11;-->
								</p>
							</li>
						</ul>
						<p>Figure 3 depicts the relation between the different definitions and their hierarchical structure. The servlet definitions are embedded in the web application definition. From a web application definition several portlet application definitions can be created that may consist of portlet definitions based on the servlet definitions defined in the web application definition. Using the portlet application definition several portlet application entities can be created that include portlet entities that are based on the corresponding portlet definitions. Finally the portlet windows of a portlet entity are linked to their corresponding portlet entity.</p>
						<div align="center">
							<p>
									<a href="../../images/v101/Relations.jpg">
										<img src="../../images/v101/Relations.jpg" alt="Portal Architecture"/>
								</a>
							</p>
							<p>
								<b>
									<i>Figure 3. Relations between the different application and portlet representations
									</i>
								</b>
							</p>
						</div>
						<p>The portlet object model represents these different layers allowing the portlet container to access the information layer-based.</p>
						<p>The object model is split into four different sub-packages:</p>
						<ul>
							<li>
								<p>common</p>
								<p>contains generic interfaces that can be reused</p>
							</li>
							<li>
								<p>window</p>
								<p>contains all interfaces handling with portlet windows</p>
							</li>
							<li>
								<p>entity</p>
								<p>contains all interfaces handling with portlet application entities and portlet entities</p>
							</li>
							<li>
								<p>portlet</p>
								<p>contains all interfaces handling with portlet application definitions and portlet definitions</p>
							</li>
							<li>
								<p>servlet</p>
								<p>contains all interfaces representing the web application definitions and servlet definitions</p>
							</li>
						</ul>
						<p>For the implementation of the different artifacts in the object model the model-view-controller pattern is used and for each artifact a read-only interface exists, and if required an interface with the setter methods and the ending Ctrl is provided.</p>
					</subsection>
				</subsection>
			</subsection>
		</section>
	</body>
</document>