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.
...
Concepts like classes and objects disappear. Others like parameter and primitive have a narrower connotation than what a Java developer would be accustomed. And the definition of "osid" gets fuzzier.
Terminology Issues
These are a list of terms that often get tossed around. Mixing terminology across frameworks will always cause confusion. When a term is in direct conflict with the OSID Specification or its few basic concepts, it's a good idea to lose it and adapt. This can be difficult when trying to learn something by comparing it to another thing something else you already know.
Others terms are more conceptual in nature and we tend to use them informally.
...
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 a special kind of OsidObject called OsidRelationship. An OsidRelationship is an entity relation between two OsidObjects that exists for a period of time. Not every entity relation between two entities is an OsidRelationship.
Service (OSID, Package)
The term "service" doesn't have any formal definition in the OSID Specification. It's tossed around because this is a Service Design Methodology .
Standard
and OSIDs are specifications for how OSID Providers provide services to OSID Consumers.
However, it doesn't mean anything in particular. 't OSID may define other OSIDs within it and each OSID defines OsidManagers and OsidSessions, each which provide a service. Then, each OsidObject as an interface into an OSID Provider is also a service. Once again, the OSIDs go out of their way to confuse conventional classifications.
The term OSID can also be over-interpreted. OSID is an acronym for Open Service Interface Definition. It is the interface definition, or specification itself, not any implementation of it. Thus the phrase "OSID Provider."
However, OSID is often used to describe an entire package, i.e. "The Authorization OSID" or "The Billing OSID." OSID isn't used for any particular interface but rather a set of interfaces. But some OSIDs contain other OSIDs, and it tends to mean just the top level, i.e. "The Course OSID" vs. "The Course Registration OSID."
OSIDs do not formally define the term package. Packages seem to be implied by the naming of the interfaces (osid.mapping.Location) and the OSID Java Binding takes that literally into the Java world. However, not all Java packages are OSIDs as can be seen with the OsidRecord interfaces, i.e. osid.personnel.records.PersonRecord is part of the Personnel OSID.
The ERD below captures the difficulty in moving among all of these terms as there are no direct 1:1 mappings anywhere. Using the more specific OSID terminology is helpful when precision is needed.
| Gliffy | |||
|---|---|---|---|
|
...
|