Oh, this "an intermediary"... In this case, Hitoshi-san, what the consumer knows about the service interface - is it with a List or with a non-List? If it is with the List - problem not only stays but gets worth; if the consumer gets a non-List, do you wan the intermediary be so smart to know what transformations are needed for each consumer (assuming that service interface is with List)? I do not even talk about Service Contract where all service interfaces must be agreed with the consumer (and the intermediary is invisible; we talked about it already in this Forum). What the purpose of having List on the sender side while receivers need have non-Lists?
- Michael ________________________________ From: Hitoshi Ozawa <[email protected]> To: [email protected] Sent: Sunday, August 23, 2009 11:23:06 PM Subject: Re: [service-orientated-architecture] Re: good or bad practice? or maybe ugly Hi, On a local call, using List with TypeOf can be used. List is just a handy way to allow different subclasses of List to be passed. When using on a network interface, more consideration is necessary. It is possible to predefine elements in a List both at both ends but this doesn't make too much sense because it defeats the meaning of using List. What is possible is to predefine a structure so it will contain both the definition and the data. In this case, you'll actually be extending the interface standard, which means you shouldn't be using it for a public service. It's, nevertheless, is convenient when creating a 1 supplier to N consumer format with a List being used between a supplier and an intermediary and an intermediary converting the List to a non-List's. :-) H.Ozawa 2009/8/22 Gregg Wonderly <[email protected]>: > > > 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 >> > >> >> > >
