Fintech Success Story

In 2017 PLEUS Consulting supported Yareto GmbH in the development of their new independent comparision site for the automotive finance industry.
Yareto is a fintech company that specializes in automotive financing. In 2016 the corporate startup was founded to build a brand new comparision site for the automotive finance industry. The site enables car dealers to compare credit offers in the areas of sales financing and purchase financing. Lenders get access to sales channels they couldn’t serve before.

PLEUS Consulting supported Yareto in setting up a Creative Software Workbench. The Creative Software Workbench aligns technology, processes and people in a way that creates an environment in which high quality digital products can be developed in short time.

The front-ends were developed using modern web technologies such as Java-/Typescript, HTML5, CSS and Angular. For the backend Java Enterprise (JEE) and a Sustainable Service Design approach was utilized to design and build a backend with a high degree of reuse and scalability. The service landscape was established using Domain Driven Design principles. Operations was performed using cloud platforms.

On the technical side, PLEUS Consulting supported the teams as Lead Developer. In the area of agile techniques, PLEUS Consulting supported the development teams as Agile Coach. The combination of those roles worked quite well especially in the phases of seed and growth. With these roles the company received thorough support in the areas of technology and methodology.

The project has shown that with a combination of modern technologies, agile approaches and the right people a very short concept to market cycle can be achieved, creating competitive advantages. This is what the Creative Software Workbench is all about.

You can read more details about the project in the official success story. More info about the Creative Software Workbench can be found on the official website.

Turn contracts into code

Interfaces are one of the most important parts in software design. Designing software around properly defined interfaces has many benefits for instance in the areas of consistency, maintainability and reuse. A well written contract describes precisely how software artefacts (or services) interact with each other. Approaches such as Sustainable Service Design or the BiPRO standards rely on contracts based on XML Schema (xsd). As they start with the contract design, they are called contract or schema first approaches.
Once you have a contract the question is how to turn it into code. In the Java world JAXB is the first choice. Lets’s see how we can generate Java sourcecode from the schema.

We start with a simple schema shown in the following listing.

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="contract.xsl"?>
<xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xml="http://www.w3.org/XML/1998/namespace"    
    xmlns:service="http://www.pleus.net/services"
    xmlns:tns="http://www.pleus.net/services/calculator/api/model"
	targetNamespace="http://www.pleus.net/services/calculator/api/model"
	elementFormDefault="qualified" attributeFormDefault="qualified"
	version="1.0">
	  
    <!-- ################################################### -->
	<!-- ################### Messages ###################### -->
    <!-- ################################################### -->

    
	<xs:element name="PerformSimpleCalculationRequest">
		<xs:annotation><xs:documentation>Performs a simple calculation</xs:documentation></xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="operation" type="tns:Operation" minOccurs="1" maxOccurs="1">
					<xs:annotation>
                        <xs:documentation xml:lang="EN">Operation to perform</xs:documentation>
                        <xs:documentation xml:lang="DE">Operation zur Ausführung</xs:documentation>
                    </xs:annotation>
				</xs:element>
				<xs:element name="value-a" type="tns:decimal9F2" minOccurs="1" maxOccurs="1">
					<xs:annotation><xs:documentation>First value</xs:documentation></xs:annotation>
				</xs:element>
				<xs:element name="value-b" type="xs:decimal" minOccurs="1" maxOccurs="1">
					<xs:annotation><xs:documentation>Second value</xs:documentation></xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
    
	<xs:element name="PerformSimpleCalculationResponse">
		<xs:annotation><xs:documentation>Result of a simple calculation</xs:documentation></xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="result" type="xs:decimal" minOccurs="1" maxOccurs="1">
					<xs:annotation><xs:documentation>Result</xs:documentation></xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
    

   <xs:element name="CalculatorError">
   	  <xs:annotation><xs:documentation>Provides error information</xs:documentation></xs:annotation>
      <xs:complexType>
         <xs:sequence>
				<xs:element name="message" type="xs:string" minOccurs="1" maxOccurs="1">
					<xs:annotation><xs:documentation>Fehlermeldung</xs:documentation></xs:annotation>
				</xs:element>
				<xs:element name="code" type="xs:int" minOccurs="1" maxOccurs="1">
					<xs:annotation><xs:documentation>Fehlercode</xs:documentation></xs:annotation>
				</xs:element>
         </xs:sequence>
      </xs:complexType>
   </xs:element>
	
    <!-- ################################################### -->
    <!-- ################# Type definitions ################ -->
    <!-- ################################################### -->

	<!--  Enum type  -->
	 <xs:simpleType name="Operation">
	    <xs:annotation><xs:documentation>Defines the arithmetic operations</xs:documentation></xs:annotation>
		<xs:restriction base="xs:string">
			<xs:enumeration value="ADD"><xs:annotation><xs:documentation>Add</xs:documentation></xs:annotation></xs:enumeration>
			<xs:enumeration value="SUBTRACT"><xs:annotation><xs:documentation>Substract</xs:documentation></xs:annotation></xs:enumeration>
			<xs:enumeration value="MULTIPLY"><xs:annotation><xs:documentation>Multiply</xs:documentation></xs:annotation></xs:enumeration>
			<xs:enumeration value="DIVIDE"><xs:annotation><xs:documentation>Divide</xs:documentation></xs:annotation></xs:enumeration>
		</xs:restriction>
	</xs:simpleType>

        <xs:simpleType name="decimal9F2">
          <xs:restriction base="xs:decimal">
            <xs:totalDigits value="9"/>
            <xs:fractionDigits value="2"/>
          </xs:restriction>
        </xs:simpleType>

