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