[AG-TECH] Venue Server protocol/API?

Jim Miller jmiller at insors.com
Tue Oct 8 22:52:49 CDT 2002


Agreed.  inSORS (you got the capitlization correct!) is striving for full
inter-operability with the implementation of AG2.0.



-----Original Message-----
From: owner-ag-tech at mcs.anl.gov [mailto:owner-ag-tech at mcs.anl.gov]On
Behalf Of Randy Groves
Sent: Monday, October 07, 2002 11:45 AM
To: ag-tech at mcs.anl.gov
Subject: RE: [AG-TECH] Venue Server protocol/API?


I hope that you didn't think I implied or meant to imply that inSORS (I can
never remember which way I'm supposed to capitalize the name ... ;-)  )
wasn't maintaining compatibility with the Argonne suite.  But, correct me
if I'm wrong, it is a one way compatibility.  Argonne clients cannot use
your venue service to access inSORS venues, and inSORS clients cannot
directly utilize an Argonne-style venue server.

And as Ivan pointed out, that is what the emphasis on defining the venues
in WSDL is intended to address.

My note was mainly a plea that we all support the goal of full
inter-operability.  And it sure looks like we're headed in the right
direction.

-randy

At 03:16 PM 10/4/2002 -0500, Jim Miller wrote:
>inSORS plans to remain a very active participant within the AG community.
>To that end, we plan to assist in the future development/deployment of the
>AG architecture and version 2.0 where possible.  Additionally, we are firm
>in our commitment to maintain compatibility/connectivity to all Argonne
>venues and AG nodes that comply with Argonne's requirements.
>
>As far as venues work currently, most of our corporate customers want a
>private, inside their firewall venue to conduct internal communication as
>well as a link to our venue to communicate with suppliers and customers as
>well as the research community.
>
>Finally, our focus for our commercial software is to develop, deploy and
>support a software product that maintains the features and functions of the
>AccessGrid software with some enhancements for the corporate world that
>makes it easier to use, operator free, and easier for us to support.
>
>Jim
>-----Original Message-----
>From: owner-ag-tech at mcs.anl.gov [mailto:owner-ag-tech at mcs.anl.gov]On
>Behalf Of Randy Groves
>Sent: Friday, October 04, 2002 12:36 PM
>To: ag-tech at mcs.anl.gov
>Subject: [AG-TECH] Venue Server protocol/API?
>
>
>I definitely enjoyed the first two sessions of AG2.0 this week.  I was
>unable to attend the third, but have reviewed the sessions.  I like the
>general direction that things are taking - but I have at least one big
>concern: venue server compatibility.
>
>Right now, I see three camps in the AG community, in relation to venue
>services: Argonne, InSors, and Microsoft.  There may be more, but I'm
>unaware of them.  All seem to be taking separate, incompatible routes to
>venue service, and this definitely concerns me.  Wearing my implementer
>hat, and looking at a world-wide entity with diverse operating groups and a
>desire to collaborate with many equally diverse external partners, I want
>to be know that when we install a solution, that we will be able to
>communicate with others that may have installed a different solution.  The
>relative homogeneity of the AG community, and the fact that we're pretty
>much depending upon one venue server at Argonne for the services makes the
>present situation possible.
>
>I definitely understand that this is NOT a simple problem.  Just the
>question of authentication and authorization alone is one that gives anyone
>who has worked with this pause.  But I think that the venue services, as a
>defined point of interface between groups of 'AG-like' communities, is the
>perfect place to take the time to make sure that we can handle
>heterogeneity and still be able to collaborate.
>
>I certainly don't have the answers.  But please see this as a plea to
>consider the global situation when crafting the potential solutions.
>
>-randy







More information about the ag-tech mailing list