Difference: DefiningDalStandards (1 vs. 4)

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

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

Notes on Defining a DAL Standard

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Notes on Defining a DAL Standard

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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.

The Problem

Or should that be opportunity? Either way, it 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. The time honoured way of defining the problem is to produce a Statement of Requirements. The modern way to do this 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.

Architecture

Defining Use Cases

The subject of much thought and the production of many books, a basic agreement as to what constitutes a Use Case must be reached. Use Cases themselves need to be organised into groups and priorities from which the requirements for a given revision of the Standard can be agreed. This is the Use Case Suite. The primary goal of writing use cases is to specify the system to be built. No single use case specifies the entire requirements of the system. Each use case merely explains one particular interaction.
I am using this site for some of these definitions. Other noteworthy sites can be found here and here. I suggest the following definitions meets our needs nicely:

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

Satisfying Use Cases

When formulating solutions to Use Cases, it is vital that the key elements of the system are considered, namely, Client, Payload, Protocol and Service (see Architecture). Each must be used correctly and not overloaded with features that rightly belong in other areas. Whilst we may compromise over where certain functionality is implemented, we should only do so where there is a clear and compelling need so to do, not because it provides a short term gain. To do so is to invite deep rooted problems that will be hard or impossible to solve at a later date.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->