avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hamm...@apache.org
Subject cvs commit: jakarta-avalon-excalibur/altrmi/src/xdocs index.xml
Date Mon, 13 May 2002 23:00:11 GMT
hammant     02/05/13 16:00:11

  Modified:    altrmi/src/xdocs index.xml
  Log:
  refactor mentions of EOB.  Words originally stolen from EOB pages.
  
  Revision  Changes    Path
  1.5       +33 -12    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.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- index.xml	5 Apr 2002 08:21:03 -0000	1.4
  +++ index.xml	13 May 2002 23:00:11 -0000	1.5
  @@ -7,6 +7,7 @@
       <title>Excalibur AltRMI - Overview </title>
       <authors>
         <person name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
  +      <person name="Vinay Chandran" email="vinayc77@yahoo.com"/>      
       </authors>
     </header>
     <body>
  @@ -43,7 +44,7 @@
     	  RemoteException does).  Many feel that allowing the bean developer to 
     	  ignore the robustness issues is a mistake.  We think not given the following.
     	<ol>
  -  	  <li>The EOB Container knows about AltrmiInvocationException.</li>
  +  	  <li>The container could be programmed to know about AltrmiInvocationException.</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

  @@ -52,7 +53,7 @@
      	  exceptions are already caught.</li>
   	</ol>
         </p>      
  -      <s2 title="1. The EOB Container knows about AltrmiInvocationException">   
        
  +      <s2 title="1. The container could be programmed to know about AltrmiInvocationException">
           
           <p>
             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 
  @@ -69,7 +70,7 @@
             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

  -          (configured in EOB) could be "try perpetually to reconnect", "try five times
only, 
  +          (configured in the container) could be "try perpetually to reconnect", "try five
times only, 
             one a second", "fail immediately".
           </p>            
         </s2>
  @@ -155,11 +156,8 @@
         </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.
  +          We have implemented an experimental callback structure.  We have had to make
the 
  +          communication asynchronous to do this.
           </p>
         </s2>
         <s2 title="True dynamic creation of Proxies">
  @@ -167,9 +165,32 @@
             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).
  +          some less static and more beanlike tool.  An obvious choice would be BCEL and

  +          we are working on an implementation.
  +        </p>
  +      </s2>  
  +      <s2 title="Secure Transports">
  +        <p>
  +          Some variations on the current transports to allow SSL connections.
  +        </p>
  +      </s2>
  +    </s1>
  +    <s1 title="External uses of AltRMI">  
  +      <s2 title="Transport package in Avalon-Cornerstone">
  +        <p>
  +          Allowing transparent publication of phoenix services and for phoenix services.
See 
  +          <link href="http://jakarta.apache.org/avalon/cornerstone">Cornerstone</link>.
  +        </p>
  +        <p>
  +          Using that transport package are <link href="http://jakarta.apache.org/avalon/apps/apps/db">
  +          AvalonDB</link> and <link href="http://jakarta.apache.org/avalon/apps/apps/demo">Demos</link>
  +          (both in Avalon-Apps).
  +        </p>
  +      </s2>        
  +      <s2 title="Enterprise Object Broker">
  +        <p>
  +          An EJB replacement, current hosted at <link href="http://eob.sourceforge.net">
  +          SourceForge</link>
           </p>
         </s2>  
       </s1>    
  @@ -177,7 +198,7 @@
     <footer>
       <legal>
         Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
  -      $Revision: 1.4 $ $Date: 2002/04/05 08:21:03 $
  +      $Revision: 1.5 $ $Date: 2002/05/13 23:00:11 $
       </legal>
     </footer>
   </document>
  
  
  

--
To unsubscribe, e-mail:   <mailto:avalon-cvs-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-cvs-help@jakarta.apache.org>


Mime
View raw message