Architectual Choices

[ajordens]

A little background....

I'm currently involved in a situation where we have an existing J2EE application.

The majority of the functionality is exposed via a thick swing client. We also have a thin web interface that targets a different class of end-users. We're using Entity EJB's and CMP for the backend DB interactions. These entity beans are fronted by a remote (or local in the case of the in-container web interface) session bean facade. JMS is used in combination with stateful session beans to help synchronize the potentially concurrent thick-clients current accessing the system.

The system does manage a fairly significant amount of data and looking forward I forsee some problems arising particularily in regards to performance and maintainability.

I have experience with Hibernate on some personal projects and Spring to a lesser extent. I'm working my way through (and enjoying) Rod's latest J2EE without EJB book. I have a lot more reading and understanding to do but I'm open to any suggestions from the group as to what direction I could move.

I'm currently trying to brainstorm potential choices. Benefit of moving away from entity beans (and session beans) is the ability to do out of container testing. Testability is one concern with the current architecture.

Choice 1:

Keep the session bean facade but ideally transition from stateful to stateless session beans. Move the JMS handling (msg firing) into spring. Move from entity beans and CMP to Hibernate. Thick clients would continue to interact with the session facade. Immediate problems I see is in the serialization of data objects between the app server and remote clients.

Choice 2:

Move away from an app server. Deploy the web interface with spring layer into a web container. Couple the spring/hibernate layer with the thick-client. A JMS server would be hosted on the same server as the web container. This solution moves from 3 tiers to 2 tiers which I cannot really convince myself is optimal. However, I can see performance picking up immediately. The application is multi-user but in the short to medium-term, not massively multi-user.



Anyways, I'm open to feedback, alternative choices and any experiences that others have made when faced with similar circumstances.


Regards.

[Ben Alex]

Does your application use distributed transactions? Or does it have its beans distributed between multiple application servers? These are the sorts of situations where a traditional EJB approach will shine. Do you need to minimise risk by a gradual migration from your present application to the new platform?

"Choice 2" is probably better if the above factors do not apply. The fact the web and application tiers are collocated will only improve performance due to in-JVM calling rather than remoting. As Rod's book continuously says, unless there is a compelling reason you should collocate all of your beans and your webapp.

[ajordens]

Does your application use distributed transactions? Or does it have its beans distributed between multiple application servers? These are the sorts of situations where a traditional EJB approach will shine. Do you need to minimise risk by a gradual migration from your present application to the new platform?

"Choice 2" is probably better if the above factors do not apply. The fact the web and application tiers are collocated will only improve performance due to in-JVM calling rather than remoting. As Rod's book continuously says, unless there is a compelling reason you should collocate all of your beans and your webapp.

No, the application does not current use or have a need for distributed transactions. Furthermore, beans are co-located in a single application server. I don't anticipate where a situation would arise where application beans were spread out over multiple application servers. I admit that I don't know an awful lot about clustering, but I don't believe that even if we did cluster the application that we would spread the beans out...

Well, it would be ideal if a gradual migration from the current architecture to a new architecture could be achieved, but it is not a hard requirement. The ideal situation is to be able to test a slice of the application in the new architecture to get an idea of what kind of improvements could be anticipated.

On to choice #2 where the majority of the users access data via a thick webstartable application. A smaller set of end-user's access the web interface. Our priority lies primarily with the thick-client users and ensuring them a measure of performance and us, a measure of flexibility and improved maintainability. It definately makes sense to co-locate spring's beans with the web application in the web container. However, what are the implications for co-locating the spring beans with the thick-client. Database connection pooling could be one concern, but in reality there likely won't be hundred's of concurrent users. If we do need to scale upwards, we could likely do so on the database level. Are there any gotchas associated with colocating the beans with each thick-client (quasi 2 tier) as opposed to using a spring remoting strategy (like HTTP Invoker) and only having the beans reside in the web container (natural 3 tier) ?


Thanks for the reply.

Regards.

[Ben Alex]

I guess there's nothing fundamentally wrong with a two tier approach where beans are deployed along with the rich client, provided that:

- You don't need server services such as JMS, JTA etc
- You trust clients won't lookup the RDBMS connection password and misuse it
- You can ensure changes in versions are deployed via JWS without any old prior version deployments co-existing
- You won't have database connection pool limitations
- You don't need to move large amounts of data from the RDBMS to the clients across slower links (a server could be located near the RDBMS)
- You don't think much benefit would come from caching in the middle tier
- You don't have computationally intensive calculations which would perform better on dedicated server hardware
- You aren't concerned by the fact you'll still need a web server anyway, to handle web clients

Personally I would use a three tier approach with a servlet container in most cases. Having said that, if you design a correctly layered architecture (ie a clear line between business tier and presentation tier), it shouldn't be too difficult to change deployment structure in the future. For example, in the Petclinic RCP sample we simply use a different application context (no Java code changes) to accommodate a local service layer (two tier) versus a remote service layer (three tier).

[ajordens]

I guess there's nothing fundamentally wrong with a two tier approach where beans are deployed along with the rich client, provided that:

- You don't need server services such as JMS, JTA etc
- You trust clients won't lookup the RDBMS connection password and misuse it
- You can ensure changes in versions are deployed via JWS without any old prior version deployments co-existing
- You won't have database connection pool limitations
- You don't need to move large amounts of data from the RDBMS to the clients across slower links (a server could be located near the RDBMS)
- You don't think much benefit would come from caching in the middle tier
- You don't have computationally intensive calculations which would perform better on dedicated server hardware
- You aren't concerned by the fact you'll still need a web server anyway, to handle web clients

Personally I would use a three tier approach with a servlet container in most cases. Having said that, if you design a correctly layered architecture (ie a clear line between business tier and presentation tier), it shouldn't be too difficult to change deployment structure in the future. For example, in the Petclinic RCP sample we simply use a different application context (no Java code changes) to accommodate a local service layer (two tier) versus a remote service layer (three tier).


Thanks.

I think I'm going to roll with the same approach as the RCP sample. I've got a simple implementation going that can either use 2 tiers or 3 tiers with tomcat in the middle. Off the top I'm using hessian for the serial communication, I'm not sure if there is a higher performance option?

I will need to incorporate JMS. I haven't look into it in great detail but I would hope/imagine Spring has the appropriate mechanisms to connect to a topic. The rich client should be able to do what it always has done, subscribe to the topic and take appropriate msg response actions.

In the short term, at the very least I'm able to write unit tests against both strategies which is a benefit over the traditional ejb approach.

I'm intigued by Spring RCP but I think it may be too early stage for me. Definately something I'll be keeping my eye on.


Cheers.

[Franklin Antony]

I never got a chance or I never knew about the Petclinic RCP. Now I will have a look at it. So I am assuming that in a 3 tier approach like Petclinic RCP we can independently scale each tier??? Like only the Business Layer !!

Regards,
Franklin.