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]>
