File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Should Swing application connect to Web application or directly to EJB tier? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Should Swing application connect to Web application or directly to EJB tier?" Watch "Should Swing application connect to Web application or directly to EJB tier?" New topic
Author

Should Swing application connect to Web application or directly to EJB tier?

Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
This seems to be a common discussion in many topics so let's find out the ultimate truth here.

If I want web application taking care of the security alone, I would have to connect to it from swing application. How this would be implemented in practise? Do I have to use URLConnection or similar class and format requests and parse responses? How would I transfer http-view data into swing?

Maybe this is trivial procedure, but sounds very difficult to handle compared to a direct connection to EJB server with RMI(IIOP). In that way we are dealing with serialized objects and method calls in true o-o fashion. Swing is event-driven and rich client is providing usually more information in one screen. So I find it difficult to use Web app screen flow manager for Swing.

Are there any other real benefits in Swing connecting to Web application than security issue? It's not much work to make EJB server use the same authentication realm and configure container managed security also there. I could put stuff that's common to both clients anyway to EJB tier controller (or command classes).

This is a big issue for my design so any comments will be appreciated.

Tomi
Darryl A. J. Staflund
Ranch Hand

Joined: Oct 06, 2002
Posts: 303
Hi there,

Cade distinguishes the client tier from the presentation tier. The client tier contains applications responsible for rendering business data in a given display technology. The presentation tier on the other hand is responsible for managing authentication, filtering, and presentation logic / flow that is common to all the various client front-ends of a given application.

Given this, you could view the assignment as consisting of two client front-ends (one JSP, the other Java GUI) whose filters, authentication, and presentation logic are managed by a common presentation tier. The presentation tier in turn would be responsible for accessing the business tier.

Darryl
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Thanks Darryl, I get the idea. But is this presentation tier in a web server or in an application server? In other words, is it implemented as servlet(s) or as session bean(s)? If it is in the web server, how would Swing communicate with it?

Tomi

[ July 22, 2004: Message edited by: Tomi Tuomainen ]
[ July 22, 2004: Message edited by: Tomi Tuomainen ]
Darryl A. J. Staflund
Ranch Hand

Joined: Oct 06, 2002
Posts: 303
> Thanks Darryl, I get the idea. But is this presentation tier in a web
> server or in an application server?

Web server.


> If it is in the web server, how would Swing communicate with it?

You could use XML-RPC over HTTP. Or SOAP. Or RMI. I don't think it really matters. As long as you map various client request protocols (HTTP, SOAP, RMI, etc.) into a client-neutral representation (using something like the Context Object design patterns) then you can handle all clients using the same common logic.

Darryl
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Yep, I thought of SOAP too. I'm just not sure that these clients have that much in common logic that building a presentation tier is worth the trouble. Presentation logic can be quite different in Swing: search, results, alternative choices, confirmation can be shown in one frame. And it's surely not wise to access the server in every KeyEvent. With web-container managed security we can define protected resources and container shows a login screen whenever necessary. This doesn't fit very "automatically" in Swing client. What could common filters be? Container managed authentication should be easily tuned in EJB tier too, extra logging in Web tier is not must help for Swing. Perhaps common session checks could be useful though in Web tier.

Maybe I'm thinking this too much in coders point of view. Creating sensible architecture is our task and I think both choices (Swing -> Web App and Swing -> EJB) should be acceptable as long as we justify our choices.

Tomi
Nancy Field
Greenhorn

Joined: Jun 22, 2004
Posts: 3
I think an easy and good solution is : web application leverages web container managed security, while agent must login first to use the Swing GUI. What do you guys think?

BTW, I do not like the idea to build the common presentation tier. The two clients do not have much common logic. Tightly bundling the presentation control will make the system hard to extend. Besides, this will add one more dependency to the swing : the web server. If the web server is down, an agent cannot access the system.
[ August 10, 2004: Message edited by: Nancy abc ]
Gavin Andrews
Greenhorn

Joined: Aug 09, 2004
Posts: 18
The Web and TravelAgent (Swing) application have IDENTICAL functionality in that they share all the same use cases.

