[jboss-remoting-commits] JBoss Remoting SVN: r4264 - remoting2/branches/2.x/docs/guide/en.
jboss-remoting-commits at lists.jboss.org
jboss-remoting-commits at lists.jboss.org
Thu May 29 00:08:13 EDT 2008
Author: ron.sigal at jboss.com
Date: 2008-05-29 00:08:13 -0400 (Thu, 29 May 2008)
New Revision: 4264
Modified:
remoting2/branches/2.x/docs/guide/en/chap11.xml
Log:
JBREM-840: Added bisocket section and removed multiplex section.
Modified: remoting2/branches/2.x/docs/guide/en/chap11.xml
===================================================================
--- remoting2/branches/2.x/docs/guide/en/chap11.xml 2008-05-29 02:53:23 UTC (rev 4263)
+++ remoting2/branches/2.x/docs/guide/en/chap11.xml 2008-05-29 04:08:13 UTC (rev 4264)
@@ -550,6 +550,31 @@
</section>
<section>
+ <title>Bisocket transport</title>
+
+ <para>The bisocket example shows how to set up push callbacks with the bisocket transport, using its facility for avoiding the use of a <classname>ServerSocket</classname> and TCP port on the client. The key section is</para>
+
+ <programlisting>
+ HashMap metadata = new HashMap();
+ metadata.put(Bisocket.IS_CALLBACK_SERVER, "true");
+ TestCallbackHandler callbackHandler = new TestCallbackHandler();
+ client.addListener(callbackHandler, metadata);
+ </programlisting>
+
+ <para>which configures the callback <classname>Connector</classname> appropriately.</para>
+
+ <para>To run the example, type</para>
+
+ <programlisting>ant run-bisocket-server</programlisting>
+
+ <para>in one window, and type</para>
+
+ <programlisting>ant run-bisocket-client</programlisting>
+
+ <para>in another window.</para>
+
+ </section>
+ <section>
<title>Streaming</title>
<para>The streaning sample (found in the org.jboss.remoting.samples.stream
@@ -707,7 +732,7 @@
and expose a remote proxy to it via JBoss Remoting. Dynamic proxies and
reflection are used to make the typed method calls on that target POJO.
Since JBoss Remoting is used, can select from a number of different
- network transports (i.e. rmi, http, socket, multiplex, etc.), including
+ network transports (i.e. rmi, http, socket, etc.), including
support for SSL. Even clustering features can be included.</para>
<bridgehead>How it works</bridgehead>
@@ -2524,111 +2549,4 @@
</section>
</section>
- <section>
- <title id="section-multiplex-invokers"
- xreflabel="Multiplex invokers">Multiplex invokers</title>
-
- <para>This section illustrates the construction of multiplex invoker
- groups described in the section <xref linkend="section-multiplex-invoker" />. The
- directory</para>
-
- <blockquote>
- <para><code>examples/org/jboss/remoting/samples/multiplex/invoker</code></para>
- </blockquote>
-
- <para>contains a server class,
- <classname>MultiplexInvokerServer</classname>, which is suitable for use
- with any of the client classes described below. It may be run in an IDE or
- from the command line using ant target <code>run-multiplex-server</code>
- from the <code>build.xml</code> file found in the <code>examples</code>
- directory. The server will stay alive, processing invocation requests as
- they are presented, until it has sent two push callbacks to however many
- listeners are registered, at which time it will shut itself down.</para>
-
- <para>The sample clients are as follows. Each sample client
- <emphasis><client></emphasis> may be run in an IDE or by using the
- ant target <code>run-</code><emphasis><client></emphasis> (e.g.,
- <code>run-Client2Server1</code>).</para>
-
- <itemizedlist>
- <listitem>
- <para><classname>Client2Server1</classname>: A
- <classname>MultiplexClientInvoker</classname> starts according to
- client rule 2, after which a
- <classname>MultiplexServerInvoker</classname> is started according to
- server rule 1. Note that the <classname>Client</classname> and
- <classname>Connector</classname> are passed matching
- <emphasis>clientMultiplexId</emphasis> and
- <emphasis>serverMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
-
- <listitem>
- <para><classname>Client2Server2</classname>: A
- <classname>MultiplexClientInvoker</classname> starts according to
- client rule 2, after which a
- <classname>MultiplexServerInvoker</classname> is started according to
- server rule 2. Note that no <emphasis>clientMultiplexId</emphasis> is
- passed to the <classname>Client</classname> and no
- <emphasis>serverMultiplexId</emphasis> parameter is passed to the
- <classname>Connector</classname> in this example.</para>
- </listitem>
-
- <listitem>
- <para><classname>Client3Server1</classname>: A
- <classname>MultiplexClientInvoker</classname> is created, and, lacking
- binding information, finds itself governed by client rule 3.
- Subsequently, a <classname>MultiplexServerInvoker</classname> is
- started according to server rule 1, providing the binding information
- which allows the <classname>MultiplexClientInvoker</classname> to
- start. Note that the <classname>Client</classname> and
- <classname>Connector</classname> are passed matching
- <emphasis>clientMultiplexId</emphasis> and
- <emphasis>serverMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
-
- <listitem>
- <para><classname>Server2Client1</classname>: A
- <classname>MultiplexServerInvoker</classname> starts according to
- server rule 2, after which a
- <classname>MultiplexClientInvoker</classname> is started according to
- client rule 1. Note that the <classname>Connector</classname> and
- <classname>Client</classname> are passed matching
- <emphasis>serverMultiplexId</emphasis> and
- <emphasis>clientMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
-
- <listitem>
- <para><classname>Server2Client2</classname>: A
- <classname>MultiplexServerInvoker</classname> starts according to
- server rule 2, after which a
- <classname>MultiplexClientInvoker</classname> is started according to
- client rule 2. Note that no <emphasis>serverMultiplexId</emphasis> is
- passed to the <classname>Connector</classname> and no
- <emphasis>clientMultiplexId</emphasis> parameter is passed to the
- <classname>Client</classname> in this example.</para>
- </listitem>
-
- <listitem>
- <para><classname>Server3Client1</classname>: A
- <classname>MultiplexServerInvoker</classname> is created, and, lacking
- connect information, finds itself governed by server rule 3.
- Subsequently, a <classname>MultiplexClientInvoker</classname> is
- started according to client rule 1, providing the connect information
- which allows the <classname>MultiplexServerInvoker</classname> to
- start. Note that the <classname>Connector</classname> and
- <classname>Client</classname> are passed matching
- <emphasis>serverMultiplexId</emphasis> and
- <emphasis>clientMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
- </itemizedlist>
-
- <para>For variety, the examples in which the client invoker starts first
- use the configuration <classname>Map</classname> to pass invoker group
- parameters, and the examples in which the server invoker starts first pass
- parameters in the <classname>InvokerLocator</classname>.</para>
- </section>
</chapter>
\ No newline at end of file
More information about the jboss-remoting-commits
mailing list