Web services in an embedded environment

[Default User]

I work in software research and developement in the aerospace industry.
We're assisting a project where they are interested in looking at web
services in an embedded system. This would most likely be WSDL/XML/SOAP.

While there would be fairly powerful processing to an extent, it's
still a resource-constrained environment, running on an RTOS (I think
VxWorks). In particular they are concerned about dynamic memory (don't
like it).

We're still at the stage of developing the actual requirements for the
services, as well as a notional API.

I'd be interested in either papers on the general subject (particularly
recent ones) or open-source projects that are targeted towards this
sort of application.

I have found some, like this one from John Canosa:

<http://www.embedded.co m/9900482?_reques tid=1451389>
This message is cross-posted to comp.text.xml and comp.arch.embed ded.
If anyone replying feels the need to remove one of the groups, that's
not a problem, I will be monitoring both.

Brian

[Ali]

On Sep 1, 5:49 am, "Default User" <defaultuse...@ yahoo.comwrote:

I work in software research and developement in the aerospace industry.
We're assisting a project where they are interested in looking at web
services in an embedded system. This would most likely be WSDL/XML/SOAP.

While there would be fairly powerful processing to an extent, it's
still a resource-constrained environment, running on an RTOS (I think
VxWorks). In particular they are concerned about dynamic memory (don't
like it).

We're still at the stage of developing the actual requirements for the
services, as well as a notional API.

I'd be interested in either papers on the general subject (particularly
recent ones) or open-source projects that are targeted towards this
sort of application.

I have found some, like this one from John Canosa:

<http://www.embedded.co m/9900482?_reques tid=1451389>

This message is cross-posted to comp.text.xml and comp.arch.embed ded.
If anyone replying feels the need to remove one of the groups, that's
not a problem, I will be monitoring both.

Brian

As you pointed that your device will be on RTOS, I think Boa [
http://www.boa.org/0.92/ ] web server should be the good choice. It is
a single-task web server so that means very less resources are
required which makes it good candidate for embedded systems.

WSDL/XML/SOAP are just common ways of information exchange for systems
with ample processing and hell memory. IMHO, you got to make your own
compact exchange layer(rather SOAP). Sure, XML does make life easier
while having a parser on both sides to extract the real information
out from request/response and invoking RMI or RPC services. And on
the top you can use UPnP layer for service discovery.

stack should be like this:

2) UPnP
1) XML
0) Web Server

Thats too much abstraction here as you didn't really shared much
details. maybe folks might give you better solutions if you can
elaborate your requirements.

ali

[Default User]

Ali wrote:

On Sep 1, 5:49 am, "Default User" <defaultuse...@ yahoo.comwrote:

I work in software research and developement in the aerospace
industry. We're assisting a project where they are interested in
looking at web services in an embedded system. This would most
likely be WSDL/XML/SOAP.

As you pointed that your device will be on RTOS, I think Boa [
http://www.boa.org/0.92/ ] web server should be the good choice. It is
a single-task web server so that means very less resources are
required which makes it good candidate for embedded systems.

Thanks, I'll take a look at that, and think about the other issues you
raised.


Brian

--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

[Default User]

Joe Kesselman wrote:

There are certainly folks putting web services in low-powered
embedded boxes -- most cheap routers these days support a simple web
GUI, for example. "If it happens, it must be possible."

Thanks for the input, I'll see what I can find along these lines.


Brian