<document>
<header>
<product>resin</product>
<title>Features - Resin and Resin Professional</title>
<description>

<p>Resin is a high-performance, scalable Java/PHP application server.  We
release two versions of Resin: an open source version under the GPL, and
a professional version with enhanced performance, clustering,
and reliability features.</p>

</description>
</header>

<body>

<localtoc/>

<s1 name="resinpro" title="Resin Professional">
<p>
Resin is provided in two versions, Resin Professional and Resin Open Source.
Resin Professional adds features and enhancements commonly needed in a 
professional production environment.  Resin Open Source is suitable
for hobbyists, developers, and low traffic websites that do not
need the performance and reliability enhancements of Resin Professional.
</p>

<s2 name="reliability" title="Reliability features">
  
<p>Resin Professional provides a number of reliability features,
including automatic server restart, detection and restart of locked or
stalled servers, and monitoring of JVM memory usage for applications
with memory leaks.</p>

<ul>
<li>Resin configuration: <a href="cluster-tags.xtp#ping">&lt;ping&gt;</a></li>
<li>Resin configuration: <a href="server-tags.xtp#min-free-memory">min-free-memory</a></li>
</ul>

</s2>

<s2 name="cluster" title="Clustering">
<p>
Clustering provides the ability for multiple servers to appear as one server
to clients.  Clustering  provides enhanced reliability and allows sites to
scale up as server demand increases,
</p>
<p>
Clustering is supported with the standalone web server, Apache, and IIS.
</p>

<ul>
<li>Resin documentation: <a href="resin-clustering.xtp">Reliability and Load Balancing</a></li>
</ul>
</s2>

<s2 name="session" title="Persistent and Distributed sessions">
<p>Persistent sessions guarantee that a server can restore the contents
of the HttpSession object when it is restarted.
Distributed sessions provide the ability for multiple
servers in a cluster to share the values stored in the HttpSession.
</p><ul>
<li>Resin documentation: <a href="tcp-sessions.xtp">Persistent and Distributed Sessions</a></li>
</ul>
</s2>


<s2 name="native" title="Performance enhancing native code">
<p>
Resin Professional includes a native code libary on both Windows and Unix
platforms.  Native code is used to provide significant performance benefits
in areas like socket connections, keepalive connections, and file system
access.
</p>
</s2>

<s2 name="openssl" title="OpenSSL">
<p>
Resin Professional uses native code to link to the OpenSSL libraries,
a much better and more efficient SSL solution than the Java facilities
provided by JSSE.
</p>

<ul>
<li>Resin documentation: <a href="ssl.xtp">OpenSSL</a>
</li></ul>
</s2>

<s2 name="caching" title="HTTP proxy caching">
<p>
Resin Professional provides a memory and disk based caching system for
increased performance benefits.
Server caching can speed dynamic pages to
near-static speeds. Small but frequently accessed resources
such as images and css files are cached in memory and served directly
to the client, avoiding even a read from the disk.
</p>

<p>
Many pages require expensive operations like database
queries but change infrequently.
Resin can cache the results and serve them like static pages.
Resin's caching will work for any servlet, including JSP
and XTP pages.
</p>

<ul>
<li>Resin documentation: <a href="proxy-cache.xtp">Caching</a></li>
<li>Resin configuration: <a href="cluster.xtp#cache">&lt;cache></a>
</li></ul>
</s2>

<s2 name="gzip" title="Gzip filter">
<p>
Bandwidth costs are significant for many websites. The GzipFilter
enables automatic compression of responses for browsers that support
it.  Use of the GzipFilter reduces bandwidth usage
and may provide significant cost savings.
</p>
<ul>
<li>Resin documentation: <a href="filter-library.xtp#GzipFilter">GzipFilter</a>
</li></ul>
</s2>
  
</s1> <!-- resinpro -->

<s1 name="webserver" title="Web Server">
<s2 title="Standalone">
<ul>
<li><a href="resin-web-server.xtp">Resin documentation: Standalone web server Unix and Windows</a>
</li></ul>
<s3 name="http" title="Hypertext Transfer Protocol (HTTP)">
</s3>

<s3 name="ssl" title="Secure Socket Layer (SSL) 3.0">
<ul>
<li><a href="ssl.xtp">Resin documentation</a>
</li></ul>
</s3>

</s2> <!-- webserver -->

