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 connection-listeners.xml facades.xml generating-proxies.xml otherfeatures.xml pingers.xml publishing.xml transports.xml
Date Thu, 12 Dec 2002 07:56:59 GMT
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 &amp; 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 &amp; 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 &amp; impl using
  -	    different classloaders. Impl and 'remote' proxy do not need to see the same
  +	    These are useful for complete classloader separation of interface &amp; 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:avalon-cvs-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-cvs-help@jakarta.apache.org>


Mime
View raw message