| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Question on WMB8 Library usage and deployment |
« View previous topic :: View next topic » |
| Author |
Message
|
| bijesh |
 Posted: Tue Oct 30, 2012 9:53 am Post subject: Question on WMB8 Library usage and deployment |
 |
|
Acolyte
Joined: 30 Jan 2007
Posts: 66
|
Hi All,
We have a requirement in our project to use Canonical message model for all the services developed in the environment.
We currently use WMB8 as our broker environment.
If we go by the infocenter documents, a library has to be created with the canonical message model.
All the applications will have to refer to the common library which has the canonical mesage model defined in it.
If there is a change to the canonical message model, every application that uses this message model have to be redeployed in order to have the latest change reflected.
I believe this will be an overhead with respect to the deployment of all the applications that is referring to the library(canonical message model).
Please correct me if there is anything wrong with the above understanding.
Please suggest if there is a better way to do it ?
Thanks
Bijesh. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Oct 30, 2012 9:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| How could the canonical model change without requiring that the transformations that use the canonical model also change? |
|
| Back to top |
|
|
| bijesh |
| Posted: Tue Oct 30, 2012 11:41 am Post subject: |
|
|
Acolyte
Joined: 30 Jan 2007
Posts: 66
|
Yes, that is true. A canonical model change could result in a transformation change to the services that make use of it which will result in deployment of the application.
But if there is a situation where there is a structural change (addition of optional elements) to canonical message model and some of the services does not have any transformation requirement with respect to the newly added elements.
In such a case, should we still continue deploying those services which does not have any change or should we allow it to refer to the previous version of the library which do not have the latest set of changes, thus by creating multiple versions of the library in the runtime environment.
We are trying to analyse and come up with a conclusion in terms of how to use or structure the Applications and Libraries in our environment.
Please suggest. |
|
| Back to top |
|
|
| NealM |
| Posted: Tue Oct 30, 2012 3:15 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Usually, changing an underlying canonical message model is a pretty serious business. If you want to allow two or more versions, you do open yourself up for additional support issues down the road vs the upfront work of moving everything to the new version and retesting. I know that my client hates the idea of supporting multiple versions. Even though we set up a URL naming structure that allows for it for web services, we never do so. |
|
| Back to top |
|
|
| goffinf |
| Posted: Wed Oct 31, 2012 1:27 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| bijesh wrote: |
But if there is a situation where there is a structural change (addition of optional elements) to canonical message model and some of the services does not have any transformation requirement with respect to the newly added elements.
In such a case, should we still continue deploying those services which does not have any change or should we allow it to refer to the previous version of the library which do not have the latest set of changes, thus by creating multiple versions of the library in the runtime environment.
We are trying to analyse and come up with a conclusion in terms of how to use or structure the Applications and Libraries in our environment.
Please suggest. |
Well, as you will have no doubt found out from your experiments with Apps and Libs, the context in which you deploy your business flows that use your common library makes all the difference in terms of the impact of change and how you can apply version control to your canonical model.
ie. if your common Lib is referenced by business flow(s) packaged as an App then essentially that App has a private copy of the Lib, so changing it doesn't have any effect unless you recompile and redeploy the App. If that particular App has no interest in the change you have made, why would you redeploy it. The same can be true of other deployed flows, again depending on how you have packaged them (i.e. whether you use 'Compile and in-line resources', whether you use the 'default' Application context that all EGs have, and so on).
Allied to this of course is how you manage your resources in terms of source control.
I think the problem you are really trying to resolve here is how you manage a shared resource (your canonical data model) when that resource has to change. Essentially this is determined by your versioning policy. Clearly anything that is shared has a greater potential to impact existing deployed code, so you versioning policy becomes key. In my experience it is unlikely that you can follow a 'big bang' approach to every change that might effect your shared Lib (your comments suggest you realize that so sorry if I'm telling you how to suck eggs here).
This subject is also linked to the way in which you choose to validate messages against your canonical model. Personally I prefer 'selective' validation, mostly because it deals with the 'I don't care about the change made to the shared model so I intend to ignore it', but YMMV. That said, it is important to think about the potential change in semantics and fidelity when you make changes to your common model ... that is, its not just about the syntax (angle brackets and names in XML).
So whilst I understand why you want to try and figure all this out in terms of what Message Broker v8 offers, IMHO that's slightly 'putting the cart before the horse'.
We too are wrestling with how we might leverage the Apps/Libs feature in MBv8. I like mqjeffs advice a while back on another thread which touched on this which basically was along the lines of ' ... you should work with Independant Resources until you know you have a firm (coherent) unit. Then consolidate to an App or Lib'. We have found this to be pretty good advice so far, as our knowledge of v8 matures (you can get along just fine with Message Broker Projects to start with and refactor later if the need arises).
I think its also worth bearing in mind that we are currently only on Fixpack 1 and probably Fixpack 2 is imminent. There have been some rumblings about some changes (relaxation) of some of the constraints in this area which might make a difference to your question. So I for one am keeping my 'powder dry' until at least the time that this comes out.
HTHs
Fraser. |
|
| Back to top |
|
|
| goffinf |
| Posted: Wed Oct 31, 2012 1:33 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| NealM wrote: |
| Usually, changing an underlying canonical message model is a pretty serious business. If you want to allow two or more versions, you do open yourself up for additional support issues down the road vs the upfront work of moving everything to the new version and retesting. I know that my client hates the idea of supporting multiple versions. Even though we set up a URL naming structure that allows for it for web services, we never do so. |
I hear that, ... but perhaps like you, I realize that a versioning model that expects to release every change in 'big bang' fashion is doomed. Thus supporting multiple concurrent versions is somewhat inevitable, you just have to decide how 'long a tail' you are willing to accept. I for one think you have done the right thing by building in that capability from the start. There are of course strategies for minimizing incompatible changes. |
|
| 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
|
|
|
|
