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.
...
terminology incompatible with the OSIDs
API
OSIDs are consumed by OSID Consumers in software. They 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
Boundary can be a cool word but is a bit slippery. In the OSIDs, it may also refer the line between an OSID Consumer and an OSID Provider, i.e. "The details of the Asset are opaque through the OSID boundary."
...
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 contractual agreement between service consumers and service providers. In the OSID world, most everything in the specification is 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 through system layersvalues. However, OSIDs are interfaces into OSID Providers. OSID Providers may be dynamic and DTOs are static.
Most DTOs are bi-directional. The same object is often used for retrieval and update with setters and getters. OSIDs are just piles of method signatures organized in interfaces.
...
define different interfaces for these operations making most interfaces, except for OsidPrimitives, uni-directional.
However, OsidObjects are not domain or business objects either. Their interfaces define methods to access information and relations. Actions are defined in OsidSessions. This is much more like a DAO/DTO model than a pure object oriented model as it allows for better defined integration points. The absence of setters in the OsidObject interfaces, the inability to send an OsidObject into an OSID Provider, and the extensible OsidRecord mechanism make these analogies ripe for confusion.
Endpoint
In the web service world, an endpoint is essentially a URI that identifies a service provider and to which data will be serialized. In the OSID world, there are no URIs and serialization is handled by an OSID Consumer or OSID Provider.
However, the concept of service endpoints can be brought into the OSIDs. The first identifier is the implementation name of an OSID Provider given to OsidRuntimeManager to get an OsidManager. This can be considered the first service endpoint. Or perhaps an OsidProxyManager was requested instead. This can be considered an alternate service endpoint. In OSIDs, to get a service endpoint means to get an interface.
From there, OsidSessions are requested. Each OsidSession can also be considered endpoints. Then so can OsidLists and OsidObjects.
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
Message Structure
...