<s2 title="Apache 2.0 and 2.2 integration">
<ul>
<li><a href="install-apache.xtp">Resin documentation: Resin with Apache</a>
</li></ul>
</s2>

<s2 title="IIS 5 and IIS 6 integration">
<ul>
<li><a href="install-iis.xtp">Resin documentation: Resin with IIS</a>
</li></ul>
</s2>

<s2 name="cgi" title="CGI">
<ul>
<li><a href="servlet-library.xtp#CGIServlet">Resin documentation</a>
</li></ul>
</s2>

</s1>

<s1 title="Resin-IoC and Dependency Injection">

<ul>
<li>See <a href="resin-ioc.xtp">Resin-Ioc</a> documentation.</li>
</ul>

<p>Resin uses its own IoC/Dependency Injection engine for all of its JavaEE
configuration.  With the new WebBeans (JSR-299) specification draft, Resin
provides the same capabilities to application code.  Components and
singleton beans can be configured in the resin-web.xml for full XML
configurability, or scanned for the class annotations for lightweight
injection to match the style of the application.</p>

<p>Because Resin-IoC is fully integrated with Resin's EJB 3.0 support, all
application components and beans can use EJB aspects such
as @TransactionAttribute, @Stateless, @InterceptorClass, and @AroundInvoke.</p>

<p>The WebBeans IoC capabilities provide finely-controlled interception
with @InterceptorType binding, and type-safe dependency-injection
with @BindingType annotations.  Testing with mock components are automatically
supported with custom @ComponentType annotations.</p>

<p>Event handling is fully integrated with the WebBeans API using a flexible
@Observes parameter attribute, enabling any bean or component to listen to
any matching typed event thrown through the WebBeans Container interface.</p>

<p>Resin-managed classes are automatically enlisted in the IoC engine.  So
Servlets, Filters, application listener classes, remote objects, and
EJBs can all use Resin-IoC capabilities without any
additional configuration.</p>

<p>Resin-IoC provides a straightforward driver for integrating Resin-IoC
capabilities with popular frameworks.
<a href="http://wiki.caucho.com/Struts2">Struts2</a>,
<a href="http://wiki.caucho.com/Spring">Spring</a>, 
<a href="http://wiki.caucho.com/Mule">Mule</a>,
and <a href="http://wiki.caucho.com/Wicket">Wicket</a> have already been
integrated.</p>

</s1>

<s1 name="php" title="Quercus/PHP">
<ul>
<li>See <a href="quercus.xtp">Quercus/PHP</a> documentation</li>
</ul>

<p>Resin includes Quercus, our PHP 5 implementation, written entirely
in Java.  Quercus is a reliable PHP, compiling to Java code and taking
advantage of the JDK's JIT compiler for maximum performance.  Because
Quercus is in Java, it's security is far superior to a C implementation.  The
JVM automatically protects Quercus from stack overruns, pointer overflows,
and third party C-modules.</p>

<p>And the performance is great.  The compiled Quercus code is 4 to 6 times
faster than raw, mod_php code.  Even when compared with PHP accelerators,
Quercus code is equal or slightly faster, depending on the application.</p>

<p>Quercus integrates tightly with Java, naturally since it is written in
Java.  Resin-IoC applications can easily provide beans and components to
a Quercus/PHP presentation layer through a simple <code>java_bean</code>
call.  For more involved integration, Quercus provides a complete API
for generating PHP facades over Java libraries.  All the PHP libraries
are written to this public API.</p>

<p>With Quercus, Java sites have access to the PHP killer applications.
For blogs, Quercus supports the extremely popular Wordpress.
For wikis, Quercus supports MediaWiki, the engine behind Wikipedia.</p>

</s1>

<s1 name="db" title="Database Pooling">
<p>
Resin provides a robust connection pool for any JDBC 1, JDBC 2, or JDBC 3
database driver.  Resin's database pools integrate with full 2-phase XA
transaction capabilities.  In addition, the database connections can use
round robin load balancing and backup failover for increased performance
and reliability.
</p>

<ul>
<li>See <a href="config-database.xtp">Resin databases</a> documentation</li>
</ul>
</s1> <!-- db -->

<s1 name="ejb" title="EJB 3.0 (Enterprise Java Beans)">

<ul>
<li>See <a href="ejb.xtp">Resin EJB 3.0</a> documentation</li>
<li>See <a href="amber.xtp">Amber (JPA)</a> documentation</li>
</ul>

