> Harm Smit wrote:
>>> 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.
>
[snip]
>
> 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.
>
And this for me is the real lesson (an architectural one). By all means
use a common standard where you can but don't try and force it into
every corner because it's not always appropriate given your constraints
(which can change over time of course).
And having got yourself a common standard be prepared to use
bridging/adaption/mediation patterns at the edges to do translation back
and forth in cases where that common standard isn't appropriate.
Further, make sure that your common standard can support such bridging.
There is no such thing as a one size fits all solution - it's an 80/20
thing.
Dan.
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.
