Witsml/> Core Application Program Interface Version 1
Authentication and Encryption
Download 0.54 Mb.
|
- Navigate this page:
- 7.4Capabilities Objects
- 7.4.1Client Capabilities (capClient) Object
- 7.4.2Server Capabilities (capServer) Object
- 7.4.3Capabilities by Object
7.3Authentication and EncryptionThe STORE interface uses HTTP/S Basic Authentication, as described in IETF RFC’s 2616 (HTTP 1.1) and 2617 (Authentication). The userid and password transported via the HTTP/S Basic Authentication mechanism can be used by the STORE implementation to perform authorization checking and control of client access. The capabilities and implementation of authorization checking, if any, are not specified by WITSML. It is up to participating companies to agree if authentication is required to access a WITSML server. If it is required, the authentication data should be sent with each WITSML message. Secure Sockets Layer (SSL) for HTTP (HTTPS) can be used to encrypt the HTTP traffic. 7.4Capabilities ObjectsThe STORE interface uses two special objects to exchange information about the “capabilities” of the Client and the Server. These special objects are called the Capabilities objects. RESTRICTION While the Capabilities objects are a type of “WITSML API object” they cannot be accessed by the STORE interface’s standard data query functions. The Capabilities objects are not persisted as data. They can only be accessed using the WMLx_GetCap functions and the CapabilitiesIn/Out parameters of the various STORE interface functions. 7.4.1Client Capabilities (capClient) ObjectThe Client Capabilities or “capClient” object is used to inform the Server of the Client’s functional capabilities. The capClient object is conveyed as the CapabilitiesIn parameter of various STORE interface functions. It must be passed on each call; the value is not maintained across calls. The CapabilitiesIn parameter may be set to a null string to indicate that no capClient object is being provided. When a capClient object is not provided, default values for the various capabilities are used by the Server. 7.4.2Server Capabilities (capServer) ObjectThe Server Capabilities or “capServer” object is used to inform the Client of the Server’s functional capabilities. The capServer object is conveyed as the CapabilitiesOut parameter of the STORE interface’s WMLS_GetCap (Get Capabilities) function. 7.4.3Capabilities by ObjectThese are the presently defined capabilities that can be exchanged using the capClient and/or the capServer objects: Capability: version of the API which the Client or Server supports Applies to: capClient and capServer objects Conveyed as: apiVers attribute of the capServer or capClient element Syntax: apiVers=”n.n.n” Default: 1.3.1 Example: Notes: this is the value to be used if it is necessary to dynamically adapt to differing implementation levels (do not use the version element below) Capability: contact information for the Client or Server Applies to: capClient and capServer objects Conveyed as: contact child element of the capServer or capClient element Syntax: nnn…nnn
Default: none Example: 1-800-555-1212 Notes: any descriptive text Capability: description of the Client or Server Applies to: capClient and capServer objects Conveyed as: description child element of the capServer or capClient element Syntax: Default: none Example: Notes: any descriptive text Capability: name of the Client or Server Applies to: capClient and capServer objects Conveyed as: name child element of the capServer or capClient element Syntax: Default: none Example: Notes: any descriptive text Capability: vendor (producer) of the software Applies to: capClient and capServer objects Conveyed as: vendor child element of the capServer or capClient element Syntax: Default: none Example: Notes:
Capability: version (build) of the executable program Applies to: capClient and capServer objects Conveyed as: version child element of the capServer or capClient element Syntax: Default: none Example: Notes:
Capability: schema version(s) that are supported Applies to: capClient and capServer objects Conveyed as: schemaVersion child element of the capServer or capClient element Syntax: Default: none Example: < schemaVersion >1.1.0,1.2.0,1.3.1.0 < schemaVersion >1.3.1.0 Notes: The values must match the version attribute in the plural object. For capClient, the value is a comma separated list of values without
Capability: the STORE functions, versions and data objects that the Server supports for each function Applies to: capServer object only Conveyed as: function child element of the capServer element
Syntax: Default: none (Client should not assume capability exists if not explicitly listed) Example: Notes: the example shows supports for only the three specified data object types for WMLS_GetFromStore and only the log object for WMLS_AddToStore. The function calls are from version 1.3.1 of theAPI. It also supports the WMLS_GetVersion function. The capServer object does not need to specify the WMLS_GetCap function, as this is implied if the capServer object is returned to the Client. Directory: schema schema -> Recommended list of diagrams for the Anatomy final examination Skeleton, joints, muscles schema -> Schema/Assimilation/Accommodation Schema schema -> Resume: exhibitions schema -> B2b web Service Guidelines V2 rsvz enterprise Architecture schema -> State of Maine-Sample Automobile Lifts and Hoists Schema-Sample schema -> Outline of Critique Of Pure Reason Download 0.54 Mb. Share with your friends:
|