Yes, "Sometimes, interfaces are pre-determined". Then here are the questions and suggestions: 1) if you cannot modify the interface to make it less granular and you have "slightly different data from multiple sources" but you want to use the same service (with the same interface), how this would work if the data does not match the interface?"slightly different data from multiple sources" 2) if you need a data format transformation between consumer code and service code, you have to control one side, at least (because if you do not, you are looking for troubles getting in between). So, if you cannot change the interface while controlling the service, I would created another interface, less granular, and gracefully transferred all consumer on that one rather than delegate my communication with my consumers to uncontrolled (by me) intermediary that I have to be responsible for to my customers anyway. If I control consumer, why I cannot change it to accept "slightly different data from multiple sources"? 3) an intermediary that intercepts exchange of business data (for the purpose of transformation) interferes with business services, which I think is unacceptable because it compromised the business service integrity. Example: assume, we need just a part of data structure provided by a service. We can a) assign data transformation to an intermediary and become totally dependent on its life-cycle, behavior, internal policies, etc. or b) we can develop a simple (at the beginning) service-adapter, which will perform data transformation into our format from any other current and future formats; in this case, the client controls everything it needs. 4) Doesn't ESB that transforms data formats create coupled dependencies instead of de-coupling (as promised)?
- Michael ________________________________ From: Hitoshi Ozawa <[email protected]> To: [email protected] Sent: Tuesday, August 25, 2009 1:35:15 PM Subject: Re: [service-orientated-architecture] Re: good or bad practice? or maybe ugly 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 <m3pou...@yahoo. com>: > > > 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 >>> > >>> >>> >> >> > >
