hammant 02/04/03 10:29:15
Modified: altrmi/src/xdocs index.xml
Log:
sectionize a bit more
Revision Changes Path
1.2 +55 -26 jakarta-avalon-excalibur/altrmi/src/xdocs/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/altrmi/src/xdocs/index.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.xml 3 Apr 2002 13:59:22 -0000 1.1
+++ index.xml 3 Apr 2002 18:29:15 -0000 1.2
@@ -15,7 +15,7 @@
AltRMI is a from-scratch replacement for RMI. It has a number of
different features that make it easier to use. It tries as far as possible to
be transparent in use.
</p>
</s1>
- <s1 title="Feature Differencs">
+ <s1 title="Feature Differences">
<p>
Some good, some bad:
<ul>
@@ -38,16 +38,16 @@
ignore the robustness issues is a mistake. We think not given the
following.
<ol>
<li>The EOB Container knows about AltrmiInvocationException.</li>
- <li>AltRMI has configurable policies that can help reestablish
connection whilst in use.</li>
+ <li>AltRMI has configurable policies that can help re-establish
connection whilst in use.</li>
<li>Standard handling of RemoteException sucks.</li>
<li>It is difficult in EJB, in terms of coverage, to test your huge
amounts of RemoteException handling code.</li>
- <li>Most webapp uses of beans have a single "handler" place where
pertinent
+ <li>Most web-app uses of beans have a single "handler" place where
pertinent
exceptions are already caught.</li>
</ol>
</p>
- <s2 title="The EOB Container knows about AltrmiInvocationException">
+ <s2 title="1. The EOB Container knows about
AltrmiInvocationException">
<p>
- A lot of beans coding is bean invokes method in bean which invokes
method in bean. In
+ A lot of beans coding is 'bean invokes method in bean which
invokes method in bean'. In
this case there are several places in the invocation stack where
the container's logic
is delegating between beans. Container could easily handle
failing connections and take
multiple actions: re-establish report, redirect, abend services or
server. If there is
@@ -55,10 +55,10 @@
say, 'contingency' beans.
</p>
</s2>
- <s2 title="AltRMI has configurable policies that can help reestablish
connection whilst in use.">
+ <s2 title="2. AltRMI has configurable policies that can help
reestablish connection whilst in use.">
<p>
AltRMI has a pluggable architecture for re-establishing
connections (and reporting timings
- etc). Whilst in the middle of an invocation, if the connection is
lost, Altrmi can try to
+ etc). Whilst in the middle of an invocation, if the connection is
lost, AltRMI can try to
re-establish the connection and complete the method invocation
normally. A delay would of
course be encountered, but if administrators are watching the
logs, then they can determine
where failures are happening and what to do long term about it.
Programmed policies
@@ -66,36 +66,39 @@
one a second", "fail immediately".
</p>
</s2>
- <s2 title="Standard handling of RemoteException sucks.">
+ <s2 title="3. Standard handling of RemoteException sucks.">
<p>
- Referring to the various ways EJB teams handle RemoteException in
the thousands of places in a typical J2EE solution where it thrown. Different
designs are...<br/>
- <br/>
- 1. Declare throws RemoteException on every applicable method.<br/>
- <br/>
- - That means that it can often arrive back at the container. The
container always reports it verbosely.<br/>
-
- 2. Have a standard catch block and pass the RemoteException to a
standard handler method that does something with it. <br/>
- <br/>
- - That something can often by turn it into a custom derivative of
RuntimeException as well as reporting it. This strategy makes you wonder why
it was not a derivative of RuntimeException in the first place.<br/>
- <br/>
- 3. Try the failing method call again, or n times.
- <br/>
-
- - Clutters your code with reams of retry logic. What if it
still fails? Combine this with (1) or (2) as well?
+ Referring to the various ways EJB teams handle RemoteException, in
the thousands of places
+ in a typical J2EE solution where it is thrown, different solutions
are...<br/>
+ <s3 title="3.1. Declare throws RemoteException on every applicable
method.">
+ <p>
+ That means that it can often arrive back at the container. The
container always reports it verbosely.<br/>
+ </p>
+ </s3>
+ <s3 title="3.2. Have a standard catch block and pass the
RemoteException to a standard handler method that does something with it.">
+ <p>
+ That something can often by turn it into a custom derivative of
RuntimeException as well as reporting it. This strategy makes you wonder why
it was not a derivative of RuntimeException in the first place.<br/>
+ </p>
+ </s3>
+ <s3 title="3.3. Try the failing method call again, or n times.">
+ <p>
+ Clutters your code with reams of retry logic. What if it
still fails? Combine this with (1) or (2) as well?
+ </p>
+ </s3>
</p>
</s2>
- <s2 title="It is difficult in EJB, in terms of coverage, to test your
huge amounts of RemoteException handling code">
+ <s2 title="4. It is difficult in EJB, in terms of coverage, to test
your huge amounts of RemoteException handling code">
<p>
Your EJB team has developed a huge amount of code for the business
logic, and consequentually
loads of code concerning RemoteException. Question how do they
test the "connection failing"
logic? Do they rip out cables while the machine is in use? No
that does not yield good
- coverage. Do they have test cases and mock beans that throw
RemotException? Yes probably,
+ coverage. Do they have test cases and mock beans that throw
RemoteException? Yes probably,
but that is an artificial connection outage. However most teams
do not test more than a
single case, and are happy for the same RemoteException handler
block to be used all over
the place.
</p>
</s2>
- <s2 title="Most webapp uses of beans have a single 'handler' place
where pertinent
+ <s2 title="5. Most web-app uses of beans have a single 'handler' place
where pertinent
exceptions are already caught.">
<p>
Webapps that use multiple beans (assuming a decent MVC separation
or a framework like Velocity) already have a place where central exception
handling is going on. With AltRMI, you can catch AltrmiInvocationException
where you feel is fit. EJB teams that choose to have throws RemoteException on
all methods (percolating it up the stack) probably also choose to finally
handle it centrally. Like so ...
@@ -126,12 +129,38 @@
}
</source>
</s2>
+ </s1>
+ <s1 title="Things yet to do">
+ <p>
+ There is an ongoing plan for features to be added to AltRMI. On the
+ transports page, there are some related future requirements listed.
Below are
+ the big features yet to do.
+ </p>
+ <s2 title="Callback">
+ <p>
+ We have yet to implement callbacks. We need to make the
communication
+ asynchronous to do this. We have toyed with standard APIs like
BEEP but
+ find the performance is not quite good enough. We may not need the
+ sustained power of BEEP as our needs are for short bursts rather
than
+ multiplexing sustained streams.
+ </p>
+ </s2>
+ <s2 title="True dynamic creation of Proxies">
+ <p>
+ We curently use javac to compile stubs from source. It feels
natuaral to use
+ this technique as we think in terms of the Java the language. We
know that
+ the main interface to Javac is deprecated in JDK1.4 and feel we
should move to
+ some less static and more beanlike tool. An obvious choice would
be BCEL, but we
+ find it too hard to work with (it being closer to bytecode machine
than the Java
+ language).
+ </p>
+ </s2>
</s1>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/04/03 13:59:22 $
+ $Revision: 1.2 $ $Date: 2002/04/03 18:29:15 $
</legal>
</footer>
</document>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