<p>Resin's EJB support is fully integrated with Resin-IoC and WebBeans.
This integration means you can use only the EJB capabilities you need
without the overhead of .ear packaging.  (Although, .ears are
fully supported.)  A servlet, for example, can use EJB's
@TransactionAttribute without any special packaging.</p>

</s1>

<s1 title="Server Push (Comet)">

<ul>
<li>See <a href="resin-comet.xtp">Resin Comet</a> documentation.</li>
</ul>

<p>As web users are expecting dynamic responses from web sites, the
server push HTTP processing model has become important.  Also called
Comet, server push sends event or streaming data from the server
to the client without waiting for a client poll.</p>

<p>Resin's Comet support focuses on solving the concurrency issues around
server push.  Since the servlet is now responding to events from internal
services as well as managing HTTP data, the synchronization issues become
more complex.  The Resin Comet API is designed to cleanly separate the
concurrency roles, letting the servlet continue to operate as a
single-threaded request, while letting the event services send asynchronous
messages.</p>

<p>JavaScript browsers and Flash applications are both supported by
Resin's Comet.  Flash can take advantage of Resin's Hessian support
to stream binary-encoded events.</p>

</s1>

<s1 name="jsp" title="JSP 2.1 (Java Server Pages)">

<ul>
<li>See <a href="jsp.xtp">Resin JSP</a> documentation</li>
</ul>

<p>Resin's JSP implementation is tightly integrated with the JSTL
and JSF implementations.  Because of the tight binding, Resin can
generate optimized JSP code, improving performance, reducing code size
and reducing memory consumption.</p>

<p>Even JSP tag libraries can run faster with Resin's JSP.  Resin
bytecode-analyzes your tag libraries to determine which capabilities
your actually using, and generates only that code necessary to run the
features you're using.</p>

<p>The JSP implementation aggressively reuses your tag library instances,
reducing memory consumption and improving performance.  Because of Resin's
reuse, application libraries must strictly follow the JSP tag
specification.</p>

<p>Resin-IoC beans are always available through JSP EL expressions.
This IoC integration means your custom components and beans are directly
accessible to your HTML generating code.</p>

</s1>

<s1 name="jstl" title="JSTL 1.01 (Java Standard Template Library)">
<ul>
<li>See <a href="jstl.xtp">Resin JSTL</a> documentation</li>
</ul>

<p>Resin's JSTL works together with its JSP implementation to provide
efficient, generated Java code.  Since Resin's JSP is fully JSTL-aware,
it can implement the JSTL tags directly in Java code, without involving
the overhead of the JSTL tag libraries.</p>

</s1>

<s1 name="servlet" title="Servlet 2.5">
<ul>
<li>See <a href="servlet.xtp">Resin servlet</a> documentation</li>
</ul>

<p>Since the servlet engine of Resin is built on a Resin-IoC foundation,
servlets can use WebBeans dependency injection, event observation, and
interception.  Remember that Resin-IoC is fully integrated with its
EJB support?  By transitivity, Resin servlets automatically have access
to EJB transaction aspects without any extra overhead.</p>

<p>Remote services are tied into servlet capabilities as well.  Because remote
services are URL-based, they naturally fit into the the familiar servlet
processing model.  There's no need to introduce complexities like standard
EJB deployment or add extra frameworks just to expose a service as a URL.</p>

</s1>

<s1 title="Resin Embedding">
<ul>
<li>See <a href="resin-embedding.xtp">Resin embedding</a> documentation</li>
</ul>

<p>Resin embedding is a lightweight facade over the core Resin server
suitable for automated testing frameworks and IDE environments.  With
Resin's embedded testing interface, your tests can send HTTP requests directly
to the server, skipping the overhead of TCP connections, and saving
time on test setup and teardown.</p>

<p>The embedded API gives you hooks into Resin-IoC, so you can
inject mock services into your tests, and still ensure that your application
is tested in the full application server environment.  Since integration
testing uses the actual, deployment environment, elusive production bugs
are easier to catch and destroy.</p>

</s1>

<s1 title="Resin Remoting">
<ul>
<li>See <a href="resin-remoting.xtp">Resin remoting</a> documentation</li>
</ul>

