Difference: DefiningDalStandards (2 vs. 3)

Revision 32007-09-24 - KeithNoddle

 
META TOPICPARENT name="IvoaDAL"

Notes on Defining a DAL Standard

Deleted:
<
<
Under construction.

>
>
The Protocols:
 
Added:
>
>
  • 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


-- KeithNoddle - 20 Sep 2007
 
<--  
-->
Changed:
<
<
META FILEATTACHMENT attr="h" comment="" date="1190217259" name="serviceDiagram.png" path="serviceDiagram.png" size="16823" user="KeithNoddle" version="1.1"
>
>
META FILEATTACHMENT attr="h" comment="" date="1190629717" name="serviceDiagram.png" path="serviceDiagram.png" size="15333" user="KeithNoddle" version="1.2"
 
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback