I'd like to thank all people who helped me with the thesis by providing comments to this blog and other information.

A special case is the evolution of complex objects. The type of an object needs to be declared and needs to be known on both sides of interacting partners.

I found a more flexible approach using a self-describing ontology. This means the object type is described by meta data which is exchanged between the partners, too. By this the object type may change and the change is automatically transferred.

Both partners need to be able to understand this meta data. If they do, objects may change as they like.

A simple idea how this can be achieved without using different namespaces and without the need that the consumer needs to know that there is versioning support is the following:

A fixed value is used for the version information. This way the version information automatically filled in every SOAP message and the consumer does not need to care about it. It just uses a certain WSDL description at one point in time, reads that it needs to send a fixed value in every SOAP message and that's it.

My list so far:

• Changing Operation Name: convertible
• Adding an operation: no influence on existing service
• Deleting an operation: not convertible
• Changing parameter name: convertible
• Adding a parameter: convertible (use default value)
• Deleting a parameter: not convertible
• Combining parameters to a complex object (or other way round): convertible
• Changing parameter order: convertible (or no influence?)
• Changing data types of parameters (simple data types, complex objects, hierarchy or not?): may be possible to convert for simple data types and objects in a hierarchy
• Changing return data type: same as above

You can think of the XML elements on their own, too:

• Renaming an element: convertible
• Adding an element: convertible (default value)
• Deleting an element: not convertible
• Changing from element to attribute (and other way round): convertible
• Moving a node up or down in the XML tree: convertible

Can you think of other changes? I have to think of how convertible parts can be converted (something like mapping functions).

My idea:

If a consumer sends a SOAP message to the provider that conforms to an earlier version of a WSDL than the current one it may be not accepted by the Web service stack.

It should be possible to create an interceptor/proxy that is aware of the old and the new WSDL (and knows how to convert from old to new messages). The old message (which is not conform to the current WSDL) is converted (maybe XSLT is a good choice) to a new message that conforms to the current WSDL and then it is send to the service.

The part I am not sure about is how the WSDL and a SOAP message can be labelled with a version information. Some possibilities are stated in Best practices for Web services versioning.

It is possible to use a new target namespace for the WSDL, but all data is changed to the new namespace this way. Another possibility is to use a version-aware UDDI registry.

It would be fine if the WSDL had a version field. Maybe it is possible to define a version information somewhere in the WSDL. The SOAP message may be labelled with a version information in a SOAP header...

Sample main program:

public class Test{
  
  @WebService
  public static void sayHello(String name) { }
  
  public static void main(String args[])
  {
    sayHello("Tom Sawyer");
  }
}

You think this does nothing, right? Correct! But it works using an aspect:


public aspect TestAspect {
  
  pointcut execWebService() : execution(@WebService * * (..));
          
  Object around(): execWebService()   {
    //Handle request and send SOAP message...
  }
}

This way the request is handled by the aspect.

This is just an uncommon idea of a Web service proxy. The developers of the consumer don't have to know about proxies. They may wonder about the empty Web service method in the main class, only.

Why would someone need to return void as return value? If there is no return value, you may return null or declare the method void instead of trying to return void.

The idea is that a service consumer is changed automatically if the Web service itself changes. At first, I'd like to look at simple examples, like changing a method name or changing the return type to void.

For example this would mean that if a method of the service is changed from public void hello(); to public void helloWorld(); the consumer is changed to helloWorld(), too (i.e. the SOAP message contains the new method name).

This is the idea. I'm not sure how to implement this idea, yet.

Here are some things I thought of:

• Using aspect-oriented programming (good tutorial here). But I don't know yet, how to use it to automatically change the consumer...
• I tried to use Java 5 Instrumentation, too (tutorial part 1, part 2). But this seems to be very complicated, because you need to work directly on the byte code.

I have to think about what needs to be changed on consumer side. I don't think that you have to change the consumer classes directly, but the SOAP message that is sent, only.

Maybe like this:


public interface HelloWorld{
  public void sayHello(String name); }


is mapped to


<sayHello>
  <name>Tom Sawyer</name>
</sayHello>


Problems occur if method name or parameter names are changed (either on consumer or provider side). The names won't match anymore.

My idea to solve this: Make the mapping of names independent from the names used in the programming language. This is achieved using meta-data for method and parameter names (annotations in Java). This may look like this:


public interface HelloWorld{
  public void
    @methodAnnot(methodName="helloThere")
    sayHello(
      @paramAnnot(paramName="nameOfGuy") String name); }


that would be mapped to


<helloThere>
  <nameOfGuy>Tom Sawyer</nameOfGuy>
</helloThere>


Now you are independent of names in the programming language, i.e. you can change sayHello or name to anything you want as long as the annotations are not changed.

Mapping simple data type fields is easy. Mapping references to other objects is done by including the referenced object as child XML nodes.

A simple example (simplified version, better would be getter/setter methods):


public class Person{
  public String name;
  public Person relatedTo;
}


A person with a reference to another person could be mapped like this:


 <person>
  <name>Donald</name>
  <relatedTo>
   <person>
    <name>Daisy</name>
    <relatedTo />
   </person>
  </relatedTo>
 </person>


