See in-line comments introduced by [HS]. Harm.
De : [email protected] [mailto:[email protected]] De la part de Steve Jones Envoyé : vendredi 28 août 2009 11:55 À : [email protected] Objet : Re: [service-orientated-architecture] Re: good or bad practice? or maybe ugly 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 you have a perceived greater degree of independence of end-points and 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, its 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. Technically there is ZERO difference between the protocol defined in XML or in any other exchange mechanism [HS] Depending on the other exchange mechanisms, thats not necessarily true. A simple example: in ASN.1 there was no such thing as a namespace. 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. 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 Greggs underlying assumption is that the whole world speaks Java. As you say, this is not how the world works. Steve 2009/8/26 Gregg Wonderly < <mailto:gergg%40cox.net> [email protected]>: > > > 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 >> >> >> > >
