I'm sorry that I have to talk technology oriented. In this particular case the client only has access to abstract contract i.e WSDL. So if list includes the type i.e. List<SomeType>, it is possible to identify the content structure of "SomeType" but it seems to be very risky because based on some prototypes, some of the content might not be discovered if "SomeType" do not fully comply with a java bean convention (having getter/setter for all attributes). this is only for dynamic access to services
Sasan ________________________________ From: Michael Poulin <[email protected]> To: [email protected] Sent: Monday, August 24, 2009 12:49:21 PM Subject: Re: [service-orientated-architecture] Re: good or bad practice? or maybe ugly 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 <htshoz...@gmail. com> To: service-orientated- architecture@ yahoogroups. com 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 >> > >> >> > >
