This is where I strongly disagree with your "world". XML is a "type" of data that is "application specific" and has "limitations" right in line with any other "form" of transport. Failing to understand that XML is a documented standard of "structure" and "format" and that there are other such standards, including Java's serialization structure is, to me, just simple ignorance.
It's important to understand what is constructive power and what is destructive power. XML as a data transport has only served to divide the power of programming languages and create a completely new form of commerce that is extracting the wealth of many a company by causing a reinvention of so many things that have already existed, for years if not decades. Sound like a rant? Maybe so, but I'd like to see the count of hands of people that have had ZERO and I mean ZERO issues with making XML data transport work well. If it didn't help people be more productive it wasn't an improvement, and I've yet to see people say that it's working like a champ. Java serialization supports mobile code and that means you can get smart proxies into applications to mascarade new data and APIs as if they were old without changing the client. As soon as you change the structure of your XML, you have to still send everything that anyone needs without any hope of minimizing the network traffic. With mobile code, you can send only the data that actually needs to go, and rely on the smart proxy/mobile code to manage the interface to the client. If you are not sure that mobile code is important, look at all the "semantics" that are creeping into more and more XML so that it's not really data, it's data that has a meaning in specific contexts of other data over time. Look at how important javascript is to web applications now... Is it wrong to send javascript to a web browser because that is "native" code from the browsers perspective... Gregg Wonderly Michael Poulin wrote: > Any List object or any Object is worth than XML because any object pro > grammatically couples consumer and service. XML, in the contrast, > represents a declarative loose coupling via the XML Scheme. > > That is, an exchanging Objects written in any programming languages is > not the good practice for SOA Services. This practice is similar to > bearded RPC and suitable only for the cases where the same development > team/developer controls both consumer and service sides ALWAYS(!) If > this is the case, why anybody would need a SO implementation? > > The definition of type Object in Java is available only starting with > jdk 1.5, earlier versions do not have such feature. > > - Michael Poulin > > ------------------------------------------------------------------------ > *From:* Gregg Wonderly <[email protected]> > *To:* [email protected] > *Sent:* Friday, August 21, 2009 11:32:06 PM > *Subject:* Re: [service-orientated-architecture] Re: good or bad > practice? or maybe ugly > > > > 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> > > <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 > > > > > > > > > >
