IMO, this is an auful practice! The problem is not in that the receiver does not know particular type of the objects but in that the method'd parameter is the object.
This parameter explicitly couples the service consumer with the service, which is not acceptable in SOA (even in 'technical SOA'). Any RPC-like service interface is an architectural Error - this RPC revokes the platform independence, couples the sender and received code (the receiver in this case must understand what any object means and in which version it may be used)and delivery processes, and so on. If I would be an architect reviewing this code, it would be the strict 'no-go' review result. --- In [email protected], 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 >
