On Wed, May 20, 2009 at 8:11 AM, John Bywater <[email protected]> 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 _______________________________________________ okfn-discuss mailing list [email protected] http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss
