Web Service using Axis 2: Complex type or simple type parameters?

Question

The question is a specialization of:

http://stackoverflow.com/questions/403058/oo-style-parameters-vs-type-parameters

What if you want to define a Web Service operation? To have parameters beeing passed as complex types like this

public String insertPerson(Person person);

seems pretty cool since you're able to change the definition of Person without changing the interface definition. But what if another WS Client implemented in C/C++ (e.g. with gsoap or axis2c) uses this definition. Could it be a problem to access the Web Service implemented using Axis2 in Java? May be it's more safe to use the simple parameterized approach:

public String insertPerson(long id, String name, String personalId);

I'm not quite sure about that. What do you think?

Fred

Answer 1

A good Web Services framework will be able to understand the complex type. Some tweaking may be necessary. Axis2 can cope with it.

I generally prefer the parameterized approach, especially if the count of parameters is small (no more than 4). It has the advantage that the WSDL file and the generated SOAP message are easier to write and read. This is very helpful for testing and debugging.

Answer 2

I strongly prefer the first approach.

But be aware that changing the Person type does change the interface. The interface (calling convention, ...) of a Webservice is defined by the WSDL and the XML Schema it includes (or references). If you change any of those, you're changing the interface of your web service.

If you look at it purely from the Java point of view, then you should treat it as if the Person class (and any other class it references!) is part of the Interface of the web service!

The good thing is that you can do compatible changes to the Person class (or to be more precise: the complex type/element represented by the Person class) without breaking older clients. Adding an optional element or attribute is a good example. New clients can use it and old clients won't know about it, but won't break (since the server doesn't enforce its existence).