So Donald is related to Daisy, but Daisy not related to Donald. If the inclusion process is continued, it would cause problems if Daisy is related to Donald, too. These are cyclic references and this way of mapping would include Donald in Daisy and Daisy in Donald continuing unlimitedly. There needs to be another way of mapping cyclic references.

A possible solution:

• Each object is added to an Object Hashtable and gets an ID
• If a reference to an object should be mapped, the object is looked up in the Hashtable.
• If the object is found, a reference to the ID is mapped only.

The same mapping with Donald related to Daisy and the other way round looks like this:


 <person id="1">
  <name>Donald</name>
  <relatedTo>
   <person id="2">
    <name>Daisy</name>
    <relatedTo ref="1" />
   </person>
  </relatedTo>
 </person>



class Person{
  @Annotation public String getName() { ... }
}


has an annotated method getName() but for


class ExtendedPerson extends Person{
  public String getName() { ... }
}


getName() is not annotated.

I found a blog entry that describes this problem, too. It is called Annotation Design Patterns. A comment in this blog supposes to use the @Inherited meta-annotation when the annotation is defined, but I found no difference between using this meta-annotation or without using it. The annotation on the method is not inherited. I tried to use the meta-anntotation @Override for the method, too, but no difference at all.

Of course, if the method is not overridden in the child class the annotation is present, because the method of the parent class is used (which is annotated).

It is not a big problem that annotations are not inherited, but it would be easier if the annotations would not need to be repeated everytime.

Is there a better way to inherit annotations or it is not possible at all?

I tried a first approach to loosen this problem using dynamic proxies. For that I wrote a proxy myself that is based on Java 1.3 dynamic proxies.

The advantage is that the remote procedure call is as easy as before and it is possible to change the service without the need to regenerate the stubs and ties. In this case changing the service means that both sender and receiver are changed in the same way.

Nevertheless if sender and receiver have different method interfaces (e.g. the sender thinks the method is void helloWorld(String name) and the receiver's implementation uses void helloWorld(String name, int age) the dynamic proxy approach fails, too (i.e. same RPC problems occur as described earlier).

If the service is changed and all service consumer get the new method interfaces there is no need to regenerate the stubs and ties anymore.

The article mentions that dynamic proxies are an advantages for Web services/SOAP, too, because there are no additional stubs that need to be generated but there is a dynamic proxy for everything.

I didn't read the article completely, yet. May this be a way to implement the suggested second concept of "intelligent proxies" for my master thesis?


public static void main(String[] args) throws Exception
{
 DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
 documentBuilderFactory.setNamespaceAware(true);
 DocumentBuilder documentBuilder = documentBuilderFactory.newDocumentBuilder();
 XPath xPath = XPathFactory.newInstance().newXPath();
 Document doc = documentBuilder.parse(new File("C:/test.xml"));
 Node node =(Node) xPath.evaluate("/address", doc, XPathConstants.NODE);
 System.out.println(node);
}


The corresponding XML file looks like this:


<?xml version="1.0" encoding="UTF-8"?>
<address xmlns="http://wsiftypes.addressbook/" />


On the first view the XPath expression "/address" should match the root element "address" of the XML document. But this does not work. The resulting node is "null".

The element "address" is assigned to the namespace "http://wsiftypes.addressbook/" and must be used in the XPath expression. Because it is not possible to map this namespace to an empty prefix it must be mapped to a named prefix.

The above code is changed to use an Implementation of the interface NamespaceContext that maps namespaces to prefixes and the other way round. So using the default namespace works like this:


public static void main(String[] args) throws Exception
{
 DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
 documentBuilderFactory.setNamespaceAware(true);
 DocumentBuilder documentBuilder = documentBuilderFactory.newDocumentBuilder();
 XPath xPath = XPathFactory.newInstance().newXPath();
 Document doc = documentBuilder.parse(new File("C:/test.xml"));
 NamespaceContextImpl nci = new NamespaceContextImpl();
 nci.setNamespaceURI("typens","http://wsiftypes.addressbook/");
 xPath.setNamespaceContext(nci);
 Node node =(Node) xPath.evaluate("/typens:address", doc, XPathConstants.NODE);
 System.out.println(node);
}


• Sun XML Instance Generator (Supports DTD, RELAX, TREX, Part of XML Schema. Can generate invalid documents, too)
• XML-XIG (Early stage SourceForge project)
• Microsoft .NET XmlSampleGenerator (limitations: xs:key, xs:keyref, xs:unique, xs:ENTITY, xs:ENTITIES and xs:NOTATION not supported, incomplete support for xs:pattern and xs:base64Binary)
• Altova XMLSpy (Commercial product)
• My own implementation so far (xs:pattern, xs:substitutionGroup, xs:any, xs:anyAttribute, xs:key, xs:keyRef, xs:unique, xs:notation, xs:annotation not supported, yet)]]> http://www.innoq.com/blog/dm/2006/04/generating_xml_1.html http://www.innoq.com/blog/dm/2006/04/generating_xml_1.html Tue, 11 Apr 2006 17:29:28 +0100