[okfn-discuss] OSSD and Service Orientation

Wed May 20 22:22:58 UTC 2009

On Wed, May 20, 2009 at 8:11 AM, John Bywater
<john.bywater at appropriatesoftware.net> wrote:
> 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.
> """

I prefer the current version.  There is no point defining "web
service" here.  "web-API" covers that case.

> 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. :-)

Agree on the last sentence.

Mike