It would seem that the simplest implementation shares the biz logic in a tier accessed by either a web tier or via a proxied swing app... i.e. expose the biz tier as say SOAP??? use SOAP from the web app AND the swing app???
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Originally posted by Gavin Andrews:
The Web and TravelAgent (Swing) application have IDENTICAL functionality in that they share all the same use cases.

If the user interfaces would be identical, it wouldn't make sense to build two clients. Specification doesn't say much about the differences but the user interface functionality is a design issue I think...

It would seem that the simplest implementation shares the biz logic in a tier accessed by either a web tier or via a proxied swing app... i.e. expose the biz tier as say SOAP??? use SOAP from the web app AND the swing app???

No SOAP in EJB tier for me, thanks . Swing can use SOAP to access common presentation tier in a web server, but there's no need to use it otherwise (unless we want to support also .NET clients ). EJB tier business services can be accessed via standard InitialContext and jndi-lookup methods from both Web and Swing clients.

Tomi
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782

EJB tier business services can be accessed via standard InitialContext and jndi-lookup methods from both Web and Swing clients


I agree. Have a common business delegate implementation that is deployed with both Web and Swing client apps. The delegate will then talk to service locator....and you get the point


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Frank Silbermann
Ranch Hand

Joined: Jun 06, 2002
Posts: 1387
This discussion makes me wonder, suppose this were purely a 3-tier client-server application with fat client. How would we handle login security?

Would the application server housing the EJB container handle login security for me? Would a web tier be considered just one more "fat client"?
Parag Doshi
Ranch Hand

Joined: Jun 29, 2004
Posts: 317
The approach which makes sense to me is that the swing app communicates directly to the ejb tier (via business delegate) and the web client does it thru its action/event objects communicating with a web app implementation of the business delegate.

I think having separate implementation for business delegate would help as the swing based BD implementation would do something extra like caching, broader queries/larger resultset retrieval etc which the web based BD may not do. Plus making a swing client communicate via the web tier has performance implications. It would either have to create HTTPConnection objects or do XML-RPC connections. Both has additional overheads and I am more driven to keep the swing app as performance-efficient as possible. I know it may not be the "ideal" textbook solution, but I would like to keep it simple with as less layers as possible in the swing app.

As far as security is concerned, I like the following implementation scenario. Swing based client are authenticated by the ejb client container and the User Principal is propagated to the ejb tier which depends on trust association and does not do any more authentications. It does its authorization based on the propagated User Principal.

Web based clients can be authenticated in 2 possible ways. The first way is to let the web container (running on the web servers) authenticate the user and then propagate the User Principal to the EJB tier (same flow as Swing client). Or the EJB container authenticates the user. In this scenario the war file would be deployed on the app server (as the secured resources need to be deployed in the ejb container if it needs the ejb container to authenticate it). If the jsp/servlets etc are deployed as a war on the app server, then I am not using the web servers to the fullest possible extent and they are merely reduced to file servers serving static content. This is ok for certain large scale apps having heavy static content, but does not meet my assignment requirements.

Hence, I am leaning more towards the web container authentication for web tier (with trust association and User Principal propagation to do the rest for me for EJB tier) and ejb client container authentication for swing clients , with security trust association and User Principal propogation to the ejb tier.

Ofcourse, I could be wrong in the assumptions I have made above, and if anything sounds technically wrong, please correct me.

Thanks,
Parag
[ August 11, 2004: Message edited by: Parag Doshi ]
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Frank,

I've been thinking about the same problem. The best practise is to use container-managed security whenever possible. For web tier this is not a problem, I think we can count on web container to handle authentication and authorization. I like this idea a lot because it's the preferred way for web applications and very easy to implement.

For application client (Swing) we could use security roles with components in EJB tier. But how the authentication/authorization will be implemented in practise when the client doesn't know anything about protected resources? Can client just catch security exceptions and conclude when login is needed, username/password was wrong or credentials wasn't enough? Do we need a component in EJB tier, which could tell the client what functionality is available (result of getCallerPrincible method)?

And is there any reasonable way to build a common authentication/authorization mechanism for both client types if we want to stick to container managed security?

Any thoughts appreciated...

Tomi
Parag Doshi
Ranch Hand

Joined: Jun 29, 2004
Posts: 317

