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.
...
Others terms are more conceptual in nature and we tend to use them informally.
terminology compatible with OSIDs shaky terminologywith caveats
terminology incompatible with the OSIDs
API
OSIDs are consumed by OSID Consumers in software. OSIDs are Application Programming Interfaces.
However, OSIDs are designed around integration points and abstracted to promote interoperability in software by moving configuration and control from consumers to providers. Many APIs are to utility libraries that allow their applications to more easily command what the library will do, such as storing data in a HashSet, building a DOM tree, when to send data over the wire. So, not all APIs make good service contracts (in fact few are designed with this intent).
Attributes & Data Fields
...
An OSID Provider may likely employ data objects to satisfy the contract of an OsidObject. An OSID Consumer sees this through the window of the interface. The OSID Consumer may do whatever it likes with this information, including referring to them as simple data elements. However it can be an impediment when trying to understand the nature and applications of these interfaces whose implementation may require an underlying OSID Provider rather than a pull from a database table, for example.
Boundary (Service Boundary)
...
Many listeners will assume it means the scope of a service, i.e. "There's a service boundary between authentication and authorization." However, jumping laterally between two OSIDs also implies a movement between OSID Providers. This interpretation would not be wrong but it may fail to clarify exactly what is meant.
Contract (Service Contract)
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.
...
Because OSIDs abstract away issues of serialization and protocol, we are just left with interface definitions that are utilized directly in software. The SOA concepts of endpoint and contract still apply but without the web services part. SOA - WS = OSIDs
Entity (Service Entity)
In the modeling world, entity is simply a fancy way of saying thing. They are the boxes in an entity model and often correspond to OsidObjects in the OSIDs.
...
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 and OSIDs are specifications for how OSID Providers provide services to OSID Consumers.
...