struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Why Use Serialized Value Objects instead of XML or SOAP? (Was.... Can V in MVC be Swing in Struts?)
Date Thu, 17 Oct 2002 21:51:43 GMT

> Just to give you a little background : The application involves hundreds
> Busines Objects and complex business rules.
> The number of different ways in which a client can manipulate Business
> objects (POST methods or RPC calls) is quite large (ofcourse we are
> to use Facades and BusinessDelegates to avoid too many granular actions).

Couple questions/assumptions:

 - Am I right in assuming that a good number of these business objects need
to be accessible to the Client application individually even counting the
facades you create? Sounds like you could have 100 or more 'endpoints'.

 - And these individual 'endpoints' need to be accessible from the Swing

 - If so, then the creation of each individual endpoint needs to be pretty
efficient. That is, it can't take hours of coding time to add a new

(I'm using the term 'endpoint' as it is a part of the WSDL spec with a
particular meaning).

 - Another question is how reliable is the application? If you ABSOLUTELY
CANNOT lose a message, then HTTP in general may be a problem. It's not
designed to provide a guarantee of 'once and only once' delivery. That
being said, many times the loss of a request isn't as big a deal as it
first seems. The Swing application can sense a problem and just retry. The
real problem could occur if the message is delivered, but the response to
the swing application isn't conclusive so it resends.

 - Another question is are you tied to HTTP? If you are on an intranet and
can use some other transport you may be able to get better reliability (and
potentially performance). More on this below.

> Our first stab at the design was to model all Business objects as Java
> Classes (We have good reasons not to use EJBs, but that is a different
> story). For some reasons, the front-end has to be a java swing
> We will have ValueObjects that will be passed back and forth between
> and client.

Non-EJB's are fine - though they have advantages if you need to manage
transactions and roll-back things that fail mid-stream.

Sending Value Objects seems a good decsion - they aren't tied to any
particular app on either the front or back and they are easy to model in
XML if desired.

> The transfer of value objects data between client tier and web/app tier
> could be (1) XML (2) Serialized objects.
> Sending XML representation of ValueObjects would increase our 'payload'
> factor of atleast 5 (due to XML tags etc.) and also we have to write
> conversion routines. Our ValueObjects hierarchy is a bit complex. (JAXB
> could help here though.)
> On the other hand sending Serialized Value Objects tree seems straight
> forward and efficient. So we decided to give it a shot. Don't know if
> is the best way.

A third option you haven't mentioned is using JMS (assuming you want to
stay J2EE-based). JMS provides higher reliability than anything you would
send over HTTP.  Since JMS is transactional it can guarantee 'once and only
once' delivery. Plus it works great for carrying objects in general. It
also provides you a way to persist requests if the back-end goes down in
the middle of something.

But JMS messages would need to be 'pulled' by the server. What you may need
to do would be have the client send a JMS message into a queue, then have
another app that locks on the queue waiting for a message. This app would
receive the message, invoke a request to Struts (assuming you need to use
struts on the server) and then get the response and package it back up to
return on the queue. Things would honestly be easier if you just had your
server application locking on the queue directly and you didn't use Struts
(of course, then you wouldn't be here!).

Another option would be to have the Swing app use Axis/SOAP, but sending
the SOAP messages over JMS instead of HTTP. Interestingly, I just posted a
weblog entry on this approach on O'Reilly's site a couple
days ago (See "SOAP over JMS - What does it mean and why should I care?" ). The advantage of this is that you
use Web Services client and server code, and the Transport is JMS
underneath - though the web service isn't significantly different. Axis has
this capability, but it's pretty new. Again, this approach implies not
using Struts necessarily.

So getting back to using Struts and having your 'View' components actually
serializing objects (or sending XML). If you need to use Servlets/JSP/HTTP
for whatever your reasons are, using Struts is as good (or better) than
anything else for all the reasons people like Struts to begin with. You
just have to have the 'view' components be different. The differences I can
see in using serialized objects versus XML would be:

 - XML is easier to read and debug

 - If you built an XML-RPC or SOAP interface in front of Struts, you'd be
able to repurpose the 'server-based' services using clients on other

 - Using SOAP may mean writing serializers/deserializers for both ends of
the communications, but not necessarily. Axis has a built-in
'BeanSerializer/BeanDeserialzer' that you could use that would likely be
able to handle all that work. You could feed 'beans' into the web service
and get them back out without having to create the XML yourself. That is,
Axis knows how to serialize/deserialize beans with no extra code.

 - Using Axis for communications would require that you write a bridge
between the Axis server and Struts (assuming you used Struts). This may not
be as hard as it seems since they would both be webapps running on the same
server (or, if you are a do-it-yourself'er you might be able to write a
Struts request processor that understood SOAP requests - which again may
not be that hard, I haven't looked too deeply into this). SOAP requests are
after all HTTP POST's against a particular URI (which could be
/ format). The only real difference is that the SOAP
request devlivers its data in a SOAP envelope using XML instead of the
normal name/value pairs.

In the end, I think it probably comes to this:

 - The upside to using serialized objects is that it's not that hard and
you already know how to do it. Learning curve is shorter, risk is lower.

 - The upside to going through the effort to create a Web Service approach
      1. That the 'Web Services' you build will be reusable for other types
of client applications if you need to write them.
      2. That having the Swing client know how to access data from web
services will allow you to access other web services from it (which are
popping up everywhere).
      3. Since most of the effort is one time learning and building, once
you get up to speed you'll have a great tool to do other things with.

Reliability is likely to be the same for either - HTTP is probably the
'weakest link'.

Tough call. Here's what *I'd* do


If I had time I'd implement the solution using Web Services. When I say
time, I mean about an extra few weeks. I just think the long-term value of
what you're building and the skills you'd have would be greater. They day
will come when you'll be sorry you didn't.

Also, if I were going to do this using Web Services and SOAP, I'd
reconsider using Struts <Gasp!>. All the taglibs (and more importantly, the
way it receives and parses HTTP POSTS) are all very HTML and 'form'
oriented. Now if Struts could be made to parse a SOAP Envelope as it's
incoming request, then that would be different.


Of course, this approach is riskier too since you've never done it before.
If your management has a very low tolerance for failure, then that may be
worth considering. As they say, 'Plan on throwing one version away, because
you will'. (Of course the second version will go up in much less time and
be much better...)

I'd be interested in hearing what others on the list think of my assessment
<he said as he reached for his flame retardant shorts...>.


Kevin Bedell
Author, Struts Kick Start

> Regarding using the SOAP, we are seriously looking at it as an option.
> (Trying to get upto speed on web services is the first step...I guess :

This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message