<p>Resin remoting builds on the strengths of the Servlet architecture.
As developers turn away from complicated remoting frameworks,
the simplicity and elegance of the Servlet model becomes more appealing.
Multithreaded, IoC-enabled, designed for HTTP and the web's URL
architecture, well-known, well-documented, and well-integrated with
application servers, the Servlet model has enjoyed phenomenal success.</p>

<p>Services expose remote APIs with the same interfaces and classes their
clients will use, taking advantage of the Java compiler to enforce
protocol compatiblity.  Since Resin remoting protocols are available using
a simple driver API based on Servlets, your services can choose the
protocol to expose at deployment time, whether its a fast, binary
wire-protocol like Hessian, or an XML-based wire-protocol like SOAP.
Resin remoting clients select the wire-protocol matched with service API,
and register with Resin-IoC/WebBeans, so
application code can obtain the client proxy with simple, typed
dependency injection.</p>

</s1>

<s1 title="JPA (Java Persistence Architecture)">
<ul>
<li>See <a href="amber.xtp">Resin's Amber</a> documentation</li>
</ul>

</s1>

<s1 title="Resin Watchdog">

<ul>
<li>See <a href="resin-watchdog.xtp">Resin watchdog</a> documentation</li>
</ul>

<p>The Resin watchdog service manages each Resin instance, allowing for
graceful recovery and restart from critical server deadlocks and crashes.
As a management capability, it offers a centralized interface for starting,
stopping, and checking the status of multiple JVM instances.  Because the
watchdog is well-placed to gather information, it is responsible for
management and logging of the server's debugging or warning messages.</p>

<p>For unix systems, the watchdog also improves system security.  While
the watchdog will run as the root user, Resin JVM instances run as
low-authorization users, protecting your system from application bugs
and security holes.</p>

<p>As a side benefit of the watchdog, JVM parameters like heap settings,
agent configuration, remote JMX and system properties can be configured
in the resin.xml itself.  The watchdog can read the same resin.xml as
the server itself, putting all configuration relevant to the server in
one location.</p>

<p>For more complicated configurations like an ISP setting, the watchdog
can use a separate configuration file readable only by root.  The watchdog
will launch Resin JVMs with assigned resin.xml files, ports, and user
assignment, protecting each Resin JVM user from each other.</p>

</s1>

<s1 name="jms" title="Messaging (JMS 1.1)">

<ul>
<li>See <a href="resin-messaging.xtp">Resin messaging</a> documentation</li>
</ul>

<p>Resin's messaging focuses on simplifying the use and deployment of
messaging applications.  At the core, a messaging system is really just
a queue with extra reliability and performance features like persistence,
transactions, and clustered distribution.  So Resin provides
the standard queueing APIs like the JDK <code>BlockingQueue</code> as
facades to the JMS API.</p>

<p>On the receiving end, <code>MessageListener</code> implementations are
just Java services implementing a single <code>onMessage</code> method to
receive the message, so there's no need for complications.  The only
configuration needed is a binding between the service class and the
queue it wants to receive messages from.  Three lines of XML is sufficient
for that binding, with no need for any extra packaging.</p>

<p>Of course, the message listeners are can use all Resin-IoC capabilities,
including injecting JPA <code>EntityManager</code> for database management, or
other queues to filter and pass the message along.</p>

</s1>

<s1 name="jta" title="Transactions (JTA 1.0.1b)">

<p>Resin's transaction manager handles full two-phase XA transaction
suppport, including transaction logging for reliable transaction recovery.
The transaction capabilities are integrated throughout Resin, so your
databases, JCA connections, and EJBs work together.  Since Resin's
<code>UserTransaction</code> and <code>TransactionManager</code> are
registered with Resin-IoC, injecting these managers into any IoC-enabled
component is just adding an @In annotation.</p>

</s1>

<s1 name="os" title="Operating Systems">

<p>Resin and Resin-Professional are tested and supported on
the following operating systems:</p>

<ul>
<li>Linux</li>
<li>Solaris</li>
<li>Windows</li>
<li>Mac OS X</li>
</ul>

<p>Resin is known to work on the following operating systems:</p>

<ul>
<li>AIX
</li><li>HP-UX
</li><li>Free-BSD
</li></ul>

<p>
Resin is used on these operating systems, however there may or may not be
difficulties with Apache integration, and the JNI code that Resin uses to
increase performance may not be available.
</p>

</s1> <!-- os -->


</body>
</document>
