Design issue concerning TclSOAP

Hello out there,
I am using the excellent TclSOAP package (more precisely its XML-RPC
part) to communicate with several devices on a local network. The
current setup consists of _one_ process which queries all devices at a
certain interval for their current data - sort of a logger process.
Everything is working fine.

Now requirements have evolved:
- The time interval should be different for different devices and
- it shall be possible to send data to some of these devices.

The easiest way to solve this would be to start different processes:
- Each logger process talks to its specific device at its specific
time interval.
- For each device which can accept data there will be a "controller
process" which will transmit this data if and when necessary.

My question is: Is this enhanced setup going to work?
- Is it possible to have several processes [package require XMLRPC] on
the same machine?
- At some point in time they will interrupt each other: Process A
starts its request, time slicing occurs and process B starts its
request. Will this create havoc?
- The "controller" processes might / will complicate matters. Like so:
Logger process A starts getting data from device X,  time slicing
occurs and controller process C starts sending data to this same
device X. Does the SOAP package serialize these commands or will
device X get a mixup of requests?

Having just started to rip apart the current implementation to
implement these new requirements, these questions occurred to me, and
I thought I'd ask the experts before possibly running against a wall.

Any insight into this matter will be greatly appreciated. Oh, this is
Tcl 8.4.7 on Linux.

Best regards
Helmut Giese

hgiese@ratiosoft.com (Helmut Giese) writes:

[snip]
>My question is: Is this enhanced setup going to work?
>- Is it possible to have several processes [package require XMLRPC] on
>the same machine?
Yes
>- At some point in time they will interrupt each other: Process A
>starts its request, time slicing occurs and process B starts its
>request. Will this create havoc?
No
>- The "controller" processes might / will complicate matters. Like so:
>Logger process A starts getting data from device X,  time slicing
>occurs and controller process C starts sending data to this same
>device X. Does the SOAP package serialize these commands or will
>device X get a mixup of requests?

Each connection to an endpoint is a separate HTTP connection. Just as a
web browser can manage to download from multiple sites simultaneously
so can XML-RPC/SOAP deal with multiple providers. I doubt that you need
a separate process even. If you arrange your code to be properly event
driven then all you need is a separate XML-RPC command for each
endpoint. Under the covers, each time you run the XML-RPC command it
will create a new http request to service that command. So no
collision will occur between serviceA and serviceB

--
Pat Thoyts                            http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

On Wed, 01 Jun 2005 14:42:42 GMT, Pat Thoyts
<cng@mfcyng.serrfreir.pb.hx> wrote:

Hi Pat,
thanks for re-assuring me.
[snip] 
>
>Each connection to an endpoint is a separate HTTP connection. Just as a
>web browser can manage to download from multiple sites simultaneously
>so can XML-RPC/SOAP deal with multiple providers. I doubt that you need
>a separate process even. If you arrange your code to be properly event
>driven then all you need is a separate XML-RPC command for each
>endpoint. Under the covers, each time you run the XML-RPC command it
>will create a new http request to service that command. So no
>collision will occur between serviceA and serviceB
I am worried about the devices getting messed up when requests get
mixed up, e.g a request for data arrives and before it is honoured
another request to set some data arrives. (These devices are all kinds
of gizmos - some microcontroller based - and of course all have their
own implementation of XMLRPC. I don' trust them very far.)

What I think I will do is to have one process for each device. If
there is only logging to do - fine. If there is logging _and_ sending
data to do, I can easily coordinate these two activities since they
happen in the same process.

Thanks for your help and best regards
Helmut Giese

Interesting that this subject came up.

I have a large batch job that uses TclSOAP, how can these be paralleled
so that we are not doing one at a time?

We currently have separate intrepreters launching to do this, it works
well, but it is a pain to setup/configure.

Any suggestions?

Dave

Helmut Giese wrote:
> On Wed, 01 Jun 2005 14:42:42 GMT, Pat Thoyts
> <cng@mfcyng.serrfreir.pb.hx> wrote:
>
> Hi Pat,
> thanks for re-assuring me.
> 	[snip] 
> I am worried about the devices getting messed up when requests get
> mixed up, e.g a request for data arrives and before it is honoured
> another request to set some data arrives. (These devices are all kinds
> of gizmos - some microcontroller based - and of course all have their
> own implementation of XMLRPC. I don' trust them very far.)
>
> What I think I will do is to have one process for each device. If
> there is only logging to do - fine. If there is logging _and_ sending
> data to do, I can easily coordinate these two activities since they
> happen in the same process.
>
> Thanks for your help and best regards
> Helmut Giese

On 2 Jun 2005 04:22:18 -0700, davidhbigelow@simplifiedlogic.com wrote:

>Interesting that this subject came up.
>
>I have a large batch job that uses TclSOAP, how can these be paralleled
>so that we are not doing one at a time?
I am not using it, but there is a '-command callback' option in the
SOAP package. Using it you could launch multiple requests all at once
and each of them will eventually get its result passed to the callback
function you provided with each call - could be the same function with
an additional parameter describing the source or could be all
different functions.
HTH
Helmut Giese

Interesting - I will check in to that.

Any word on when TclSOAP will be upgraded to version 2.x (as I recall)
of the SOAP Spec?

Dave

davidhbigelow@simplifiedlogic.com writes:

>Interesting - I will check in to that.
>
>Any word on when TclSOAP will be upgraded to version 2.x (as I recall)
>of the SOAP Spec?

SOAP 1.2 is the current version. TclSOAP already has a certain amount
of support for this -- it's mostly a matter of fixing the namespaces
involved. Specifying -version SOAP1.2 fixes the SOAP envelope
namespace and you proabbly also need to fix the encoding and maybe the
schemas. When I last looked at this people were using various mixes
but it has probably all settled down now. Look at the -encoding
SOAP1.2 option and -schemas option. -schemas lets you rewrite and add
namespaces into the SOAP envelope eg:
-schemas {xsd http://www.w3.org/2001/XMLSchema xsi \
http://www.w3.org/2001/XMLSchema-instance}
is what you want for SOAP 1.2 I think.

--
Pat Thoyts                            http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD