> Harm, there is no doubt that new hardware systems can be designed and built to
> support XML and HTTP. At issue is whether that hardware is already in place.
> In many environments, there are highly precise and expensive software systems
> which are targeted at very specialized environments. These software systems
> can't always be recreated or upgraded for a managable cost or impact on the
> application. Thus, you need to be able to handle their associated transport and
> management interfaces in your system design, if you have such devices.
>
> Another important issue is that there are bandwidth limited transports such as
> satellite links, which can have costs, on a byte by byte basis. Thus, a simple
> modbus request to read a register, such as
>
> 01 06 02 01 01 56 24
>
> which is just 7 bytes and which has a reply of just 8 bytes, is a total
> bandwidth cost of 15 bytes.
Satellites typically bill by time (use of the link), not bytes. You
also normally have carte blanche as to how you use that time, so can
therefore tweak your protocols (e.g. packet size) to accomodate
changes in payload size.
FWIW, on my last large project, which involved distributing seismic
data around the globe by both satellite and landline, we used;
- a highly compressed "binary" format for raw seismic data over sat & landline
- RDF/XML for configuration and state-of-health (SOH) data over sat & landline
- RDF/Turtle for configuration & SOH between seismograph and
seismometer (i.e. between a near-desktop-class CPU and an ARM
microprocessor) over RS232 and other serial links
This system replaced (except for the raw data format) a series of
highly optimized binary formats for configuration & SOH which had poor
extensibility characteristics, which increased maintenance costs as
new software had to be deployed anytime a new SOH or configuration
parameter was deployed. Very painful. RDF/XML/Turtle completely
resolved that problem, and with an open format for which many tools
had already been developed. And that reduced development time
considerably.
> If I coded that in XML, it would likely be an order
> of magnitude larger in bandwidth.
Probably, but if it's sent infrequently, or the typical document fits
into your packets, then the advantages can be worth it... even moreso
for RDF/XML, which provides additional advantages over vanilla XML,
and was very well suited to configuration & SOH data (because the
structure is simple).
Mark.
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
