Open service interface definition: Difference between revisions

Revision as of 13:56, 14 October 2016

Latest revision as of 06:51, 18 July 2023

(10 intermediate revisions by 7 users not shown)

Line 1:

{{no footnotes|date=July 2023}}

'''Open Service Interface Definitions''' ('''OSIDs''') are programmatic interface [[specifications]] describing services. These interfaces are specified by the [[Open Knowledge Initiative]] ('''O.K.I.''') to implement a [[Service-Oriented Architecture]] (SOA) to achieve [[interoperability]] among applications across a varied base of underlying and changing technologies.

An '''Openopen Serviceservice Interfaceinterface Definitionsdefinition''' ('''OSIDsOSID''') areis a programmatic interface [[specifications]]specification describing servicesa service. These interfaces are specified by the [[Open Knowledge Initiative]] ('''O.K.I.'''OKI) to implement a [[Serviceservice-Orientedoriented Architecturearchitecture]] (SOA) to achieve [[interoperability]] among applications across a varied base of underlying and changing technologies.

To preserve the investment in [[software engineering|development]], program logic is separated from underlying technologies through the use of software interfaces each of which defines a contract between a service [[consumer]] and a [[service provider]]. This separation is the basis of any valid SOA. While some methods define the service interface boundary at a protocol or server level, '''OSIDs''' place the boundary at the application level to effectively insulate the consumer from [[Protocol (computing)|protocols]], server identities, and utility libraries that are in the ___domain to a service provider resulting in software which is easier to develop, longer-lasting, and usable across a wider array of computing environments.

== Rationale ==

'''OSIDs''' assist in [[software design]] and development by breaking up the problem space across service interface boundaries. Because network communication issues are addressed within a service provider and ''below'' the interface, there isn't an assumption that every service provider implement a remote communications protocol (though many do). OSIDs are also used for communication and coordination among the various components of complex software which provide a means of organizing design and development activities for simplified [[project management]].

To preserve the investment in [[software engineering|development]], program logic is separated from underlying technologies through the use of software interfaces each of which defines a contract between a service [[consumer]] and a [[service provider]]. This separation is the basis of any valid SOA. While some methods define the service interface boundary at a protocol or server level, '''OSIDs''' place the boundary at the application level to effectively insulate the consumer from [[Protocol (computing)|protocols]], server identities, and utility libraries that are in the ___domain to a service provider resulting in software which is easier to develop, longer-lasting, and usable across a wider array of computing environments.

'''OSIDs''' assist in [[software design]] and development by breaking up the problem space across service interface boundaries. Because network communication issues are addressed within a service provider and ''below'' the interface, there isn't an assumption that every service provider implement a remote communications protocol (though many do). OSIDs are also used for communication and coordination among the various components of complex software which provide a means of organizing design and development activities for simplified [[project management]].

OSID providers (implementations) are often reused across a varied set of applications. Once software is made to understand the interface contract for a service, other compliant implementations may be used in its place. This achieves [[reusability]] at a high level (a service level) and also serves to easily scale software written for smaller more dedicated purposes.

Line 9 ⟶ 13:

An OSID provider implementation may be composed of an arbitrary number of other OSID providers. This layering technique is an obvious means of [[abstraction]]. When all the OSID providers implement the same service, this is called an ''adapter'' pattern. Adapter patterns are powerful techniques to federate, multiplex, or bridge different services contracting from the same interface without the modification to the application.

==Service definitionsList ==

* Agent

* [[Agent Open Service Interface Definition]]

* [[Assessment Open Service Interface Definition]]

* [[Authentication Open Service Interface Definition]]

* [[Authorization Open Service Interface Definition]]

* [[CourseManagement Open Service Interface Definition]]

* [[Dictionary Open Service Interface Definition]]

* Filing

* [[Filing Open Service Interface Definition]]

* Grading

* [[Grading Open Service Interface Definition]]

* [[Hierarchy Open Service Interface Definition]]

* Logging

* [[Logging Open Service Interface Definition]]

* [[Messaging Open Service Interface Definition]]

* [[Repository Open Service Interface Definition]]

* [[Scheduling Open Service Interface Definition]]

* [[Workflow Open Service Interface Definition]]

== See alsoReferences ==

* [[Open Knowledge Initiative]]

*Baving, T., Cook, D., Green, T. [http://simba.cs.uct.ac.za/~honsproj/cgi-bin/view/2003/baving_green.zip/baving_green/coursetool/downloads/paper.pdf Baving, T., Cook, D., Green, T. ''Integrating the Educational Enterprise'']. 2003.]

==References==

* [http://www.okiproject.org/documents/OKIandIMS-WiresAndSocketsRevisited.pdf Kraan, W. ''O.K.I. and IMS, wires and sockets revisited''.]

*Baving, T., Cook, D., Green, T. [http://simba.cs.uct.ac.za/~honsproj/cgi-bin/view/2003/baving_green.zip/baving_green/coursetool/downloads/paper.pdf ''Integrating the Educational Enterprise'']. 2003.

*Kraan, W. [http://www.okiproject.org/documentslibrary/OKIandIMS-WiresAndSocketsRevisiteddoc_41.pdfhtml ''O.K.IKahn, J. and IMS,''Screen wiresShots: andRepository socketsOSID revisitedInteroperability'']. 2005.]

*Kahn, J. [http://www.okiproject.org/libraryfilemgmt/doc_41visit.php?lid=44 Kumar, V., Merriman, J., Thorne, S.html ''ScreenOpen Shots:Knowledge RepositoryInitiative OSIDFinal InteroperabilityReport'']. 20052004.]

*Kumar, V., Merriman, J., Thorne, S. [http://www.okiproject.org/filemgmt-data/visitfiles/RepositoryDevelopersGuide-v1.php?lid=440.pdf ''OpenKahn, KnowledgeJ. Initiative Final''Repository ReportDeveloper's Guide'']. 20042006.]

* Kahn, J. [http://www.okiproject.org/filemgmt-datadocuments/files/RepositoryDevelopersGuide-v1.0OKIManagingComplexity_rel_1_0.pdf Kahn, J. ''RepositoryManaging Developer'sComplexity and Surviving Technology GuideChange'']. 20062005.]

* Kahn, J. [http://www.okiproject.org/documents/OKIManagingComplexity_rel_1_0.pdf ''Managing Complexity and Surviving Technology Change'']. 2005.

== External links ==

* [http://osid.org OSID Web Site]

* {{Official website|http://osid.org}}

* [http://wiki.okapia.net OSID WIki]

* [https://okapia.atlassian.net/wiki/spaces/OSID/overview OSID wiki]

* [https://web.archive.org/web/20081226161331/http://www.phpoki.org/ PHP OSIDs]

{{internet-stub}}

[[Category:Software architecture]]