Distributed computing using SOAP. What about speed ?

[Graham Dumpleton]

Tim Daneliuk <tundra at tundraware.com> wrote in message news:<3B60EEA0.70BC492A at tundraware.com>...
> In an ideal world, you's have a layering scheme something like this:
> 
> 
>        Chunk of distributed application.
>            |     and/or    |
> -------------------------------------------
> tx Queuing API | Direct Message Passing API
> -------------------------------------------
> tx Q Manager  M|           |              M
> ----------------           |
>             Reliable Messaging Layer
> --------------------------------------------         Where, "M" is a pluggable
>             Reliable Comms Transport      M          management & security
> --------------------------------------------         facility for each layer
>              Speeds, Feeds, & Wire        M          in question
> --------------------------------------------
> 
> 
> (You'll notice that my picture is a bit different than the usual
> one in which Q management lives *below* the messaging layer.  This
> is a matter of taste because you can accomplish the same things
> either way.  In any case, if you need message persistence as a 
> class of service (almost all enterprises need this on occasion),
> you will end up implementing a disk-based Q under the Messaging
> Layer above and beyond what the Transactional Q Manager has to do.)

I'll say now that I sent my last message without properly understanding
what you have written. Even now I still have to read it properly as am
trying to respond to this all quite quickly.

Anyway, it seems you model may be quite close to how OSE is structured.
OSE has a base reliable messaging layer (subject to processes not being
shutdown or crashing), with a direct message passing API being exposed.
OSE doesn't currently have a transactional queing mechanism. If it was
done, I also saw it sitting out the side, or maybe partially also using
the direct messaging API. I definitely didn't see things as being
dependent on transactional queuing. OSE doesn't necessarily address issues
of security to much degree as it is being seen as best suited to closed
corporate networks.

Will now have to sit down and look at your paper and other comments when
I get a chance as I can understand where you are coming from.