Venue membership via soap?

[Thomas D. Uram]

Comments below.  Give this discussion lower priority than 
release-related tasks...

Ivan R. Judson wrote:

>I have a lot of questions, but I'm definitely not opposed to the idea.
>
>Questions:
>
>1) Are you suggesting this for this cycle? We nominally froze code last
>Friday (or were trying to) we really need to close this cycle asap to do any
>real testing.
>  
>
I was throwing it out for discussion only.  I don't see that it could go 
in this release, due to the timeline and its impact on client/server 
compatibility.

>2) Is it true that heartbeats are the only event channel data (currently)
>that are sent from client to server?  By moving this to SOAP are you
>implying that services will do the same (I'm thinking a data storage service
>that gets files dumped into it needs to indicate such a change to the
>venue(s) it's present in). This looks like a general design suggestion that
>the venue is the *only* source of event data, all data that results in event
>generation is done via SOAP...
>  
>
Clients _do_ send data other than heartbeats, but those are not for 
membership. 

>3) I would argue we *have* to do either the OpenSSL or unsecured SOAP to
>make this feasible, a call every n seconds that takes ~1 second overhead is
>the wrong performance ratio to be living with, when n < 100, IMHO. 
>  
>
This point and the one below speak to performance, which we would 
certainly need to consider.  In fact, we have felt that pressure ever 
since we plugged in GSI beneath SOAP, so we need to look into it anyway.

>4) Do we know we can mix SOAP server/clients, GSI server, SSL client? If so
>can we mix unsecured and use session headers to make it even faster?
>
>5) What effect if any does this have on the potential design changes for the
>event/text channels (merging them into a more basic communication channel
>with a richer data protocol), since text is mostly client produced data, if
>any server produced (this seems to be a direct counter example for moving
>heartbeats if it's working, doesn't it?)
>  
>
I don't see that it has any impact on changes of that type for the 
event/text channels.  Could you explain why it's a counter-example?

>--Ivan
>
>  
>
>>-----Original Message-----
>>From: owner-ag-dev at mcs.anl.gov 
>>[mailto:owner-ag-dev at mcs.anl.gov] On Behalf Of Robert Olson
>>Sent: Saturday, March 20, 2004 12:45 PM
>>To: Thomas D. Uram
>>Cc: ag-dev at mcs.anl.gov
>>Subject: Re: Venue membership via soap?
>>
>>I think it's a great idea. If there's concern over the GSI 
>>connection overhead, we can do straight SSL with connection tokens.
>>
>>--bob
>>
>>On Sat, 20 Mar 2004, Thomas D. Uram wrote:
>>
>>    
>>
>>>Considering the difficulties we've had with the event 
>>>      
>>>
>>service, and the 
>>    
>>
>>>concerns people have about losing their membership in a venue (and 
>>>having their media tools shutdown), I was wondering if we 
>>>      
>>>
>>should move 
>>    
>>
>>>membership management (i.e. heartbeats) over to the SOAP realm.
>>>Especially considering that the SOAP server is now 
>>>      
>>>
>>multithreaded, this 
>>    
>>
>>>could be more reliable than the event channel, and would leave the 
>>>event channel strictly to managing coherence.
>>>
>>>This would simplify some services, too.  If they're not 
>>>      
>>>
>>concerned with 
>>    
>>
>>>coherence, they don't need an event client.
>>>
>>>Thoughts?
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-dev/attachments/20040323/d953c184/attachment.htm>