/[debian]/libjpf-java/trunk/jdocs/about.jxp
ViewVC logotype

Contents of /libjpf-java/trunk/jdocs/about.jxp

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1601 - (show annotations)
Sat Feb 28 23:28:19 2009 UTC (12 years, 5 months ago) by gregoa
File size: 8524 byte(s)
[svn-inject] Forking libjpf-java source to Trunk
1 <%
2 // Java Plug-in Framework (JPF)
3 // Copyright (C) 2004 - 2006 Dmitry Olshansky
4 // $Id$
5 // Updated by Michael Dawson 11/01/2006
6 %>
7 <%
8 include("/functions.ijxp");
9
10 printHeader("Home");
11 printMenu("about");
12 %>
13 <div class="content">
14 <h1>JPF System Overview</h1>
15 <h3>Introduction</h3>
16 <p>The JPF framework is based around the concept of "plug-ins". A plug-in is a structured component that contributes code and resources to the system and describes them in a structured way. These plug-ins can further define <b>extension points</b>, well-defined method hooks that can be extended by other plug-ins. When one plug-in provides an implementation of an extension point defined by another plug-in, we say that it adds an <b>extension</b> to the system. This approach allows developers using JPF to build highly modular and easily extendible applications.</p>
17 <h3>Framework Structure</h3>
18 <p>All required information about a plug-in is defined in the plug-in manifest. Depending on the <a href="api/org/java/plugin//PluginRegistry.html">PluginRegistry</a>, this may be any structured data that exists at some URL. JPF provides a default XML-based manifest implementation. The format of this XML document is defined by the JPF <a href="dtd.html">plug-in DTD</a>. It is very important to include as much information about a plug-in in its manifest as possible. This is because the JPF framework uses this information to check plug-in consistency, whether plug-in dependencies (relationships between plug-ins) are satisfied (including version compatibility check) and that all declared resources are available. JPF also checks that all provided extensions have been declared with the required parameters.</p>
19 <p>The high-level structure of framework can be represented by this diagram:</p>
20 <p><img src="resources/images/jpf-diagram.png" width="500" height="292" border="0" alt="JPF High-level Structure Diagram" title="JPF High-level Structure Diagram" /></p>
21 <p>The diagram shows the three major parts of JPF:</p>
22 <ul>
23 <li><a href="api/org/java/plugin/registry/PluginRegistry.html">PluginRegistry</a> - the storage repository for meta-information about all discovered plug-ins</li>
24 <li><a href="api/org/java/plugin/PathResolver.html">PathResolver</a> - the component responsible for finding the physical lcation of all discovered resources</li>
25 <li><a href="api/org/java/plugin/PluginManager.html">PluginManager</a> - the framework runtime that loads and activates the plug-ins</li>
26 </ul>
27 <p><a href="api/org/java/plugin/registry/PluginRegistry.html">PluginRegistry</a> is a set of interfaces that abstract meta-information about plug-ins and plug-in fragments. The framework provides <strong>default implementations</strong> of these interfaces based on XML plug-in manifests mentioned earlier (<a href="dtd.html">plug-in DTD</a>). The general rule here is that a manifest should be registered with the <a href="api/org/java/plugin/registry/PluginRegistry.html">PluginRegistry</a> for every plug-in and plug-in fragment.</p>
28 <p>The framework also provides a <a href="api/org/java/plugin/standard/StandardPathResolver.html">default implementation</a> of <a href="api/org/java/plugin/PathResolver.html">PathResolver</a>, which simply maps manifest locations to the context ("home") folder of their corresponding plug-ins. A <a href="api/org/java/plugin/standard/ShadingPathResolver.html">special implementation</a> of <a href="api/org/java/plugin/PathResolver.html">PathResolver</a> is also available that makes "shadow copies" of plug-in resources before resolving paths to them. This helps avoid locking of local resources and running native code from remote locations.</p>
29 <p>Bringing these interfaces together is <a href="api/org/java/plugin/PluginManager.html">PluginManager</a>. You can access an instance of the "standard", or default, <a href="api/org/java/plugin/PluginManager.html">PluginManager</a> by just one <a href="api/org/java/plugin/ObjectFactory.html#createManager()">method call</a>. This makes using JPF very simple in most situations.</p>
30 <h3>Plug-in manifest</h3>
31 <p>If you are using <a href="api/org/java/plugin/registry/xml/package-summary.html">the default XML based implementation</a> of <a href="api/org/java/plugin/registry/PluginRegistry.html">PluginRegistry</a> provided by JPF, you'll need to learn the plug-in manifest syntax. It is simple and shouldn't be too difficult for any familiar with HTML or XML.</p>
32 <p>The plug-in manifest is an XML file which contains all the information needed by the JPF framework about each plug-in. The XML syntax should conform to the <a href="dtd.html">plug-in manifest DTD</a>. Look at this file carefully, all elements are documented.</p>
33 <h3>PluginRegistry</h3>
34 <p><a href="api/org/java/plugin/registry/PluginRegistry.html">PluginRegistry</a> manages all meta-information about discovered plug-ins. In general, you may provide your own registry implementation, but the standard one should be enough in most cases.</p>
35 <p>To make plug-in meta-data available for the application, you (as the application developer, but not plug-in developer) should <a href="api/org/java/plugin/registry/PluginRegistry.html#register(java.net.URL[])">register</a> their manifests with PluginRegistry. The counterpart method - <a href="api/org/java/plugin/registry/PluginRegistry.html#unregister(java.lang.String[])">unregister()</a> is used to "remove" plug-in meta-data from the registry. To make plug-ins available for activation, use <a href="api/org/java/plugin/PluginManager.html#publishPlugins(org.java.plugin.PluginManager.PluginLocation[])">publishPlugins()</a> method (about <a href="api/org/java/plugin/PluginManager.html">PluginManager</a> class see bellow). Note that all mentioned methods may be called not only during the application start up phase but in also at runtime. This allows application developers to implement "hot" plug-in deployment functionality.</p>
36 <h3>PluginManager</h3>
37 <p><a href="api/org/java/plugin/PluginManager.html">PluginManager</a> is the <b>runtime system</b> of the Framework. The main responsibility of the manager is to activate (load plug-in code and call the plug-in initializer class) plug-ins upon client code requests and manage inter plug-in dependencies. Usually, programmers shouldn't care about plug-in activation, this is done automatically when the plug-in code is first called. It is also possible to "deactivate" plug-ins during the life of the application. This feature may help to reduce application resources requirements. For complex usage scenarios it is possible to disable/enable plug-ins. A plug-in that is marked as disabled can't be activated with <a href="api/org/java/plugin/PluginManager.html">PluginManager</a> (but it's meta-data remains available from the PluginRegistry).</p>
38 <h3>Object factory</h3>
39 <p>The <a href="api/org/java/plugin/ObjectFactory.html">ObjectFactory</a> class allows application developers to easily create base JPF objects: <a href="api/org/java/plugin/registry/PluginRegistry.html">PluginRegistry</a>, <a href="api/org/java/plugin/PluginManager.html">PluginManager</a> and <a href="api/org/java/plugin/PathResolver.html">PathResolver</a>. It uses a simple and efficient discovery algorithm to find the available implementations of the main framework classes. It is possible to provide your own "vision" of all aspects of the Framework: you may write your own registry and manager and that will be used by JPF.</p>
40 <h3>Usage scenario</h3>
41 <p>A typical JPF-based application may consist of a small <b>boot launcher</b>, which initializes the registry, instanciates <a href="api/org/java/plugin/PluginManager.html">PluginManager</a> and activates <b>the main plug-in</b> by calling some of it's methods (Or you can use <a href="boot.html">the JPF Boot Library</a> provided by JPF to greatly simplify this task). From this point on the flow of control remains within the registered plug-in code. This allows the development of applications of any kind, not only GUI applications, but also J2EE applications, command line utilities and more.</p>
42 <p>See the <a href="http://sourceforge.net/project/showfiles.php?group_id=110394">demo application</a> source code for an example on how to build an application with JPF. You can also go through the <a href="tutorial.html">tutorial</a>, that explains the internals of JPF-Demo application.</p>
43 </div>
44 <%
45 printFooter();
46 %>

  ViewVC Help
Powered by ViewVC 1.1.26