We recently "inherited" a system written in a third-world country, and they did something very interesting I've not seen before, and I can't figure out their motivation for doing it. Instead of having objects to encapsulate data, they just pass a String object around everywhere and write and read XML data, and when a value is needed they look it up. Also, they use Oracle's proprietary api's for returning resultsets back in xml format. Has anyone seen this?? I can't think of any benefits, I can only think of negatives. Obviously, there is no inheritence and OOP concept, so I wonder about reusability and maintainability. Also, performanmce is the biggest hit I can see on doing it this way; parsing XML data and reading&writing XML streams all over the place iso bviously thousands times slower than a method call.

Thoughts?

In arguing against a proposal to use XML in a similar fashion for a system we're developing, I found the following quote in Floyd Marinescu's new book, EJB Design Patterns, relevant:

"...When communicating between two Java systems, XML does not really make sense; in fact it can result in unnecessary performance overhead and bloated code. In particular, using XML as a mechanism for transferring data between client and server should only be done if you really, really have to."
If it's wrong for two separate systems, it follows that it's even worse to use it to transfer data within the same system.

   

Suppose you have an n-tier system where you wish to separate concerns in the layers for flexibility. Using XML/SOAP to communicate between layers could be beneficial in this case even if the layers may be both Java.

I would be very careful about introducing XML communication between tiers of a J2EE system, especially in the form of SOAP. I have worked on SOAP several times and it is a complex beast.

The design on one system I worked on had the Servlet/JSP Web Tier talked to the EJB's by posting XML to a Servlet on the Weblogic server which then used a controller to call the EJB. I would call this over architeting. There was no need to do it and it over complicated the system and caused a performance bottle kneck.

IMHO SOAP/XML for communication works best for distributed systems not local tiers of the same system.

I was actually referring to using SOAP to communicate with a back end that would be on a different machine. Yet we've had pleasant experiences with SOAP, I haven't found it hard at all especially with the more advanced tools available today.

Hi,

Both SOAP systems I have been part of building connected Microsoft legacy systems to J2EE based systems. First one we built about 1.5 years ago now and the last one pretty recently.

Most of the issues were around the classic interop problems and some arouund authentication and session handling due to lack of agreed standards in these areas.

Which tools did you use as I am always interested in making life easier?

IMHO

Even if the Web Tier and the Application Tier are on different machines if they on the same LAN and are both Java/J2EE then I think RMI/IIOP is a better option for inter-tier communication.

I am currently having this battle as to whethr XML or not XML. I am saying NO but a few are XML happy as said earlier.

Our requirements are to have a flexible/extendable messaging system so sub-systems can communicate in a flexible manner (maybe a mini holy grail). I would like your opinions on my suggestion. First passing objects around is pretty 'fixed' I know you can extend them etc. but its is not quite as flexible as we would like. Hence XML but to me that seems a bad idea from a bandwidth and processing view. So I am suggesting we use a data transfer hash-map approach. We gain the extensibility and flexibility we need. We gain the granularity od data being passed around. And we gain the advantages of on OO approach to the data.

As I envisage the system being we would build a class to act as the hash-map that is basically our message. We can send this around the system and all sub-systems support marshalling and de-marshalling this message object. A

I think it boils down to the performance requirements and the design. If you have some extreme real-time requirements, typed MOM transports like Tibco make sense. For subsystems that don't have the real-time high-perf communication requirements SOAP/WS are useful since they do offer looser coupling, dynamic discovery, etc.

I can think of one exception to the "not on the same network rule."

If you are building a data layer which is to be used by a wide variety of clients then XML is a good choice. You accept a cost of performance in terms of generation, but you also create contracts which specify data formats in terms of DTDs or Schemas.

If you have a wide variety of clients all interested in the same data then you need to be able to render it in a language neutal form, in which case XML is not a bad idea.

Even if the two layers are Java. We built an XML abstraction across 10 database and several outside data sources and use a simple facade (We have servlet, EJB and within the same JVM) to get data. That said, we INSTANTLY turn it back into Java objects. The XML is used to get the data into memory, then it's gone. That way you pay the performance price for XML, but only to get it in the door. No way should you let the XML get any further into your system than that.

Shame JAXB has died down recently really. That was looking like a great way to solve this kind of problem without having to code the extraction of data from the XML...

Chz

Tony

David,

"IMHO SOAP/XML for communication works best for distributed systems not local tiers of the same system."

I would even go further and demand that the tiers are not in one network. Communication using SOAP over HTTP makes sense only as a circumvention to a firewall/packet filter or similar.

Unmarshalling an XML-marshalled object is a very expensive operation, as you have to create something that exists already elsewhere, and then fill it with data parsed from a stream. As long as there are other alternatives (RMI, IIOP) these should be used, from the performance viewpoint at least.