</xs:schema>

The schema is part of an example project which can be downloaded here.

A more appealing representation would look as follows:

In order to turn this schema into code we can call the xjb tool which is part of the Java SDK on the command line like this:

xjc calculator.xsd

As a result we get Java code that we can incorporate in our code base. Another option is to generate the Java code from our Maven build. This can be achieved by adding following Maven Plugin to your pom.


<plugin>
	<groupId>org.jvnet.jaxb2.maven2</groupId>
	<artifactId>maven-jaxb2-plugin</artifactId>
	<version>0.8.1</version>
	<executions>
		<execution>
			<goals>
				<goal>generate</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<schemaDirectory>${project.basedir}/src/main/resources/xsd</schemaDirectory>
		<bindingDirectory>${project.basedir}/src/main/resources/xsd</bindingDirectory>  
                <generatePackage>net.pleus.services.calculator.api.model</generatePackage>
	</configuration>
</plugin>

As a result we get basic Java classes that represent the messages and types defined in our schema. If you want to affect the way the code is generated you can provide xjb binding files to customize the generated code. If you want for example use java.util.Calendar to be generated for an xsd:date type you can use the following binding:


<jaxb:bindings version="2.1"
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
    xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <jaxb:globalBindings generateElementProperty="false">
      <jaxb:javaType name="java.util.Calendar" xmlType="xsd:date"  
             parseMethod="javax.xml.bind.DatatypeConverter.parseDate"  
             printMethod="javax.xml.bind.DatatypeConverter.printDate">
      </jaxb:javaType>  
    </jaxb:globalBindings>   
</jaxb:bindings> 

Just drop the file jaxbbinding.xjb in the the same directory as your xsd file.

The foundation
We now have a simple Java class without any additional features:

JAXB comes with very useful plugins to pimp our generated code.

HashCode, equals, toString
If we want standard operations such as hashCode, equals or toString we can use the plugin org.jvnet.jaxb2_commons:jaxb2-basics.

This gives us:

Value Constructor
If we want value constructors, we can use the plugin org.jvnet.jaxb2_commons:jaxb2-value-constructor.

The result is:

Fluent APIs
Fluent APIs can be generated with the plugin net.java.dev.jaxb2-commons:jaxb-fluent-api.

This gives us a very nice fluent API to produce intuitive and readable code.

Bean Validation
One great aspect of schema first design is that one can nicely define types and constraints like tns:decimal9F2 shown in the listing at the top of this page. Wouldn’t it be nice if we could check those constraints in our code without additional effort? The plugin com.github.krasa:krasa-jaxb-tools generates JSR349 compliant bean validation annotations from our XSD types. After running the build we get annotated classes shown below for valueA which appears in the xsd as tns:decimal9F2:


