I agree with most of your comments. There is no one-size-fits-all and
encapsulating legacy technology is an ever-returning issue.
We have actually done such technology bridging exercises. In one of
them, a home-gateway scenario, we made fieldbus-connected home control
devices look as if they were DPWS-enabled, so that you can control your
heating, lighting, shutters, etc. from your (DPWS-capable) MediaCenter
PC. An individual light bulb exposes a service interface with operations
like "TURN-ON", "TURN-OFF" and "DIM", but whether this service is
actually implemented by the device itself or by a gateway/mediator is
irrelevant to the MediaCenter (or smartphone or other controlling
device, for that matter).
As to the bandwidth issue in relation to XML transfers, this is very
context-dependent. On a 100 Mbps Ethernet link, it's really a non-issue:
the network transfer is much faster than the processing of the messages.
On a wireless link, it may be a problem, depending on the density of
your message traffic. Even so, network speeds are increasing faster than
processing power. Satellite links are not a very common use case and the
cost of using them is such that gatewaying solutions may be needed
anyway.
Harm Smit.
> -----Original Message-----
> From: [email protected]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Dan Creswell
> Sent: mercredi 10 mai 2006 16:42
> To: [email protected]
> Subject: Re: [service-orientated-architecture] Re: MQSeries vs. ESB
>
>
> Gregg Wonderly wrote:
> > 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.
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Get to your groups with one click. Know instantly when new
> email arrives
> http://us.click.yahoo.com/.7bhrC/MGxNAA/yQLSAA/NhFolB/TM
> --------------------------------------------------------------
> ------~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
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.
