+1. Client and server should also be completely arbitrary to make the system loosely coupled. Otherwise, we'll just end up with just a rewrite of the old system.
H.Ozawa Robin wrote: > 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. >>> >>> >>> >>> > > > >
