Versions Compared

Old Version 28

changes.mady.by.user Tom Coppeto

Saved on

compared with

New Version Current

changes.mady.by.user Tom Coppeto

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Summary

Interfaces, contracts, methods, operations, entities, objects, and tables, oh my! The OSID Specification defines its own language solely in reference to itself. Developers . The vocabulary is defined and built upon without importing words from outside the OSIDs.

However, developers will look at it from the OSID Language Binding perspective. Others Many will import concepts from what they have worked with in databases, web services, or MVC-based platforms. The result is can be a mash of terms that matters once in a whilegets in the way of understanding the OSIDs and how they can be applied.

Table of Contents
excludeSummary

Perspectives

The OSID Perspective

The OSID Specification schema (XS-OSID) defines:

  • osid: a bunch of interfaces an enumerations
  • enumeration: a list of values
  • interface: a bunch of method definitions
  • method: something that is invoked with parameters, returns a value or an error
  • parameter: defines what may be supplied to a method as an argument, can be an interface, enumeration, or a language primitive
  • return: defines what may be returned from a method, if anything, can be an interface, enumeration, or a language primitive
  • language primitive: boolean, byte, cardinal. decimal integer, object. string, timestamp
  • error: an error from a method such as OPERATION_FAILED or ILLEGAL_STATE
  • compliance: a compliance statement for a method - mandatory or optional

...

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. The specifications on osid.org display the OSIDs, not the OSID Java Binding.

Terminology Issues

These are a list of terms that often get tossed around. Mixing terminology across frameworks will always result in confusioncomplacent agreements over different things and heated debates over the same thing. 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. Other terms are kinda similar, but not equal. Level setting can be difficult when trying to learn something by comparing it to something else you already know.

...

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."

(error) 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. 

...