| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Managing Libraries and Applications in V9 |
« View previous topic :: View next topic » |
| Author |
Message
|
| magvlvri |
 Posted: Wed Nov 12, 2014 8:29 am Post subject: Managing Libraries and Applications in V9 |
 |
|
Apprentice
Joined: 07 Nov 2014
Posts: 26
|
This topic is regarding Integration Bus V9.0 management of Application and library components at runtime.
If Application A is deployed with Library L1 to server and further, if Application B is deployed with *updates* to Library L1 to the same EG, will there be any impact to Application A?
I assume there wont be any impact, please correct me if am wrong.
If the above is true, does one have to redeploy all applications that use the library L1 if there are any updates to it?
Is there a way to do a standalone deploy of library and have applications refer to just one copy of library? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Nov 12, 2014 8:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Nothing has changed with Apps and libraries in v9 from v8.
Applications are containers. Nothing outside a container is visible to anything inside a container, and vice-versa.
Anything deployed outside an application is deployed to the default container.
Nothing inside the default container is visible to other containers, and vice versa.
If you wish to update part of an application, you must rebuild the entire application, and redeploy the entire application. |
|
| Back to top |
|
|
| magvlvri |
| Posted: Wed Nov 12, 2014 9:04 am Post subject: |
|
|
Apprentice
Joined: 07 Nov 2014
Posts: 26
|
Thanks, i had the same understanding from the "Runtime isolation and resource sharing with applications and libraries" topic in infocenter.
However, when you have a considerably large application running in production, for small updates in the code, you wouldnt ideally want to redeploy the whole thing all over again. This would raise questions about regression testing the whole application.
Is this not a scenario that one would come across frequently?
Again, Instead of redeploying all applications to pickup changes in library, is there not a need for a better solution? Just saying. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 12, 2014 9:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Shouldn't you be regression testing anyway?
At what point is a "change to an application" small, versus large? one line of code? one hundred? one field in a schema? ten?
If doing any kind of deployment at all doesn't cause an outage, does it matter how much is deployed?
Please note that these are all questions, and not opinions, nor facts.
I'm reasonably sure there's more than one RFE on this topic. And I know that the dev team is aware of the overall picture.
I don't know if or when anything will change. Perhaps you could review the v10 open beta. |
|
| Back to top |
|
|
| magvlvri |
| Posted: Wed Nov 12, 2014 10:47 am Post subject: |
|
|
Apprentice
Joined: 07 Nov 2014
Posts: 26
|
There is always a distinction in the scope of impact when a change is done. When a complex application with multiple services is in discussion, a minor update to one of the services doesnt directly translate into a wholesome regression testing exercise but will be limited to that service alone.
Anyways, thanks for reminding about the V10 beta documentation, yes, there is an update callled "shared libraries" where multiple applications can access a common library at runtime which resides outside the application container. Deploying an update to shared library would automatically translate into all applications accessing the new version of the library without redeploying every application. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 12, 2014 11:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| magvlvri wrote: |
| There is always a distinction in the scope of impact when a change is done. When a complex application with multiple services is in discussion, a minor update to one of the services doesnt directly translate into a wholesome regression testing exercise but will be limited to that service alone. |
If I had $5 for every "minor" change that couldn't possibly affect anything but managed to cause a serious problem and/or outage which I've seen, I'd have retired to Bali by now. Having bought the entire island cash.
The need to do a regression test every time you sneeze at Production is why there are so many automated testing tools. The problem will only become more acute when you start using shared libraries and have the ability to affect components you've not even changed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
