If I use an arbitrary List or array of objects of simple data structs, my addressee will be in the high and constant risk of misreading my message. I would not use a service which forces me to guess what I've got from it.
- Michael ________________________________ From: Chris Deweese <[email protected]> To: [email protected] Sent: Saturday, August 22, 2009 8:14:24 PM Subject: Re: [service-orientated-architecture] Re: good or bad practice? or maybe ugly Just to add, because I have seen this with both .NET and Java. Serializing List<T> can generate some ugly Xml, so if you need to serialize a list, I would recommend an array instead. Internally you can use a List<T> and then simply convert that to an array when you return from the method. The code for doing that should be pretty trivial. Exposing a base type like object generates an xs:Any which can lead to very fun interoperability issues and at that point it is a guessing game as to what you should send to the service; especially if you do not know the authors of the service. I agree with the other comments that you are generally better off using a specific message defined to contain everything the service needs to do it's work. Chris On Fri, Aug 21, 2009 at 5:32 PM, Gregg Wonderly<[email protected]> wrote: > > > In this particular case with Java, the interface can include generic type > references on the List to control the types of things sent to it. > > public int method(List< DataObject> lis) > > helps software developers know exactly what kind of list should be passed. A > List is not any worse than a XML document or a stream of some other > structure > values. It is important to understand that exporting "DataObject" in the > interface definition does create a type base dependency that you have to be > ready to manage the life cycle of. > > Gregg Wonderly > > jesseezell wrote: >> >> >> Best practice with service interfaces is to pass messages that have been >> specifically crafted to contain information about the requested >> operation, not lists of objects. Any interface where you are basically >> just taking a call that could have been a local method call and exposing >> it over the wire may be a web service, but that doesn't mean it's >> service oriented. It is often a good idea not even to use objects from >> your domain model directly, because you want your service interface to >> be stable. >> >> --- In service-orientated- architecture@ yahoogroups. com >> <mailto:service- orientated- architecture% 40yahoogroups. com>, Sasan >> <sasanp...@. ..> wrote: >> > >> > Hi, >> > >> > Is it good practice to have a service that exposes a method with a >> List of objects as a parameter? Programmatically speaking from Java >> programming point of view java.util.List. >> > >> > Example: >> > >> > public int method(java. util.List objects) >> > >> > Even if the interface is documented, I do not see this as a good >> practice cause this tells me the method takes a list of basically any >> object type. This could be troublesome for clients that discover >> services dynamically. >> > >> > I appreciate all opinions on this. >> > >> > Thanks, >> > Sasan >> > >> >> > > -- Chris Deweese, Microsoft MVP, Solutions Architect http://christopherDeweese.com
