Harm Smit wrote: >> *De :* [email protected] >> [mailto:[email protected]] *De la part de* >> Steve Jones >> The point is one of perception and "because XML is human readable" it >> is perceived that XML is a better neutral interchange format that IIOP >> or the Java specific protocols. With a "neutral" protocol like XML >> as a result the market goes with that perception and voila you have a >> greater degree of independence because multiple people in multiple >> languages now have developed parsers for XML rather than the numerous >> binary protocols that exist. > > */[HS] This neutrality (why the quote marks?) with respect to > technologies and to vendors is essential, it’s not just a matter of > perception. Actually, the next-to-universal acceptance of XML as a > neutral interchange format is unprecedented in the computing and > networking industry. Before XML, ASN.1 came closest but some influential > players turned it down and it also suffered from feature creep./*
There is perceived neutrality, from the perspective that you can visibly see and understand the structure. But the cost is not neutral. The cost is very much part of the choices you make. Because XML carries semantic meaning without programatically representing these semantics, everyone that consumes it must implement the same semantic behavior when consuming the content, or the results are different. It is this cost that is hugely different from what mobile code provides. Why in the world would javascript and flash exist if XML/xHTML was such a good neutral thing in the web world? Delivering everything together is a much more valuable system than delivering in pieces and having everyone reassemble the pieces, correctly, to get the same results. > Technically there is ZERO difference between the protocol defined in > XML or in any other exchange mechanism > > */[HS] Depending on the “other exchange mechanisms”, that’s not > necessarily true. A simple example: in ASN.1 there was no such thing as > a namespace./* ASN.1 was for documenting the structure of the data, not for representing the data. The data was separate from the ASN.1 description. In this way, ASN.1 is more like schema than like XML. "Abstract Syntax Notation One (ASN.1) is a standard and flexible notation that describes data ..." There is really a big difference because the data was the data, and it's format and structure was not the standard. The standard was how to describe the data. ASN.1 would be more equivalent to the Java serialization specification, or the IP packet header specification etc. In this context, name spaces don't have much meaning. > but the reality is that there > is a significant increase in independence by choosing XML because that > is what people have backed. > > */[HS] This *is* quite true./* Independence is an interesting word in this context. What are you independent of? You are not independent of using XML. You depend on having the engine on both sides which must be in working order and compatible with the standards. How is this different from being "dependent" on the Java language standard or the C# language standard or something else? > As my father noted at an XML conference in 2001 "Oh great ASCII RPC" > the point being than none of these elements are fundamentally > different but thanks to the excess of bandwidth and CPU power we have > these days we can use one of the most inefficient mechanisms (Text > processing) based in part on a false assumption (its human readable) > rather than nice efficient protocols that are better suited to M2M > exchange. > > */[HS] It should be noted here that encoding of XML (Infoset) is no > longer necessarily textual. The binary encoding according to the > Efficient XML specification (under standardization by W3C) has shown to > be very bandwidth-efficient (outperforming all other binary > representations) and may thus extend the reach of XML into M2M > scenarios, such as wireless sensor networks, where textual XML would be > a showstopper./* > > My reading on this thread is that Gregg is right technically and > Michael is right in the reality of how the world works today. > > */[HS] It seems to me that Gregg’s underlying assumption is that the > whole world speaks Java. As you say, this is not how the world works./* My question (not assumption) is why is it more expensive or less attractive to speak the Java serialization standard as opposed to XML? Both require software systems to be integrated and installed as part of your SOA. What things make it seem "cheaper" or "easier" to use XML. The more I survey the world around me and see comments and supporting arguments the more I find myself wondering if we just do not have ignorant masses driving us down a path of "less technology" and "more hacking" because it's easier for those that don't have "computer science" backgrounds and thus they are just doing what is easy for them to do. At some point, such things come back to bite us. As I posted elsewhere last week, I recall the discussion in the early 80's on USENET lists for MSDOS/windows vs Unix. The Unix people were saying, DOS is fine for one program at a time doing simple things, but to actually be useful in production environments that involve multi-computing paradigms, it needs memory production between processes, user ids for data security and system security etc. The MSDOS people (what I would call the high-school hackers, because I was just out of highschool and could recognize their "expertise") would say, "You Unix hackers are lazy and just need to write good software without bugs and do adequate testing." They hadn't had enough experience and schooling to recognize that bugs will always happen because of human nature. It is cheap to get to 80% functionality, costs twice as much to get to 90% functionality, and the last 10% cost goes up by an order of magnitude. So you have to build resilent systems that can deal with errors and handle them effectively so that bugs don't completely disable the software systems (remember the mars mission and that important question about the approach rate in meters/sec or ft/sec). What we've of course experienced over the past 2 decades, is that all the lack of security and isolation that crept into MSDOS and Windows software has allowed all the world to be a stage for exploit and abuse (and the occasional bug, wasn't Vista just perfect for you too :-), while the Unix world has benefited from the "science" of it's design so that it hasn't needed rearchitecting for security, only bugs fixed. There is a lot to learn once history is visible. I'm betting that we'll learn something about this use of XML "everywhere" that will teach us some things that we didn't really think were as important as they turned out to be. Gregg Wonderly > Steve > > 2009/8/26 Gregg Wonderly <[email protected] <mailto:gergg%40cox.net>>: >> >> >> Michael Poulin wrote: >> > Sorry, Greag, I did not mean to push you :-) >> >> I am trying to find the gap between our thinking because I still don't > sense >> you >> get my point, and I am not sure I understand where you find the gap > between >> Java >> and XML. > > > >> By coupling I meant programming coupling which threats usability. There > >> are no totally decoupled things in the interaction (otherwise there will > >> be two monologues). > > > > This is an important point. If I send you XML, you have to have an XML > > engine > > to access it. If I send you a Java serialized stream you have to have an > > engine > > to access it. For me, both a sequences of data values, delimited by some > > documented structure that allows access to the real data. > > > > XML requires that I write code and depend on the structure of the XML to > > know > > how to use it. Even XSL is "code". It requires knowledge of what you have > > and > > what you need. This is the basic premise behind software development. > Taking > > something present in "your" world and processing it into something more > > useful > > in "your" world. > > > >> 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. > > > > There has to be something to document the stucture Schema is one way > to say > > what > > should be in the structure, but any "documentation" is a dependency > > identical in > > nature to a software system interface definition. > > > >> 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). > > > > I illustrated below that ticket, person and event could be seen > separately > > as > > the interfaces or together as the class object that implements the > > interfaces. > > This is exactly equivalent to an XML schema in complexity and > knowledge of > > what > > is "present" in the service definition. > > > >> 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. > > > > With a smart proxy, I can deliver only a portion of the data, and then if > > the > > other parts are requested, I can go get them, or derive them in some way. > > The > > presence of software in the form of mobile code, allows me, as the > service > > provider, to optimize my users experience by adapting and changing over > > time, > > what the service implementation is, without having to ask the client > to do > > something different as long as I meet the contract that they signed > up for > > (the > > interfaces that I documented). > > > > The problem with XML is that it has to be there. You have to send the > data, > > or > > the client has to have all the knowledge to know what bits and pieces > come > > from > > where, how to get them, what's expensive to get, what changes over time, > > when it > > changes etc. All the clients have to do all the same work to get changed > > behavior that is needed to evolve the services interface if not > > implementation. > > > >> 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. > > > > If the content of the document is not identical in element, attribute and > > structure, how can there be immutable code? > > > >> 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). > > > > I didn't quite understand this. Mapping between XML and Java requires an > > engine > > that somehow has knowledge of how that works. This is no different > that the > > underlying Java Serialization between on the wire structure and live Java > > object. > > > >> 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. > > > > But you are just writing code in Schema defn, XSL or otherwise, > instead of > > writing it elsewhere. In Jini, we write code into proxies to do the > types of > > stuff that you might do in Schema and XSL things. > > > > The big difference is that I, as the service provide can do this > once, and > > all > > of my clients can benefit, where as, you, as an XML service provider, > can't > > change the document elements, attributes and structure, without > delivering > > something to your clients to aid them in making use of the new > "structure" > > of > > your XML. > > > > Sending them such things is a type of mobile code I guess, but it is > > delivered > > and activated out of band, which creates decoupling that can seem > > empowering, > > but for me, it is nerve wracking, because I can't change anything on the > > service > > until everyone has the changed "code". > > > > When I deliver such things with mobile code, its the service object > > reference > > that the client is accessing that provides the new implementation, and so > > everyone sees it the moment I make the change active, and I don't have to > > ask > > people reporting problems, what version of the schema they have and where > > they > > got it from etc. They always have the "production" version and I can > always > > support problems with my service with a full understanding of the > "software" > > involved. > > > > Gregg Wonderly > > > >> - Michael > >> > >> ---------------------------------------------------------- > >> *From:* Gregg Wonderly <[email protected] <mailto:gergg%40cox.net>> > >> *To:* [email protected] > <mailto:service-orientated-architecture%40yahoogroups.com> > >> *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 > >> > >> > >> > > > > *//* > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
