« April 2006 | Main | June 2006 »
May 31, 2006
Independent mapping of methods and parameters
How are Java methods and parameters mapped to be included in a SOAP message (e.g. when calling a remote procedure of a Web service)?
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.
Posted by Dominik Marks at 12:29 PM | Comments (3150)
May 26, 2006
Mapping complex objects to XML: Cyclic reference problems
I'm trying to map complex objects to XML to be able to transfer the object data from a client to a Web service. The data fields are transferred only, i.e. the object is mapped and not serialized (like Java serialization).
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>
Posted by Dominik Marks at 2:42 PM | Comments (6933)
May 25, 2006
Annotation Inheritance
According to JSR-175 annotations are not inherited in a class hierarchy, i.e.
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?
Posted by Dominik Marks at 10:20 AM | Comments (1774)
May 13, 2006
More flexibility for Web services using dynamic proxies
The normal Web services tools generate static stubs and ties for RPC style programming. Every time the service is changed these stubs and ties need to be regenerated.
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.
Posted by Dominik Marks at 12:35 PM | Comments (61)
May 1, 2006
Intelligent proxies
I found an interesting article about dynamic proxies. It is called "Praktische Anwendungsszenarien des Dynamic Proxy API".
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?
Posted by Dominik Marks at 11:16 AM | Comments (0)