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 vsh-pilot.idl) This way all authentication will remain at one layer, otherwise we'll get some serious syncronising problems. Please do doubt & discus my opinion! bye, jarl