6 Replies Latest reply on Jul 27, 2006 5:05 PM by wconroy

Type Hiererchy

wconroy Jul 25, 2006 4:48 PM

If I have the following classes

public class Animal {
...
}

public class Cat extends Animal {
...
}

public class Dog extends Animal {
...
}

and the following method exposed through a web service

public Animal[] getAnimalsByOwnerName(String ownerName) {
...
}

I am using the javax.jws annotation and deploying without running wstools or anything and it looks like the definition of Cat and Dog are not in the wsdl that gets generated. Does JbossWS not support type hierarchies like this? If they do, is there anything that I need to do to get it to work correctly? Do the WSTools java-wsdl do anything that the annotations alone will not do?

Thanks,

Bo

1. Re: Type Hiererchy

heiko.braun Jul 26, 2006 10:28 AM (in response to wconroy)

Could check if it relates to JBWS-1010?
Actions
2. Re: Type Hiererchy

wconroy Jul 27, 2006 2:26 PM (in response to wconroy)

It doesnt look like it. correct me if I am wrong, but it looks like JBWS-1010 has to do with exposing every method in every parent interface for the service. I am more talking about the return types on a method. Take the following interface

public interface GetAnimals extends Remote {
public Animal[] getAllAnimals();
}

using the animal class defined above. Looking at the WSDL generated for this I dont see Dog or Cat show up anywhere. Is that not valid for web services? Do I need to have separate getAllCats and getAllDogs methods that specify the exact return type?

Another small complication is that I am trying to use the annotations and am not using wstools. Do the 2 generate identical wsdl files?
Actions
3. Re: Type Hiererchy

arnowerr Jul 27, 2006 3:58 PM (in response to wconroy)

Looking at the WSDL generated for this I dont see Dog or Cat show up anywhere. Is that not valid for web services? Do I need to have separate getAllCats and getAllDogs methods that specify the exact return type?

Me neither. Yet I think it's correct.
Ask yourself for which purpose in Java-to-Java communication you would need such heavy web service implementation as SOAP (standard? marketecture over architecture?). In Java-to-Java there are plenty much lighter alternatives - just look at Spring remoting.

We really need SOAP when we communicate with non-Java client/server - interoperability. And what if that non-Java platform does not support all/some features of OOP including inheritance? So SOAP web service is the lowest and heaviest possible denominator. Use concrete classes instead - exact return types.
Actions
4. Re: Type Hiererchy

wconroy Jul 27, 2006 4:12 PM (in response to wconroy)

That doesnt make sense. If I have getCats() and getDogs(), then look at the wsdl, it creates a type Animal then, then has Cat and Dog that extends it. How non object oriented languages handle it is their own business, but the wsdl allows hierarchies as do the the SOAP messages.

That being said, can I expose the base class in my interfaces and the wsdl will generate the correct complex types for all of its subclasses?
Actions
5. Re: Type Hiererchy

arnowerr Jul 27, 2006 4:45 PM (in response to wconroy)

In my view what makes sense and what doesn't in the world of JAX-RPC/WS, we shouldn't look at www3c specifications, but rather at Web Services Interoperability Organization's Basic Profile 1.0/1.1. This is the only standard that have been proven in production and is explicitly required by the J2EE Web Services platform. Hey, lots of stuff which is allowed in www3c specs is actually either not implemented or bluntly prohibited by WSI Basic Profile. For instance, although SOAP supports four modes of messaging (RPC/Literal, Document/ Literal, RPC/Encoded, and Document/Encoded) the BP permits the use of RPC/ Literal or Document/Literal only. Although SOAP is protocol agnostic, Basic Profile permits only HTTP and so on and so on. All these restrictions are in the name of interoperability between different platforms some of which are not object-oriented. To my knowledge, for instance, the Basic Profile prohibits operation overloading. Every operation defined by a particular portType must have a unique name. That said, it's perfectly acceptable for two or more portType elements to declare operation elements with the same name, because each portType is considered a separate definition.
So, we'd better check Basic Profile regulations on this inheritance issue. But, like I said, I see the reason why this might not work - again interoperability.
Actions
6. Re: Type Hiererchy

wconroy Jul 27, 2006 5:05 PM (in response to wconroy)

I am looking at this

http://www.ws-i.org/Profiles/BasicProfile-1.1.html

and it doesnt mention anything about the complex types with extensions from what I can see.

At any rate, is it really the policy of jbossWS to develop features that only work in the lowest common denominator? not adding features because not all possible consumers are object oriented seems kind of odd. doesnt it make more sense to give those developers creating services as many tools as possible and allow them to choose whether they want to use features not all languages can consume.

Anyway, the complexType extension stuff is really just a simple way to define the schema and allowed attributes. it doesnt matter if you are object oriented or not, the xml parser should be able to use this to validate.
Actions

Go to original post