[Pipet Devel] summary for web

Jarl van Katwijk jarl at casema.net
Fri Mar 31 07:38:11 EST 2000

Brad Chapman wrote:

> >>
> >> 5. Communication with remote vsh programs as both a client and a
> >> server
> >> using corba (through an idl that still has to be defined). This
> allows
> >> a
> >> specific implementation of vsh to serve out a specialized node or
> set
> >> of
> >> nodes to be utilized by other vsh implementations at remote
> locations.
> >> The processing layer will handle the specifics of this
> communication,
> >> but the middle will define a protocol to authenticate remote vsh
> >> implementations and provide access only to available nodes.
> >
> > When the DL is authenticated by the BL, shoudn't 5) also be located
> inside
> > the
> > BL?
> Yes, I think so. I'm not at all clear on how the specifics of the node
> sharing are going to work eventually, although this is a very
> important part of vsh.
>     I'll try and describe my ideas on this by an example. Lets say I'm
> running a vsh implementation at home, and I want to connect with a
> high speed machine of Jeff's running vsh at a remote location. My
> rough idea was that things would work as follows:
> 1. From within the user interface, I would request to see the
> available nodes at Jeff's computer, and enter a password for
> connection.
> 2. My definition layer would get access to Jeff's machine via some
> repository of IORs and machines, and connect with his corba server.
> 3. My dl would authenticate with his dl, and then would send a request
> of all nodes that I have permissions to use.
> 4. My definition layer would recieve this list and make these nodes
> known to the user interface. I would then use one of them in a
> work-flow diagram.
> 5. I would send this work-flow diagram with the remote node (as XML)
> to the brokering layer in a processing request.
> (okay, this is where things get pretty hazy).
> 6. The brokering/processing layer would set up its path of processing
> (by whatever method) and start processing.
> 7. When it needed the info from that node, it would need to connect
> with Jeff's computer remotely (this connection would occur somewhere
> inside the brokering/processing layers), send the node the info it
> needs, let it process it, and then get the results back.
> 8. Then the results can be fetched from the brokering layer on my
> computer in the same way as for the execution of a local node.
> Okay, that my cloudy idea of how things would work. Is this what you
> all were thinking? Is this at all feasible?
> Brad

If you want to accomplise 1) you do a ReteiveInfo::uriStatus() on the BL.

5) will work by Representation::upload()

Look again at the uriS structure.

What we'll need ain't a DL <-> DL communication line, but a BL -> DL one.

(opposing the DL -> BL commmunication we've described by the

This way all authentication will remain at one layer, otherwise we'll get
serious syncronising problems.

Please do doubt & discus my opinion!


More information about the Pipet-Devel mailing list