@NotNull
@Digits(integer = 7, fraction = 2)
protected BigDecimal valueA;

To trigger the validation from your code we just need the following code snippet:


import javax.validation.*;

ValidatorFactory validatorFactory = Validation.buildDefaultValidatorFactory();
Set<ConstraintViolation<PerformSimpleCalculationRequest>> violations = validatorFactory.getValidator().validate(request);
for(ConstraintViolation<PerformSimpleCalculationRequest> violation : violations){
  System.out.println("Violation: " + violation);
}

Javadoc
And finally it would be nice to have the documentation from within the XSD file in the generated Java code as well.
This can be achieved by the org.dpytel.jaxb:xjc-javadoc plugin.

If you have additional needs to manipulate the generated code, you can implement your own JAXB plugin which can be hooked into the build process. This gives you maximum flexibility and full control of the code generation.

The entire plugin configuration is shown here:



	org.jvnet.jaxb2.maven2
	maven-jaxb2-plugin
	0.8.1
	
		
			
				generate
			
		
	
	
		true
		>net.pleus.services.calculator.api.model
		
			-Xinheritance
			-XtoString
			-XhashCode
			-Xequals
			-Xvalue-constructor
			-Xfluent-api
                        -XJsr303Annotations
		
		${project.basedir}/src/main/resources/xsd
		${project.basedir}/src/main/resources/xsd
		
			
				org.jvnet.jaxb2_commons
				jaxb2-basics
				${jaxb2-basics.version}
			
			
				org.jvnet.jaxb2_commons
				jaxb2-value-constructor
				${jaxb2-value-constructor.version}
			
			
				net.java.dev.jaxb2-commons
				jaxb-fluent-api
				${jaxb-fluent-api.version}
			
			
     				com.github.krasa
				krasa-jaxb-tools
				${krasa-jaxb-tools.version}
			
                        
		                org.dpytel.jaxb
  		                xjc-javadoc
		                ${xjc-javadoc-version}
		        
		
	


In this post I’ve shown how to turn contracts into code on the Java platform easily. The contracts are 100% reusable, interoperable and cross platform, of instance on the .NET platform. Here you would use svcuitl.exe to turn the contract into code.

In part two I’m going to show how to turn contracts in into documentation.

Free Visual XML Schema Designer

Those of you who utilize a contract first design such as in Sustainable Service Design have the need to edit XML Schema files frequently. If you are like me you are using a plain text or xml editor, as it gives you the greatest flexibility to express exactly what you want.
But sometimes it is great to have a visual representation. For instance when you discuss business related interfaces with people from the business. Eclipse is somewhat limited in this regard as it does not show the structures and types in context.

Visual Studio.NET comes with a great XML Schema designer which is part of the professional edition for a long time. Now Microsoft offers the Visual Studio.NET Community Edition which is a fully featured Visual Studio including the XML Schema designer for free.

Here you can see how it looks like:

It works even if the types are spread into several XSDs. And it shows the documentation. You don’t even need a Visual Studio project. Just drop the Schema into the IDE and off you go.

How to Link WSDL-Services To BPMN-Processes

Since BPMN2.0 it is not only possible to design processes but to also execute them using a process engine. The process flow has a appropriate visual representation in the standard. But executable processes are mostly data driven. They interact with external services and exchange data with them. In addition to that processes maintain their own internal state. So a common requirement is to model the process internal state and connect to external services using the service data representation. BPMN is capable to include data definitions based on WSDL and XML Schemas, although the capabilities of the tools (that I know) to visualize data are somewhat limited.

In this blogpost I would like to show you how data looks like in BPMN and how a process can be linked in a standardized way to existing services based on WSDL and XSD.

The process is as simple as possible. The service is based on a BiPRO service description. The BiPRO is a standardization organisation in the German insurance market that standardizes processes and services at a technical and business level.

WSDLtoBPMN

Below you see a simplyfied version in plain BPMN (when you import the bpmn below you will only see the events and tasks).


