> Paolo, > > Thanks again for your advice. I'm using wsdl.exe to generate the proxy. > > What specifically about ConceptBean is "too complex" or otherwise non-interoperable? > > From my point of view, ConceptBean is an extremely simple object. Regarding the "logic" of the class, why does it matter? The bean serializer should only serialize state, right? Methods that don't start in "get" or "set", or aren't public, shouldn't matter. > > Basically, I need to know where to draw the line. Is the problem the depth of my object graph? Can beans only have primitives (and not other beans) as attributes? > > In a perfect world, I suppose my web service would only deal in primitives. In reality, I have an existing Java API that I would like to wrap with a web service. Perhaps I should look into custom serializers... > > In the meantime, I'll check your theory that the ConceptBean object is the problem by creating a new service that dispenses Form objects. > > - Matt >
==>Yes, logic shouldn't matter, as you say just only state is serialized. But I experienced the same kinds of problems as you do now, when I began developing WS. As I said, it is enough that you forget a setter or a getter for a member and .NET isn't able to translate the bean in a corresponding type. Pretty simple types, like hashtable, are mapped as "map" by Axis, but .NET isn't able to deserialize them. So, when I develop my services, I prefer to keep as much logic as I can into the Classes at Server side, and send simple beans (yes, you can use beans as attributes of a bean) as parameters. This is a common practice that lots of programmers teach. I didn't look in depth into your bean, but at a first glance I deemed it "hazardous" to be sent as a whole parameter, but maybe it is just only a matter of opinions.... Maybe it is ok and it is just only a matter of null object...in any case, keeping parameters simple simplify our life..... --P
