← Back to branch summary

~ubuntu-branches/ubuntu/raring/libjboss-remoting-java/raring

« back to all changes in this revision

Viewing changes to docs/guide/en/chap2.xml

  • Committer: Package Import Robot
  • Author(s): Torsten Werner
  • Date: 2011-09-09 14:01:03 UTC
  • mfrom: (1.1.6 upstream)
  • Revision ID: package-import@ubuntu.com-20110909140103-hqokx61534tas9rg
Tags: 2.5.3.SP1-1
http://bugs.debian.org/628303
* Newer but not newest upstream release. Do not build samples.
* Change debian/watch to upstream's svn repo.
* Add patch to fix compile error caused by tomcat update.
  (Closes: #628303)
* Switch to source format 3.0.
* Switch to debhelper level 7.
* Remove useless Depends.
* Update Standards-Version: 3.9.2.
* Update README.source.

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/guide/en/chap2.xml
 
1
  <chapter>
 
2
    <title>Architecture</title>
 
3
 
 
4
    <para>The most critical component of the JBoss Remoting architecture is
 
5
    how servers are identified. This is done via an InvokerLocator, which can
 
6
    be represented by a simple String with a URL based format (e.g.,
 
7
    socket://myhost:5400). This is all that is required to either create a
 
8
    remoting server or to make a call on a remoting server. The remoting
 
9
    framework will then take the information embedded within the
 
10
    InvokerLocator and construct the underlying remoting components needed and
 
11
    build the full stack required for either making or receiving remote
 
12
    invocations.</para>
 
13
 
 
14
    <para>There are several layers to this framework that mirror each other on
 
15
    the client and server side. The outermost layer is the one which the user
 
16
    interacts with. On the client side, this is the Client class upon which
 
17
    the user will make its calls. On the server side, this is the
 
18
    InvocationHandler, which is implemented by the user and is the ultimate
 
19
    receiver of invocation requests. Next is the transport, which is
 
20
    controlled by the invoker layer. Finally, at the lowest layer is the
 
21
    marshalling, which converts data type to wire format.</para>
 
22
 
 
23
    <graphic fileref="images/design.jpg" />
 
24
 
 
25
    <para>When a user calls on the Client to make an invocation, it will pass
 
26
    this invocation request to the appropriate client invoker, based on the
 
27
    transport specified by the locator url. The client invoker will then use
 
28
    the marshaller to convert the invocation request object to the proper data
 
29
    format to send over the network. On the server side, an unmarshaller will
 
30
    receive this data from the network and convert it back into a standard
 
31
    invocation request object and send it on to the server invoker. The server
 
32
    invoker will then pass this invocation request on to the user’s
 
33
    implementation of the invocation handler. The response from the invocation
 
34
    handler will pass back through the server invoker and on to the
 
35
    marshaller, which will then convert the invocation response object to the
 
36
    proper data format and send back to the client. The unmarshaller on the
 
37
    client will convert the invocation response from wire data format into
 
38
    standard invocation response object, which will be passed back up through
 
39
    the client invoker and Client to the original caller.</para>
 
40
 
 
41
    <bridgehead>Client</bridgehead>
 
42
 
 
43
    <para>On the client side, there are a few utility class that help in
 
44
    figuring out which client invoker and marshal instances should be
 
45
    used.</para>
 
46
 
 
47
    <graphic fileref="images/design_client.jpg" />
 
48
 
 
49
    <para>For determining which client invoker to use, the Client will pass
 
50
    the InvokerRegistry the locator for the target server it wishes to make
 
51
    invocations on. The InvokerRegistry will return the appropriate client
 
52
    invoker instance based on information contained within the locator, such
 
53
    as transport type. The client invoker will then call upon the
 
54
    MarshalFactory to get the appropriate Marshaller and UnMarshaller for
 
55
    converting the invocation objects to the proper data format for wire
 
56
    transfer. All invokers have a default data type that can be used to get
 
57
    the proper marshal instances, but can be overridden within the locator
 
58
    specified.</para>
 
59
 
 
60
    <bridgehead>Server</bridgehead>
 
61
 
 
62
    <para>On the server side, there are also a few utility classes for
 
63
    determining the appropriate server invoker and marshal instances that
 
64
    should be used. There is also a server specific class for tying the
 
65
    invocation handler to the server invoker.</para>
 
66
 
 
67
    <graphic fileref="images/design_server.jpg" />
 
68
 
 
69
    <para>On the server side, it is the Connector class that is used as the
 
70
    external point for configuration and control of the remoting server. The
 
71
    Connector class will call on the InvokerRegistry with its locator to
 
72
    create a server invoker. Once the server invoker is returned, the
 
73
    Connector will then register the invocation handlers on it. The server
 
74
    invoker will use the MarshalFactory to obtain the proper marshal instances
 
75
    as is done on the client side.</para>
 
76
 
 
77
    <bridgehead>Detection</bridgehead>
 
78
 
 
79
    <para>To add automatic detection, a remoting Detector will need to be
 
80
    added on both the client and the server side as well as a NetworkRegistry
 
81
    to the client side.</para>
 
82
 
 
83
    <graphic fileref="images/design_detection.jpg" />
 
84
 
 
85
    <para>When a Detector on the server side is created and started, it will
 
86
    periodically pull from the InvokerRegistry all the server invokers that it
 
87
    has created. The detector will then use the information to publish a
 
88
    detection message containing the locator and subsystems supported by each
 
89
    server invoker. The publishing of this detection message will be either
 
90
    via a multicast broadcast or a binding into a JNDI server. On the client
 
91
    side, the Detector will either receive the multicast broadcast message or
 
92
    poll the JNDI server for detection messages. If the Detector determines a
 
93
    detection message is for a remoting server that just came online it will
 
94
    register it in the NetworkRegistry. The NetworkRegistry houses the
 
95
    detection information for all the discovered remoting servers. The
 
96
    NetworkRegistry will also emit a JMX notification upon any change to this
 
97
    registry of remoting servers. The change to the NetworkRegistry can also
 
98
    be for when a Detector has discovered that a remoting server is no longer
 
99
    available and removes it from the registry.</para>
 
100
  </chapter>
 
 
b'\\ No newline at end of file'