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. _______________________________________________ okfn-discuss mailing list [email protected] http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss
