Services operations in a real world will quite always return an element that is described in XML schema notation using a complex type. If the developer uses a tool that is marshalling/unmarshalling the XML element into an object, this marshalling/unmarshalling should not tightly couple the Object model(=value object model) to the XML schema. If you do this, it means any change in any XML element will potentially break your client. <http://blogs.ittoolbox.com/eai/applications/archives/the-web-services-wise-man-9598>
I would strongly advise not to use this kind of marshalling/unmarshalling tool unless it is change-tolerant. For example the mapping between the XML and the Object model can be configured without changing the code. Robin --- In [email protected], Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote: > > You're missing Viju's point, Steve. Of course it's easy to build > services that utilize complex objects. Viju's question - a deep and > important one, imho - is about limitations on the client, not on the > server. I hope Viju won't mind if I paraphrase it: > > /If a service returns a "complex object" - i.e., an object whose > properties are not all primitive - then what are the limitations on the > client?/ > > Many services are produced on the assumption that the consumer uses a > code base related to that of the producer - including, for instance, > interfaces that can be used as proxies for the objects returned by the > service. If this is true, it makes a mockery of a key part of the SOA > concept, namely the supposed independence of producer and consumer. But > what client technologies allow you to call services from anywhere, > without access to the producer's code base, and utilize programmatically > the complex objects that are returned? > > I have asked exactly this question before to this group > <http://tech.groups.yahoo.com/group/service-orientated-architecture/message/2400>, > since I have been looking for solutions since 2001. And the _only_ > practical suggestion I got was from Aleksander Slominski, whose XSUL > project <http://www.extreme.indiana.edu/xgws/xsul/> includes a "Super > Dynamic Invoker" (based on WSIF, which I also used in an earlier attempt > to deal with the problem). > > As you say, Steve, "there should be no limitations" - but there > certainly appear to be at the moment. > > -- > > All the best > Keith > > http://keith.harrison-broninski.info > > Steve Jones wrote: > > > 1) Service is a business concept > > > > So I'm assuming you are talking about WS-*. If you can't return > > complex XML schemas from your WS-* implementation then quite frankly > > its rubbish. There should be no limitations. > > > > Steve > > > > > > > > On 06/12/06, *darlin' Viju* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > All, > > > > Is there any limitations for the return type of a service ? > > My understanding is the service should return only primitive types > > and objects which has primitive types as variables. This is to > > ensure that the service can be used across languages. > > Is this correct or is it like there is no limitation at all? > > Is it posible to return an xml from a service? > > > > Thanks, > > - d Vj > > > > ------------------------------------------------------------------------ > > Check out the all-new Yahoo! Mail beta > > <http://us.rd.yahoo.com/evt=43257/*http://advision.webevents.yahoo.com/mailbeta> > > - Fire up a more powerful email and get things done faster. > > > > > > >
