Summary
Interfaces, contracts, methods, operations, entities, objects, and tables, oh my! The OSID Specification defines its own language solely in reference to itself. Developers will look at it from the OSID Language Binding perspective. Others will import concepts from what they have worked with in databases, web services, or MVC-based platforms. The result is a mash of terms that matters once in a while.
| Table of Contents | ||
|---|---|---|
|
Perspectives
The OSID Perspective
The OSID Specification schema (X-OSID) defines:
...
| Gliffy | ||||||
|---|---|---|---|---|---|---|
|
The Java Perspective
- package: a bunch of interfaces, classes, enums, annotations, and other sub-packages
- enums: constants and methods
- interface: a bunch of method definitions
- class: a pile of attributes that include methods and may implement one or more interfaces
- object: an instance of a single class
- method: something that is invoked with parameters, returns a value or throws an exception
- parameter: defines the type supplied to a method as an argument, can be a class, interface, enum, or a primitive
- return: defines the type of return value, can be a class, interface, enum, primitive, or void
- primitive: boolean, byte, char, double, float, int, long, short
- exception: an event that occurs during the execution of a program that disrupts the normal flow of instructions such as SecurityException or NullPointerException
The OSID Java Binding Perspective
The OSID Specification is transformed into the OSID Java BindingTerminology. The resulting merge creates the following OSID terminology in Java:
...
Concepts like classes and objects disappear. Others like parameter and primitive have a narrower connotation than what a Java developer would be accustomed. An OSID Language Binding can hide certain aspects of the OSID Specification that are conceptually relevant because it is an interpretation. The Java is pretty close, but can cause some head scratching about why something was done one way or the other.
...
terminology incompatible with the OSIDs
API
OSIDs are consumed by OSID Consumers in software. OSIDs are Application Programming Interfaces.
...
The term contract is often used in service designs to distinguish an interface from a message structure or DTO. The message structure and DTO are considered data while the contract defines the operations on that data. OSIDs define the agreement between service consumers and service providers. In the OSID world, most everything in the specification can be considered a contract, i.e. "The AgentList is a contract."
DTO (DAO, Bean, Domain Object)
A Data Transfer Object is used to transfer bags of data values. However, OSIDs are interfaces into OSID Providers. OSID Providers may be dynamic and DTOs are static.
...
OSIDs have historically been referred to as specifications. The difference between a standard and a specification is confusing at best. Typically, one incorporates standards into specifications while others refer to specifications as a type of standard. Some believe a standard has accreditation associated with it, as in meets the standard while others perform quality assurance based on a specification. Some believe that a standard is based on a consensus process but a specification is not. However, most use these terms interchangeably today and more often they get strung together. Who knows.
See Also
About OSIDsAnchor About OSIDs About OSIDs - OSID Language Binding
OSID Java BindingAnchor OSID Java Binding OSID Java Binding - osid.OsidObjects