I have concerns about the performance of the following architecture:
- Java EE application in an appserver, ejb 开发者_开发百科session bean and DAOs
 - remote (rich) client, a swing app. A classic, form-based client
 - only one stateless ejb, the ejb is accessed via web services, not rmi, through a homegrown framework
 - each web service request will get authenticated against an LDAP
 - no state stored on the server, only client-side sessions
 
I guess working on the rich GUI will involve a remote call in every 2-10 seconds, or more, per user.
What do you think?
That's basically a client-server architecture. Whether it will work in practice in your case depends not only on the architecture diagram made of box and arrows, but will depend on a lot of other factors:
- performance and maturity of the home-grown web service framework?
 - size of the data transferred between the tiers?
 - performance of the authentication mechanism, number of roles, users, etc. ?
 - ability to cache information here and there?
 - how many concurrent users?
 - etc.
 
To me, that looks like a possible architecture. But I suggest you identify potential bottlenecks (e.g. authentication of each request) and make sure it works for your non-functional requirements. If yes, fine, if not, adapt the architecture.
                                        
                                        
                                        
                                        
                                        
                                        
                                        
                                        
 加载中,请稍侯......
      
精彩评论