Oh, this is a new stream: Java vs. XML. When I responded to initial post, I did not mean to open this new stream...
Anyway, I, personally, never ever considered XML as a data structure, it was always about semantics to me. At the same time, Java serialization is a Java object state snapshot, i.e. data structure. To use this data on the receiver side, we need to have a shared interface/class definition. This leads to programming coupling. Since you emphasis on serialization smart proxy, I can tell you that I can do exactly the same reduction of sent data with with XML, i.e. in the XML Schema, by manipulating with name-spaces. I am not a big specialist in Jini (though always wanted to be) but, to my understanding, smart proxy can be designed as a wrapper of the remote call or even as a replica of remote service acting locally, on the client side. This only confirms, IMO, that the client and service sides have to share the same Java interfaces/classes if not packages (due to the requirement of serialization object tree). This is a clear coupling, isn't it? I have mentioned XML only as an example of decoupling code on the sender and receiver sides because with services (even in Java) we are more and more getting in the the world of different authorities and ownership that prevents sharing packages (libraries). Now, about productive development. If one is very productive today and produces simple and straight-forward code that couples everything, I would say it is very much contra-productive for services. Yes, SOA services require different understanding of may traditional things. If you want, this is about 'what should be done' rather than 'what can be done'. Could you, please, elaborate on your example with JavaScript with regard to this discussion? -- Michael ________________________________ From: Gregg Wonderly <[email protected]> To: [email protected] Sent: Monday, August 24, 2009 8:57:49 PM Subject: Re: [service-orientated-architecture] Re: good or bad practice? or maybe ugly 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:* service-orientated- architecture@ yahoogroups. com > *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 > > > > > > > > > >
