Notes on Defining a DAL Standard

When embarking upon the definition of something as profound and all-encompassing as a network application standard, due consideration must be given to all aspects of the problem it seeks to address. It is particularly important to have a context within which the standard is defined and evolved. This page proposes such a context.

Scoping the proposed Standard

Typically within the DAL-WG we define Protocols to facilitate interoperability between similar Services and their Clients (see below). Before we can do that, we need to consider the system as a whole and relationship between the various elements therein such as the Clients and Services and the Contract that binds them before we can decide what (and how many) Protocols will be required. Sometimes we also define the payload that is exchanged between Client and Service (e.g. Cone Search, SIA, SSA etc), but often it is other groups that make these decisions (e.g. VOQL-WG are defining the ADQL payload etc). It is important that we observe the distinction between these various system elements.

Therefore the scope of the whole must be defined and bounded if the standard is to have any hope of emerging fully formed and within a reasonable time frame. It is OK if the standard evolves over time, but the basic requirements for each evolution must be set.

One successful way to scope this whole is through the production of a series of Use Cases that fully encapsulate the scenario being addressed and the mechanisms used to address it. Defining the requirements must also be done within the context of the architecture of the infrastructure itself.

With the scope defined, attention can be focused on the definition and adoption of the protocol and possibly the payloads in question.

The Use Cases provide the absolute scope from which the protocol is defined and all use cases that are formally recorded as backing for the standards must have sponsors within IVOA.

Architecture

Taking a Table Access service as an example, such a system might have the following structure:

The service:

• Provides dataset querying functions in response to requests from the client
• Offers interfaces to the client that satisfy the Use Case Suite defined when the Table Access system was analysed
  • These include TAP for managing ADQL queries
  • SimpleTAP for key-value pair querying
  • Information-schema provision of content metadata
• As part of its general IVOA contract, it offers the VOSInterface
  • This provides service and standardised content metadata in VOResource format
  • Other features as defined by GWS-WG in their VOSI definition
• Implements the Protocols needed to support the above

The Client:

• Creates Payloads that suit its specific Use Cases goals
• Implements the protocols required by those goals

The Protocols:

• Define how service features can be invoked
• Define error reporting and handling

The Payload:

• In the case of ADQL is the responsibility of the VOQL-WG
• In the case of Simple Access is the subject of a separate but related standard defined by DAL-WG

Defining the Standard

These then are the steps and documents I would like to see leading to the drafting of the standards:

• Document the Use Cases describing the system in question (e.g. IVOA Table Access) on the IVOA Wiki
• Describe the software architecture (this is likely to be common across many such systems)
• Define the Service Interfaces that will be required
• Define the Protocols those Interfaces will support
• Define the Payload the Service will process (this include inbound and outbound and may be defined by an IVOA WG other than DAL)
• Discuss and draft the Standard(s) (both Protocol and Payload) required
• Where the Protocol and the Payload are tightly bound for reasons of convenience, note this and draft accordingly

Once agreed and drafted, Standard(s) will be prosed as a Recommendation(s) following the usual IVOA mechanisms.

---

Definitions

1. Client: "A computer application, such as a web browser, that runs on a user's local computer or workstation and connects to a server as necessary."
2. Server: "A software system designed to support interoperable Machine to Machine interaction over a network.
3. Protocol: "A convention or standard that controls or enables the connection, communication, and data transfer between two computing endpoints"
4. Payload: "The data, such as a data field, block, or stream, being processed or transported; the part that represents user information and user overhead information. Note that the payload does not include system overhead information for the processing or transportation system."
5. Contract: "...how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits"
6. System: "a set of computer equipment and programs used together for a particular purpose"
7. Use Case: A use case bridges the gap between user needs and system functionality by directly stating the user intention and system response for each step in a particular interaction. Each use case should show a straightforward example of the user succeeding at a goal. The steps in a use case are almost always a linear sequence.
8. Use Case Suite: An organized suite of use cases is needed to fully specify the software requirements. A Use Case Suite is effectively table of contents for the individual use cases.

References

• ReadySET: Open Source Software Engineering Tools
• ReadySET Pro: Enterprise ready software engineering templates
• Alistair A.R. Cockburn: Structuring use cases with goals
• ReadySET: Use Case
• ReadySET: Use Case Suite
• Wikipedia: Protocol
• Wikipedia: Service
• Wikipedia: Payload
• Wikipedia: Client
• Wikipedia: Contract
• Cambridge Dictionary: System

---

-- KeithNoddle - 20 Sep 2007