We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

TEAM Engine - Validation of new OGC standard WFS 3.0 and status update of project

00:00

Formal Metadata

Title
TEAM Engine - Validation of new OGC standard WFS 3.0 and status update of project
Title of Series
Number of Parts
295
Author
Contributors
License
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
TEAM Engine is a testing facility enabling developers and users to test geo services, such as WFS or WFS, and geo formats, like GML or GeoPackage. The Open Geospatial Consortium (OGC) provides various test suites for TEAM Engine to support implementing and testing of GIS software basing on OGC standards. TEAM Engine is an OSGeo project in incubation phase. A test suite for new OGC standard WFS 3.0, which is currently a candidate standard (status of April 2019), was developed as part of OGC Testbed 14 initiative. As this standard uses completely different concepts in comparison to, for example, WFS 2.0, several conceptional questions had to be discussed and solved during implementation of test suite. This talk presents how the new OGC standard WFS 3.0 can be validated with TEAM Engine. The process of creating a new test suite as part of OGC Testbed 14 initiative is highlighted. This includes a short introduction of WFS 3.0 standard itself. Further, current developments in TEAM Engine project are presented and an outlook is given.
Keywords
129
131
137
139
Thumbnail
28:17
Graph coloringVideo gameLecture/Conference
Standard deviationComputer animationLecture/Conference
Standard deviationSuite (music)Expert systemSoftwareSoftware developerAreaImplementationOpen sourceType theoryPresentation of a groupInstance (computer science)Focus (optics)Degree (graph theory)Software developerSoftwareSuite (music)Standard deviationMereologyStatistical hypothesis testingSource codeProjective planeStatistical hypothesis testingMathematicsValidity (statistics)Computer animation
SoftwareExpert systemSoftware developerStandard deviationOpen sourceAreaImplementationMIDIStatistical hypothesis testingProduct (business)Installable File SystemMaxima and minimaPerformance appraisalMeasurementJava appletService (economics)Client (computing)Numbering schemeScripting languageWeb browserInterface (computing)Formal languageSuite (music)CodeComputer programmingSoftware suiteLink (knot theory)Execution unitEmulationChemical equationAmicable numbersMultiplicationPhysical lawLemma (mathematics)Chi-squared distributionData managementValidity (statistics)CASE <Informatik>ImplementationSource codeStatistical hypothesis testingInformationStatistical hypothesis testingFormal languageBitNetwork topologyComplete metric spaceReading (process)Limit (category theory)Self-organizationSuite (music)Service (economics)TorusDegree (graph theory)Standard deviationNumbering schemePoint (geometry)Message passingMereologyKey (cryptography)Descriptive statisticsLatent heatAdditionUltraviolet photoelectron spectroscopyResultantWeb browserRepresentational state transferSoftware suiteWiki1 (number)Symbol tableRepository (publishing)Software bugWeb serviceInterface (computing)Traffic reportingUser interfaceComputer animation
Revision controlComplete metric spaceData managementOcean currentSuite (music)12 (number)Integrated development environmentSoftware suiteRepository (publishing)Service (economics)Library catalogMarkup languageClient (computing)PlanningComputer-generated imageryProcess (computing)Software developerTask (computing)ChecklistOpen setMereologyElectronic program guideProbability density functionCoordinate systemSystem programmingVotingParallel portStatistical hypothesis testingBeta functionSuite (music)Greatest elementProjective planeRevision controlRepository (publishing)Ocean currentMereologyPlanningChecklistSoftware suiteStatistical hypothesis testingProcess (computing)Descriptive statisticsDifferent (Kate Ryan album)ImplementationIntegrated development environmentMedical imagingStandard deviationWikiSoftware developerSoftware bugTorusProduct (business)Point (geometry)Reduction of orderSlide ruleScaling (geometry)Data managementLibrary (computing)Traffic reportingReal numberVotingInsertion lossMetropolitan area networkMenu (computing)Multiplication signXML
Electronic program guideSystem programmingProbability density functionElectronic meeting systemMereologyProcess (computing)VotingStandard deviationFunctional (mathematics)Core dumpLatent heatComputer animationLecture/Conference
Standard deviationComponent-based software engineeringInterface (computing)Core dumpDatabase transactionQuery languageMereologyCodierung <Programmierung>TestbedStatistical hypothesis testingSoftware frameworkJava appletSuite (music)AbstractionImplementationSoftware suiteThread (computing)Link (knot theory)ParsingParsingCharacteristic polynomialIndependence (probability theory)Social classBeta functionGastropod shellIntegrated development environmentComputerFeedbackStatistical hypothesis testingSweep line algorithmComponent-based software engineeringCausalityHypermediaSocial classInstance (computer science)CASE <Informatik>Service (economics)Statistical hypothesis testingIntegrated development environmentGroup actionRepository (publishing)InformationWhiteboardLibrary (computing)NeuroinformatikLatent heatProcess (computing)Projective planeCuboidCore dumpData storage deviceCodierung <Programmierung>CodeObject (grammar)Software suiteImplementationComputer configurationOpen setReal numberTestbedParsingStandard deviationNP-hardConformal mapWebsiteJava appletSuite (music)Software frameworkBeta functionAbstractionGastropod shellComputer animation
Content (media)Medical imagingRepository (publishing)CodeMatching (graph theory)Speech synthesisStatistical hypothesis testingImplementationComputer fileCentralizer and normalizerCodierung <Programmierung>Process (computing)Software suiteWeb 2.0Computer animationLecture/Conference
Computer animation
Transcript: English(auto-generated)
Hello, everyone. We will now start our final session here. We have with us Dirk Stenger from LatLon, and he will present us TeamEngine.
So Dirk, welcome. Hello, everyone. My name is Dirk Stenger, and I'm doing a presentation about TeamEngine.
And the focus of the second part will be on the new OGC standard OGC API for features. So in the title, it still says WFS 3.0, but the name changed in the recent month.
So this is my agenda. First, I'm going to tell you what TeamEngine is, what the OGC side team is. And we developed test suites. I will show you some test suites. Then I talk about the current development in the project.
And finally, I'm talking about OGC API for features. So my name is Dirk Stenger. I'm working at LatLon as a software developer since 2012. And LatLon is mainly working with OGC standards.
So we have the software implementing. We work with the software implementing the standards degree. And since 2017, we are the manager of the OGC validation tool. So we are mainly doing all technical work
regarding TeamEngine, the test suites. So what is TeamEngine? Here you can see a screenshot of TeamEngine. It has a web interface. You can access. There you can register and execute test suites, which are testing OGC standards.
TeamEngine stands for Test Evaluation Measurement Engine. It can be used for several cases, so for validation of services, clients, schemas, and data. It's written in Java. And there's also a GitHub repository available.
So you can check out the URL. And the complete source code is there also. And there's a wiki with important information and the issue tracker, of course. So TeamEngine is the engine to execute the tests,
but not the test itself. So the tests have to be written separately. There are two languages to write the tests with. One is the OGC compliance test language, and the second one is TestNG.
So but like the CTL language is a little bit outdated, so all new test suites are written with TestNG and just the old ones in CTL. As I already said, there's a web browser interface. Also we have a command line interface
and a REST API to execute the tests. The OGC provides over 40 test suites. I think maybe you already have around 60. The source code of all tests can be found at the OpenGeospatial organization.
So if you go to that organization, you find different repositories for all test suites. These are just a few examples for test suites. So there's a WFS11 test suite, WFS20 test suite, WMS13 test suite, the OGC API for features test suite.
And as you can see here, each test suite has its own repository. Also each test suite has its own issue tracker. That's very good because if you do not understand the result of your test run or if you detect a bug in a test suite,
you can directly go to the issue tracker, create an issue there, and we will take care of it or analyze it and give you an answer. So we actively use the issue trackers of all test suites and of team engine, of course. So this is an example how test is run with the web browser
interface. So first you log in on the left side. You can see that you can select a specification you want to test. In this case, we are testing WFS20. Then you click on start a new test session.
Then you see some information about the test suite. You have to enter the endpoint you want to test. So in this case, a degree of web service is tested. And then you can add additional information and click on start. Then you can see on the left, there's
a waiting symbol when the tests are executed. And after, I would say, half a minute, the test report appears. And on the right side, this report tells you which tests passed and which failed.
And if any tests failed, you can click on the tests and see a description of the failure. So the OGC hosts one installation of team engine, or even more than this one. But this is the official OGC team engine,
which is used to certify an implementation as OGC compliant. So it does not cost anything to register there. If you go to that URL, you can just create an account there and use that team engine as often as you want.
And then if your implementation passes all tests, you can ask for a compliance badge. Then you have to pay a little bit of money to the OGC. And then you get an OGC compliant badge.
Also, the test suites are used to certify reference implementations. So reference implementations are implementations of certain standards which are passing all important tests. And those implementations are available on the web, and everyone can use them. So you can always use those implementations as a reference.
OK, now I come to the current development of team engine. So version 3.4 was released in May 2019. So it's still actively developed. Currently, version 5.5 is prepared.
We take several issues with the milestone of 5.5. So you can see which features will be part of version 5.5. So mainly, we are updating the party libraries, enhance the user management, improve the report,
the final report, and the plan is to release version 5.5 late this year. OK, on the other hand, we have the test suites and different repositories. So for all repositories, bug fixes and enhancement
are implemented regularly. And also, releases are created regularly of all test suites. So we try to create one release each month. And then when the releases are created, we install these releases immediately
at the beta environment of the OGC. So it's that URL with TE2. And on that installation of team engine, you always find the latest versions of all test suites. So if you really want to use the latest version of everything, you should go to the beta
environment. So it's the same as to the official production environment. You can just register there and use it. It doesn't cost anything. Yeah, of course, everyone is welcome to participate. So we are using all the issue trackers
and try to answer all questions. There was a big update of the production environment in July 2019, so last month. So yeah, actually, we updated all test suites
which are the newer version on beta to the version on beta because all of them are stable now. And so if you used the production environment before in July 2019, you can try to run your tests again because there are many new versions of test suites available.
OK, then another thing is that we have a Docker repository and we provide images for all test suites. Not for all test suites, but for selected test suites. When a new release is created, like a new Docker image
is automatically created and pushed into that repository. So you can see that that should be the current status. So which test suites already have a Docker image and it's very easy to use those.
So it's just one command to download it and to run the test suite. And there's like the URL is on the bottom of the slide. There's a short manual in the description text of the Docker
repository. So you can just use that to download and start the test suite. OK, another big thing we are currently doing is that we want to become a full OCL project. So currently, team engine is in incubation.
So we are still in the process of becoming a full OCL project. For that, we created a wiki page with a checklist what we have to do to become a full OCL project.
So everyone can access this and check the current status. And we filled it out and then we realized, OK, for some checkpoints, there are open questions. And for all of those open questions, we created one issue in the issue tracker,
which is labeled with OCL minus graduation. So yeah, that's our plan for the next month to solve all those issues. And then team engine will become a full OCL project. I come to OGC API features.
So I don't know if you have heard of this standard. So in the past, it was called WFS 3.0. It's not an official standard yet, but currently it's in the voting process of OGC. So we can expect that it will be an official standard soon.
Also, it's a modular standard. So the first document of the standard is called core, and just covers core functionalities and further functionalities are covered by further specifications, which are currently worked on.
So OGC API features tries to use industry standard instead of WFS specific resources or components.
So basically, it's a complete rewrite of the WFS. It uses a RESTful approach. So yeah, that's, of course, a concept which is used by many people, and everyone understands it.
Also, there's no capabilities document anymore, but the API is defined by an open API document. Another important thing is that there's, so in the past, DML was like the most important encoding
for OGC services, and that was dropped. So there's no mandatory encoding anymore, but there are some proposed encodings, for example, JSON, HTML, and GML. But I think most people use JSON to implement their first OGC API features service.
Okay, during Testbed 14 compliance, during the Testbed 14 project, we developed a OGC API features test suite. So that was last year.
Yeah, the test suite is a new test suite written in TestNG. Of course, the test can be executed with team engine. We implemented the abstract test suite, which is documented in the specification. And yeah, there's, of course, a repository where you can find the test suite,
so it's still called WFS 3.0, but we'll rename it soon. Okay, so there were a couple of new challenges during the implementation of the test suite.
So in the past, we had a capabilities document we had to parse, but now there's an OMA API document. So that's a JSON document, so the parsing was different. Also, there's no mandatory encoding,
so that is a real hard issue for test suite because we do not know what we are expecting as return value, so we just defined a couple of restrictions that the JSON encoding must be supported, otherwise the test suite will not work.
And okay, of course, we introduced new Java libraries frameworks to make the implementation easier. Okay, and one other important thing is that the test suite is data-agnostic, so you can test any implementation
of the standard with the test suite, and especially old test suites often have the restriction that they are data dependent. Okay, so the test suite completely implemented
the core conformance class of the specification, so yeah, it's already complete. There are also a couple of optional conformance classes in the specification, those are not implemented so far. Yeah, of course, the current release
as for all test suite is in the OGC beta environment, so you're welcome to create an account and use it. Also, of course, you can execute the test suite via IDE command shell or Docker, so those approaches are described on that ascii-doc site.
Just a very easy way to install and start the test suite is to just execute this command, so if you have Docker installed, you can immediately execute this command,
and then you have a running instance of team engine with the OGC API features test suite. And as always, if you have any questions, find any bugs, you're very much welcome to report those
to the issue tracker. Yeah, and that's it from my side. Are there any questions?
All right, thank you very much. Please, questions, yes? So you want to extend the Docker image?
Yes, so currently we are using the Tomcat image as base image, so the Docker image does not contain the command line tool, but the web tool.
So I would, in this case, I would propose to write a new Docker file that's probably easier. Yeah, so we upload them to MAME central repository,
not for all test suites, but for most. And team engines also upload to central MAME repository. Nope, it's fine, so actually you do not have
to support any of those encodings because all of them are optional. Yeah, but yeah, this test suite has the restriction that you have to implement JSON, but yeah, that's enough to pass on the test suite.
Any other questions, please? One man, please.
So I heard the answer, but I don't know what the question was. So one question was if the Docker image can be used in a CI pipeline, but my answer was yeah, that I would write
a new Docker file for that purpose because the Docker images just support the web interface, and the command line interface probably better for a CI process. And the other question was if you have to support
the JSON, if you pass the test, if you just support the JSON encoding, that's correct. So you can pass the test then if the rest is implemented correctly.
Are there any other questions? I guess not, so thank you very much. And we'll be back in 10 minutes with the next speech.
Thank you.