From jim_pruyne at hp.com Wed Feb 1 02:28:29 2006
From: jim_pruyne at hp.com (Jim Pruyne)
Date: Wed, 01 Feb 2006 00:28:29 -0800
Subject: [graap-wg] telecon on 2/1
Message-ID: <43E0712D.70803@hp.com>
We will have a telecon. on Wed. morning/evening. Dial-in numbers will be
the same.
The time is:
9:00AM Central Time US (GMT-0600, I think)
which should be:
10:00AM Eastern Time US
1500 UK
1600 Germany
midnight Japan
2200 Thailand
Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the
US.
Conference code #8578310.
We'll continue addressing comments received during public comment. The
current draft is stored on Grid Forge.
--- Jim
From jim_pruyne at hp.com Wed Feb 1 09:30:20 2006
From: jim_pruyne at hp.com (Jim Pruyne)
Date: Wed, 01 Feb 2006 07:30:20 -0800
Subject: [graap-wg] telecon on 2/1
In-Reply-To: <43E0712D.70803@hp.com>
References: <43E0712D.70803@hp.com>
Message-ID: <43E0D40C.8040505@hp.com>
Toshi and I were the only ones on the call, so we cut it short. Next
week is the last before GGF, so hopefully we can have good attendance to
have any last discussions on presentations at GGF, and to have a little
more progress to show by then.
--- Jim
Jim Pruyne wrote:
> We will have a telecon. on Wed. morning/evening. Dial-in numbers will
> be the same.
> The time is:
> 9:00AM Central Time US (GMT-0600, I think)
> which should be:
> 10:00AM Eastern Time US
> 1500 UK
> 1600 Germany
> midnight Japan
> 2200 Thailand
>
> Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside
> the US.
> Conference code #8578310.
>
> We'll continue addressing comments received during public comment.
> The current draft is stored on Grid Forge.
>
> --- Jim
>
From jim_pruyne at hp.com Wed Feb 8 02:29:17 2006
From: jim_pruyne at hp.com (Jim Pruyne)
Date: Wed, 08 Feb 2006 00:29:17 -0800
Subject: [graap-wg] telecon on 2/8
Message-ID: <43E9ABDD.1010307@hp.com>
We will have a telecon. on Wed. morning/evening. Dial-in numbers will be
the same.
The time is:
9:00AM Central Time US (GMT-0600, I think)
which should be:
10:00AM Eastern Time US
1500 UK
1600 Germany
midnight Japan
2200 Thailand
Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the
US.
Conference code #8578310.
We'll finalize plans for GGF which is next week and continue addressing
comments received during public comment. The current draft is stored on
Grid Forge.
--- Jim
From Anne.Anderson at sun.com Wed Feb 8 08:44:19 2006
From: Anne.Anderson at sun.com (Anne Anderson)
Date: Wed, 08 Feb 2006 09:44:19 -0500
Subject: [graap-wg] condition expression language requirements for WS-Agreement
Message-ID: <43EA03C3.5050006@Sun.COM>
WS-Agreement is supposed to be "a Web Services protocol for establishing
agreement between two parties". Unless there are defined mechanisms for
reaching agreement on the contents of a WS-Agreement specification, I
don't believe WS-Agreement has met its primary goal.
Particularly in the area of condition expression languages, there has
been little successful work on feasible intersection/agreement
mechanisms other than the work done in the field of "narrowing
algorithms". For example, there is intersection/agreement between two
general XQuery expressions is undefined. There is a comment suggesting
that the condition expression language/dialect be completely at the
discretion of the WS-Agreement instance originator, which will make this
problem even harder unless there is a corresponding requirement that two
parties must either agree on the dialect used (and that it have a
feasible intersection/agreement mechanism) or that there must be a
defined intersection/agreement mechanism between the two dialects.
I recommend inserting a requirement that any language/dialect specified
for WS-Agreement condition expressions must have a referenceable
specification for computing intersection or agreement between any two
expressions in the language/dialect. Unless this is done, WS-Agreement
will not meet its goals and will not be interoperable.
Regards,
Anne
--
Anne H. Anderson Email: Anne.Anderson at Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
From karlcz at univa.com Wed Feb 8 09:06:38 2006
From: karlcz at univa.com (Karl Czajkowski)
Date: Wed, 8 Feb 2006 22:06:38 +0700
Subject: [graap-wg] condition expression language requirements for WS-Agreement
In-Reply-To: <43EA03C3.5050006@Sun.COM>
References: <43EA03C3.5050006@Sun.COM>
Message-ID: <20060208150638.GC6327@moraine.localdomain>
On Feb 08, Anne Anderson modulated:
> WS-Agreement is supposed to be "a Web Services protocol for establishing
> agreement between two parties". Unless there are defined mechanisms for
> reaching agreement on the contents of a WS-Agreement specification, I
> don't believe WS-Agreement has met its primary goal.
>
I think I understand your point, and unfortunately this is an area
that has not been documented very well. Aside from your assertion
below, I think most of us have considered this a non-normative
documentation issue that should be captured in a "primer" document.
In a nutshell, the expected "agreement handshake" really starts with
the initiator consuming the advertised template(s) from a responder.
The first decision then is the initiator deciding whether the
responder accepts an agreement format that is acceptable to the
initiator. If so, he may proceed with formulating an agreement and
making an offer. If not, he has to go back to discovery.
The second decision is whether the responder understands an offer and
wants to accept it. This of course requires being able to extract the
semantic content of the offer in some form such that the responder's
policies can be evaluated to determine whether to accept or reject.
> Particularly in the area of condition expression languages, there has
> been little successful work on feasible intersection/agreement
> mechanisms other than the work done in the field of "narrowing
> algorithms". For example, there is intersection/agreement between two
> general XQuery expressions is undefined. There is a comment suggesting
> that the condition expression language/dialect be completely at the
> discretion of the WS-Agreement instance originator, which will make this
> problem even harder unless there is a corresponding requirement that two
> parties must either agree on the dialect used (and that it have a
> feasible intersection/agreement mechanism) or that there must be a
> defined intersection/agreement mechanism between the two dialects.
>
You are assuming, perhaps, that a general WS-Agreement implementation
will exist that computes intersections without domain-specific
knowledge. While I think this would be interesting, I think many
participants have set a lesser goal of being able to implement
domain-specific WS-Agreement implementations which can interoperate
according to a "profile" specification. There are two reasons this is
worth pointing out:
1) the profile may define the specific intersection model that is
appropriate for the domain
2) the profile may define additional discovery content to simplify
discovery of "interoperable profile implementations"
You might be pleased if you were to look into the JSDL job example in
the specification. I think you will find that the "range value" type
in the JSDL language has very simple intersection semantics which can
allow narrowing between the template, offer, and responder operating
policies to determine a match.
> I recommend inserting a requirement that any language/dialect specified
> for WS-Agreement condition expressions must have a referenceable
> specification for computing intersection or agreement between any two
> expressions in the language/dialect. Unless this is done, WS-Agreement
> will not meet its goals and will not be interoperable.
>
I don't have a problem with inserting a "SHOULD" statement about this,
but I think I disagree about the consequence of not having it. I do
not think there is a necessary interoperability between all
WS-Agreement implementations, but merely between implementations which
follow profiles where the conditional languages are normatively
defined.
I would be interested to hear others' opinions on this...
karl
--
Karl Czajkowski
karlcz at univa.com
From Anne.Anderson at sun.com Wed Feb 8 10:01:30 2006
From: Anne.Anderson at sun.com (Anne Anderson)
Date: Wed, 08 Feb 2006 11:01:30 -0500
Subject: [graap-wg] condition expression language requirements for
WS-Agreement
In-Reply-To: <20060208150638.GC6327@moraine.localdomain>
References: <43EA03C3.5050006@Sun.COM>
<20060208150638.GC6327@moraine.localdomain>
Message-ID: <43EA15DA.1000002@Sun.COM>
Karl,
Thank you very much for pointing out the RangeValue_Type in the Job
Submission Description Language (JSDL), which I had overlooked in my
earlier reading of WS-Agreement. This is exactly the type of mechanism
on which automated intersection/agreement can be based. RangeValue_Type
handles numeric types; also needed, however, are SetValue_Type types for
IP address subnets, regular expressions over strings, and a few other
basic types used in service agreements, along with Boolean operators for
combining range or exact-value constraints. The simple condition
language in the WS-Agreement "Preference Example" is an example of such
Boolean operators.
So many of the pieces exist. If they can be pulled together into a
"condition expression language" that could be referenced, it would go
far toward allowing automated agreement, and would improve
interoperability. The variables used in such expressions will be
domain-dependent, but if the condition expressions over their values use
a standard condition expression language, then implementations of
WS-Agreement can be smaller (supporting fewer mechanisms), more easily
testable (no domain-specific tests of comdition expression
intersection/agreement), and more interoperable. Agreements can be more
easily computed by brokers or other 3rd parties that may not have or
need the domain-specific code associated with the variables themselves:
this seems like an important consideration for Grid environments.
Interoperability may not be a goal, but if an implementation of
WS-Agreement will be used with more than one other partner, with more
than one other condition expression language, being able to reduce the
number of mechanisms that need to be supported is at least a valuable
objective.
For the current draft, if you are really intending to address the
condition expression language in a meaningful way in the next version,
how about removing the suggestions that XQuery might be an appropriate
condition expression language. XQuery is great for what it was designed
to do: express query constraints. But it was not designed for nor is it
suitable for expressing agreement constraints. There are no
intersection/agreement mechanisms defined for XQuery expressions in
general, and intersection/agreement is undefinable in many cases.
This would involve removing the statement that "An example of a generic
assertion language can be found in [XQUERYX]." in section "4.2.6.2
Qualifying Condition and Service Level Objective" and the statement that
"A general purpose constraint language has been proposed as part of the
XQuery and XPATH language. The XML rendering of this expression
language, XQueryX, MAY contain a suitable constraint language that can
be used to phrase constraints involving multiple items." in section
"5.1.2 Free?form Constraints", along with the subsequent
"wsag:XQueryXConstraint" extension of "".
Please understand, I am not objecting to XQuery itself, but only to
suggestions that it may be an appropriate constraint language where
agreement semantics are needed. Few WS-Agreement users will understand
the real implications of the choice of condition expression language
until they have invested significant time and effort into implementation
and use. At least don't lead them down the wrong path while you wait
for an appropriate path to appear.
Regards,
Anne
Karl Czajkowski wrote On 02/08/06 10:06,:
> On Feb 08, Anne Anderson modulated:
>
>>WS-Agreement is supposed to be "a Web Services protocol for establishing
>>agreement between two parties". Unless there are defined mechanisms for
>>reaching agreement on the contents of a WS-Agreement specification, I
>>don't believe WS-Agreement has met its primary goal.
>>
>
>
> I think I understand your point, and unfortunately this is an area
> that has not been documented very well. Aside from your assertion
> below, I think most of us have considered this a non-normative
> documentation issue that should be captured in a "primer" document.
>
> In a nutshell, the expected "agreement handshake" really starts with
> the initiator consuming the advertised template(s) from a responder.
> The first decision then is the initiator deciding whether the
> responder accepts an agreement format that is acceptable to the
> initiator. If so, he may proceed with formulating an agreement and
> making an offer. If not, he has to go back to discovery.
>
> The second decision is whether the responder understands an offer and
> wants to accept it. This of course requires being able to extract the
> semantic content of the offer in some form such that the responder's
> policies can be evaluated to determine whether to accept or reject.
>
>
>
>>Particularly in the area of condition expression languages, there has
>>been little successful work on feasible intersection/agreement
>>mechanisms other than the work done in the field of "narrowing
>>algorithms". For example, there is intersection/agreement between two
>>general XQuery expressions is undefined. There is a comment suggesting
>>that the condition expression language/dialect be completely at the
>>discretion of the WS-Agreement instance originator, which will make this
>>problem even harder unless there is a corresponding requirement that two
>>parties must either agree on the dialect used (and that it have a
>>feasible intersection/agreement mechanism) or that there must be a
>>defined intersection/agreement mechanism between the two dialects.
>>
>
>
> You are assuming, perhaps, that a general WS-Agreement implementation
> will exist that computes intersections without domain-specific
> knowledge. While I think this would be interesting, I think many
> participants have set a lesser goal of being able to implement
> domain-specific WS-Agreement implementations which can interoperate
> according to a "profile" specification. There are two reasons this is
> worth pointing out:
>
> 1) the profile may define the specific intersection model that is
> appropriate for the domain
>
> 2) the profile may define additional discovery content to simplify
> discovery of "interoperable profile implementations"
>
> You might be pleased if you were to look into the JSDL job example in
> the specification. I think you will find that the "range value" type
> in the JSDL language has very simple intersection semantics which can
> allow narrowing between the template, offer, and responder operating
> policies to determine a match.
>
>
>
>>I recommend inserting a requirement that any language/dialect specified
>>for WS-Agreement condition expressions must have a referenceable
>>specification for computing intersection or agreement between any two
>>expressions in the language/dialect. Unless this is done, WS-Agreement
>>will not meet its goals and will not be interoperable.
>>
>
>
> I don't have a problem with inserting a "SHOULD" statement about this,
> but I think I disagree about the consequence of not having it. I do
> not think there is a necessary interoperability between all
> WS-Agreement implementations, but merely between implementations which
> follow profiles where the conditional languages are normatively
> defined.
>
> I would be interested to hear others' opinions on this...
>
>
> karl
>
--
Anne H. Anderson Email: Anne.Anderson at Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
From jim_pruyne at hp.com Wed Feb 8 10:12:32 2006
From: jim_pruyne at hp.com (Jim Pruyne)
Date: Wed, 08 Feb 2006 08:12:32 -0800
Subject: [graap-wg] minutes from 2/8 telecon
Message-ID: <43EA1870.5060101@hp.com>
They are attached. Next week is GGF, so there will be no conference
call. We'll plan to have one the following week, on the 22nd, unless no
one is ready to do so soon after GGF. Also, and updated version of the
spec. from today's call will be uploaded to grid-forge in a moment.
--- Jim
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Feb0806-minutes.txt
Url: http://www.ogf.org/pipermail/graap-wg/attachments/20060208/9a8a323d/attachment.txt
From karlcz at univa.com Wed Feb 8 10:21:59 2006
From: karlcz at univa.com (Karl Czajkowski)
Date: Wed, 8 Feb 2006 23:21:59 +0700
Subject: [graap-wg] condition expression language requirements for WS-Agreement
In-Reply-To: <43EA15DA.1000002@Sun.COM>
References: <43EA03C3.5050006@Sun.COM> <20060208150638.GC6327@moraine.localdomain> <43EA15DA.1000002@Sun.COM>
Message-ID: <20060208162159.GE6327@moraine.localdomain>
On Feb 08, Anne Anderson modulated:
...
> This would involve removing the statement that "An example of a generic
> assertion language can be found in [XQUERYX]." in section "4.2.6.2
> Qualifying Condition and Service Level Objective" and the statement that
> "A general purpose constraint language has been proposed as part of the
> XQuery and XPATH language. The XML rendering of this expression
> language, XQueryX, MAY contain a suitable constraint language that can
> be used to phrase constraints involving multiple items." in section
> "5.1.2 Free?form Constraints", along with the subsequent
> "wsag:XQueryXConstraint" extension of "".
>
> Please understand, I am not objecting to XQuery itself, but only to
> suggestions that it may be an appropriate constraint language where
> agreement semantics are needed. Few WS-Agreement users will understand
> the real implications of the choice of condition expression language
> until they have invested significant time and effort into implementation
> and use. At least don't lead them down the wrong path while you wait
> for an appropriate path to appear.
>
> Regards,
> Anne
>
I would strongly endorse such a change, as well as a replacement text
that mentions a better assertion language. I think this is one of
those spots where something was stuffed in because previous commentary
had called for more concrete examples...
While we're at it, we SHOULD remove the inappropriate use of "MAY" in
such a recommendation. :-)
karl
--
Karl Czajkowski
karlcz at univa.com
From nakata at mtg.biglobe.ne.jp Wed Feb 8 10:28:40 2006
From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata)
Date: Thu, 09 Feb 2006 01:28:40 +0900
Subject: [graap-wg] condition expression language requirements for WS-Agreement
In-Reply-To: <20060208162159.GE6327@moraine.localdomain>
References: <43EA03C3.5050006@Sun.COM> <20060208150638.GC6327@moraine.localdomain> <43EA15DA.1000002@Sun.COM> <20060208162159.GE6327@moraine.localdomain>
Message-ID: <43EA1C38.8060705@mtg.biglobe.ne.jp>
I'll add Anne's suggestion to the 'Public Comments' list
Toshi.
Karl Czajkowski wrote:
> On Feb 08, Anne Anderson modulated:
> ...
>
>>This would involve removing the statement that "An example of a generic
>>assertion language can be found in [XQUERYX]." in section "4.2.6.2
>>Qualifying Condition and Service Level Objective" and the statement that
>>"A general purpose constraint language has been proposed as part of the
>>XQuery and XPATH language. The XML rendering of this expression
>>language, XQueryX, MAY contain a suitable constraint language that can
>>be used to phrase constraints involving multiple items." in section
>>"5.1.2 Free?form Constraints", along with the subsequent
>>"wsag:XQueryXConstraint" extension of "".
>>
>>Please understand, I am not objecting to XQuery itself, but only to
>>suggestions that it may be an appropriate constraint language where
>>agreement semantics are needed. Few WS-Agreement users will understand
>>the real implications of the choice of condition expression language
>>until they have invested significant time and effort into implementation
>>and use. At least don't lead them down the wrong path while you wait
>>for an appropriate path to appear.
>>
>>Regards,
>>Anne
>>
>
>
> I would strongly endorse such a change, as well as a replacement text
> that mentions a better assertion language. I think this is one of
> those spots where something was stuffed in because previous commentary
> had called for more concrete examples...
>
> While we're at it, we SHOULD remove the inappropriate use of "MAY" in
> such a recommendation. :-)
>
>
> karl
>
From nakata at mtg.biglobe.ne.jp Wed Feb 8 10:33:31 2006
From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata)
Date: Thu, 09 Feb 2006 01:33:31 +0900
Subject: [graap-wg] minutes from 2/8 telecon
In-Reply-To: <43EA1870.5060101@hp.com>
References: <43EA1870.5060101@hp.com>
Message-ID: <43EA1D5B.5080602@mtg.biglobe.ne.jp>
Public Comment List updated.
Toshi
Jim Pruyne wrote:
> They are attached. Next week is GGF, so there will be no conference
> call. We'll plan to have one the following week, on the 22nd, unless no
> one is ready to do so soon after GGF. Also, and updated version of the
> spec. from today's call will be uploaded to grid-forge in a moment.
>
> --- Jim
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PublicComments060208.xls
Type: application/vnd.ms-excel
Size: 100352 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060209/2bb41863/attachment.xls
From ph.wieder at fz-juelich.de Thu Feb 9 15:57:02 2006
From: ph.wieder at fz-juelich.de (Philipp Wieder)
Date: Thu, 09 Feb 2006 22:57:02 +0100
Subject: [graap-wg] GSA-RG session at GGF 16
Message-ID: <43EBBAAE.5030102@fz-juelich.de>
Dear All,
the GSA-RG would like to invite you to our session at GGF 16.
Date: Tuesday, February 14, 2006
Time: 3:30 pm - 5:00 pm
Location: Olympia B
We are especially looking forward to see three presentations on
state-of-the-art scheduling systems. These presentations will examine
generic Grid scheduling requirements and will therefore also be of
interest to groups like GRAAP or OGSA-RSS. Please find the respective
abstracts below.
I hope to see you in Athens.
Best regards, Philipp.
ABSTRACTS:
----------
1. "Workflow Scheduling in the ASKALON Grid Environment" by Marek
Wieczorek, University of Innsbruck
The ASKALON Grid environment is a full Grid environment designed to compose
and execute scentific workflow applications. The ASKALON scheduler is a
dynamic scheduling service using different optimization techniques to
maximize the user's profit in accessing the Grid. Pluggable architecture
of the scheduler enables the user to apply different workflow scheduling
algorithms, to apply advance reservations, and to consider different
optimization criteria, among them execution time and economic cost.
Acting as a part of a full Grid environment, the scheduler interacts
with other components of the ASKALON, namely with the resource
management, the enactment engine, the performance prediction and the
monitoring services, trying to make scheduling decisions based on the
most reliable and up-to-date information. Our goals are to make the
service SLA-aware and to extend it in the directions recommended by the
GGF community. Besides the functionality of ASKALON scheduler we will
also reflect general requirements for a Grid scheduler.
2. "The VIOLA Meta-scheduling Service" by Wolfgang Ziegler, Fraunhofer SCAI
Distributed applications or workflows usually require different
specialised resources like compute nodes, visualisation devices, storage
devices, or network connectivity with a defined QoS at the same time or
within a given period of time to be executed successfully. Orchestrating
such resources on a local level within one organisation is only a minor
organisational problem. Orchestration of resources on a Grid level
requires a service that is able to solve the same problems in an
environment that probably stretches across several administrative
domains. Additional conditions have to be taken into account, like site
autonomy and different site policies.
In this talk we first describe the environment where co-allocation of
resources is of vital importance, the requirements for the
MetaScheduling service that provides the required co-allocation means,
and related work. In the next step we characterise the functionality of
the MetaScheduling service, followed by the description of the current
implementation. As a use case we show the integration of the scheduling
system into the UNICORE Grid middleware and finally we present a new
project based on this work that started end of 2005.
3. "GridWay Scheduling Architecture" by Ignacio Mart?n Llorente,
Universidad Complutense de Madrid
GridWay, on top of Globus services, enables large-scale, secure and
reliable sharing of computing resources (clusters, computing farms,
servers, supercomputers...), managed by different resource management
systems (PBS, SGE, LSF, Condor...), within a single organization
(enterprise grid) or scattered across several administrative domains
(partner or supply-chain grid). GridWay is an open source
meta-scheduling technology that performs job execution management and
resource brokering, allowing unattended, reliable, and efficient
execution of jobs, array jobs, or complex jobs on heterogeneous and
dynamic Grids. GridWay performs all the job scheduling and submission
steps transparently to the end user and adapts job execution to changing
Grid conditions by providing fault recovery mechanisms, dynamic
scheduling, migration on-request and opportunistic migration. The
presentation describes the scheduling requirements for partner grid
computing, the functionality provided by GridWay to meet those
requirements, the GridWay scheduling architecture and finally its
requirements on core Grid services for the implementation of such
functionality.
From ali at epcc.ed.ac.uk Fri Feb 10 07:00:34 2006
From: ali at epcc.ed.ac.uk (Ali Anjomshoaa)
Date: Fri, 10 Feb 2006 13:00:34 +0000 (GMT)
Subject: [graap-wg] JSDL Workshop at GGF16
Message-ID:
Dear colleagues,
[My apologies for cross-posting]
Just a quick announcement of the JSDL-WG Workshop at GGF16.
Date: Wed. 15th Feb.
Time: 08:30 - 12:00
Room: Mycenae
The talks are in the schedule below.
We all look forward to seeing you there and to your feedback and
contributions towards our ongoing work in the JSDL-WG.
Kind regards,
Ali (on behalf of the JSDL-WG)
JSDL-WG: https://forge.gridforum.org/projects/jsdl-wg/
JSDL-Spec: http://www.gridforum.org/documents/GFD.56.pdf
--
---------------------------------------------------- |epcc| -
Ali Anjomshoaa
EPCC, University of Edinburgh
James Clerk Maxwell Building
Mayfield Road E-mail: ali at epcc.ed.ac.uk
Edinburgh, EH9 3JZ Phone: + 44 (0) 131 650 5818
United Kingdom Fax: + 44 (0) 131 650 6555
-------------------------------------------------------------
---- GGF16, JSDL Workshop Schedule ----
08:30 - Welcome and Introductions
08:35 - JSDL Tutorial
Andreas Savva (Fujitsu Laboratories Ltd, Japan)
Steve McGough (LeSC, Imperial College London, UK)
William Lee (Lesc, Imperial College London, UK)
09:20 - GridSAM presentation
William Lee, (LeSC, Imperial College London, UK)
09:40 - NAREGI presentation
Kazushige Saga (National Institute of Informatics, Japan)
10:00 - *** BREAK ***
10:30 - HPCEuropa presentation
Ariel Oleksiak (Poznan Supercomputing and Networking Centre,
Poland)
10:50 - Japan Business Grid presentation
Andreas Savva (Fujitsu Laboratories Ltd, Japan)
11:10 - UniGrids presentation
Michel Drescher (Fujitsu Laboratories of Europe, UK)
11:30 - Platform Computing presentation
Christopher Smith (Platform Computing, USA)
11:50 - Conclusions and closing remarks
12:00 - END
----------
From pruyne at hpl.hp.com Tue Feb 21 17:00:56 2006
From: pruyne at hpl.hp.com (Jim Pruyne)
Date: Tue, 21 Feb 2006 15:00:56 -0800
Subject: [graap-wg] No telecon on 2/22
Message-ID: <43FB9BA8.3060808@hpl.hp.com>
Folks,
Let's wait one additional week to start our telecons again. We'll have
the next one on March 1.
--- Jim
From Wolfgang.Ziegler at scai.fraunhofer.de Sun Feb 26 07:58:18 2006
From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler)
Date: Sun, 26 Feb 2006 14:58:18 +0100
Subject: [graap-wg] GGF16 minutes & slides uploaded
In-Reply-To: <43FB9BA8.3060808@hpl.hp.com>
References: <43FB9BA8.3060808@hpl.hp.com>
Message-ID: <4401B3FA.2010302@scai.fraunhofer.de>
Hi,
the minutes and slides of the presentations are accessible here now
https://forge.gridforum.org/docman2/ViewCategory.php?group_id=71&category_id=1233
Best regards
Wolfgang
--
Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI)
Schloss Birlinghoven, D-53754 Sankt Augustin, Germany
Tel: +49 2241 14 2258 Fax: +49 2241 14 42258 www.scai.fraunhofer.de
CoreGRID Network of Excellence www.coregrid.net
Collaboration Gateway www.coregrid.net/mambo/content/viev/53/74/
Institute on Resource Management and Scheduling www.coregrid.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3761 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/graap-wg/attachments/20060226/5c1b0e48/attachment.bin