StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POWhat is the best practice in defining a soap service (generic vs. specific operation)?
text
Body
copied!<p>My situation is as follows:</p> <p>I have a normalized database, in which I hold geographic information about airports. The structure is:</p> <pre><code>airport --is in--> city --is in--> country --is in--> continent </code></pre> <p>Now I want to let users administrate this data, without giving them direct access to the database. We need to offer this administration interface via a web service.</p> <p>Now, when it comes to designing the service, we ran into the discussion about how to define the operations. We came up with different solutions:</p> <p><strong>Solution A: specific operations</strong></p> <p>For each of the four tables (airport, city, country, continent) we define 3 operations:</p> <ul> <li>insert</li> <li>get</li> <li>update</li> </ul> <p>This would lead to 12 operations with 2 request/response objects = 24 objects</p> <p>To create an all new airport with all dependencies, at least 4 requests would be necessary.</p> <p><strong>Solution B: generic</strong></p> <p>There is only one operation, which is controlled via parameters. This operation is capable of creating everything needed to administer the database.</p> <p>The operation would decide what needs to be done and executes it. If an error occures, it will roll back everything.</p> <p>==> 1 Operation = 2 highly complex request/response-objects</p> <p><strong>Solution C: Meet in the middle 1</strong></p> <p>One generic operation per table, which is capable of executing get, insert, update, just like solution B, but focused on one table each.</p> <p>==> 4 operations = 8 complex request/response-objects</p> <p><strong>Solution D: Meet in the middle 2</strong></p> <p>One generic operation per action (get, insert, delete), which can work on each table and resolve dependencies.</p> <p>==> 3 operations = 6 slightly more complex request/response-objects</p> <p><strong>Example</strong></p> <p>Since this was rather abstract, hier a simplified example for request-objects for creating (JFK/New York/USA/North America):</p> <p><strong>Solution A:</strong></p> <p>Request 1/4:</p> <pre><code><insertContinent>North America</insertContinent> </code></pre> <p>Request 2/4:</p> <pre><code><insertCountry continent="North America">USA</insertCountry> </code></pre> <p>Request 3/4:</p> <pre><code><insertCity country="USA">New York</insertCity> </code></pre> <p>Request 4/4:</p> <pre><code><insertAirport city="New York">JFK</insertAirport> </code></pre> <p><strong>Solution B:</strong></p> <p>Request 1/1:</p> <pre><code><action type="insertCountry" parent="North America">USA</action> <action type="insertAirport" parent="New York">JFK</action> <action type="insertContinent" parent="">North America</action> <action type="insertCity" parent="USA">New York</action> </code></pre> <p><strong>Solution C:</strong></p> <p>Request 1/4:</p> <pre><code><countryAction type="insert" parent="North America">USA</countryAction> </code></pre> <p>Request 2/4:</p> <pre><code><airportAction type="insert" parent="New York">JFK</airportAction> </code></pre> <p>Request 3/4:</p> <pre><code><continentAction type="insert" parent="">North America</continentAction > </code></pre> <p>Request 4/4:</p> <pre><code><cityAction type="insert" parent="USA">New York</cityAction > </code></pre> <p><strong>Solution D:</strong> Request 1/1:</p> <pre><code><insert airport="JFK" city="New York" country="USA" continent="North America" /> </code></pre> <p>Solution D seems rather elegant for me, therefore I tried to put this in XSD:</p> <p>Code:</p> <pre><code><complexType name="NewContinent"> <sequence> <element name="NAME" type="string"></element> </sequence> </complexType> <complexType name="NewCountry"> <sequence> <element name="ISOCODE" type="string"></element> <element name="NAME" type="string"></element> <choice> <element name="newCONTINENT" type="tns:NewContinent"></element> <element name="CONTINENT" type="string"></element> </choice> </sequence> </complexType> <complexType name="NewCity"> <sequence> <element name="IATA" type="string"></element> <element name="NAME" type="string"></element> <choice> <element name="COUNTRY" type="string"></element> <element name="newCOUNTRY" type="tns:NewCountry"></element> </choice> </sequence> </complexType> <complexType name="NewAirport"> <sequence> <element name="IATA" type="string"></element> <element name="NAME" type="string"></element> <choice> <element name="CITY" type="string"></element> <element name="newCITY" type="tns:NewCity"></element> </choice> </sequence> </complexType> </code></pre> <p>A corresponding request would then look like follows:</p> <pre><code><complexType name="Request"> <choice> <element name="AIRPORT" type="tns:NewAirport"></element> <element name="CITY" type="tns:NewCity"></element> <element name="COUNTRY" type="tns:NewCountry"></element> <element name="CONTINENT" type="tns:NewContinent"></element> </choice> </complexType> </code></pre> <p>Now my question: <strong>Is this really the best solution available? Is the XSD enough to understand, what is going on?</strong></p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload