tern [3] is analyzed and applied into context of this sec-
tion.
Fig. 4 shows component-based architecture pattern
which is applied into computer network context. Client
module has its component framework in client computer.
It is serviced by client interfaces of many server compo-
 nents. Each of server components is stored in specified
folder of a server computer (for example, it can be
C:\MySCADA). For the first time of search, client does
not know the IP address of the server computer but it
knows the folder storing the server component. The
component framework includes component loader and
component repository. Client module uses component
loader to search in network for IP address of server com-
puter (which stores specified server component in
C:\MySCADA folder) and load server components. Re-
pository is used by component loader to save addresses
of server components for later use. This means that the
component loader does not need to search in the network
for IP addresses of server computers if these are in re-
pository. When loading a server component, component
loader uses management interface to confirm server
name and to know the name list of the other components
which the server component depends on. The component
loader has to load all of these components to give ser-
vices for the server component. This means that a server
component of client module can be a client of other
server components.
The searching mechanism of component loader is de-
scribed in Fig. 5. The component loader has two places
to search the requested component: its repository and
computer network. At first, it starts searching in reposi-
tory, if it finds the address, it will return this for client
and finish searching. If it does not find the address of
requested component in repository, it will search in net-
work. The search in network needs the IP range provided
by client. The component loader pings IPs in IP range to
find the list of live hosts; then, it starts the iteration to
looks for the requested component by name in the ad-
dress {IP[i]\component folder}, where, component folder
is the default storing folder (C\MySCADA, for instance)
of the component in the host whose IP address is the
number i in the list of live hosts. If it finds the requested
component at IP[i] address, it will add this IP into reposi-
tory, return this address to  client and end searching. If
the iteration ends but the requested component is not
found, it will give a “not found” message to client and
finish searching.
This searching mechanism is also a solution for re-
dundancy technology which is a complexity in automa-
tion. Redundant server package can be stored in specified folder in anywhere of network. Main server can use this
searching method to invoke the redundant server without
caring about the position of redundant server computer in
network.  
Client-server interaction in Fig. 4 is from computer to
computer. Thus, remoting technology has to be applied.
On .NET platform, remoting technology is supported
well [2]. .NET gives two options for accessing an object
through network (application domain boundary): by val-
ue and by reference.
When accessing an object by value (or marshaling by
value), client can not write value into server side, be-
cause the object in server side is copied to client side, so
client gets a copy of the object and these two objects are
distinct. Changes in the object in client side do not affect
the object in server side. This option is not suitable for
remoting SCADA application, in which, client has to
change tag values in I/O driver server. 数据采集与监视控制系统英文文献和中文翻译(4):http://www.youerw.com/fanyi/lunwen_7332.html