|
Replies:
7
-
Last Post:
Mar 5, 2008 2:06 PM
by: Glenn Holmer
|
|
|
|
|
|
|
remote EJB best practices
Posted:
Mar 5, 2008 6:11 AM
|
|
|
What's the best way to write a standalone app that accesses EJBs in a
running enterprise app on a different machine?
--
____________________________________________________________
Glenn Holmer gholmer@weycogroup.com
Software Engineer phone: 414-908-1809
Weyco Group, Inc. fax: 414-908-1601
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
Re: remote EJB best practices
Posted:
Mar 5, 2008 6:23 AM
in response to: Glenn Holmer
|
|
|
|
|
Maybe you can be a bit more specific with your question. What actually
do you like to know?
Otherwise the answer cannot be more specific than:
* User your faviourite Java IDE.
* Read the Java EE 5 spec.
* Type in the code.
But I assume that this is not what you like to know...
Do you already know about the Java EE 5 architecture in general, and
client containers in particular?
Have Fun
Markus
Glenn Holmer schrieb:
> What's the best way to write a standalone app that accesses EJBs in a
> running enterprise app on a different machine?
>
>
--
http://www.xing.com/go/invita/58469
[smime.p7s]
|
|
|
|
|
|
|
|
|
Re: remote EJB best practices
Posted:
Mar 5, 2008 6:36 AM
in response to: Markus KARG
|
|
|
Markus KARG wrote:
> Maybe you can be a bit more specific with your question. What
> actually do you like to know?
I'm thinking about the classic example of an e-commerce site with a
web-facing storefront and a separate customer service interface. Is it
feasible to write the customer service interface as a Swing app that
calls the EJBs? We're also concerned that we won't be able to do SQL
"quick fixes" directly against the database because of JPA holding
records, so the question of being able to write one-off programs without
restarting the app has come up. Part of an appclient has to be deployed
to the server along with the enterprise app, doesn't it?
> Do you already know about the Java EE 5 architecture in general, and
> client containers in particular?
We're fairly new to EJBs and GlassFish. We've used Struts and Spring
before (with Tomcat).
> Glenn Holmer schrieb:
>> What's the best way to write a standalone app that accesses EJBs in
>> a running enterprise app on a different machine?
--
____________________________________________________________
Glenn Holmer gholmer@weycogroup.com
Software Engineer phone: 414-908-1809
Weyco Group, Inc. fax: 414-908-1601
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: remote EJB best practices
Posted:
Mar 5, 2008 7:02 AM
in response to: Glenn Holmer
|
|
|
|
|
Glenn Holmer schrieb:
> Markus KARG wrote:
>
>> Maybe you can be a bit more specific with your question. What
>> actually do you like to know?
>>
> I'm thinking about the classic example of an e-commerce site with a
> web-facing storefront and a separate customer service interface. Is it
> feasible to write the customer service interface as a Swing app that
> calls the EJBs? We're also concerned that we won't be able to do SQL
> "quick fixes" directly against the database because of JPA holding
> records, so the question of being able to write one-off programs without
> restarting the app has come up. Part of an appclient has to be deployed
> to the server along with the enterprise app, doesn't it?
>
(1) The Java EE 5 "Default Architecture" for this scenario (you can
always derive from it) could to have all business rules in session beans
(like a "business service"), and make that session beans call entities
(JPA API), and (a) have a servlet or JSP/JSF page call the session bean
for browser clients and (b) have a Swing client that calls the session
bea for "fat clients". Clients always run in contains (unless you are
using Web Services): The container for servlet or JSP/JSF is the "web
container" running on the server side, the container for the "fat
client" is the so-called "Client Container", running on the client
computer (remotely, obviously). The container deals with all the nice
stuff like user authentication, client-server-communication etc., so
your client doesn't need to deal with that mostly. I recommend that you
first check some good book on Java EE before starting, at least you
should read either the official Java EE 5 Tutorial (very good starting
point), Java EE 5 Blueprints or the spec (if you have time to read 5000+
PDF pages).
(2) JPA allows to run native SQL, but most of the time you won't need
it, since JPA is quite powerful and mighty. You'll seldomly have a
*real* need to run native SQL. No records will be "hold" (I think you
mean locks or cached instances), since transactions are short termined
typically in JPA (if not, it was you that told the app to keep the TX
open for long time, so it is your own fault most of the time). No
records will get inconsistent by "bypassing" JPA, unless you tell JPA to
do so, since the cache is only used WITHIN a transaction by default
AFAIK (but I could imagine that this is vendor dependent).
(3) I have no clue what you mean with "on-off programs", actually.
(4) No part of the client application has to be deployed to the app
server, as long as "client" means "Swing fat client". If "client" means
"server", "JSF" or "JSP", this is completely installed on the
application server.
>
>> Do you already know about the Java EE 5 architecture in general, and
>> client containers in particular?
>>
>
> We're fairly new to EJBs and GlassFish. We've used Struts and Spring
> before (with Tomcat).
>
Ok then I think it is a good start to check the official Java EE
Tutorial to get a first impression of the core architecture and usage of
both.
>
>> Glenn Holmer schrieb:
>>
>>> What's the best way to write a standalone app that accesses EJBs in
>>> a running enterprise app on a different machine?
>>>
>
>
Have Fun
Markus
--
http://www.xing.com/go/invita/58469
[smime.p7s]
|
|
|
|
|
|
|
|
|
Re: remote EJB best practices
Posted:
Mar 5, 2008 10:17 AM
in response to: Glenn Holmer
|
|
|
> I'm thinking about the classic example of an e-commerce site with
> a web-facing storefront and a separate customer service interface.
> Is it feasible to write the customer service interface as a Swing app
> that calls the EJBs? We're also concerned that we won't be able to do
> SQL "quick fixes" directly against the database because of JPA holding
> records, so the question of being able to write one-off programs without
> restarting the app has come up. Part of an appclient has to be deployed
> to the server along with the enterprise app, doesn't it?
Writing the Swing app is no problem. It can talk to Remote EJBs in two ways.
One, is the "official" JEE way using the appclient. This is, indeed, deployed to the app server, and typically run through a Webstart link (there are other ways of getting the application than webstart, but that's a simple way).
Using this model, you can leverage the new injection capabilities of EJB3, much like you do with modern servlets (e.g. @EJB YourRemoteEJB ejb;).
The other model is a generic, standalone client. This model is perfectly workable, and has no real dependencies on the app server. However, this model is not portable across JEE containers. But, to be fair, porting this is not particularly difficult with some clever refactoring. Just the actual connecting up to the host EJB server is the non-portable part, and that part can be readily isolated in your application. Once you have the actual EJB reference, all of that code is the same. The other detail is that you need to deploy container specific JARs with your application, which would change if you changed container. But it's really not that big of a deal. Once you do it the first time, you've worked out most of the issues. Consult the Glassfish EJB FAQ for details on this.
There's actually a 3rd way, and that's using just web services rather than remote EJB. This is a different development model (remote EJBs can return object graphs, while web services can only return object trees) and has its own challenges, but it's quite viable if you want to consider that option. It seems to me that the wind is turning toward web services over Remote EJBs.
You WILL potentially have issues with "quick SQL fixes", depending on their nature and how they are done. JPA caches much of it data, and a classic issue would be going in to the DB and, say, changing a flag on a customer record. Odds are if that customer has already been cached by the JPA, your application will not see the change.
One mechanism to avoid this is rather than doing "quick SQL fixes", instead, do "quick EQL fixes". And by that I mean create a simple, secure (natch), client to your EJB tier that can take arbitrary EQL statements and execute them. EQL is much like SQL for many tasks (so you can, say, easily do bulk EQL update statements, and the like). EQL is a JPA artifact, so it "knows" about the JPA cache and will "do the right thing".
This is far easier than fighting the JPA second level caches.
Another interesting thing you can do is add a scripting interface to the EJB tier which takes a JavaScript script and executes it. JavaScript it now bundled with Java 6, or can easily be added using the Rhino project. You can easily call your Entities from JavaScript (as well as your Session Beans), which would again leverage JPA. This, too, is not hard to implement, and gives you a lot of flexibility for writing "one offs" that you can readily run on the app tier.
Either of these gives a quick ability to do on the fly stuff via the app tier, without having to do a lot of work. Now, out of the box it won't necessarily be as nice as a good SQL program, but ideally you're not doing "exploratory" stuff on your production DB anyway, but you "know exactly what you need to do" and just need a mechanism to do it, so these ad hoc interfaces aren't as horrible as they may sound. And if you're wrap them tightly in transactions, they're pretty safe from typos, 10 thumb event's and other minor traumas.
|
|
|
|
|
|
|
|
|
Re: remote EJB best practices
Posted:
Mar 5, 2008 1:01 PM
in response to: whartung
|
|
|
glassfish@javadesktop.org wrote:
> The other model is a generic, standalone client. This model is
> perfectly workable, and has no real dependencies on the app server.
> Consult the Glassfish EJB FAQ for details on this.
Thanks, I was able to get one of those up and running very quickly after
reading the FAQ. I think that's exactly what we're looking for. I
haven't tried it across machines yet, but that doesn't seem like it
would be a problem.
The only thing that concerns me is whether having the remote interfaces
in place (we weren't planning that for now) will slow the web app down?
> You WILL potentially have issues with "quick SQL fixes", depending on
> their nature and how they are done. JPA caches much of it data, and a
> classic issue would be going in to the DB and, say, changing a flag
> on a customer record. Odds are if that customer has already been
> cached by the JPA, your application will not see the change.
Exactly what we're concerned about.
> One mechanism to avoid this is rather than doing "quick SQL fixes",
> instead, do "quick EQL fixes". And by that I mean create a simple,
> secure (natch), client to your EJB tier that can take arbitrary EQL
> statements and execute them.
I thought of that, but didn't want to admit it  But if we can get
standalone clients working, we can write single-use programs for things
like that.
--
____________________________________________________________
Glenn Holmer gholmer@weycogroup.com
Software Engineer phone: 414-908-1809
Weyco Group, Inc. fax: 414-908-1601
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: remote EJB best practices
Posted:
Mar 5, 2008 1:52 PM
in response to: Glenn Holmer
|
|
|
> The only thing that concerns me is whether having the
> remote interfaces
> in place (we weren't planning that for now) will slow
> the web app down?
Recall that Remote EJBs are simply an option as well as Local EJBs.
If you web tier is colocated with the app tier in the same EAR (and on the same server, obviously), then your web tier can enjoy the local calling semantics with Local beans while you Swing client will use the Remote interfaces. Neither will affect the other.
I have found, tho, that if you're sending large collections of objects (like a List of a several thousand non-trivial objects), that Remote EJBs can be memory intensive and, in fact, slower than Web Services. (It was for the one specific instance I was playing with.)
Also, Remote Beans won't enjoy the lazy loading abilities that the JPA provides to local instances. It's probably not a big deal, obviously it depends on your application, but it's something to be aware of.
|
|
|
|
|
|
|
|
|
Re: remote EJB best practices
Posted:
Mar 5, 2008 2:06 PM
in response to: whartung
|
|
|
glassfish@javadesktop.org wrote:
>> The only thing that concerns me is whether having the remote
>> interfaces in place (we weren't planning that for now) will slow
>> the web app down?
>
> Recall that Remote EJBs are simply an option as well as Local EJBs.
>
> If you web tier is colocated with the app tier in the same EAR (and
> on the same server, obviously), then your web tier can enjoy the
> local calling semantics with Local beans while you Swing client will
> use the Remote interfaces. Neither will affect the other.
I noticed that when I asked NetBeans to generate session beans for my
entity classes that he gave a warning about local and remote interfaces
having the same names (even though he generated them that way). What's
best practice on that? Do I have local and remote interfaces with
different names, e.g. create() and createRemote() and have them both
delegate to the same method in the implementing class? Is the warning
because GlassFish might not know whether to call the local or either the
remote interface?
P.S. I have it working across machines now, as well.
--
____________________________________________________________
Glenn Holmer gholmer@weycogroup.com
Software Engineer phone: 414-908-1809
Weyco Group, Inc. fax: 414-908-1601
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
java.net RSS
