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,Serializable {
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