<?xml version="1.0" encoding="UTF-8"?>
<definitions id="definitions" xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
  xmlns:bpmn="http://schema.omg.org/spec/BPMN/2.0"
  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"  
  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"  
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://www.pleus.net/example"
  xmlns:tns="http://www.pleus.net/example"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  xmlns:nachrichten="http://www.bipro.net/namespace/nachrichten"
  xmlns:bipro="http://www.bipro.net/namespace"
  xsi:schemaLocation="http://www.omg.org/spec/BPMN/20100524/MODEL http://bpmn.sourceforge.net/schemas/BPMN20.xsd">
  
  <!-- WSDL Import -->
  <import importType="http://schemas.xmlsoap.org/wsdl/"
          location="KompsitService_2.4.3.1.1.wsdl"
          namespace="http://www.bipro.net/namespace" />

   <!-- Item definition. Link to the external WSDL/XSD structure. structureRef: QName of input element -->
   <itemDefinition id="getQuoteRequestItem" structureRef="nachrichten:getQuote" />
   <itemDefinition id="getQuoteResponseItem" structureRef="nachrichten:getQuoteResponse" />

   <!-- Message definitions. Link to the item definition. Can be visualized by using DI -->
   <message id="getQuoteRequestMessage" itemRef="tns:getQuoteRequestItem" />
   <message id="getQuoteResponseMessage" itemRef="tns:getQuoteResponseItem" />

   <!-- Interface definition. implementationRef = QName of WSDL Port Type -->
   <interface name="Komposit Interface" implementationRef="bipro:KompositServicePortType">
      <!-- Operation: implementationRef = QName of WSDL Operation -->
      <operation id="getQuoteOperation" name="getQuote Operation" implementationRef="bipro:getQuote">
         <!-- Links to the message definitions --> 
         <inMessageRef>tns:getQuoteRequestMessage</inMessageRef>
         <outMessageRef>tns:getQuoteResponseMessage</outMessageRef>
      </operation>
   </interface>
 
  <process id="servicecall">
 
   <!-- Datasources and targets for the service call (process state). Can be visualized by using DI and dataObjectReferences -->
   <dataObject id="dataInputOfProcess" name="Input for webservice" itemSubjectRef="xs:string"/>
   <dataObject id="dataOutputOfProcess" name="Output for webservice" itemSubjectRef="xs:string"/>
  
   <!-- Process start -->
   <startEvent id="start" />
 
   <sequenceFlow id="flow1" sourceRef="start" targetRef="initScript" />
 
   <!-- Initialization of process data -->
   <scriptTask id="initScript" scriptFormat="groovy" name="Initialize process">
     <script>
       def temp = "2.4.3.1.1"
       execution.setVariable("dataInputOfProcess", temp)
     </script>
   </scriptTask>
 
   <sequenceFlow id="flow2" sourceRef="initScript" targetRef="webService" />
 
   <!-- Web Service call -->
   <serviceTask id="webService" name="Call getQuote" implementation="##WebService" operationRef="tns:getQuoteOperation">
       
       <!-- Defines the inputs and outputs and links to item definitions -->
       <ioSpecification>
          <dataInput itemSubjectRef="tns:getQuoteRequestItem" id="dataInputOfServiceTask" />
          <dataOutput itemSubjectRef="tns:getQuoteResponseItem" id="dataOutputOfServiceTask" />
          <inputSet>
             <dataInputRefs>dataInputOfServiceTask</dataInputRefs>
          </inputSet>
          <outputSet>
             <dataOutputRefs>dataOutputOfServiceTask</dataOutputRefs>
          </outputSet>
       </ioSpecification>
       
       <!-- Defines the mapping between process data and service input -->
       <dataInputAssociation>
          <sourceRef>dataInputOfProcess</sourceRef>
          <targetRef>dataInputOfServiceTask</targetRef>
          <assignment>
            <from>
             bpmn:getDataObject('dataInputOfProcess')
            </from>
            <to>
             bpmn:getDataInput('dataInputOfServiceTask')/BiPROVersion/
            </to>
          </assignment>
       </dataInputAssociation>

       <!-- Defines the mapping between process data and service output -->
       <dataOutputAssociation>
          <sourceRef>dataOutputOfServiceTask</sourceRef>
          <targetRef>dataOutputOfProcess</targetRef>
          <assignment>
            <from>
             bpmn:getDataOutput('dataOutputOfServiceTask')/BiPROVersion/
            </from>
            <to>
             bpmn:getDataObject('dataOutputOfProcess')
            </to>
          </assignment>
       </dataOutputAssociation>

   </serviceTask>
 
   <sequenceFlow id="flow3" sourceRef="webService" targetRef="end" />
   
   <!-- Process end -->
   <endEvent id="end" />
 
  </process>