For application client (Swing) we could use security roles with components in EJB tier. But how the authentication/authorization will be implemented in practise when the client doesn't know anything about protected resources? Can client just catch security exceptions and conclude when login is needed, username/password was wrong or credentials wasn't enough? Do we need a component in EJB tier, which could tell the client what functionality is available (result of getCallerPrincible method)?


I think the ejb client container steps in whenever an ejb resource is requested. One of the requisites of the ejb client container is to authenticate the user before it can access any of the ejb resources. It might either authenticate at startup or might implement lazy authentication. So, when the user requests an ejb resource, the client container will do the authentication and propagate the user principal to the ejb server container where the authorization will take place.
There is a concept of a ejb client xml descriptor file, where the application developer has to mention the ejbs which will be invoked from the standalone client. That way, the ejb client container knows which ejbs you are gonna invoke and does authentication appropriately.

I hope I understood your question..

parag
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Thanks Parag . I just didn't know EJB Client Container can take care of all that stuff. I checked it from BluePrints and it seems that we don't have to worry about Java Application client security either. Of course all of this stuff must be configured, but I guess we don't have to think about security components in our diagrams? (if we count on container security)

Of course it is a good idea to explain a little about security mechanisms in assumptions.

Tomi
Gavin Andrews
Greenhorn

Joined: Aug 09, 2004
Posts: 18
In deployment terms the connectivity between the Swing client and the 'Application' should be made as friendly as possible to allow easy configuration of the network infrastructure... IMHO I would say this eliminates an RMI based solution... and also you need to consider security... is the network secure to the Travel Agent???

The alternative is either do-it-yourself XML exchange, XML-RPC or SOAP over HTTPS.

You could just have a SOAPy front controller that shares the same Business Delegates as the WAF commands.
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Gavin,

RMI can be used with SSL (see here). EJB containers may require a special protocol, for example Weblogic uses t3 which I think is RMI over IIOP. The connection can be secured with ssl (t3s). Application client needs weblogic.jar which is used for EJB tier connection via InitialContext.

I think we can assume that a decent application server will be selected, which offers secured connections between a client and a server. Otherwise we would have to build also application server by ourselves, this is not the purpose of the assignment, no?

Tomi
Gavin Andrews
Greenhorn

Joined: Aug 09, 2004
Posts: 18
Tomi,

The choice is down to the level at which you expose the interface... You can either expose at the EJB layer (presumeably the Session Facade) or move the interface back up the web tier through the Business Delegates or all the way back to the Front Controller.

Personally, I advocate moving the interface all the way back to the GUIFrontController and accessing it via a Service Endpoint (i.e. SOAP); this allows common functionality between the Web version and the Swing version to be implemented only once (and remember they do share the same use cases so it likely they will be doing similar things even if the rendering is different).

Of couse, as with any architecture there is an element of 'style'... there is not 1 right answer.

Regards,
Gavin
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Thanks Gavin, I think get your point now. You we're talking about common presentation tier all along...

My point just was that if this common GUIFrontController is running in an application server, there's a "container-preferred", secured way to access it from different clients. If common GUIFrontController is running in a web server, we surely need SOAP or some other way to communicate with a Swing application client.

Tomi
D. Rose
Ranch Hand

Joined: Apr 25, 2003
Posts: 215
Hi,
For authentication, can I use third party tool (like LDAP) than container security?It would then be common for both clients.
I can directly go to EJB tier for GUI client.
That way I would need to worry about network security for both clients.

Do we have to stick to just J2EE solution for this?
Gavin Andrews
Greenhorn

Joined: Aug 09, 2004
Posts: 18
>>> My point just was that if this common GUIFrontController is running in:
>>> (1) an application server
>>> (2) a web server

Yeap; that's the decision that has to be made.
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Originally posted by D. Rose:
For authentication, can I use third party tool (like LDAP) than container security?

Hi D,

The idea of container managed security is that container can be mapped to an extra resource like LDAP or a database table, which holds users and roles. This means that both servers (Web and Application) can use a common resource. This way also both clients will finally access the same user data.

I don't think it's necessary to worry about network security in diagrams, but we should understand and explain shortly how security will be implemented. (I hope I'm not wrong in this one!)

I hope that answers the question...

Tomi
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Should Swing application connect to Web application or directly to EJB tier?