OGSA-DMI Plain WS Rendering Interop Tests

This page gives the details of the interoperability tests for the OGSA-DMI Plain Web Services Rendering Specification. It lists the contact information of all implemented and participating endpoints and their status (whether available or down) for other implementers to configure their clients. It gives an overview of the tests that must be conducted, and the requirements that must be met in order to mark success or failure for that test between participating services and clients.

The tests are conducted in a "for-way" fashion. That is, for any two participants "A" and "B" conducting a certain test:

• A's client conducts the test against A's service
• A's client conducts the test against B's service
• B's client conducts the test against A's service
• B's client conducts the test against B's service

The outcome is recorded in the tables provided in the outcomes section below.

Public Endpoints

For each participating endpoint there must be a responsible contact person, as well as all required information about the endpoints present.

• Fujitsu Laboratories of Europe, Ltd. (FLE)
  • Contact Information
    • Michel Drescher (details removed for Spam reasons, please use the OGSA-DMI ML)
  • OGSA-DMI DTF Endpoint
    • Address: https://www.arcon-grid.net:8443/dmi-factory
    • WSDL Address: https://www.arcon-grid.net:8443/dmi-factory?wsdl
    • Note: The Factory implementation requires WS-Addressing headers (but ot necessarily a WS-Addressing EPR to talk to it).
  • OGSA-DMI DTI Endpoint
    • Instance Address: https://www.arcon-grid.net:8443/dmi-instance
    • Instance WSDL Address: https://www.arcon-grid.net:8443/dmi-instance?wsdl
    • Note: The Instance implementation requires WS-Addressing and the use of the EPR that you get when invoking the factory's "Create Instance" operation.
  • Certificates
    • The self-signed certificate for the Fujitsu imlementation (in RFC text format) can be found here
  • Endpoint container status: RUNNING

• Microsoft HPC Group
  • Contact Information
    • Steven Newhouse (details removed for Spam reasons, please use the OGSA-DMI ML)
  • OGSA-DMI DTF/DTI Endpoints
    • Details made available on request.

• UNICORE Grid Middleware
  • Contact Information
    • Mohammad Shahbaz Memon (details removed for Spam reasons, please use the OGSA-DMI ML)
  • OGSA-DMI DTF Endpoint
    • Address: https://zam461.zam.kfa-juelich.de:9103/services/DataTransferFactory?res=default_dtf
    • WSDL Address: https://zam461.zam.kfa-juelich.de:9103/services/DataTransferFactory?wsdl
  • OGSA-DMI DTI Endpoint
    • Instance Address: https://zam461.zam.kfa-juelich.de:9103/services/DataTransferInstance?res=xxxx
    • Instance WSDL Address: https://zam461.zam.kfa-juelich.de:9103/services/DataTransferInstance?wsdl
    • Note: The particle 'xxxx' indicates that the Instance Address is augmented with a UUID to disambiguate individual instances managed by the same implementation (as per WSRF)
  • Certificates
    • fakeca-cert.pem
  • Endpoint container status: DOWN

Test Scenarios

This section gives details about which tests should performed, and the required outcome for the test to pass.

1. Get Factory Attributes

Description:
The Client obtains the factory attributes of the target endpoint.

Expected outcome:
The Factory returns the current values for its attributes.

Success Requirements:
- The attributes list MUST contain a supported protocol with the URI "http://www.ogf.org/ogsa-dmi/2006/03/im/protocol/ftp"
- Each supported protocol MUST provide an Undo URI which MAY be "http://www.ogf.org/ogsa-dmi/2006/03/im/retry/none", or "better". - The attributes list MAY contain other, proprietary attributes.

2. Get Data Transfer Instance (1)

Description:
The Client asks the Factory to create a Data Transfer Instance.

Expected outcome:

The Factory creates an EPR to a created Data Transfer Instance.

Success Requirements:
- The returned EPR MUST validate against the WS-Addressing requirements

3. Get Data Transfer Instance (2)

Description:
The Client asks the Factory to create a Data Transfer Instance.
The source and sink EPRs are suitable to create a DTI instance, but the transfer requirements must be bogus (i.e. EndNoLaterThan is in the past).

Expected outcome:
The Factory returns a UnsatisfiableRequestOptionsFault.

Success Requirements:
- The Factory MUST return a UnsatisfiableRequestOptionsFault.

4. Get Data Transfer Instance (3)

Description:
The Client asks the Factory to create a Data Transfer Instance.
The source and sink EPRs are unsuitable to create a DTI instance (i.e. an unsupported protocol identifier), but the transfer requirements are fine.

Expected outcome:
The Factory returns a NoTransferProtocolAgreementFault.

Success Requirements:
- The Factory MUST return a NoTransferProtocolAgreementFault.

5. Get Instance Attributes

Description:
The Client asks the Factory to create a Data Transfer Instance.
The source and sink EPRs, and the transfer requirements must be suitable to create a DTI instance. The TransferRequirements MUST be empty.
After obtaining the EPR to the DTI instance the client then asks the DTI instance for its attributes.

Expected outcome:
The DTI instance returns its attributes without faults.

Success Requirements:
- The instance attributes list MUST contain a valid set of attributes.
- The Status attribute MUST have the value "Created".
- The instance attribute list MUST NOT have a value for StartTime.

