|
Replies:
13
-
Last Post:
Mar 27, 2008 5:08 PM
by: cool9889
|
|
|
|
|
|
|
JMS Standalone Client
Posted:
Mar 20, 2008 3:46 PM
|
|
|
hi,
I am trying to access a JMS resource from a Stand alone client. In order to achieve this I guess i need following jar files in my classpath at client side.
javaee.jar
appserv-rt.jar
appserv-deployment-client.jar
appserv-ext.jar
appserv-admin.jar
Becoz of all these jar files my client is becoming very heavy which I want to avoid. Is there any way that I can access resources from app server with minimum overhead on standalone client? I believe ACC (Application client container) will also required all above jar files hence using ACC may not help.
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 21, 2008 6:40 AM
in response to: cool9889
|
|
|
For GlassFish V2, there is no work-around. There are some optimizations made in ACC (using Java WebStart -- Ask Tim Quinn, who is an expert), but you need these jars. The fact that you are using
ACC actually hides what you need and does the right thing.
Are you saying that your standalone client becomes "heavy-weight" because you are packaging
them in your client? What does "heavy-weight" really mean? (I understand your client needs to have
access to classes/interfaces from these jars).
- Kedar
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 25, 2008 5:40 AM
in response to: km
|
|
|
> Are you saying that your standalone client becomes
> "heavy-weight" because you are packaging
If so, that's an incorrect definition of "heavy-weight".
I guess he means his application deployment gets rather large in diskspace due to the size of the required jars.
> them in your client? What does "heavy-weight" really
> mean? (I understand your client needs to have
> access to classes/interfaces from these jars).
heavy-weight means it has a lot of functionality.
Typically used to distinguish traditional client/server applications from terminal/web applications, the client/server application is heavy on the client side because the client contains a relatively large chunk of application business logic where in the terminal/web application this is all (or almost all) contained on the server, leaving a lightweight client.
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 21, 2008 7:21 AM
in response to: cool9889
|
|
|
My application that is client is basically bundled in jar files. it does not refer to any exterior jar files as it consists of all the required class files. Now if I unjared above jars in my jar then obviously size increases. Above jar files are around 20MB which is making my jar file heavy and hence it is no more portable. Also I was accessing webservices from my stand alone client by creating web service client in it. Now for this to run I require webservices-rt.jar This jar file is around 10MB. So instead of using this I switched to Apache Axis 1.4 which is around 3 MB which makes it lightweight. So on similar basis I was wondering If i can access JMS resources directly.
If we dont have any solution then I guess only way i have to communicate to the server is through web services.
Regards,
Kuldeep
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 23, 2008 4:36 AM
in response to: cool9889
|
 |
