1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
<title>RSE Model</title>
<link rel="stylesheet" type="text/css" HREF="../book.css">
</head>
<body>
<h1>DataStore Communications</h1>
<p>
Communication in the DataStore is asynchronous and symmetric. Commands sent and results received are all represented in the same form,
<a href="DataElements.html">DataElements</a> and the underlying means of transmitting this information is basically the same for each.
When a command is issued, it gets queued and then later routed to the appropriate <b>miner</b> where it gets executed.
A miner returns results by updating the DataStore repository with information. Like commands, these
results are queued and then later notifications are sent out to any listener that requires the results.
</p>
<p>
The asynchronous routing of data and commands between a client and the tools is made possible by threads, called <i>handlers</i>. There are two
types of handlers - a <a href="#commandhandlers">Command Handler</a> and an <a href="#updatehandlers">Update Handler</a>. Each handler thread contains a queue
of data that needs to be transmitted and each periodically communicates the data contained in it's queue.
</p>
<h2><a name="commandhandlers">Command Handlers</a></h2>
<p>
The job of the Command Handler is to route commands to the miners. There are two types of command handlers.
</p>
<h3><a name="clientcommandhandler">Client Command Handler</a></h3>
<p>
The <b>Client Command Handler</b> is a command handler responsible for transmitting its queue of DataStore commands across a network to
the server DataStore. This handler encapsulates the communication of DataStore client data to a DataStore server. The Client Command Handler
interfaces the DataStore communication layer, where its queue of commands gets serialized into XML before being sent over a TCP/IP socket
to the server.
</p>
<h3><a name="servercommandhandler">Server Command Handler</a></h3>
The <b>Server Command Handler</b> is a command handler responsible for directly routing the DataStore commands in its queue to the appropriate
miner(s) depending on the command.
<h2><a name="updatehandlers">Update Handlers</a></h2>
<p>
The job of the Update Handler is to notify the client that some results have been received or changed. There are two types of
update handlers.
</p>
<h3><a name="clientupdatehandler">Client Update Handler</a></h3>
<p>
The <b>Client Update Handler</b> is an update handler responsible for sending out domain notifications for each unit of data
contained in its queue.
</p>
<h3><a name="serverupdatehandler">Server Update Handler</a></h3>
<p>
The <b>Server Update Handler</b> is an update handler responsible for transmitting its queue of DataStore objects across a network to
the client DataStore. This handler encapsulates the communication of DataStore server data to a DataStore client. The Server Update Handler
interfaces the DataStore communication layer, where its queue of data gets serialized into XML before being sent over a TCP/IP socket
to the client.
</p>
<p>
Communication between a client and tools may either occur locally and remotely depending on how the
user chooses to connect to the DataStore. The client interface and the server tooling are the same regardless of
whether the DataStore is standalone or client/server based. The communication differences are encapsulated by
the DataStore handlers.
</p>
<h2>Standalone Local DataStore</h2>
<p>
Locally, the DataStore may be used standalone such that all communication through the DataStore goes directly to between the <b>miners</b>
and the client, all running within the same process. In this case, there is only a single DataStore and no communication goes
over the network. For its handlers, the local DataStore uses a <b>Client Update Handler</b> and a <b>Server Command Handler</b>.
</p>
<img src="images/local.jpg" alt="Local DataStore Eclipse" border="0">
<p>
In the above dialog, the path of commands to the tools is shown with solid lines, while the path of data to client is shown with dotted lines.
<ol>
<li>
In RSE, a subsystem calls a DataStore command API to issue a command.
</li>
<li>
The command is then queued in the <b>Server Command Handler</b>.
</li>
<li>
The Server Command Handler gets the command from the queue, determines which miner should run it, and passes the command into that miner.
</li>
<li>The miner then executes the command and produces results by calling DataStore object creation methods. When the resulting objects are created,
the DataStore queues them in the <b>Client Update Handler</b>.
</li>
<li>
The Client Update Handler gets the data from the queue and sends out a domain notification for each data object in the queue.
</li>
<li>
A domain listener for the RSE subsystem receives the notification and then uses the result data to update the UI.
</li>
</ol>
</p>
<h2>Client/Server DataStore</h2>
<p>
In the remote case, a DataStore client is part of the Eclipse process, while the DataStore server is run
in a separate process on a remote host. Information is transferred between the two DataStore repositories over
a TCP/IP socket. Any data that is created or changed on either the client or the server is asynchronously
propagated over to the other side via serialization/deserialization of the delta.
Like in the standalone case, the client DataStore uses a <b>Client Update Handler</b>, but instead of using
a Server Command Handler it uses a <b>Client Command Handler</b>. The server DataStore uses a <b>Server Update Handler</b>
and a <b>Server Command Handler</b>.
</p>
<img src="images/remote.jpg" alt="Remote DataStore Eclipse" border="0">
<ol>
<li>
In RSE, a subsystem calls a DataStore command API to issue a command.
</li>
<li>
The command is then queued in the <b>Client Comamnd Handler</b>.
</li>
<li>
The Client Command Handler gets the command from the queue and, via the communication layer, transmits it to the server DataStore.
The communication layer on the client serializes the DataStore respository objects that make up the command and sends that
serialization over a socket to the server.
</li>
<li>
The communication layer on the server deserializes the socket data and creates DataStore objects in the DataStore repository.
Those command objects are added it to the <b>Server Command Handler</b> queue.
</li>
<li>
The Server Command Handler gets the command from the queue, determines which miner should run it, and passes the command into that miner.
</li>
<li>
The miner then executes the command and produces results by calling DataStore object creation methods. When the resulting objects are created,
the DataStore queues them in the <b>Server Update Handler</b>.
</li>
<li>
The Server Update Handler gets the results from the queue and transmits them, via the DataStore communicate layer, to the client DataStore.
The communication layer on the server serializes the DataStore objects from the queue and sends that serialization over a socket
to the client.
</li>
<li>
The communication layer on the client deserializes the socket data and creates DataStore objects in the DataStore respository.
Those results are added to the <b>Client Update Handler</b> queue.
</li>
<li>
The Client Update Handler gets the data from the queue and sends out a domain notification for each data object in the queue.
</li>
<li>
A domain listener for the RSE subsystem receives the notification and then uses the result data to update the UI.
</li>
</ol>
</p>
</body>
</html>
|
