« May 2006 | Main | July 2006 »
June 19, 2006
Convertible and unconvertible Web service changes
I'm thinking about the possibility to convert incoming SOAP messages so that they conform to the current WSDL. Therefore I'd like to list up all possible changes to a message and if these are convertible or not.
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).
Posted by Dominik Marks at 11:59 AM | Comments (0)
June 12, 2006
Web service versioning
There are several approaches to allow Web service versioning.
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...
Posted by Dominik Marks at 9:53 AM | Comments (3255)
June 8, 2006
Uncommon idea for consumer proxies
RPC-style communication use proxies to hide the communication between Web service consumer and provider. Here is another idea how to use a proxy on consumer side. For this idea the consumer doesn't even have to know that there is a proxy.
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.
Posted by Dominik Marks at 9:32 AM | Comments (1307)
June 7, 2006
Is void a data type?
Found an interesting discussion about if Java void is a data type or not.
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.
Posted by Dominik Marks at 12:10 PM | Comments (100)
June 6, 2006
Automatic adaption to Web service changes
I'm just brainstorming about a new concept in the Web service area.
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.
Posted by Dominik Marks at 10:27 AM | Comments (6)