>
>> If you want to deploy a service into a resource-constained device, you
> probably don't want to use XML/SOAP/HTTP. (This is a point that Gregg
> has pointed out repeatedly.)
>
> Anne, We *do* want to use XML/SOAP/HTTP, precisely for the reason you
> point out below: using a unique technology base, which allows to break
> down technology silos and to readily integrate device-level services
> into enterprise scenarios. The latter is extremely important for
> industrial environments where build-to-order and mass customization are
> becoming the name of the game and where plants have to be rapidly
> reconfigurable.
> We have experimentally demonstrated that the Devices Profile for Web
> Services can be implemented on an ARM9 processor using as little as 512K
> of ROM and 128K of RAM, yielding response times below 10 ms. Single-chip
> network-connected components incorporating such processor and memory
> capacity are available today and will soon cost less than $5, hence you
> can put them in most every device.
> Note further that using HTTP is an option - whether or not to use it is
> a matter of policy, as is the use of angle brackets or of some binary
> representation.
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. If I coded that in XML, it would likely be an order
of magnitude larger in bandwidth. This would mean that in order to maintain the
same cost base, I'd either have to decrease my information flow rate by an order
of magnitude, or have to deal with an order of magnitude increase in costs. In
cases where the satellite system is operating at 80% capacity, and I am using 30
percent of that bandwidth, my switch to XML could render the satellite system as
completely saturated and make it necessary to install and support a different
communications system.
This is where an ESB can be helpful. You can use a mediation service that
translates your modbus data into XML, or some other bus standard format to help
reduce your enterprise dependency on such a technology. By having an ESB in
place for inbound and outbound data flows, you allow your services to have a
standardized view into all services without having to be configured to deal with
all possible services. Remember, your ethernet cable is an ESB!
But, you really have to be prepared, in your architecture, to neutralize any
disturbance created by a new/different technology. If you don't design your SOA
with this concept in mind, you'll find yourself struggling. You may not be able
to use a cost effective solution because your SOA can't integrate it effectively.
Gregg Wonderly
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.