On the other hand, XML (especially one that follows a tight notation) can be a way to reduce object granularity - instead of a complex object graph we simply have one String object. This is even more valuable when we do read-only access all the time.

And another point where XML comes in handy is creating home-grown persistence mechanisms that store objects which can be loaded as well in other languages. But this is going to far now... :o)

Regards,
Lars

well, few years ago OOP was considered something of academic use only. I remember hard times to convince managers or even programmers to go with OOP. Today we have this:

"Obviously, there is no inheritence and OOP concept, so I wonder about reusability and maintainability. Also, performanmce is the biggest hit I can see on doing it this way; parsing XML data and reading&writing XML streams all over the place iso bviously thousands times slower than a method call."

How the world changed! Today we favour OOP due to PERFORMANCE considerations!

Back to our ships. I don't know what's in your "inherited" system, but the idea itself (of having everything in XML without OO encapsulation) seems to me fine. As a matter of fact, I was thinking to redesign parts of one system using this approach.

Briefly, idea is that NOT to marshal data from strings to objects. Certainly, it's not going to be FAST, if u internally work with objects, then marshal/unmarshall data every time u pass the data to other components. Here I'd agree with you completely.

But, what if we don't work with objects internally? We get STRINGS from Web browser POST/GET requests, aren't we? Let's wrap them in XML. Further, let's apply series of transformations. We get XML, get elements, then use them to query/modify the databse with parameters. We DO NOT have objects in the database, they need to be constructed somehow. Why? Let's simply wrap the data coming from databse into XML. Happily, there are tools for that, if you don't want to write your own content generators. Having XML we, again, may apply transformations, e.g. with XSLT. We may use XSL-FO etc.

What's the point? The point is that objects are from our world, we think and code in terms of objects. Users dont have objects, as well as HTTP browsers. All they have is STRINGS, sometimes graphs and pictures. So, the idea is directly manipuate with STRINGS.

This isn't going to be ALWAYS effective. But for many Web apps, this approach will prevail in future - it's my prediction.

You seem the be in the minority on your prediction.

Argyn,

"What's the point? The point is that objects are from our world, we think and code in terms of objects. Users dont have objects, as well as HTTP browsers. All they have is STRINGS, sometimes graphs and pictures. So, the idea is directly manipuate with STRINGS.

This isn't going to be ALWAYS effective. But for many Web apps, this approach will prevail in future - it's my prediction."

I agree with you, but would then favor - for Web apps - a programming language that is more String-centric than Java. For instance TCL, where everything is a String, or Perl, where you have much more powerful tools for String-manipulation than in Java (before 1.4, that is :o).

Up to date, I would really consider writing any Web apps using the conventional CGI approach instead of Servlet/JSP, as a result of having Strings as THE primary datatype.

Regards,
Lars

Java is better than scripting languages like TCL or Perl, when it comes to building complex large systems. So, I would be cautious with scripting. It's easy to start and maintain when the Web application is small. But everything tends to grow. So, maybe you should feel the point when it's time to port everything to Java. I mean the prototyping and first release in anything which is quick and easy, like Perl. I'm talking about the applications, with considerable backend.

Hi,

I think their motivation like so many companies over the last few years is that they are XML happy. Got a problem? I'm sure it can solved it if we put XML in their somewhere. ;-).

Having worked for a lot of dot com companies over the last few years I can' tell you how many systems I have seen in this mess. Always the same cause, someone thinks XML is the cure for everything. I have seem companies fail because their architect went the XML happy path.

XML is good a providing a human readable way to present data or as a wire protocol. However it is not good at being the way data gets passed around and manipulated in a Java application.

As you mention the perfomation implications blow. A system that relies heavly on String manipulation is not going to scale. DOM manipulation if you go that way also sucks and causes a real garbage collection knightmare.

My best solutions is to use some form of Java object/XML binding framework (Castor). Turn XML into Java Objects on the way into the system and then if need be turn it back to XML on the way out.

David

Excellent summary, David.

XML is not a silver bullet like some believe. XML should be used at the entry and exit points of the JVM only when necessary.

I agree, there's no silver bullet

>XML should be used at the entry and exit points of the JVM only when necessary.

I agree :) When I say XML, I don't necessarily mean the bytestream with XML data. It's just one of the representations of XML data structure.

Look at Apache Cocoon project. They have pipelines. Pipeline elements consume and produce SAX events. You may have the file generator, which reads XML file then produces SAX events for further processing in the pipeline. At the end of the pipeline there is a serialazier which consumes the SAX events, then serializes them into a bytestream.

So, internally, you may say that the pipeline operates with Java objects. But conceptually you don't have to think about SAX events, you think in terms of XML, XSL etc. For example, you can insert a transformer which will take your XSL template, and apply them to the XML document passing through the pipeline. It's the "real" XML file is being processed inside the pipeline, it's SAX events.

That's what I mean by total XML based processing. This is a very promissing way in Web publishing.