You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by ha...@apache.org on 2002/04/03 20:29:15 UTC
cvs commit: jakarta-avalon-excalibur/altrmi/src/xdocs index.xml
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>