[okfn-discuss] OSSD and Service Orientation

[John Bywater]

Hi All,

Not sure what the change management process is for the Open Software
Service Definition (OSSD), but after reviewing literature on Service
Orientation, it appears that adjusting the OSSD to be more in line with
software industry language and behaviour would make lots of sense.

I have two issues. Firstly, we could establish better the distinctions
between a service, a software service, and a Web service. These terms
could then be used with more confidence in the definition.

CURRENT VERSION
"""
The Open Software Service Definition defines 'open' in relation to
online (software) services.

An online service, also known under the title of Software as a Service
(SaaS), is a service provided by a software application running online
and making its facilities available to users over the Internet via an
interface (be that HTML presented by a web-browser such as Firefox, via
a web-API or by any other means).
"""

It might be better to have something like:

SUGGESTION
"""
The Open Software Service Definition defines 'open' in relation to Web
and other software services.

A service is functionality that is specified in agreements between the
provider of the functionality and its consumers. The implementation of a
service does not have to be automated and could consist of purely human
activity.

A software service is a type of service that is implemented by software
and that offers one or more operations. A Web service is a software
service that uses Web services technology, such as the XML-based
industry standards and specifications.
"""

Secondly, the OSSD could itself be presented as a service, so as to be
made more usable within third-party Service Level Agreements, and also
more open to feedback and development. This merely amounts to
understanding something of how Application Service Providers (or their
Service Level Managers) are tending to provide software services, and
therefore how they might be inclined (and want) to provide an Open
Software Service.

What's new with software orientation is that integration and reuse occur
at run-time, not design-time. Services are therefore critically
dependent on other services, and an agreement about the level of a
service cascades down to include agreements about the service levels of
the dependencies.

So, when addressing the open aspects of an Open Software Service, a
service provider would firstly treat each independent aspect as an
independent service. At this point, they would find it useful to copy
(or derive from) a standard "open software service source code
acquisition SLA" pattern/template establishing precisely how the
service's codes can be acquired. She could do similarly for the
service's data, indicating availability, data latency, or other quality
of service issues. The code acquisition SLA and the service data SLA
would then slot into the aggregation of SLAs that increasingly form the
agreements between providers of software service and consumers. Any
issues with the open aspects of Open Software Services could then bubble
up to the Service Code Provider, or the Service Data Provider, or the
Open Software Service SLA Template Provider, according to the issue.

I don't think Web Buttons scale in quite the same way. :-)

Best wishes,

John.