Helpful |
|
|
Hi,
I agree with the fat client problem.
I had hopes that EJB3 would solve the dependency between client and server. But I now understand that a JMS client made for GlassFish will not work with a another JMS "server" like Websphere or JBoss. I guess that using while other beans, there are dependencies between clients and their server implementation. A little bit a waste I think.
The added value of JMS is standardized asynchronous communication. If we use web services instead we have to invent our own callback method.
See http://weblogs.java.net/blog/johnreynolds/archive/2006/02/can_i_call_you.html
Kuldeep, perhaps you should have a look at JMX. JMX clients are thin clients and events can be used as callback. JMS can be used between different EJBs inside the appserver to simulate multi threading.
Perhaps this is not so fancy as EJB and Web Services. What do other people think?
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 24, 2008 11:32 AM
in response to: jooper
|
|
|
That's an interesting idea of using JMX as a primary application interface.
It somewhat routes around the development and deployment model (since JMX components are server centric rather than application centric).
But it does have the benefit of being portable and cross container, something, as you noted, that can't be said for either JMS or Remote EJB. (By portable I mean runtime portable, where a single client can talk to multiple hosts of different vendors).
You can MAKE (sorta) Remote EJB (or even JMS I suppose) container portable, but only if you include their runtime jars with your client (and primary complaint for this topic).
Of course, web services tend to be more firewall friendly.
One thing we've done is the past is to have webservice calls poll and block. By that I mean we send a request with the webservice, the actual server endpoint then blocks (on a JMS topic/queue) with a timeout. If the service gets a message, it tries to slurp up "some more" until it reaches a certain time out or count of messages, then send the bulks back as a result.
This gives decent responsiveness without bombarding the server with 'are we there yet' polling requests. effectively, the client gets its responses in "bursts" of activity, othewise it simply sits idle with a "long" (like 5 minute) time out. So, a completely idle client with no activity makes 12 polls per hour, which is nothing.
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 26, 2008 1:03 AM
in response to: whartung
|
|
|
I was thinking a little longer about this idea. I think we can both agree that the problem is that it will not scale too well, since you have only one instance of an MBean. EJBs are made for scalability.
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 25, 2008 5:47 AM
in response to: cool9889
|
|
|
the size of your deployment archive does NOT influence application portability nor does it have any influence on how "heavy" the application is.
Get your terminology right.
Choosing your libraries based on their size is foolish to say the least. You should choose them solely on the functionality they provide.
What does reduce your portability is the use of applicationserver specific client libraries, but that's only a problem if you plan to support several application servers on a single client version as that would require a separate deployment for each (or deployment of the client libraries for each).
JMS will always require some sort of library. And those libraries will depend on the JMS stack you're planning to talk to.
But that shouldn't be a reason to not use it, as your idea that you should select your technologies solely on the size of their jarfiles is idiotic.
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 25, 2008 10:48 AM
in response to: jwenting
|
|
|
It matters if you're have to move the final application to a client over a slow connection.
Writing a Swing app with a single panel and a couple of buttons that instantly blows up to a 20, 30, or 40MB jar file because of runtime dependencies may not "be heavyweight" but it certainly "feels heavy".
The basic question is whether or not the client runtime libraries have been "properly factored" to take this kind of limitation in to account. For example, WebLogic puts the kitchen sink in to their weblogic.jar, but they do have a much smaller "client.jar" file for standalone clients that want a smaller footprint.
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 26, 2008 1:00 AM
in response to: jwenting
|
|
|
>But that shouldn't be a reason to not use it, as your >idea that you should select your technologies solely on >the size of their jarfiles is idiotic.
Please mind your words. Professional software engineers know that user requirements are never idiotic or foolish.
For me an expected file size can be a very real requirement. For example in applet situations. Downloading 40 MB for a simple Swing application can be unacceptable.
It is a different story when you install a server. Perhaps then a few megabytes do not count. Did you forget why flash is so sucesful compared to Java applets? Been there done that.
Other problems related to just loading a bunch of Jar files are related to loosing control over which classes you use. This is especially dangerous when you do not a dependency management system like Maven or one of its competitors.
This can lead to
- security problems
- situations where programmers access internal classes directly just because it is possible and they are under time pressure
- potential classpath problems such as having the same class twice in your classpath without knowing it.
In larger software projects with time pressure and real customers these things can bounce back. Usually all those problems occur in the last hours before your final packaging 
Message was edited by: jooper
Message was edited by: jooper
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 26, 2008 2:37 AM
in response to: jooper
|
|
|
> >But that shouldn't be a reason to not use it, as
> your >idea that you should select your technologies
> solely on >the size of their jarfiles is idiotic.
>
> Please mind your words. Professional software
> engineers know that user requirements are never
> idiotic or foolish.
>
Au contraire. A lot of those "requirements" are idiotic and foolish, you're just not supposed to say so in their face.
So you have to use more circumspect language, going on about "practical considerations", telling customers that their requirements will lead to unwanted side effects or, in extreme cases, telling them that doing things the way they think they want will cause massively higher development cost (that almost always sways them to see your point).
> For me an expected file size can be a very real
> requirement. For example in applet situations.
> Downloading 40 MB for a simple Swing application can
> be unacceptable.
>
Hardly. The number of serious computer users who are still on slow dialup connections can be counted on the addresses in one subnet 
And most of those are probably going to want a CD shipped anyway.
> It is a different story when you install a server.
> Perhaps then a few megabytes do not count. Did you
> forget why flash is so sucesful compared to Java
> applets? Been there done that.
>
Mostly that's because of the incorrect (for the last 5-10 years) assumptions like "Java is slow", "noone has Java installed", "Java is a security risk", "Java is ugly" (the vast majority of Flash applets are just flashing buttons...).
And we're talking about application server client libraries here. Those are most likely to be used over a LAN, not the internet, and the download will (if the browser is configured right) only have to happen once anyway.
> Other problems related to just loading a bunch of Jar
> files are related to loosing control over which
> classes you use. This is especially dangerous when
> you do not a dependency management system like Maven
> or one of its competitors.
>
Hardly dangerous. There's far more classes in the core libraries, you have no control over their use either...
> This can lead to
> - security problems
No more than with small packages. Just choosing the smallest package because there's less classes in it and THEREFORE it's more secure is idiotic because it's a massive fallacy.
> - situations where programmers access internal
> classes directly just because it is possible and they
> are under time pressure
Never seen that happen.
Those classes if they're meant to be used are well documented and no risk, if not they're undocumented and more trouble to use than they're worth.
> - potential classpath problems such as having the
> same class twice in your classpath without knowing
> it.
>
Not with well written packages. In fact with small hobby project packages (which most of those tiny packages are) that risk is far higher.
> In larger software projects with time pressure and
> real customers these things can bounce back. Usually
> all those problems occur in the last hours before
> your final packaging
>
I've worked on major applications with many dependencies.
It's hardly ever a problem, and if it is it's always easily resolved (as it's usually just something like 2 different versions of the same jar ending up in a deploy, one of which can harmlessly be removed).
The only times it causes problems is when kids with no experience who think they know it all start putting things like Apache commons jars in JDK/ext/lib directories (or their appserver equivalents), something that should never be done but among youngsters remains a popular alternative to learning how to properly set up a classpath.
Ignorance of the foolish should never be the reason to not do the right thing.
Let the fools burn their fingers, they might learn not to play with fire.
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 26, 2008 7:28 PM
in response to: cool9889
|
|
|
hi all,
it looks like my word heavyweight is causing heavy discussions in this forum. I apologise if I am using the wrong terminology.
My real question will be why glassfish have heavy (here heavy means big in size) jar files like appserv-rt.jar (15MB) and webservices-rt.jar(10MB) etc... Web service client provided by Apache Axis 1.4 is around 3MB then why we have 10MB of jar? Is that these client jars are providing me some extra ordinary services?
So in order to access one JMS resource outside the glassfish I need to use 15MB (appserv-rt.jar) of code , is really not making any sense to me. Also I completely disagree that technology consideration should NOT be made on size of jar files and I really dont see anything IDIOTIC in that. Size consideration is done in order to make sure that future requirements are met. Making such consideration is called as smartness and not idiotic.
Regards,
Kuldeep
Message was edited by: cool9889
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 27, 2008 9:37 AM
in response to: cool9889
|
|
Helpful |
|
|
The issue of the number and size of JARs needed for clients - stand-alone or Java EE app clients - is represented in issues (https://glassfish.dev.java.net/issues/show_bug.cgi?id=4109) and other forum posts.
We are very eager to address this in GlassFish v3. An earlier comment mentioned about packaging or factoring, and that's precisely why we have not been able to address this prior to v3. As an example, quite a few of the classes that the app client container needs are in appserv-rt.jar (in v2). But so are many other classes that the ACC has no interest in or dependency on. Yet, as noted, the whole JAR needs to be present on the client to provide those classes that the ACC does need. The same applies to some extent with some of the other required JARs.
The packaging of classes and resources into JARs has received and continues to receive very close attention in v3. The task was just too large and its scope too broad to allow any meaningful improvements prior to v3.
I realize this does not offer much short-term relief to people strugging with this in v2. But sometimes it helps to know that improvement is on the horizon.
- Tim
|
|
|
|
|
|
|
|
|
Re: JMS Standalone Client
Posted:
Mar 27, 2008 5:08 PM
in response to: tjquinn
|
|
|
Thanks Tim, Your comments were helpful.
Regards,
Kuldeep
|
|
|
|
|
java.net RSS
