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

[Tomi Tuomainen]

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]

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]

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]

> 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]

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]

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]

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]

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]

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

[Frank Silbermann]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

>>> 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]

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