What do you think about using XML to pass data between the server and the client?
This architecture is used on my current project and it works pretty well. Data is extracted from the db using its XML query functionality (supported by MS, Oracle and possibly others). There are no entity beans, only the session ones. All the methods of the session beans take as the parameter and return XML.
1. Client app requests data (eg person details). It calls Person.getPerson (ID)
2. Client app receives XML string containing all the relevant details about that person and populates its fields accordingly.
3. Client app updates the person details. It creates an XML string from the data in its fields and calls Person.updatePerson (xmlString) method.
- No entity beans and the performance problems associated with them
- Easy maintanability: If you want to add one more field to the form then you'll have to change the stored procedure that retreives the information and the client. No need to recompile the beans or the 'Data Objects'.
- Easy to represent complex tree-like structures with XML (eg master-detail).
- No need to write BMP Entitiy beans or initialise data objects from resultsets.
- Need to parse XML on the client which adds a little to the complexity of the client code
- The stored procedures' syntax is a bit convoluted in order for them to produce XML
- Business logic could be spread between the stored procs and the session beans, with most of it residing in the stored procs.
- Strong DB vendor tie-in
- Higher network bandwidth consumption
- Use of JAXB to automatically bind XML to java objects.
If done on the client side, then the XML received is parsed automatically. Potentially, could be used in the business objects tier instead.
Please let me know what's YOUR opinion on this approach.
Which object are you using to hold your XML? Is it java.lang.String? What is your opinion on using Document object instead?
I believe you are continuing from your old question D.R. Anyhow i am sure sooner or later xml-based architecture is going to be the de-facto standard for large enterprise applications. In this connection i suggest that a thorough study of XML-RPC is going to help a lot. though fallen from favour, the XML-RPC is going to solve a host of problems that are hard to solve using RMI. And i guess the speed it is going to bring about is definitely going to help. Now as far as passing around the XML is concerned, let's look into a few issues.
To pass XML as a document object we must be sure about the size of the object. perhaps the discussion in the other forum about stack-blowing has a few merits in this regard. but i suggest that a few benchmark tests be conducted in this regard.
I guess it is pretty easy to send XML as String objects. The only problem with such a transport is having an effecient parsing code on the client side. once we ARE using XML i guess it must be understood that we can develop efficient ways to write clients to parse XML.
Passing around as Document objects is generally quicker, since parsing String into Document will take a long time compared to object serialization / deserialization. However, the point about stack blowing (I made it in the other thread) is definitely one to bear in mind. If you pass a massive great XML tree around then it could blow up the stack on the VM, since the object will recursively serialize it's children which will serialize their children which wil...........you get the idea.
Default stack size is 128K. Increasing to 256K gets rid of the problem in most cases, but that's not the real point.
The real point is this. At what size of XML do I have to tell myself I'm being silly and passing too much information around the place? That's up to you based on what you're doing, but on the wire, XML is not that efficient in whatever format you choose to use it, beit String or Document.
Don't get me wrong, I like XML, **in it's place.** I just think it gets used too often without due consideration for the downsides.
In this situation I would keep things in Document format (assuming they aren't too big) but have a facade into my system, such that I can always write another facade to serve it up in a format more suitable for some other language. For instance, an EJB facade (you could even call them adapters, it depends how much work they do really) can return a Document object, but an HTTP facade would simply return content as MIME type text/xml over an HTTP stream which lets any other language which can talk TCP/IP and HTTP get at the data as well if you want to.
I designed and built a system like this and it works extremely well. I have major portal software, written in Java talking to the data access framework using EJB stateless session bean (Note singular, only need one.) and a whole stack of VB applications talking to the same framework using HTTP. Works very well.
So, go ahead and use XML, but consider how much data you want to pass all over the place, particularly if it goes over network links you can't control (I.e. the Internet.) :-)
This is a cool idea. Actually this is i think called 80-20 rule. Use 20% technology to solve 80% of the problems. I have worked on similar styled projects and have successfully deployed it for a bunch of companies. This is a good idea for a small scale development companies with shopping carts and order fullfillment processes. But if you are talking about developing something that has a scale and size of Amazon.com i dont think it would be a correct fit.
It actually scales horizontally very well. We just add more WebLogic servers to the cluster and it handles it extremely well.
Has anyone considered the loss of Object Orientedness of the application by using the above Development patternt? Say i want to add different types of users (persons) would i be then be limited for any reasons because of the above pattern. Would i need entity beans then?