Code Reuse Vs Runtime Reuse

[Mohamed Farouk]

Dear Friends
I am working in a programme which is composed of different applications.
Now the current architecture design promotes code sharing meaning component
code is shared across applications any small change requires all the applications to be changed and redeployed which is starting to prove expensive.
Now I am thinking of suggesting new projects which include common components to run on separate JVMS as EJB to promote RUNTIME SHARING which
will make future developments easy to develop and deliver as they can just lookup JNDI and call this current common instance running on another JVM,

Please can you enlighten me the pros and cons of code and runtime sharing approach and help me to take a decision

Thanks
Farouk

[Jeanne Boyarsky]

Farouk,
The biggest pro of runtime sharing is what you've noted: the code is only deployed in one place.

The biggest con is that if that EJB goes down, it causes a big outage. You can minimize this risk with clustering.

[Mohamed Farouk]

Thanks for your reply
We use websphere in a clustered environment. I understand that pro and I am trying to convince the design team here that we should go for the single deployment approach but they are now saying about performance and outage it will cause if the component is not available.
How will you go about convincing that the way forward is to doing a single deployment.?
There main question is whether performance will be affected?
Please reply, I think this is a practical question to solve
Regards
Farouk

[Jeanne Boyarsky]

Originally posted by Mohamed Farouk:
There main question is whether performance will be affected?

That depends on how many instances you are comparing. If you have the same EJB deployed to 5 applications, are you comparing it to 5 clustered remote EJBs.

Some arguments for the reused approach being faster:
-The code is more centralized so results would be better cached.
-There is less contention with other processes within a JVM

Some arguments for the reused approach being slower:
-You have to use remote interfaces resulting in more network traffic.
-Calls may be more diverse causing less caching for the single application.

So basically, it depends. One isn't inherently faster than the other.

[Roger Chung-Wee]

Are you saying that your apps run in a WebSphere clusters but you are proposing a non-clustered deployment of your common components? This doesn't make sense to me. I think your design team raises a valid point about resilience. Furthermore, will there be an issue if your non-clustered common components fail to scale when its clustered clients are scaling?

[Mohamed Farouk]

Roger I think you have completely misunderstood my point

I am saying to use the clustered environment and deploy a single instance of an component (May be EJB) and make it available as a common run time available component (BY JNDI LOOKUP) rather than deploying the code inside each and every different application and make maintanence a night mare ..

Do you agree..
How will you argue to bring this change in to practice. As right now the component inside different EAR works fine. And they are planning for new development in the same way as before

Thanks
Farouk

[Roger Chung-Wee]

Sure, no problem in treating the common components as an app and deploying to a cluster. In fact, that's how I would expect it to be done. Indeed, a service oriented architecture encourages this.

I'm not sure what the design team's concerns are if you do deploy to a cluster as you should get high availability.