[AG-TECH] AccessGrid 3: What information is available

[Tom Uram]

Certificates will still be required.  You have now, and will have in the future, the
option of requesting a certificate from the anonymous CA that we run.  Anon certs are
signed and available for retrieval immediately.  One possibility is to have the software
request an anon cert if one doesn't exist, and use it, leaving it as a later option to get
an identity certificate.

The plan for communications within the node is that they will not be over secure
connections and will not require a certificate.  Only the venue client will require a
certificate (on the client side, anyway).  This should ease part of the difficulty of
setting up a node.

With the current software, _new_ users should get the current system node config.  This
doesn't help you when it changes, in which case you really want to be able to maintain
system node configs and allow users to choose from among them.  We're working on this
functionality, too.

These features are part of the plan of making the node more like infrastructure and easier
to use.

Tom


On 05/24/05 09:38, Derek Piper wrote:
> 
>     While we're on the subject of globus and stuff like that, will we
> still have to wait days in order to get a node up and running because of
> getting the certificates? It's one of the most tiresome things about
> setting up a new node.
>     Also, something I'd REALLY like to see is the ability to set a
> site-wide configuration under Linux and Windows. Sure have the users
> have a .AccessGrid folder (or the equivalent under 'Documents and
> Settings' for Windows) but having a system-wide config would be VERY
> advantagous to me in setting up conference room AG nodes. Then, a user
> known to the network can log in and it's already set up with the same
> config everyone else uses. I don't like having to have just one user run
> the AG stuff, especially with shared apps and the possibility that new
> users want to get on the AG for a meeting, share their stuff in a
> conference and get off. It would be nice if they could use a site
> conference room and fairly much do it themselves, albeit with a modicum
> of training.
> 
>     Derek
> 
> John Hodrien wrote:
> 
>> On Tue, 24 May 2005, Ivan R.Judson wrote:
>>
>>> Hey John,
>>>
>>> Good point. Although my skepticism keeps nagging with the worry, "Why
>>> bother
>>> with WSRF/GT4 services, aren't Web Services good enough?"  I suspect
>>> they
>>> are, I haven't seen any significant value to the layers above that
>>> provided
>>> by GT4.
>>
>>
>>
>> If you try and ignore the globus stuff, and think of it as WSRF it
>> becomes
>> more pleasant.  GT4 contains lots of crap for submitting jobs and
>> managing
>> resources, copying files about etc.  I have no immediate interest in
>> any of
>> that.  WSRF is the OASIS working draft for stateful web services, and
>> as such
>> is intended to be something nice and generic, usable whenever you want
>> state
>> in a web service.
>>
>> The most important part of it as I'm concerned (if you were
>> entertaining the
>> notion of AG with web services) would be WS-Resource and
>> WS-Notifications.
>>
>> http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-Resource-1.2-draft-03.pdf
>> http://docs.oasis-open.org/wsn/2004/06/wsn-WS-BaseNotification-1.2-draft-03.pdf
>>
>>
>> Sadly you can quickly complicate things, as you're likely to need
>> WS-Reliability if you're going down the notifications road.
>>
>> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm
>>
>> I'm not sure what else would be worth poking at, bits like
>> WS-ResourceLifetime
>> might also deserve a look in.
>>
>> Equally, playing with WS-Security and using the SAML callout would let
>> you
>> define whatever you wanted on the security front, and make it open and
>> standardised how you were doing it.
>>
>> These are all boxes of tricks that live independently of GT4 (WSRF.NET
>> for
>> example) but would open up the AG to open and standard interaction
>> with other
>> software.
>>
>> So really my case for this isn't in favour of GT4, it's in favour of
>> standardised (very nearly at least ;) stateful web services.
>>
>>> Did I miss something :-)?
>>
>>
>>
>> I'm sure we've all missed plenty ;)
>>
>> jh
>>
>