Dear GRAAP members,
we have seen in various discussions that there seems to be a frequent
desire for a standardized term language to express when a service shall
be delivered.
Examples are:
- Making a hardware reservation of a cluster for interactive use
- Co-allocation of resources of various types (hardware, network,
licenses, ...)
- Defining a deadline for the completion of a job
We have had a discussion about this in Banff after which Oliver and I
have prepared a proposal for a Time Constraints Profile for
WS-Agreement. This proposal has been uploaded here:
https://forge.gridforum.org/sf/go/doc15832?nav=1
We would be eager to hear your comments.
- Is the proposal clear?
- Is the proposal complete?
- Does the proposal satisfy your needs?
Best regards,
Dominic
Hello Costas and Dominic,
I am Carlos Müller (University of Seville) we have been working in proposals
with WS-Agreement since 2007 and after reading your emails, I think that you
may find interesting our proposal to extend the temporal-awareness of
WS-Agreement presented at the International Conference on Service Oriented
Computing celebrated (Vienna, Austria, 2007).
In such work we proposed a DSL or an XML schema (showed as an UML class
diagram) to specify any kind of validity period disjoint or not, and
periodical or not. Moreover, we give a concrete way to include such validity
periods for any agreement element of a WS-Agreement document by using the
extension points of WS-Agreement specification. You can take the paper and
the XML schema from http://www.isa.us.es/wsag/, in the section
"TEMPORAL-AWARE WS-AGREEMENT", which is the first button above.
If you have any question or comment, please feel free to contact me by my
email, phone or even by this list (I have just joined few minutes ago
because a colleague has said to me the discussion of this topic).
Best Regards.
Carlos Müller
cmuller(a)us.es
University of Seville.
(+34 954 553 868)
(+34 609 865 920) mobile phone
---------- Forwarded message ----------
From: Dominic Battre <mailinglists(a)battre.de>
Date: Thu, Dec 10, 2009 at 7:13 PM
Subject: Re: [GRAAP-WG] Time Constraints Profile
To: "Constantinos (Costas) Kotsokalis" <ckotso(a)admin.grnet.gr>
Cc: GRAAP-WG <graap-wg(a)gridforum.org>
Hello Costas,
I thought about this for time. My point of view is the following:
I can use my calendar application and define appointments for "every day
from now until next Friday, 9am-5pm". After entering this appointment
and going to the calendar view, I see one appointment each day. So
"every day from now until next Friday, 9am-5pm" was just an intensional
description of what can be expressed by an extensional description as
well (see http://en.wikipedia.org/wiki/Intensional_definition)
So what are the advantages and disadvantages of an intensional description?
1) Positive: compact representation
2) Negative: difficult to model, negotiate and evaluate adherence
3) Positive: can be used to model infinite number of repetitions (every
day until the end of the world)
I think that 3) has no real usecase as contracts should contain a well
defined end.
Considering 1) and 2) I am still in favor of the extensional
description. "every day from now until next Friday, 9am-5pm" becomes
just "2009/12/10 9am-5pm, 2009/12/11 9am-5pm, ..., 2009/12/18 9am-5pm".
When the user enters an SLA its GUI can still present "every day from
now until next Friday, 9am-5pm" but just render it as an extensional
set. Each individual time frame could be modeled as one SDT+GT.
I think the extensional description has the same expressiveness (as
mentioned, I don't see 3) as a usecase for us) but is easier to handle
and creates a leaner specification.
Best regards,
Dominic
On 12/07/2009 05:17 PM, Constantinos (Costas) Kotsokalis wrote:
> Hi Dominic,
>
> Recurring patterns for service usage is something that is needed in many
> cases, even if not allowed by current technology/service providers. In
> an example scenario where someone rents VMs to execute enterprise
> operations s/w on them, (s)he would certainly prefer to load-balance
> over a number of them available during working hours, and half or less
> that number outside working hours, to save money. I know this is not
> something that current cloud providers offer (to the extent I'm aware
> of, at least) but I believe it's a realistic need, and fits with fully
> dynamic scaling scenarios.
>
> On the same time, I do agree that it increases complexity, especially if
> one is willing to include constructs such as "on the first Monday of
> every month" etc.
>
> Just my E0.02.
>
> Best regards,
>
> Costas
>
>
> On 7 Dec 2009, at 14:39, Dominic Battre wrote:
>
>> Hello Costas,
>>
>> it would certainly be a possible extension.
>>
>> The question is do we want it? If we end up translating ical to XML we
>> come to a specification that is extremely powerful but very difficult
>> to implement.
>>
>> Our idea was to use the simplest language that would be useful.
>> Therefore, I would like to ask you and the others: Do you need
>> something like "every day, 9am-5pm"?
>>
>> Best regards,
>>
>> Dominic
>>
>> Constantinos (Costas) Kotsokalis wrote:
>>> Hi Dominic,
>>> Would you see fit to augment this also with some construct for
>>> defining periodic durations? E.g. to be able to say "every day,
>>> 9am-5pm", or things like that.
>>> Best regards,
>>> Costas
>>> On 7 Dec 2009, at 13:43, Dominic Battre wrote:
>>>> Dear GRAAP members,
>>>>
>>>> we have seen in various discussions that there seems to be a frequent
>>>> desire for a standardized term language to express when a service shall
>>>> be delivered.
>>>>
>>>> Examples are:
>>>>
>>>> - Making a hardware reservation of a cluster for interactive use
>>>>
>>>> - Co-allocation of resources of various types (hardware, network,
>>>> licenses, ...)
>>>>
>>>> - Defining a deadline for the completion of a job
>>>>
>>>> We have had a discussion about this in Banff after which Oliver and I
>>>> have prepared a proposal for a Time Constraints Profile for
>>>> WS-Agreement. This proposal has been uploaded here:
>>>>
>>>> https://forge.gridforum.org/sf/go/doc15832?nav=1
>>>>
>>>> We would be eager to hear your comments.
>>>>
>>>> - Is the proposal clear?
>>>>
>>>> - Is the proposal complete?
>>>>
>>>> - Does the proposal satisfy your needs?
>>>>
>>>> Best regards,
>>>>
>>>> Dominic
>>>> --
>>>> graap-wg mailing list
>>>> graap-wg(a)ogf.org
>>>> http://www.ogf.org/mailman/listinfo/graap-wg
>>
>
>
--
graap-wg mailing list
graap-wg(a)ogf.org
http://www.ogf.org/mailman/listinfo/graap-wg
