Hello,

I am fairly new to Web Services. I am working on developing a web service for exposing a rules engine to other business units in my organisation. My Java OO design for this rules engine defines method signatures that take high level interfaces as parameters and return high level interfaces as return values. clients can then cast those objects to whatever they asked for... Thus, the same method signature can mean many different things to clients - i.e. polymorphism. however, when i tried to generate a web service from this existing design, my wsdl generator (BEA weblogic to be specific) gave me errors saying that Objects that are to be serialized should be concrete implementations and not interfaces or abstract classes. this basically means that i will have to provide specific multiple web services for each different client. for every new client that i sign on, i will have to define new web services...

is this understanding correct? Or have I missed some important point somewhere?

-Eagle

Web services were designed to be cross-boundary and cross-platform. You can implement a SOAP web service client in cobol or assembler or whatever language you wish as long as it can construct an XML representation and send it over a TCP socket. Your post states "clients can then cast those objects to whatever they asked for". Casting assumes language specific feature on the client. SOAP web services does not require such language features to be present in a Web Service consumer why such specific language features do not have meaning in SOAP.

If your web service defines taking an interface as a parameter, and a web service client was to send in a data structure which matches the structure of that interface, how would you (or rather the web service plumbing) on your side know what implementation of that interface to create an instance from?

When the WSDL is created it simply states the data members of the structure to be exchanged. It might look like an object but in reality Web service invocations are exchanges of data structures (not objects). Tools on various platform can make SOAP look more 'object like' on the sender and receiver's side through generation of class stubs etc. but under the cover it is still data structures expressed through XML.

Thanks... that really does bring the perspecitive i was missing. However, the subject matter is still not addressed... The matter is: why do you need to define the service as one that contains concrete objects? Regardless of language, one should be able to define a service that provides you a certain type of data... what is contained in the SOAP message can be a runtime decision. I can think of this in terms of the old world MOM systems. lets say you have a cobol app on one side and a JAVA app on another. lets say that the cobol app places a message on an IBM MQ series MOM Topic and the java application picks it up via JMS interface. this is a very real world example. Still, the Topic need not re-established for each concrete implementation.

Basically, the question is why do we need new plumbing for each implementation. There should be some way that Web Services (or any service) are able to provide responses to any service request... shouldnt there be?

If you think of it from the runtime engines perspective, how based on the interface will it be able to allocate memory etc for what has been specified. Think of it this way, if you provide an interface, where will the runtime understand the details of the object which its going to receive. So it needs to have place holder (in terms of memory/resources) for the data its receiving.

Apart from that, if you think of it actually interfaces do not have any member variables, so the same issue comes again, what's the object type basically for which it has to allocate memory, before invoking the actual function.

Frankly speaking if you just rethink the desing, if you are accepting interfaces you might aswell accept a concreat class which is inherited. Cause if its being inherited/implemented, then it surly will have a few member variables too common across the interface implementations, so why not make it a concreate class and let others inherit from that, and share the common variables from the parent class.

I am not sure if I have explained it clear enough, but hope it helps.

Rakesh.

Hello,

Thanks for your suggestion related to rethinking my design. I could change my design if i found a design worthy reason for it. For now, I am trying to figure out - in my case - why is deployment dictating design. It will be great if you could share any thoughts about that.

Eagle