Now let’s look at the example step-by-step.

1. Import the service: Line 16-18 imports the WSDL file that includes the types and messages used by the external service that we want to call from the process.

2. Define the items: Line 21-22 defines items that act as links to the types defined in the imported WSDL and XSD files.

3. Define the messages: Line 25-26 defines messages to be used in the interface definition that we see in the next step. Messages can be visualized by modeling tools provided that DI Information is present in the model.

4. Define the interface: The interface is the equivalent to the WSDL port type in BPMN. It is defined in line 29-36. So far we have itemDefinitions that link to the XSD-messages and an interface that links to the WSDL-port type. The inMessageRef and outMessageRef elements use the messages defined in step 3 to indirectly reference the itemDefinitions.

5. Define the process variables: The process maintains state. This state is defined in the form of dataObjects in line 41-42. Please note that the links to the external service are defined outside the process (which begins in line 38). The dataObjects are defined inside the process as they represent the data that is maintained by the respective process instances. By the way, when importing the process in a modeling tool, dataObjects are not visualized. To visualize dataObjects as a paper sheet, dataObjectReferences can be used. In this simple example we just use a string as input and output which transports a version information send to the BiPRO service and back. In a more complex senario this could be a type from an imported XSD.

6. Initialize the process: A simple BPMN script task (line 50-55) is used to initialize the dataObject dataInputOfProcess. It just sets the version to 2.4.3.1.1.

7. Link the serviceTask: The most complex part is the serviceTask (line 60-102). The operationRef attribute (line 60) links to the operation which is part of the interface definition (line 31). This is the web service operation to be called when the serviceTask is executed. The serviceTask comprises the elements ioSpecification (line 63-72), dataInputAssociation(line 75-86) and dataOutputAssociation (line 89-100). ioSpecification can be seen as a logical port that describes the service input and output from the perspective of the service. The itemSubjectRef attribute on the dataInput and dataOutput elements (line 64-65) link to the itemDefinitions (line 21-22) and as such to the data structures in the WSDL files. The id together with the inputSet and outputSet (line 66-71) define the connection points the serviceTask offers for sending and receiving data. dataInputAssociation and dataOutputAssociation map the dataObjects (process data) to the connection points or in other words to the request and response structures of the service (service data).

When the serviceTask webService is called, the process data from the dataObject dataInputOfProcess is copied to the web service request message nachrichten:getQuote/BIPROVersion. Then the service is called. After the service call finished, the version is copied from the response message nachrichten:getQuoteResponse/BIPROVersion to the dataObject dataOutputOfProcess.

This blogpost has shown how to link WSDL/XSD based services to BPMN processes in a standardized way.
Even if automated process execution is not in focus, it can be important to unambiguously link services to processes to create an integrated view of the entire process including its data.

Schema first contract design

One of the most important artifacts in Service-oriented Architecture (SOA) is the service contract. The contract defines how service producers and consumers interact with each other. Most people agree that a contract first approach is the preferred way of creating service contracts. WSDL based service contracts are very common. In many projects they are generated by the respective frameworks, such as Apache CXF or Microsoft WCF. This is dangerous, as the developer looses control over the contract. This can result in missing interoperability and limited reusabilty expecially in cross platform scenarios.
From what I see, most developers know how to work with their favourite IDE, but only a few know how to create a proper service contract from scratch. I think that is caused by the tool vendors, which in most cases have better support for code based approaches.
In this post I would like to show how to create a portable contract from scratch and share some best practices.

