hammant 2002/12/11 23:56:59
Modified: altrmi/src/xdocs connection-listeners.xml facades.xml
generating-proxies.xml otherfeatures.xml
pingers.xml publishing.xml transports.xml
Log:
Documentation fixes from Erik Engstrom
Revision Changes Path
1.3 +3 -3
jakarta-avalon-excalibur/altrmi/src/xdocs/connection-listeners.xml
Index: connection-listeners.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/altrmi/src/xdocs/connection-listeners.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- connection-listeners.xml 26 Jul 2002 16:21:36 -0000 1.2
+++ connection-listeners.xml 12 Dec 2002 07:56:59 -0000 1.3
@@ -10,9 +10,9 @@
<body>
<s1 title="Introduction">
<p>
- Conenction listener can monitor each method invokation (affects
performance)
+ A connection listener can monitor each method invocation (affects
performance)
and handle service suspensions and abnormal ends. The connection
listener
- can decide how to do the reconnection andhow to obey the
susepension. In
+ can decide how to do the reconnection and how to obey the
susepension. In
theory a method call can just be left blocking until the servce is
reconnected (after abend) or resumed after suspension. Connection
listeners
run on the client side.
1.3 +24 -21 jakarta-avalon-excalibur/altrmi/src/xdocs/facades.xml
Index: facades.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/altrmi/src/xdocs/facades.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- facades.xml 26 Jul 2002 16:21:36 -0000 1.2
+++ facades.xml 12 Dec 2002 07:56:59 -0000 1.3
@@ -10,45 +10,48 @@
<body>
<s1 title="Introduction">
<p>
- AltRMI publishes objects via their interfaces. It does not
replicate all objects
- on the client side, it generates proxies for those defines as
facades.
+ AltRMI publishes an object via its interface. It does not replicate
the object
+ on the client side, it generates proxies for it defined as facades.
</p>
</s1>
<s1 title="Facades">
<p>
- Consider a whether system that models weather stations (fixed and
mobile) and
+ Consider a system that models weather stations (fixed and mobile) and
the meterologists that staff the stations.....
</p>
+ <!--
<figure>
<title>Facade Diagram</title>
<graphic srccredit="Paul Hammant, 2002" fileref="images/facades.jpg"
format="JPEG"/>
- </figure>
+ </figure>
+ -->
+ <img src="images/facades.jpg" />
<p>
- The interfaces and the class on the right of the right of the green
line are 'interface'
- or API, and we want them to exist as is on the client side for
general use. Things on the
- left are the implementation classes and they exist on theserver side
only. Though not
- shown here, it would be easiest to have them is a seperate package.
Representing those
- objects on the client side are generated proxies. Those proxies are
pass-by-reference
- boudaries but are castable to any of the interfaces they represent.
There is one
- pass-by-value object and that is Coordinate. It should be
serializable and final
- (Immutable pattern).
- </p>
+ The interfaces and the class on the right of the green line are
'interface'
+ or API, and we want them to exist as is on the client side for
general use. Things on the
+ left are the implementation classes and they exist on the server
side only. Though not
+ shown here, it would be easiest to have them in a separate package.
Representing those
+ objects on the client side are generated proxies. Proxies are
pass-by-reference
+ boundaries but are castable to any of the interfaces they represent.
There is one
+ pass-by-value object and that is Coordinate. It should be
serializable and final
+ (Immutable pattern).
+ </p>
<p>
- The principle point of entry into the system from the client point
of view is
+ The principle point of entry into the system from the client point
of view is
'WeatherSystem'. The mechanism of entry is a lookup on an agreed
name. We recommend
'WeatherSystem' or 'WeatherSystem_1.0' etc.
- </p>
- <p>
- Once the client has a handle on the WetherSystem normal Java
tarversals are possibleL
+ </p>
+ <p>
+ Once the client has a handle on the WeatherSystem normal Java
tarversals are possible
<source>
WeatherSystem ws = getWeatherSystem(); // some thing that does the JNDI
lookup.
// yes we know the following could throw NPEs or Array Index issues.
String aName =
ws.getWeatherStation("ArcticOne").getMeteorologists()[0].getName();
</source>
- To generate the correct proxies for the above, you would want to have
the interface as
+ To generate the correct proxies for the above, you would want to have
the interface as
'WeatherSystem' and additional-facades of 'Meteorologist' and
'WeatherStation'
- </p>
- </s1>
+ </p>
+ </s1>
</body>
<footer>
<legal>
1.4 +2 -2
jakarta-avalon-excalibur/altrmi/src/xdocs/generating-proxies.xml
Index: generating-proxies.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/altrmi/src/xdocs/generating-proxies.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- generating-proxies.xml 26 Jul 2002 16:21:36 -0000 1.3
+++ generating-proxies.xml 12 Dec 2002 07:56:59 -0000 1.4
@@ -10,7 +10,7 @@
<body>
<s1 title="Introduction">
<p>
- You can choose to generate your procies in advance of use, or to
defer generation
+ You can choose to generate your proxies in advance of use, or to
defer generation
until runtime. As the generation requires javac in tools.jar (multi
megabyte), you
have to decide whether your runtime environment or distribution can
support or
legally distribute it.
1.4 +4 -4
jakarta-avalon-excalibur/altrmi/src/xdocs/otherfeatures.xml
Index: otherfeatures.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/altrmi/src/xdocs/otherfeatures.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- otherfeatures.xml 26 Jul 2002 16:21:36 -0000 1.3
+++ otherfeatures.xml 12 Dec 2002 07:56:59 -0000 1.4
@@ -21,7 +21,7 @@
<p>
Classes providing client side implementation of the transported
interface(s) can be either on the client side or the server side (and
- duly transported) at time of lookup. On the server side, the proxy
classes
+ duly transported) at the time of lookup. On the server side, the
proxy classes
can be generated in advance (Ant Task) or at runtime - javac is
invoked.
</p>
</s2>
@@ -35,7 +35,7 @@
</s2>
<s2 title="Suspendable/Resumable service.">
<p>
- The Server supports suspend() and resume(). With the current impl
this
+ The Server supports suspend() and resume(). With the current
implementation this
replies in a timely fashion to the client that the client should try
later. The client waits for the notified amount of time and
seamlessly
tries the request again. A server could cycle through suspended and
back
@@ -87,7 +87,7 @@
<s2 title="No duplicate instances.">
<p>
For Facades, if you call Person p = getPerson("Fred") twice you
will get
- the same instance on the client side is it is the same instance on
the
+ the same instance on the client side if it is the same instance on the
server side.
</p>
</s2>
1.4 +5 -5 jakarta-avalon-excalibur/altrmi/src/xdocs/pingers.xml
Index: pingers.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/altrmi/src/xdocs/pingers.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- pingers.xml 26 Jul 2002 16:21:36 -0000 1.3
+++ pingers.xml 12 Dec 2002 07:56:59 -0000 1.4
@@ -11,8 +11,8 @@
<s1 title="Introduction">
<p>
Although it may not be necessary for all types of transport,
- there is a mechanism called a pinger that can be used to keep alive
- the connection. Pingers run on the client side.
+ there is a mechanism called a pinger that can be used to keep
+ the connection alive. Pingers run on the client side.
</p>
</s1>
<s1 title="Pinger Interface">
@@ -28,11 +28,11 @@
</p>
<s2 title="DefaultConnectionPinger">
<p>
- This pinger pings every ten seconds, but stops one hundred seconds
seoonds
+ This pinger pings every ten seconds, but stops one hundred seconds
after the last real request. The 10 & 100 are configurable of
course.
</p>
<p>
- This pinger is the default and will be used if none other is
+ This pinger is the default and will be used if no other is
specified.
</p>
</s2>
1.3 +4 -4 jakarta-avalon-excalibur/altrmi/src/xdocs/publishing.xml
Index: publishing.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/altrmi/src/xdocs/publishing.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- publishing.xml 26 Jul 2002 16:21:36 -0000 1.2
+++ publishing.xml 12 Dec 2002 07:56:59 -0000 1.3
@@ -10,16 +10,16 @@
<body>
<s1 title="Introduction">
<p>
- Publishing is an server responsibility obviously. It is quite
straight forward.
+ Publishing is a server responsibility obviously, it is quite
straight forward.
</p>
</s1>
<s1 title="Publishing">
<p>
- You have to choose your server, publish the impl (reiterating the
interfaces that will
+ You have to choose your server, publish the implimentation
(reiterating the interfaces that will
be pass-by-reference boundaries), then start the server.....
<source>
<![CDATA[
- AbstractServer as new CompleteSocketCustomStreamServer(1235);
+ AbstractServer as = new CompleteSocketCustomStreamServer(1235);
TestInterfaceImpl ti = new TestInterfaceImpl();
as.publish(ti, "Hello", new
PublicationDescription(TestInterface.class, TestInterface2.class));
as.start();
1.6 +23 -23 jakarta-avalon-excalibur/altrmi/src/xdocs/transports.xml
Index: transports.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/altrmi/src/xdocs/transports.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- transports.xml 26 Jul 2002 16:21:36 -0000 1.5
+++ transports.xml 12 Dec 2002 07:56:59 -0000 1.6
@@ -24,7 +24,7 @@
Avalon-Phoenix or or an implementation of the EJB specification will.
</p>
<p>
- All of these transports are synchronous too. That means that an
invokation acorss there connection
+ All of these transports are synchronous too. That means that an
invocation acorss there connection
will wait until the it is completed server side before the next
invocation is allowed through.
</p>
@@ -42,7 +42,7 @@
</s2>
<s2 title="Over RMI">
<p>
- This is another transport that bridges two different JVMs using
TCP/IP. It is actually the fstest of all the
+ This is another transport that bridges two different JVMs using
TCP/IP. It is actually the fastest of all the
TCP/IP using transports. and takes advantage of RMI as it's
transport while hiding RMI from the AltRMI
client and server.
</p>
@@ -50,18 +50,18 @@
<s2 title="Piped with same VM / ObjectStream & CustomStream
varients">
<p>
In a similar way to the ObjectStream and CustomStream
implementations of the plain sockets transport, these
- offer trasport using a pipe inside the JVM. Not needed for most
users of AltRMI these prove useful for
+ offer transport using a pipe inside the JVM. Not needed for most
users of AltRMI these prove useful for
developers making complex trees of classloaders with high
separation from each other. As a Pipe is being
- used there is is some opportunity for buffering of invokations.
This might slow the throughput down but
- this may releieve other parts of a particular design.
+ used there is is some opportunity for buffering of invocations.
This might slow the throughput down but
+ this may relieve other parts of a particular design.
</p>
</s2>
<s2 title="Direct within same VM">
<p>
There are 'Direct' and 'DirectMarshalled' transports. These are
use useful in the same scenarios as
- the Piped one, but with some small differences. Principally,
there is no pipe - the invokation is
+ the Piped one, but with some small differences. Principally,
there is no pipe - the invocation is
immediately handled on the server side. With Direct there is also
the fact that all mutually visible
- classes and interfaces woould have to be in a commonly visible
classloader. With DirectMarshalled,
+ classes and interfaces would have to be in a commonly visible
classloader. With DirectMarshalled,
there can be duplicate interfaces and class definitions as in the
streamed types of transport.
</p>
</s2>
@@ -74,11 +74,11 @@
</s1>
<s1 title="Supplied Callback capable Transports">
<p>
- All of these transports are asynchronous. Thais means that an
invokation across there connection
- will does not wait until the reply is ready before it allows another
request though. This allows
- two thing - excpetionally lengthy requests (that might ordinarily
affect timeouts) to be performed and
- callbacks (server invoking requests on the client). There is a smal
(15%) cost to using this transport for
- simple cases, but its benefits outweigh its deficiences.
+ All of these transports are asynchronous. Thais means that an
invocation across the connection
+ does not wait until the reply is ready before it allows another
request though. This allows
+ two things - excpetionally lengthy requests (that might ordinarily
affect timeouts) to be performed and
+ callbacks (server invoking requests on the client). There is a
small (15%) cost to using this transport for
+ simple cases, but its benefits outweigh its deficiencies.
</p>
<p>
Whilst the Callback enabled transports are better from the point of
view of asynchronous behaviour
@@ -123,8 +123,8 @@
<s2 title="AltRMI types in the same VM">
<p>
- These are useful for complete classloader separation of interface
& impl using
- different classloaders. Impl and 'remote' proxy do not need to see
the same
+ These are useful for complete classloader separation of interface
& implementation using
+ different classloaders. The implementation and 'remote' proxy do
not need to see the same
interfaces etc..<br/>
<br/>
Speed Test type Count Relative<br/>
@@ -146,9 +146,9 @@
<p>
- In VM, without using AltRMI - for comparison.
- - The inteface, impl and proxy cannot be separated in terms of
+ - The inteface, implementation and proxy cannot be separated in
terms of
branches of classloader for these three. The same interfaces
- etc must be visible to both impl and proxy.
+ etc must be visible to both implementation and proxy.
<br/>
Speed Test type Count Relative<br/>
------------------------------- ------- --------<br/>
@@ -175,21 +175,21 @@
<strong>void setObject(object o);</strong> and <strong>Object
getObject();</strong>, and clases in
B amp; C could invoke those methods freely, the you might consider
that B has a way of taking to C. if B
called (essentially) <strong>A.setObject("Hello")</strong>, then C
could indeed call <strong>String
- s = A.getObject()</strong> without ny problem. Say a class being
passed were called 'Thing' and was in the
+ s = A.getObject()</strong> without any problem. Say a class being
passed were called 'Thing' and was in the
classloader of B and duplicated in the classloader of C, but not in
A at all, then it would not be passable
- by the setter/getter mechanism outlined above. Why? The JVM
considers then differnt classes because they
+ by the setter/getter mechanism outlined above. Why? The JVM
considers then different classes because they
are mounted in different classloaders (even though from the same
source). That is a secret
of classloading (at least as it pertains to RPC in one VM).
</p>
<p>
The issue is relevent to AltRMI mostly if it is being used to
connect two nodes of a single classloader tree.
- If the trasport chosen is 'Direct' then you will get
ClassCastExceptions thrown by the JVM if you had been
+ If the transport chosen is 'Direct' then you will get
ClassCastExceptions thrown by the JVM if you had been
passed an Object you wanted to cast up to something, and that
something were represented by a class definition
in both the server and client nodes of the classloader tree. If the
something class were in a mutualy
- visible parent class loader then no issue would be apparent. IF the
client and server were in seperate VMs,
- then no issue would be apparent, princiapally because on the
marchalling to serialized form natly hides the
+ visible parent class loader then no issue would be apparent. IF the
client and server were in separate VMs,
+ then no issue would be apparent, principally because the marchalling
to serialized form neatly hides the
two class definitions from the JVM. This is the clue to the solving
of the issue for a particular
- client/server (in one JVM) confiuration you may be cooking up. If
you choose Piped or DirectMarshalled as
+ client/server (in one JVM) configuration you may be cooking up. If
you choose Piped or DirectMarshalled as
trasnports, then you can have the same class definition in multiple
classloader nodes. Of couse, both Piped
and DirectMarshalled are slower than Direct as transports.
Configuration choices for the developer/deployer.
</p>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
