23297fa3b1
git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@684661 13f79535-47bb-0310-9956-ffa450edef68
157 lines
6.9 KiB
HTML
157 lines
6.9 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!--
|
|
* Licensed to the Apache Software Foundation (ASF) under one
|
|
* or more contributor license agreements. See the NOTICE file
|
|
* distributed with this work for additional information
|
|
* regarding copyright ownership. The ASF licenses this file
|
|
* to you under the Apache License, Version 2.0 (the
|
|
* "License"); you may not use this file except in compliance
|
|
* with the License. You may obtain a copy of the License at
|
|
*
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
*
|
|
* Unless required by applicable law or agreed to in writing,
|
|
* software distributed under the License is distributed on an
|
|
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
|
* KIND, either express or implied. See the License for the
|
|
* specific language governing permissions and limitations
|
|
* under the License.
|
|
-->
|
|
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content=
|
|
"text/html; charset=us-ascii">
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
|
|
|
<title>Tuscany SCA Integration Test Databindings</title>
|
|
<!-- LINK rel="stylesheet" href="ait.css" type="text/css" -->
|
|
<link rel="stylesheet" href="../../css/base.css" type="text/css">
|
|
</head>
|
|
|
|
<body>
|
|
<h3>Tuscany SCA Integation Test Databindings </h3>
|
|
|
|
<h4>Overview</h4>
|
|
|
|
<p>
|
|
This integration test tests the Tuscany SCA databinding implementation by passing various data structures
|
|
across various bindings using the supported databindings. There are tests for the individual databindings
|
|
which exercise various bindings with the same databinding at client and server ends of each binding. There
|
|
is also an integration test which exercises the transformer chains by specifying different databindings at
|
|
client and server ends of the binding.
|
|
</p>
|
|
<p>
|
|
In doing this testing it is apparent that there is a lot of repetition in creating client, services, idl and
|
|
type for each of the data types for each of the bindings for each of the databindings. To reduce the amount
|
|
of effort required to maintain the tests as new types, bindings and databindings are added the test cases
|
|
themselves are generated from configuration files.
|
|
</p>
|
|
|
|
<h4>Test Structure</h4>
|
|
|
|
Databindings/Common - hold files common across all tests <br/>
|
|
Databindings/Interop - test the transformer chains with combinations of databindings<br/>
|
|
Databindings/sdogen and jaxbgen - test each databindings independently<br/>
|
|
|
|
<h4>Test Generation</h4>
|
|
<p>
|
|
To reduce the amount of manual effort involved in building and maintaining tests cases the test cases
|
|
themselves are generated at run time using a set of velocity templates. Each test module has a generate.xml
|
|
file in the resources/generate directory which tells the generator what to do. The file looks like this.
|
|
</p>
|
|
<img src="config.png">
|
|
<p>
|
|
Each <Template> element describes a velocit template to use in the test. The generator process is to expand
|
|
each velocity template provided with all of the types specified in the <InputFile> sections.
|
|
</p>
|
|
<p>
|
|
Each <InputFile> element describes a schema file used in the test. It also contains a description of each
|
|
data type that will be tested. The generator then arranges for the databinding being tested to generate
|
|
appropriate Java classes to represent the type at runtime. The individual databinding tests use the following
|
|
flow.
|
|
</p>
|
|
|
|
Create data object at client<br/>
|
|
Client passes data object to server<br/>
|
|
Server modifies data object<br/>
|
|
Server returns modified data object to client<br/>
|
|
Client tests that modified data object is as expected<br/>
|
|
<p>
|
|
Hence the CreateTypeCode, ModifyTypeCode and ResultComparison elements which contain the type specific code
|
|
that is used in the tests.
|
|
</p>
|
|
|
|
<h4>The Common Directory</h4>
|
|
<p>
|
|
The common directory contains the information that is common across all of the tests. This includes the
|
|
common velocity templates and the source for the generator that reads the config.xml for each test. Common
|
|
also contains all of the data type schema as these are common across all tests. Each test pom is written so
|
|
that the contents of the common project are expanded into the tests target directory before the test starts.
|
|
In this way all of the common elements are available for the test generation phase and at test runtime.
|
|
</p>
|
|
|
|
<h4>Individual Databinding Tests</h4>
|
|
<p>
|
|
The individual databinding tests, for example, sdogen and jaxbgen, are mostly empty as their content is
|
|
generated at runtime. The configuration and any test specific templates can be found in the resources/generate
|
|
directory. Some files are hand crafted for each test and live in their static position in the tests directory
|
|
structure.
|
|
</p>
|
|
<p>
|
|
Each test uses the same scenario
|
|
</p>
|
|
<img src="databinding.png">
|
|
<p>
|
|
The interface exposed by the greeter service provides a greet method for each data type being tested, for
|
|
example,
|
|
</p>
|
|
<code>
|
|
PersonType greetPersonType(PersonType param);<br/>
|
|
AttributeComplexType greetAttributeComplexType(AttributeComplexType param);<br/>
|
|
AttributeReferenceComplexType greetAttributeReferenceComplexType(AttributeReferenceComplexType param);<br/>
|
|
</code>
|
|
<p>
|
|
These methods are taken from the SDO databinding test and hence PersonType, AttributeComplexType, etc. will
|
|
have been generated by the SDO static type generator.
|
|
</p>
|
|
<p>
|
|
Hence this tests a single databinding across a variety of data types and a variety of bindings. New bindings
|
|
be tested by extending the composite. Be datatypes can be tested by updating the confix.xml file.
|
|
</p>
|
|
<h4>Databinding Interoperability Tests</h4>
|
|
<p>
|
|
This test uses the generated client, services and types from the individual databinding tests. It does not
|
|
regenerate them and you will see a dependency in the interop test pom on the other databinding tests. Is also
|
|
has some generate elements because the composite file must currently have import statements for all of the
|
|
SDO factories required during tested.
|
|
</p>
|
|
<p>
|
|
The scenario used here is,
|
|
</p>
|
|
<img src="interop.png">
|
|
<p>
|
|
A chain of components is built up for each binding. Each component, drawn from the the inidividual databinding
|
|
tests, tests the full range of datatypes. The client components are designed so that they can be chained together
|
|
and so tranformations across different databindings is tests. The service component simply changes the data
|
|
content and returns it as before.
|
|
</p>
|
|
<h4>Building And Running The Tests</h4>
|
|
<p>
|
|
The tests can be built by doing the following.
|
|
</p>
|
|
<code>
|
|
cd sca/itest/databindings <br/>
|
|
mvn
|
|
</code>
|
|
<p>
|
|
The only modification to this process is required if a new input file is added to the tests suite. In this
|
|
case you will need to edit the config.xml files as appropriate but run mvn twice. This may sound a little
|
|
odd but currently the sdo test uses its pom file to generate the require SDO types. As the test is self
|
|
generating the pom file will not be updated to include the new type file until the second time it's run. The
|
|
aim is at some point to remove this feature from the pom.
|
|
</p>
|
|
|
|
|
|
</body>
|
|
</html>
|