knut 2004/10/27 06:59:38
Modified: src/documentation/content/xdocs services.xml
Log:
fixed some typos and made some tiny clarifications
Revision Changes Path
1.11 +14 -14
jakarta-hivemind/src/documentation/content/xdocs/services.xml
Index: services.xml
===================================================================
RCS file:
/home/cvs/jakarta-hivemind/src/documentation/content/xdocs/services.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- services.xml 27 Oct 2004 13:23:49 -0000 1.10
+++ services.xml 27 Oct 2004 13:59:38 -0000 1.11
@@ -29,7 +29,7 @@
interface (packaged as part of a module). You supply
the core
implementation of the interface (in the same module, or
in a different
module). At runtime, HiveMind puts it all together.</p>
- <p>HiveMind uses four service models: primitive, singleton,
threaded and
+ <p>HiveMind defines four service models: primitive, singleton,
threaded and
pooled. In the primitive and singleton models, each
service will
ultimately be just a single object instance. In the
threaded and pooled
models, there may be many instances simultaneously, one
for each thread.</p>
@@ -37,7 +37,7 @@
always local to the same JVM. Unlike XML-based web
services, there's no
concept of language transparency: services are always
expressed in terms
of Java interfaces. Unlike JMX or Jini, there's no
concept of hot-loading
- of of services. HiveMind is kept delibrately simple,
yet still very
+ of services. HiveMind is kept deliberately simple, yet
still very
powerful, so that your code is kept simple.</p>
<section>
<title>Defining Services</title>
@@ -53,7 +53,7 @@
needed; in most cases, the service
implementation is an additional Java
class which implements the service interface.
HiveMind will instantiate
the class and configure it as needed. The exact
timing is determined
- from the service's service model:</p>
+ by the service implementation's service
model:</p>
<ul>
<li><strong>primitive</strong> : the service is
constructed on first
reference</li>
@@ -80,7 +80,7 @@
object that implements the service interface)
and, optionally, any
number of interceptors. Interceptors sit
between the core implementation
and the client, and add functionality to the
core implementation such as
- logging, security, transaction demarkation or
performance monitoring.
+ logging, security, transaction demarcation or
performance monitoring.
Interceptors are yet more objects that
implement the service interface.</p>
<p>Instantiating the core service implementation,
configuring it, and
wrapping it with any interceptors is referred
to as <em>constructing the
@@ -142,18 +142,18 @@
factory creates an instance that logs
entry and exit to each method.</p>
<p>The factory shouldn't care what the service
interface itself is ...
it should adapt to whatever interface
is defined by the service
- extension point it will create an
instance for.</p>
+ extension point it will create an
interceptor for.</p>
<p>A service extension point may have any
number of interceptor
contributions. If the order in which
interceptors are applied is
important, then the optional
<code>before</code> and <code>after</code>
attributes can be specified.</p>
<figure src="images/InterceptorStack.png"
alt="A Stack of Interceptors"
/>
- <p>In this example, is was desired that any
method logging occur first,
+ <p>In this example, it was desired that any
method logging occur first,
before the other interceptors. This
ensures that the time taken to log
method entry and exit is not included
in the performance statistics
(gathered by the performance
interceptor). To ensure that the logging
- interceptor is the first, or earliest,
interceptor, the special value
+ interceptor is the first, or earliest
interceptor, the special value
<code>*</code> (rather than a list of
interceptor service ids) is
given for its <code>before</code>
attribute (within the &interceptor;
element). This forces the logging
interceptor to the front of the list
@@ -164,7 +164,7 @@
falls between the two.</p>
<p>This is about as complex as an interceptor
stack is likely to grow.
However, through the use of explicit
dependencies, almost any
- arraingment of interceptors is possible
... even when different
+ arrangement of interceptors is possible
... even when different
modules contribute the interceptors.</p>
<p>Interceptors implement the
<code>toString()</code> method to provide
a useful identification for the
interceptor, for example: <br/>
@@ -244,9 +244,9 @@
<p>Another module may provide an interceptor:</p>
<source><![CDATA[
<?xml version="1.0"?>
-<module id="com.myco.anotherpackage version="1.0.0">
+<module id="com.myco.anotherpackage" version="1.0.0">
<implementation service-id="com.myco.mypackage.Adder">
- <interceptor service-id="hivemind.LoggingInterceptor">
+ <interceptor service-id="hivemind.LoggingInterceptor"/>
</implementation>
</module>
]]></source>
@@ -265,7 +265,7 @@
(some of which may also be services), and
building the stack of
interceptors for the service. Although HiveMind
encourages you to define
your application in terms of a large number of
small, simple, testable
- services, it is also desirable to avoid a
cascade of unneccesary object
+ services, it is also desirable to avoid a
cascade of unnecessary object
creation due to the dependencies between
services.</p>
<p>To resolve this, HiveMind defers the actual creation
of services by
default. This is controled by the
<code>model</code> attribute of the
@@ -289,7 +289,7 @@
constructed on first reference. This is appropriate for services
such as service factories and interceptor
factories, and for several of the basic services provided in the
<link
href="&hivedoc;/module/hivemind.html">hivemind module</link>.</p>
- <p> There is rarely a need use this service model in your own code. It
exists primarily to support the
+ <p> There is rarely a need to use this service model in your own code.
It exists primarily to support the
services in the hivemind module itself (the implementation of the
singleton service model is dependent on
several services that use the primitive service model). </p>
</section>
@@ -375,7 +375,7 @@
listener</em> of events produced by some other
service.</p>
<p>The producing service must include a matched pair of
listener
registration methods, i.e., both
<code>addFooListener()</code> and
- <code>removeFooListener</code>. Note that only
the <em>implementation
+ <code>removeFooListener()</code>. Note that
only the <em>implementation
class</em> must implement the listener
interface; the service interface
does not have to extend the listener interface.
The core service
implementation is registered directly with the
producer service,
@@ -404,7 +404,7 @@
<li>
<strong>What if I need to do some
initializations in my service?</strong>
<p>If you have additional
initializations that can't occur inside your
- core service implementations
constructor (for instance, if the
+ core service implementation's
constructor (for instance, if the
initializations are based on
properties set after the service
implementation object is
instantiated), then your class should use
the &hivemind.BuilderFactory;
to invoke an initializer method.</p>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
