• Post Reply Bookmark Topic Watch Topic
  • New Topic

Swing Client for J2EE App.

 
Angelino Dolce
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All!
I'm participating in the maintenance of a j2ee application, that contains both web and ejb tier. The client is a Rich Swing application that communicate with the server (Servlet) mediate XML-RPC over http. This solution work well but.... WHY I don't find nothing about this, as an alternative (on the Internet)?
What is wrong with it? Is this a bad solution?
If it is long to respond please give Me same material for illuminate my ideas.
Thank You very much.
 
Nathan Pruett
Bartender
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Angelino,

There's nothing "wrong" with doing an application this way - however, I'll agree that it would probably be difficult to discover information about similiar applications on the internet. One reason for this is that desktop applications (Swing/AWT/SWT) aren't as "popular" as web-based applications (JSP/Servlet/JSF). There are several difficulties inherent to desktop applications - First, you have to ensure that each client has a JVM (and in many cases, an up-to-date version of the JVM). You also have to provide your classes, and any libraries to each client, and again, worry about the clients correctly installing everything and keeping each client up-to-date. If there's going to be client/server communication - you'll have to worry about any sorts of firewalls or other network problems. Web-based applications do away with the majority of these problems - all the client needs is a browser. Admittedly, sometimes there are cases where the user does need an up-to-date version of a browser, or to have Javascript or cookies turned on - but in general, the amount of things that can go wrong are very less than for a desktop application. I'm not going to argue that web-based applications are a perfect fit in every case - you may need better user interfaces than HTML forms can provide; the flow of your application may not follow the request/response model of HTTP; you may want your application to work unplugged from the internet; etc.

I'm betting that the application you are working on is in an intranet environment - in this case, JVM/library/code versions can be controlled, as well as factors such as installation, network availability/troubleshooting, etc.

As far as the XML-RPC, this is a little bit of a "newer" technology, so there's not going to be as much information out there on that either.

In any case, you're probably not going to find much information on "the whole picture", i.e. an exact overview of your application architecture, how the pieces fit together, etc. However, there is definitely information out there on each piece - i.e. You'll be able to find information on XML-RPC by itself, or ideas on how to build good Swing applications, or good EJB design, etc.
 
Jignesh Patel
Ranch Hand
Posts: 626
Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are ways of doing, other then XML-RPC.
1. USE RMI with ServerSocket class or user RMI-IIOP with EJB.
2. User java.net package( but may take more time in coding).
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A Swing client is fine if the business requires such a client that has the functionality which a thin client cannot provide.

Where I feel that the design is quite probably wrong is to use web services. This may be fine for inter-system communications, but there can hardly be any benefit in deviating from the more usual RMI-IIOP calls for intra-system communications. This is quite efficient in the EJB world, I believe, quite unlike XML-RPC which can result in hugely inflated data packets by comparison. We had such an app (actually, a suite of three) and in the end we had to compact and compress the SOAP requests to meet network bandwidth requirements.

I've been working on a project which entails migrating these apps from WebLogic Server 6.1 to 8.1 and, not surprisingly, it's the web services part which has caused me the most grief for a variety of reasons. I'd have given a lot for RMI-IIOP clients ...
 
Angelino Dolce
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot to Nathan Pruett for the whole picture description
and to Patel and Roger.
However the only problem to risolve is in this code:
-----------------
byte[] abRes = oXmlRpcServer.execute(oIn);
oOut.write(abRes);
oOut.close();,
-----------------
in the doPost() method of the Servlet.
The abRes contain the compressed result of the elaboration, but in same cases the 'oOut.write(abRes)' is the bottleneck. Any Idea?
Thanks again!
 
Nathan Pruett
Bartender
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not entirely certain, but I'd be pretty sure that the 'oOut.write(abRes)' line is just writing the XML-RPC response to the servlet's output stream... If it's a big response, it will take a long time to write...

The two things that are going to impact this are 1.) How big are the XML-RPC documents. 2.) How often are documents requested.

I'm betting that the 'bottleneck' is being caused by large XML-RPC documents - one way to fix this may be to break up one big request into multiple smaller ones. The 'overall' response time may not change, but the application won't look as 'slow' because it can respond as it gets each piece of information...

(Normally, I'd also suggest buffering the stream, but I'm not sure that would make a difference here - I'm betting the XML response won't start to be processed until the entire document is returned.)
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!