Issue
100 November 1998
emWare
Top to Bottom
Part
1: Monitoring via the Internet
THE GATEKEEPER
Rather
than siphon all that good server data into a bit bucket,
emWare uses another component—emGateway—to
provide Internet access and device management. The gateway
code is responsible for gathering and delivering commands
and data to and from the emMicro server.
The
gateway can also be configured to offload some of the
service load from the server by acting as a repository
for larger pieces of data that can’t be contained
in the smaller server processor memory area.
emGateway
normally resides on a host that is networked to the
embedded server devices. If the server has enough resources,
emGateway can be embedded there. The gateway code can
also reside on the emClient machine. Where you put the
gateway code depends on your available server resources
and the network environment you’re working with.
As
with emMicro, emGateway contains building blocks that
interface its code to other emWare components. Like
emMicro, emGateway communicates at a low level using
emNet. Each external server device must be managed by
emGateway and this is done using the Device Link Module
(DLM). The DLM provides port-management services for
each external device’s network connection.
A
separate DLM codeset is used for each incoming device.
If your application uses RS-232 and Ethernet servers,
a DLM for each protocol and each device is called into
action. The recruiter in this case is Device Access
Service (DAS), which manages the external communication
of data to and from the device and browser.
emGateway
also contains the HTTP server that serves HTTP requests
from the browser. Optionally, if some emObjects are
not present at the browser level, emGateway can hold
and serve these objects as well. These emObjects consist
of HTML and Java objects not installed at the browser
level.
If
your particular application isn’t browser-based,
a command-line option is included in emWare to enable
DAS to pass data via the DLM structure and emNet to
and from the emMicro server.
I’m
gonna push the stick forward and take us down a few
thousand feet to take a peek at the client side of this
operation. Visual Café-defined objects running in conjunction
with a web browser constitute most of the client code.
Again, as you will see a little later, control and monitor
visual objects are defined and linked to the server
through a Java applet.
The
web-browser client is the means by which the user communicates
with the emMicro server device. emGateway services are
initiated via HTTP commands from the browser. The emWare-enabled
browser uses emObjects and EMIT-specific Java files
to effect this comm process.
To
be a full-fledged emClient, the emObjects and the Java-class
files must reside on the local browser machine. Otherwise,
if the emWare components are located on a remote emGateway
machine, the client is no more than a standard web-browser
configuration. Now that all the emWare players have
been introduced, here’s how it works.
A
URL is sent from the browser to the emGateway device.
Nothing is different about this URL. It contains address
information needed to target a specific emMicro device
in the network.
Typically,
host, port, device, and document names are included
in the requesting URL. emGateway’s HTTP server
receives the URL request and initiates a connection
with the targeted server device.
At
this point, the emMicro-enabled server device responds
with the requested document. This document may be microtagged.
If so, it’s expanded by the microtag expansion
services within the emGateway structure. If any of the
necessary or requested emObjects aren’t on the
local browser machine, emGateway serves them, too.
Communication
between emGateway’s DAS and the web browser are
arbitrated by EMIT’s Java run-time interface (EmitJri).
This link is established via HTTP info from emGateway.
The client HTTP module is linked to the emGateway module
for HTTP traffic, and a link is formed between the client’s
EmitJri interface and the emGateway DAS interface to
transfer data to and from the server device.
Of
course, the HTTP requests are logically linked with
the DAS requests so that the two data conduits work
together getting the requested documents from the emMicro
server machine. Looks like the install can continue
now, so let’s move on.
As
we descend, I’ve chosen to select all of these
components offered because I want to show as much code
as possible.
Oops!
The next panel states that I must have Visual Café installed
to use the client development package. OK, I just exit
the EMIT install and select the Visual Café install
button. Eventually, I’ll come back and finish where
we left off on the EMIT 2.5 install.