The domain model

The first thing to think about is the domain or entity model that the service should expose. The model should be modeled in XML Schema. XML Schema is standard, portable and supported on all platforms. In fact it is a good idea to use XML Schema as the single source of model information.

The following listing defines the entity Product:
 



  
    
      
        
          Name of the product
        
      
      
        
          Quantity on stock
        
      
    
  

The entity Product has two attributes name and quantity. Please note that the xml elements (line 10 and 15) are abbreviated. This helps to reduce the message size on the wire, expecially important in WANs. The downside is obviously reduced readability. That is not really a problem as the contract should be documented anyway using the standard XML Schema annotation elements as shown in line 11 to 13.
This is the result:

Wouldn’t it be nice to have a common base class in order to create a more generic service contract?
Luckily XML Schema allows that. Let’s create another schema BaseTypes.xsd in which we define the base types.



  
    
      
      
    
  

  
    
      
      
      
      
    
  

  
    
      
        
          Unique key
        
      
      
        
          Status of the entity
        
      
    
  

This base type Entity (line 24) defines common attributes for all entities. In XML Schema one can define enumerations as well (line 8 and 15). The enumeration EntityStatus defines the state of the entity. This is important in scenarios in which the entities are detached from the database. By marking the entities, it is easy to implement change tracking on the consumer side and just return the changed or deleted parts to the server. This saves network and processing time. EntityType is used later in our service interface to request different types of entities.
We can now import the base types into Types.xsd and change the Product type:





  
    
      
        
          
            
              Name of the product
            
          
          
            
              Quantity on stock
            
          
        
      
    
  

You can see the import in line 9. In line 12 and 13 the base type is added to the Product type.

This is the result:
Entity with base class

Now we have our model completely defined in XML Schema. By using imports and type inheritance one can create very modular entity models. Those models can be reused without any change by interface definitions such as WSDL and WADL for SOAP or REST services. Moreover the code models (Java, C#, etc.) can be fully generated from the schema. Every good framework has a generator tool on board. For instance Apache Axis/wsdl2java, Apache CXF/wsd2java, Silverlight/slsvcutil, .NET/svcutil, etc. The schema can be stored in a service repository in order to increase reusability amongst the organisation.

The messages
Every service operation receives a message and returns a message to the sender. Those messages should also be defined using XML Schema. The following snippet shows the message definitions. The fault messages are ommitted for the sake of simplification.


    
      
    
  

  
    
      
    
  

    
        
            This represents a request to read business entities
        
        
            
                
                    
                        Type of the entities to read
                    
                
                
                    
                        Unique keys of the entities to read
                    
                
            
        
    

    
        
            This represents the read response
        
        
            
                
                    
                        List of entities
                    
                
            
        
    

Those are our messages:

ReadEntitiesRequest and ReadEntitiesResponse are bulk operations that allow to read multiple entities with one call. As you can see ReadEntitiesResponse does not return Products but Entities. Do you remember? This is our base class type for all entities. By using the base class, the message can return arbitrary entity types in the same message. This is an example for a strongly typed but yet extensible interface.

The schemas can be reused in WSDL files:



  
  
  
  
      
  
  
    
  
  
  
    
      
      
    
  

  
        
    
      
      
        
      
      
        
      
    
  
  
    
      
    
  

The type information and message definitions are completely externalized to individual schemas. As a result the WSDL is small. The imported types (line 4) are used to define the WSDL messages (line 7 and 10). A WADL file would look like this:



  
    
    
  

  
    
      
        

            
              
                This is the product id
              
            
          
        
        
          
        
      
    
  

The types are imported (line 8 and 9) and used to define the return message (25).
By using the respective tool, such as wsdl2java or svcutil, we can completely generate the model and messages for the client and server on JEE, .NET and other platforms.

Summary
As you can see it is not too difficult to create schema based service contracts in a platform agnostic way. If you do, you will be rewarded with a great level of control, portability and reusability. Powerful features of XML Schema, such as inheritance, allow to create robust and extensible service contracts, which are the basis for interoperability. And if you want, you can even use an XML editor. 😉