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.
精彩评论