Sorry, Greag, I did not mean to push you :-) By coupling I meant programming coupling which threats usability. There are no totally decoupled things in the interaction (otherwise there will be two monologues).
Java and XML do couple but if Java/C# couples by compilation and semantics, XML couples by references and semantics. None of the elements in your XML exist on its own, it has to be defined in an XML Schema. However, you can have one Schema for the whole document - for all elements, or individual Schemas for each element (it is a bit of extreme but if you want full structure flexibility, you can have it). Then, if you consumer know only a sub-set of your Schemas - this is what the consumer want to receive - you can send the same document partially; plus, the consumer can use different (preliminary agreed - this is the coupling) Schema for request or require particular Schemas to be used in the responses. Now, preliminary agreed Schemas are also not that strong level of coupling as in Java because the agreement may be about two tings: 1) locations of the XML Schema; 2) ontology (vocabulary) that may be potentially used. This allows changing even the Schemas on the fly if both sides understand the same ontology. The deployment of code and code modification in the consumer and service sides remains immutable. Using technique like XMLBeans, I can generate the full or partial documents from XML-to-Java and from Java-to-XML having both controlled by XML Schema (another use of this thing is data quality control in Java since I can define, e.g. Java String to the last character and its position in the XML Schema. It is possible the same feature is now available in Java, I am not sure). To conclude, I would like to say that, IMO, I have much more flexibility with XML in manipulating the service interaction (message content) with already deployed service than with other programming languages I am aware about. - Michael ________________________________ From: Gregg Wonderly <[email protected]> To: [email protected] Sent: Wednesday, August 26, 2009 12:12:59 AM Subject: Re: [service-orientated-architecture] Re: good or bad practice? or maybe ugly Michael Poulin wrote: > > > 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. No, it leads to structured understanding. The meaning of the data, at some point is always understood, or you can't "use" it. What you are supposing, I think, is that somehow, a piece of software, is not a piece of data that can be consumed and used. XML schema, XSL and other conversions are equivalent, see below... > 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? If we have an XML document such as <ticket> <person> <first>Gregg< /first> <last>Wonderly< /last> </person> <event> <title>U2 Concert</title> <location>Chicago< /location> </event> </ticket> How do you know what these things refer to? The only way is through understanding, which creates a coupling from the source, to you as a consumer. In Java and other places where there is support for mobile code (mobile code is anything that causes change in what the user experiences with consumption of the data, aside from visually observing the content), there is an "engine" of understanding that consumes the content, and then outputs something else different. A SAX or DOM parser, for example is such an engine. Only with this engine (and it might be code you wrote yourself) can you get the "values" out of this XML document. So if my java Serialization generated XML, instead of the JRMP or JERI stream of bytes for my mobile code, the engine on the other side would still have to have a coupled understanding of the content to consume it at some level. There is always coupling. The biggest factor is whether that coupling is too complex for the value it adds. Simplifying "features" of any technology are what we like to pay for. > 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). XML creates a coupling just like any data does. The coupling it creates is two fold. First, you have to have the XML engine. If you don't have that, you loose. Second, you have to understand the XML content. You have to know what elements and attributes are present, or you can't ask for the content by bit and piece that you need. The names of elements and attributes couple your software to that document structure, plain and simple. This is no different than knowing the names of java methods and the types of parameters as in public interface Ticket { public Person getPerson(); public Event getEvent(); } public interface Person { public String getFirst(); public String getLast(); } public interface Event { public String getTitle(); public String getLocation( ); } It's exactly the same complexity. What smart proxy's and mobile code provide is that I can write the Event implementation as public class RemoteTicketImpl implements Event,Person, Ticket,Serializa ble { public Person getPerson() { return this; } public Event getEvent() { return this; } public String getFirst() { return first; } public String getLast() { return last; } public String getTitle() { return title; } public String getLocation( ) { return location; } private String first, last, title, location; } or I could implement it as something like public class LocalTicketImpl implements Ticket,Serializable { DataAccess db; public Event getEvent() { return db.handleFor( ticketId) .getEvent( ); } public Person getPerson() { return db.handleFor( ticketId) .getPerson( ); } } and the details of implementation can change at any point because the implementation is not exposed, the data is. > 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'. I think you'll have to describe what you mean by coupling. It sounds to me that you believe that any "code" that any application has knowledge of is a coupling, but somehow data never creates coupling. Perhaps you can explain more about what you mean with coupling. > Could you, please, elaborate on your example with JavaScript with regard > to this discussion? Javascript is code, it is transported to web browsers around the world and used day in and day out to deliver services to users. How does that not couple the client with the service? Can I send my own language to the browser without installing a plugin for that language, and it just works? Can I send any XML document to the browser and the user instantly use it? Not really, they can look at it, and if I refer to some XSL, I can convert it to an XHTML document, and do some rendering. But, I am using the XML and XSL and HTML "engines" in the browser to do this. I've coupled my service and client with "software" that must work together or else the service doesn't work. Code and data, equally create coupling. For example, if you always posted your emails in German, while you are using SMTP to post them and I am using POP to retrieve them, the transport/transfer standards don't guarantee that I can read them. The SMTP message format is simple, headers, blank line, content. But that still doesn't allow me to consume your message, until I have an understanding of what the content actually is. XML vs java serialization is the same issue. There is equal coupling created by either choice. You have to have the engine to wrap the content, you have to have a transport to send it to the other end, and you have to have the engine/knowledge to unwrap the content and consume it as intended. Gregg Wonderly