6. Successful Transfer (1)

Description:
The Client asks the Factory to create a Data Transfer Instance.
The source and sink EPRs, and the transfer requirements must be suitable to create a DTI instance. The TransferRequirements MUST NOT contain a value for StartotBefore, but SHOULD contain a value for StayAliveTime.
After obtaining the EPR to the DTI instance the client manually starts the transfer and monitors the progress until the end.

Expected outcome:
The DTI instance starts transferring the data as defined in the SourceDEPR and SinkDEPR.
The transfer is expected to succeed, but a failure does not necessarily result in a failed test.

Success Requirements:
- The DTI instance MUST have reported the "Created" state
- The DTI instance MAY have reported the "Scheduled" state (depending on request timing and service implementation)
- The DTI instance MUST have reported the "Transferring" state
- The DTI instance MUST have reported either "Done" or a "Failed" substate.
- The DTI instance MUST report a start time once the state has been "Transferred".
- The DTI instance MUST report a completion time if the state is "Done".

7. Successful Transfer (2)

Description:
The Client asks the Factory to create a Data Transfer Instance.
The source and sink EPRs, and the transfer requirements must be suitable to create a DTI instance. The TransferRequirements MUST contain a value for StartotBefore, but SHOULD contain a value for StayAliveTime.
After being set up, the DTI instance waits until the configured StartNotBefore time and automatically starts the transfer.
The client monitors the progress of the transfer.

Expected outcome:
The DTI instance starts transferring the data as defined in the SourceDEPR and SinkDEPR.
The transfer is expected to succeed, but a failure does not necessarily result in a failed test.

Success Requirements:
- All success requirements of test 6 MUST be met, plus:
- The DTI instance automatically starts the transfer without the client's interference.
- The DTI instance MUST report a start time even if in states "Created" or "Scheduled".

8. Mis-using the state model

Description:
The Client asks the Factory to create a Data Transfer Instance.
The source and sink EPRs, and the transfer requirements must be suitable to create a DTI instance. The TransferRequirements MUST NOT contain a value for StartotBefore, but SHOULD contain a value for StayAliveTime.
After obtaining the EPR to the DTI instance the client manually starts the transfer and monitors the progress until the DTI instance is in state "Transferring".
While the DTI instance is in state "Transferring", the client invokes the "Start()" operation.

Expected outcome:
The DTI instance starts transferring the data as defined in the SourceDEPR and SinkDEPR.
The data to be transferred should be reasonably sized, to ensure that the client catches the service in state "Transferring".
Invoking the "Start()" operation on the DTI instance provokes a "InvalidStateFault" to be returned, but the transfer continues until finished.

Success Requirements:
- The DTI instance MUST have reported the "Created" state
- The DTI instance MAY have reported the "Scheduled" state (depending on request timing and service implementation)
- The DTI instance MUST have reported the "Transferring" state
- The DTI instance MUST have reported either "Done" or a "Failed" substate.
- The DTI MUST return the "InvalidStateFault" when it is asked to start while already transferring data.

9. Invoking an unsupported operation

Description:
This test is useful only for services that do not support certain operations. For the agreed FTP used in the interoperability testing, usually the "Suspend" and "Resume" operations are not supported. Testers are REQUIRED to confirm with the service implementers which operations are not supported, if any.
The Client asks the Factory to create a Data Transfer Instance.
The source and sink EPRs, and the transfer requirements must be suitable to create a DTI instance. The TransferRequirements MUST NOT contain a value for StartotBefore, but SHOULD contain a value for StayAliveTime.
After obtaining the EPR to the DTI instance the client manually starts the transfer and monitors the progress until the DTI instance is in state "Transferring".
While the DTI instance is in state "Transferring", the client invokes the unsupported operation (e.g. "Suspend()").

Expected outcome:
The DTI instance starts transferring the data as defined in the SourceDEPR and SinkDEPR.
The data to be transferred should be reasonably sized, to ensure that the client catches the service in state "Transferring".
Invoking the unsupported operation on the DTI instance provokes a "RequestedStateNotSupportedFault" to be returned, but the transfer continues until finished.

Success Requirements:
- The DTI instance MUST have reported the "Created" state
- The DTI instance MAY have reported the "Scheduled" state (depending on request timing and service implementation)
- The DTI instance MUST have reported the "Transferring" state
- The DTI instance MUST have reported either "Done" or a "Failed" substate.
- The DTI MUST return the "RequestedStateNotSupportedFault" when it is asked to start while already transferring data.

Test outcomes

1. Get Factory Attributes

2. Get Data Transfer Instance (1)

3. Get Data Transfer Instance (2)

4. Get Data Transfer Instance (3)

5. Get Instance Attributes

6. Successful Transfer (1)

7. Successful Transfer (2)

8. Mis-using the state model

9. Invoking an unsupported operation

Failure reasons

FLE Client against UNICORE Service

conducted: Fri, 31 Oct 2008, about 15:45 BST

[1]
wsa:Action contains the wrong value - in certain situations and Web Service tooling constellations (lik this one) this may cause no harm. May be fixed in the next version of the framework.

Attachments:

fakeca-cert.pem [PlainWSInterop/fakeca-cert.pem] FLE_Endpoints_Cert.cer [PlainWSInterop/FLE_Endpoints_Cert.cer]