I'm not sure on completely arbitary. But I do tend to use such tools but I have two simple rules,
1) Never expose directly, always use a Facade pattern 2) Never consumer directly, always use a proxy pattern These two simple things provide you with the ability to evolve elements independently. Steve On 11/12/06, Hitoshi Ozawa <[EMAIL PROTECTED]> wrote: > > > > > > > +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. > >>> > >>> > >>> > >>> > > > > > > > > > > > >
