THE SLAng SLA LANGUAGE
Frequently asked questions
/faq.php Copyright UCL 2006
Web version
Disclaimer: None of the information provided on this page should be
construed as legal advice. SLAng is under development and should not yet be
used for real SLAs.
SLAs in general
- What is an SLA?
- Why isn't this legal advice?
- What is the difference between an SLA and a contract?
- Why do we need a language for SLAs?
- What are the requirements for an SLA?
- What are the requirements for an SLA language?
ASP in general
- What is Application Service Provision (ASP)?
- What are the advantages of the ASP business model?
- What are the risks with the ASP business model?
- How can SLAs mitigate the risks with the ASP business model?
SLAng
- What is SLAng?
- How can SLAng be used?
- Why should I not use SLAng for real SLAs yet?
- Who has been involved in the development of SLAng, and why?
SLAng in practice
- What parties need to be involved in an ASP SLA?
- What requirements must my service meet for me to use SLAng to offer SLAs?
- What software infrastructure is needed to use SLAng?
- I am a service client. How can I get an SLA from a provider?
- I am an application-service provider. How can I offer SLAs to my clients?
- I am a network service provider. What do I need to know about ASP SLAs?
- What happens when parties disagree about an SLA?
- SLAng is only monitorable. How can I force another party to pay a penalty if they are in violation of a SLAng SLA?
- I can't express what I need to in SLAng. What now?
SLAng in research
- How can I reuse the theory underpinning SLAng
- How can I extend SLAng?
- How can I implement SLA languages for other domains?
The SLAng open-source project
- How is SLAng licensed?
- What software is distributed for SLAng?
- How is the software for SLAng licensed?
- What software is planned for SLAng?
- How can I get involved with the development of SLAng?
- How can I support the SLAng project?
SLAs in general
- 1. What is an
SLA?
- The term SLA is much abused. We interpret the term strictly to mean the
contract or
part of a contract made between a service provider and client that assigns
penalties to undesirable behaviour on the part of either party, or the service.
Historically, SLAs usually constrain properties of a service, such as latency
or reliability, that may informally be grouped as Quality-of-Service (QoS)
properties. Therefore there is a tendency to call any specification of QoS
for a service an SLA. However, these should properly be called Service-Level
Specifications (SLSs).
The term SLA implies that an agreement exists between parties. Agreements
are only useful if they have an economic effect, and the obvious use for SLAs
is to mitigate the risk to the client that the service does not perform in
the way that they anticipate when they chose to start using it. The economic
importance of SLAs implies strong requirements on the content of such
agreements.
The principle benefit of using SLAs is that mitigating the risks in a
service provision scenario makes it possible for clients to more fully realise
the benefits of outsourcing, which potentially include reduced costs and
increased QoS. SLAs also allow discrimination between services on the basis
of quality and cost.
top
- 2. Why isn't this
legal advice?
- None of the information offered on this website should be considered to be
legal advice. This is because the authors of this information are not qualified
or insured to offer legal advice, and in many cases it would therefore be
illegal for us to do so (as far as we know).
Since this is the case, SLAng concrete SLAs should not be trusted as the sole
basis for any contractual agreement without also seeking qualified legal
advice. SLAng provides a means to represent concrete SLAs, and we have
attempted to provide vocabulary supporting likely combinations of financial
and technical arrangements. However, additional legal considerations may apply
before these can be considered legitimate contracts.
top
- 3. What is the
difference between an SLA and a contract?
- A contract is a legal instrument, and hence we are unqualified to advise
you on this matter. See the answer to Q2 for a further
explanation of this. However, we make a distinction between legitimate SLAs,
which may be contracts, or form part of contracts, and concrete SLAs that are
merely a representation of some SLA terms that may or may not be legitimate.
SLAng provides the capacity to represent concrete SLAs without in any way
guaranteeing that they will also be legitimate.
top
- 4. Why do we need
a language for SLAs?
- Trivially, we need a language for expressing SLAs because although we could
make informal verbal agreements as to the behaviour of services, we will
probably need to also record the details of any SLAs entered into, in case a
disagreement later arises that is pertinent to the SLA.
We make a distinction between concrete SLAs, and legitimate SLAs. A concrete
SLA is merely a representation of some SLA terms, whereas a legitimate SLA
reflects a genuine agreement between the parties, and satisifies all additional
legal requirements to form part of a contract. Because we can not offer legal
advice, we can not comment on the legal aspects of legitimate SLAs. Instead,
the focus of our work is on providing support for expressing concrete SLAs,
which may or may not ever form the basis for legitimate SLAs.
Why should we use a formal language, rather than a natural language for
expressing SLAs? As mentioned in the answer to Q1, the fact
that SLAs have financial components implies strong requirements for the content
of SLAs. The contents must be precise, not open to exploitation, and only refer
to events that are mutually monitorable by the client and provider. Meeting
these requirements may be difficult, raising the cost of preparing an SLA. By
using a formal language, some of the burden of expressing the SLA is passed to
the definition of the language. The language need only be defined once, in such
a way that all SLAs expressed in the language have some desirable properties,
and may then be reused for multiple SLAs, reducing the cost of their
preparation.
SLAs are also potentially relevant information for systems architecture,
where they can be used to guide adaption and deployment activities. Therefore
a machine-readable language for SLAs is desirable.
top
- 5. What are the
requirements for an SLA?
- SLAs have numerous requirements. Here we comment on the practical
requirements for SLAs if they are to be effective in mitigating the risk for
a client in entering a service-provision scenario. Legal requirements may
also apply if an SLA it to be legitimate. We may not comment on these and you
should possibly seek professional legal advice before entering into any SLA.
Most fundamentally SLAs must describe the behaviours of the system or the
parties that cause one party to have to pay a penalty to another, and they must
describe the penalty. However, in so doing an SLA should try to meet a number
of other requirements that increase the likelihood of it being an effective
basis for conflict resolution in the event of a disagreement between the
parties.
We call the capacity of an SLA to ensure that any relevant dispute is
resolved according to the original intent of the agreement the
protectability of the agreement.
A number of important requirements stem from the need for SLAs to be
protectable. For example, SLAs should also be precise and understandable, so
that disagreements concerning their original meaning are made more difficult.
SLAs should also preferably be monitorable, in that they
should only constrain events that are intrinsically visible to both parties,
or events that the parties can have monitored for them by parties that they
trust. Note that because SLAs have a financial component, parties may have
a disincentive to honestly report events relevant to penalties that they may
have to pay. Independently monitoring these events reduces the risk of
dishonest reporting, increasing the likelihood that a dispute will be
resolved according to the initial intent of the agreement.
A number of other requirements govern the practicality of using SLAs.
SLAs should also be as cheap to prepare as possible, and certainly cheap
relative to the value of the agreement being specified. Otherwise SLAs will
not be effective for risk management, as the cost of preparation could obviate
the benefit of receiving penalties.
SLAs should be non-exploitable, meaning that one party cannot by
their actions cause another party to have to pay a penalty unless the second
party is in breach of their obligations with respect to the agreement. Clearly
if an SLA is exploitable there will be a disincentive for some party to enter
it, rendering it ineffective for risk management.
top
- 6. What are the
requirements for an SLA language?
- The ideal SLA language would only permit the expression of SLAs meeting all
the requirements for SLAs in any scenario in which an SLA was desired. Such
a language may be impossible, due a conflict between the need for a high level
of expressiveness to accomodate all possible scenarios of interest, and the
need to verify properties of SLAs such as non-exploitability and monitorability.
Therefore, a number of specialised SLA languages for different domains may be
required.
In addition to the requirement that SLA languages must be able to express
a set of SLAs with good characteristics, a number of requirements may be
defined for the language itself. For example, if SLAs are to be processed in
any way automatically, it is desirable to have a language definition prepared
in such a way as to be useful in the engineering of SLA tools.
Because SLA languages assume part of the burden of expressing the meaning of
an SLA, the language definitions also inherit the requirements for precision and
understandability from the SLAs.
top
ASP in general
- 7. What is
Application Service Provision (ASP)?
- We use the term Application Service Provision to refer to the
provision of an electronic service across a network, by one organisation to
another, often in return for payment. A large number of middleware technologies
provide support for the communication that occurs between the parties during
service provisioning. These include Remote-Procedure Calls (RPC), Enterprise
JavaBeans, DCOM and .Net.
top
- 8. What are the
advantages of the ASP business model?
- Sometimes it is essential for companies to do business with other companies,
and ASP can be an efficient way to do it.
It is also certainly the case that the development and operation of
large-scale distributed systems is a complicated and costly affair. Advocates
of service-orientation suggest that outsourcing parts of these systems to
external providers allows organisations to concentrate on improving those
parts that remain. This specialisation argument also applies to the parties
providing the outsourced services, potentially allowing them to improve the
quality of the services they offer and reduce the price. Finally, a competitive
market in services may also be a driver of service quality.
top
- 9. What are the
risks with the ASP business model?
- Set against the benefits that outsourcing a service may provide are two
substantial risks.
When a client considers integrating an outsourced service into their
infrastructure, they must make two bets. The first concerns how well the
service will operate when it is operating at all. The service presumably has
some value to the client. If the service does not operate correctly, with
reference to the specification advertised to the client, then the client could
suffer financially. The second concerns the reliability of the service and
the lifetime of the service provision agreement. The client will frequently
need to make an investment to integrate a new service into their infrastructure.
Since the service presumably provides them with some value when it operates,
the client will expect to be able to recuperate this expense over the lifetime
of the service provision agreement. However, if the service fails to operate,
or the agreement is prematurely cut short, this opportunity may be lost.
top
- 10. How can SLAs
mitigate the risks with the ASP business model?
- SLAs are highly appropriate to the ASP scenario, since they can effectively
mitigate the risks involved.
By associating penalties with poor performance, SLAs can mitigate the
financial risk to the client that the service will not perform as expected.
An SLA can also be used to associate penalties with the reliability of the
service, or the early termination of the service provision agreement. In the
event of catastrophic termination of the service, the client could essentially
become a creditor of the provider. Although in many cases this will occur
due to the bankruptcy of the service provider, a small measure of protection is
still provided for the client.
top
SLAng
- 11. What is
SLAng?
- SLAng is a language for concrete service-level agreements currently
providing support for ASP SLAs. See an introduction to
SLAng for more details.
SLAng is defined using an EMOF metamodel, with embedded OCL constraints and
natural-language documentation in English. This makes it extremely precise as
well as being understandable.
SLAng is designed so that all SLAs expressed in the language are monitorable.
It includes semantics for administration, which is the process whereby the
parties to the SLA agree what penalties are to be paid. It expresses
constraints on the accuracy of reports used in administration that are
approximately monitorable.
SLAng can express a number of different types of constraints including:
reliability, timeliness, availability, data currency, data recovery
constraints and constraints on the lifetime of the agreement. The application
of these constraints can be varied according to schedules, the state of the
service or the state of an external system that is also monitorable by the
parties.
top
- 12. How can SLAng
be used?
- Ultimately, the intent is that SLAng be used to express the SLA parts of
service-provision agreements and contracts for service provision. Such contracts
will state, amongst other things, that the payment of penalties
should be in a manner consistent with the SLA interpreted according to the
semantics of the SLAng language.
Note that to be legitimate, such contracts will also need to meet legal
requirements upon which we are unqualified to comment. Please see
Q2 for a further discussion of this.
However, SLAng has not yet been extensively validated, either theoretically
or in practice. Therefore we do not recommend that it be used in real
SLAs with actual financial significance. The risk is that in the event of a
disagreement, the semantics of SLAng may be found to be ambiguous, or the formal
parts of SLAng, which are definitive of the language, may be found not to match
the informal parts that describe the design intent for the language, and may
have been the basis for deciding how to write the SLA. Therefore the SLA will
have failed to have captured the original intent of the parties with respect to
service provision and can therefore not be described as protectable.
Validation of the SLAng language is the subject of ongoing research and
development at UCL.
In the meantime, it may be appropriate to use SLAng to prototype SLAs that
may be required in the future. The innovative design of SLAng, incorporating
novel research results such as semantics for monitorability, administration
and the control of measurement error also make it a useful basis for future
research, and the development of SLA languages for other domains.
top
- 13. Why should I
not use SLAng for real SLAs yet?
- SLAng has not yet been extensively validated, either theoretically
or in practice. Therefore we do not recommend that it be used in real
SLAs with actual financial significance. The risk is that in the event of a
disagreement, the semantics of SLAng may be found to be ambiguous, or the formal
parts of SLAng, which are definitive of the language, may be found not to match
the informal parts that describe the design intent for the language, and may
have been the basis for deciding how to write the SLA. Therefore the SLA will
have failed to have captured the original intent of the parties with respect to
service provision and can therefore not be described as protectable.
top
- 14. Who has been
involved in the development of SLAng, and why?
- The original version of SLAng was developed by Davide Lamanna as part of the
IST project TAPAS. The goals of TAPAS were to produce trusted and QoS-aware
middleware for application-service provision.
When Davide quit the project, his work was taken over by James Skene, who is
now the principle developer of SLAng. During the remaining lifetime of the
TAPAS project and subsequently, James has developed SLAng as the principle topic
of his PhD, and the language has undergone very extensive revision, retaining
little but its original scope. James is, and Davide was, under the supervision
of Wolfgang Emmerich.
The TAPAS project involved a number of partner organisations who also
contributed to the development of SLAng. These include Addesso Gmbh., Newcastle
University and Bologna University.
top
SLAng in practice
- 15. What parties
need to be involved in an ASP SLA?
- SLAng SLAs are mutually monitorable. This means that both the client and
provider of the service should be able to observe all events over which
constraints are placed or have them observed on their behalf by a party that
they trust. The benefit of monitorability is that no party can
misrepresent the behaviour of the service to the other without the other
knowing.
SLAng achieves mutual monitorability be assuming that the parties are
technically adjacent to each other - in other words, separated only by an
interface which is reliable and over which messages take a negligable amount of
time to pass. At first glance this seems like a problematic assumption, as
application services will more usually be delivered across a network operated by
one or more internet-service providers, the delay of which is certainly not
negligible, and which may not be 100% reliable.
These factors may be reconciled by realising that network-service providers
may potentially offer ASP SLAs to the client themselves. In a three-party
scenario (client, provider and ISP) a safe system of
SLAs, in which parties must only pay penalties as a result of violations of
their own responsibilities, is possible to guarantee round-trip time and all
other SLAng constraints, using two SLAs, one offered by the ISP to the client,
and the other offered by the service provider to the ISP. In fact, an analysis
of all possible systems of SLAs in the ASP scenario reveals that this is the
only way to insure end-to-end QoS guarantees using SLAs that are at minimum
mutually monitorable. If more than one ISP administers the network a chain
of SLAs can be used.
This result will probably be a brake on the widespread adoption of SLAng
in the future, as ISPs are not currently used to offering ASP SLAs. However,
it is our opinion that SLAs that are anything less than mutually monitorable
do not adequately mitigate the risks in service provision.
Therefore, the parties that must be involved in an SLA are always
a technically adjacent client and service provider. However, the network
service provider will perform the role of the ASP service provider in an
SLA defined for the client's interface, and the role of the client in an
SLA defined at the service provider's interface.
top
- 16. What
requirements must my service meet for me to use SLAng to offer SLAs?
- The requirements that a service must meet depend on the constraints that are
included in a SLAng SLA.
If reliability constraints are included then the service must benefit from
a technical specification of adequate precision and understandability that the
parties can agree for any service usage whether it has been successful.
If data-currency constraints are used or reliability constraints are used for
a stateful service then the service must implement transactions and define a
timeout for all operations. This allows the parties to distinguish between
overdue requests that are assumed to have modified the state and those that
should have left the state unchanged. This then allows reliability and
data-currency assessments on the results of subsequent requests.
top
- 17. What software
infrastructure is needed to use SLAng?
- SLAng SLAs do not explicity require any additional software infrastructure
to that required to operate the service constrained by the SLA. However,
during the administration of the SLA, both the client and the provider are
required to produce logs of the behaviour of the service. These logs are
reconciled and the reconciled log is used as the basis for the calculation of
violations and hence penalty payments. Clearly the production of these logs
will require monitoring infrastructure.
When reliability constraints are used, for reasons of practicality, the
monitoring infrastructure may also require the ability to recognise service
responses not conforming to the specification of the service.
top
- 18. I am a service
client. How can I get an SLA from a provider?
- The negotiation of an SLA should be part of the negotiation of a broader
Service-Provision Agreement (SPA) or contract which will also include
details such as regular fees for the provision of the service and other
financial arrangements.
Note that if you receive a service for free then there will be no incentive
for the service-provider to provide you with an SLA. Moreover, if the
service-provider holds a monopoly on the service being provided, they may also
require that no SLA is made, or be able to negotiate much weaker constraints.
Note that if you pay for a service but do not have an SLA, there are other
ways to mitigate your risk than the use of an SLA. You may require that your
provider submits to due-diligence inspections or other management oversight.
Alternatively you may feel that your risk is reduced by your own financial might
relative to the service provider, by market forces, or by the provider's regard
for their own reputation.
If an SLA is a possibility you should carefully consider what guarantees it
offers and how these will be recorded in a concrete SLA that forms a record of
the agreement.
In our opinion, the basic purpose of an SLA is to mitigate the financial
risk to you the client in the service provision agreement. Therefore, an
SLA should describe not only what quality-of-service will be provided to you,
but the consequences in terms of penalties for the provider if it is not.
Otherwise the SLA offers no value to you the client. If you expect to incur
significant integration costs, or assume additional financial risks over the
lifetime of the service-provision agreement, should should also consider
whether the SLA offers you compensation in the event of the early termination
of the agreement by the provider, or as a result of an intolerable deterioration
in the provided quality-of-service.
You should also take care to ensure that the guarantees that are being
offered are the ones that you want. You will be concerned with the
quality-of-service as you experience it at your interface to the network. If
an application-service provider is offering you guarantees at their interface
to the network, these will not necessarily be useful to you as you will also
have to accomodate the performance of the network. Also, you may not be able
to monitor these guarantees, meaning that in the event of a disagreement over
the delivered quality-of-service, you may find it hard to prove that the SLA has
been violated. To obtain monitorable SLAs you may need to deal with the network
service provider, who can in theory act as a reseller of the application service
at your network interface, and is thus capable of guaranteeing
quality-of-service for the complete round-trip.
In considering how the SLA is recorded, you should take care that the
agreement is captured in a precise and understandable manner, so that in the
event of a disagreement, the original agreement can be interpreted and will
state unambiguously what should occur. SLAng aims to support these
requirements, and is also suitable for expressing SLAs that are monitorable
(as part of the agreement, you agree that the events under discussion are
monitorable; this is of course only valid if they really are monitorable).
However, SLAng is still undergoing validation, so we do not recommend that you
use it for real SLAs. Also, you may need to obtain legal advice from a
qualified source before entering an SLA.
top
- 19. I am an
application-service provider. How can I offer SLAs to my clients?
- The negotiation of an SLA should be part of the negotiation of a broader
Service-Provision Agreement (SPA) or contract which will also include
details such as regular fees for the provision of the service and other
financial arrangements. As a service provider you may wish to define
commodity SLAs that can be offered to different classes of customer. Note that
at present we do not recommend that you use SLAng to define your SLAs, since
the language has not yet adequately been validated. Also, you may need to
obtain legal advice from a qualified source before entering into an SLA.
As a service provider, you should understand that your clients are going to
require end-to-end QoS guarantees. If you control the network over which your
service is delivered to the client, it will be possible for you to safely
undertake to pay penalties if these are not met. Otherwise, it will probably
be necessary for you to partner with a ISP, who will resell your service to the
client, in the course of which insuring the performance of the network.
As a service provider you have the opportunity either to provide pre-defined
commodity SLAs to your clients, or to negotiate these individually. In either
case you may have to involve an ISP reseller of your service in the
negotiations.
top
- 20. I am a network
service provider. What do I need to know about ASP SLAs?
- On the face of it, network service providers, or ISPs, provide services
at a lower level of abstraction than application-services layer. However, our
theoretical results indicate that the only way in which end-to-end QoS
guarantees may be provided to the client of an application service in a manner
that is both safe and monitorable is by the ISP reselling services.
Therefore, ISPs should be prepared to act as service marketplaces. You, the
ISP will offer SLAs to clients on the edges of your network. In turn, you will
enter into SLAs guaranteeing that service providers connected to your network
will provide you with adequate QoS to service your clients. This may be done
on a bulk basis, or using SLAs paired with your client SLAs.
You will wish to monitor the performance of the services provided to you, and
the behaviour of clients, in order to monitor your SLAs. You will therefore
have to consider how monitoring technologies can be embedded in the edges
of your network.
Where services must be delivered across multiple networks, you will need to
enter into SLAs with the networks with which you connect.
top
- 21. What happens
when parties disagree about an SLA?
- Parties can attempt to disagree about an SLA in a number of ways.
Parties may disagree about the original meaning of the SLA. If this occurs,
and the SLA was expressed using SLAng, you should refer to the original
definition of SLAng, which should precisely and unambiguously document the
meaning of the SLA.
Parties may disagree about what happened that is relevant to the SLA. Since
SLAng SLAs are monitorable, parties cannot misrepresent what happened without
their partner being aware of it (if they have been paying attention). Therefore
the likelihood of this happening is reduced.
In any case, the parties may be able to resolve their differences by
referring to the original SLA document, by exchanging evidence, or through
negotiation.
Note that in the event of an irreconcilable disagreement, the parties will
have to achieve satisfaction through some mechanism, perhaps legal (although
we cannot advise on legal matters), external to the SLA.
top
- 22. SLAng is only
monitorable. How can I force another party to pay a penalty if they are in
violation of a SLAng SLA?
- First, it is a mistake to think that an SLA compels anybody to do anything.
If the SLA is a contract, or part of a contract, then the law may apply
pressure to a party as a result, although we are not qualified to advise on
this.
What SLAs do do is capture an agreement in a precise way. SLAng insists that
the things you agree on in a SLAng SLA are monitorable, so you can see whether
the other party is meeting the agreement. However, they are only monitorable
by you, as a party to the SLA, and not necessarily by anyone else. If you
therefore seek to prove that your account of events is true and that account
of your peer in the agreement is false, then the only assistance you will
get from the agreement is the ability to assert that you were capable of
gathering such evidence, not that you have necessarily done so faithfully.
SLAng SLAs are therefore not inherently arbitratable. However, they do
allow you to detect cheating partners, and hence make cheating less desirable.
Also, if you can provide access to your monitoring infrastructure to a third
party in a manner that they trust, they will be able to back your claims in
the event that your partner in the agreement tries to cheat.
top
- 23. I can't
express what I need to in SLAng. What now?
- Although ASP services all look very similar according to our definition,
SLAs for such services can still be very various. This is because the
requirements that the client has for a service may vary according to conditions
that are external to the service. Enabling the description of all of these
conditions would require a general-purpose modelling language, such as the
combination of EMOF, OCL and English that is used to define SLAng. This
would greatly increase the complexity of the language specification, so we
have so far avoided providing these facilities.
Therefore, you should consider either extending SLAng or implementing a
new language. See the answers to Q25. How can I extend SLAng?
and Q26. How can I implement languages for other domains?
top
SLAng in research
- 24. How can I reuse the theory underpinning SLAng
- Read the academic papers related to SLAng
and use citations in the normal way. We would suggest that the most significant
contributions of this work are:
- The identification of risk mitigation for the client as the principle purpose
of an SLA.
- The elaboration of an explicit set of requirements for SLAs.
- The adoption of a precise yet understandable meta-modelling formalism for
the definition of the language.
- The identification of monitorability as an important requirement for SLAs,
the provision of a method for the analysis of monitorability in systems of
SLAs for any given situation, and the identification of the most monitorable
system of SLAs for the three-party ASP scenario.
- An extension of the theory of monitorabilty to accomodate measurement
error, resulting in the notion of approximate monitorability.
- The definition in SLAng of a set of constraints that are monitorable.
top
- 25. How can I extend SLAng?
- SLAng is defined using a combination of three languages, EMOF, OCL and
English. Under the Creative-Commons Attribution 2.5 license you may produce
derivative works from the SLAng language specification provided you acknowledge
UCL as the author of the original work.
You may wish to extend SLAng for two main reasons. SLAng may not be able
to express variations in constraints according to some external conditions which
you will need to model. Alternatively, you may wish to express SLAs over
different kinds of services.
This level of expressiveness is available at the meta-level, due to
the languages chosen to define SLAng. Therefore, if you require more
expressivity then we suggest you define an extension to the language. In
principle, this should be no harder than defining the conditions that you
required in SLAng, if SLAng were totally general purpose. You will
be obliged to define your requirements initially in terms of types of objects
and events in the language extension, and then in terms of particular objects
and events in an actual SLA. However, taking a more general approach will also
allow you to reuse your extension across multiple SLAs, if this is beneficial.
Further discussion of the approach taken to define SLAng is available in
the introduction to SLAng. You should also review the
academic literature on the subject.
If you are extending SLAng for ASP constraints, you should consider how the
extension will effect the protectability of any agreements expressed in the
extended language. Will the agreements still be monitorable, and how will
measurement error be handled? Also, you should be careful to model the
semantics of any changes that you make to the syntax of SLAng, or the meaning
of these elements could be brought into question in the event of a disagreement
over an SLA.
top
- 26. How can I
implement SLA languages for other domains?
- Languages for SLAs for other domains may be implemented in a number
of ways:
- You may choose to extend SLAng.
- You may choose to use the same approach used to define SLAng, but create
a completely new language.
- You may choose to use some other approach to defining the language.
The advantages to extending SLAng include the possibility of reusing some
generic parts of the specification, such as the general handling of measurement
error and the semantics for SLA administration, which are likely to be
relevant to all SLAs that are at best monitorable, but not inherently
arbitratable, as is the case for ASP SLAs. You will also accrue benefits due
to the approach used to define SLAng.
The advantages to adopting the same approach used to define SLAng are a good
deal of precision in the definition whilst still retaining a tolerable level
of understandability. Any language specification produced in this way will also
be machine readable and a potentially useful artefact in the generation of
software, for example, using the code-generation capabilities of the
UCL MDA tools.
The advantages to using a different approach will be the opportunity to
avoid some mistakes that we may have made. We don't know what these are
however, so this is not guaranteed, and you will also have the opportunity to
make new mistakes of your own.
top
The SLAng open-source project
- 27. How is SLAng licensed?
- The SLAng language specification is licensed under a Creative Commons
Attribution 2.5 license. The copyright holder is UCL. This means that you may
use the specification commercially, and you may also prepare derivative works
provided that you acknowledge UCL as the author of the original work.
Clearly any extended or refactored language for SLAs derived from the
specification will be a derived work. It is not clear whether SLAs expressed
using the language should be considered to be derivative works. However:
- You are not required to make derivative works public.
- In order to be unambiguous, SLAs should reference the specification of the
language in which they are written (otherwise after making the agreement, the
parties could disagree about how the agreement should be interpreted). If this
specification is derived from SLAng it must acknowledge UCL as the authors of
the original work. We therefore consider the reference to the specification in
the SLAs to be adequate acknowledgement of the authorship of the original
language if the SLAs are considered to be derivative works. If such a reference
is not included then the language of the SLA is either not derived from SLAng or
you are writing a bad SLA which should be not be associated with SLAng.
- The exception to the previous point is: if you include parts of the SLAng
language specification in an SLA, the SLA is clearly a derivative work.
top
- 28. What software
is distributed for SLAng?
- At the time of writing, we make available two versions of an editor for
SLAng SLAs. Both versions are automatically generated from the SLAng language
specification using the UCL MDA
tools. One version provides a user-interface using the Java Swing library.
The other version is a plugin for the Eclipse
IDE.
top
- 29. How is the
software for SLAng licensed?
- The SLAng software is licensed under the Mozilla Public License (MPL), with
an option to relicense to GPL or LGPL. The copyright for the software is
owned by UCL. Under the MPL you may incorporate the software into new
applications, providing that you acknowledge UCL as the author of the original
software. On a per-file basis, you must also make publicly available any
modifications that you make to the program source code, although you do not
have to make public code that you integrate with the software except where
otherwise required to do so.
We do not regard programs designed to operate with the SLAng language as
works derived from the SLAng language specification for the purposes of
interpreting the Creative Commons license. The exception to this is any
translation of the specification which is then used as a definitive source for
the interpretation of an SLA, even if that language may be considered to be a
programming language. This means that you may write software that is not
derived from our software, but is designed to work with SLAng SLAs, without
any licensing restrictions, provided that software does not supercede the role
of the SLAng language specification.
top
- 30. What software
is planned for SLAng?
- In the future we may look at developing monitoring software that is
compatible with the constraints in SLAng SLAs. If you are interested in this,
please contact us.
top
- 31. How can I get
involved with the development of SLAng?
- Please contact us.
top
- 32. How can I
support the SLAng project?
- SLAng is currently supported by research project funds. Consequently its
emphasis is on academic research. If you are interested in cooperating with
UCL to extend this work, possibly within the framework of future research
projects, then we will be pleased to hear from you.
At present the SLAng open-source project does not support full-time
developers. If you are interested in commercialising SLAng technology within
the framework of the open-source project, then we will also be pleased to
hear from you.
The SLAng project does not require piecemeal donations at present.
top
|