Service contract with the consumers can be fixed. It's just gathering similar but slightly different data from multiple sources. Sometimes, interfaces are pre-determined. :-)
H.Ozawa 2009/8/24 Michael Poulin <[email protected]>: > > > 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 >>> > >>> >>> >> >> > >
