| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Compile and inline resources for ESQL library |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Tue Jul 09, 2013 8:48 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
At first glance, yes. But then comes versionning...
The use of application/libraries/service containers lets you package an application with a known coherent version of all its components and keep that untouched in the runtime. The application is not changed because you deployed a newer version of the library in a different application.
This is not the case when all is deployed to the "default" container.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| goffinf |
| Posted: Wed Jul 10, 2013 1:18 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| sunny_30 wrote: |
I think there are lot of restrictions in terms of code reusability with using named Applications.
|
Applications are not designed for that purpose (Libraries are). An Application is a single and indivisible unit of deployment that represents a coherent set of resources. What you include is your choice, .. whatever makes sense to develop and deploy together.
Also, as others have mentioned, versioning (particularly multiple concurrent deployed versions of the same capability) can be a good reason to use the Application project type.
The 'un-named' application container can get somewhat dis-organised if you deploy everything to it (and the correspondence between the development view and the deployment view is one of the reasons to organise your code as Applications or Libraries). If you were writing in some other programmatic language, would you only have one 'uber' application context ?
| sunny_30 wrote: |
But its not letting me reference an external MessageFlow Project & not permitting to reuse the ESQL, subflows unless the external flow is brought into the existing Application & to be redeployed all of them, again !
|
Yes, that's the isolation quality of the Application container (i.e. all its resources are 'private'), so its 'by design' not a defect. You just have to think about the different container types and what properties they promote. Options were very limited in versions prior to 8, now you have choice. Choice is good, embrace it.
As far as referencing is concerned, AFAIK its this :-
1. No project type (MBP, Lib or another App) can reference an App (all resources are private)
2. An App can reference a Lib but NOT an MBP. When deployed, the Lib becomes a private resource that is not impacted by any other copy of the Lib deployed to any other container (i.e. the un-named App).
3. A Lib can reference another Lib, but NOT an App or an MBP.
4. An MBP can reference another MBP or a Lib, but NOT an App.
5. JARs and similar resource have different visibility constraints (see the InfoCentre)
| sunny_30 wrote: |
Please let me know your thoughts if you still suggest using Applications &Libraries instead of individual MB projects ?
|
I think it would be unwise to ignore such a fundamental architectural property of the v8 development and runtime environment. Learn about their features and how to leverage them and try not to get 'stuck' on how v6.x/7.x works. For example one factor that impacts our choice is how we organise related MB projects that we use for functional unit testing. Another, is how we want to structure our (GiT) repositories and how that fits in with both CI and build processes (all of which you will probably have to re-visit).
HTHs
Fraser. |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Wed Jul 10, 2013 6:40 pm Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Really appreciate your detail response - Many thanks !
I have a question regarding deploying the reusable code (assume contains multiple subflows, esql functions) as a single Library unit and referenced by a MFP or an Application.
Can I be able to use the "redeployable subflow" feature of v8, to deploy just one of the changed subflows (out of the multiple deployed) into the Library ? AFAIK, I can only deploy all but nothing individually into Library- which eventually is something similar to V7 where subflows couldn't be deployed individually.
what I mean is, v8 + library has its own local copy "similar to" v7 where subflows couldn't be deployed individually & each MainFlow had its own subflow instance copy
That's the reason Im inclined to have individual MFP projects instead of Libraries to make use of V8 features, that way I have more control of what I can deploy
Please let me know if Im missing anything- thanks again |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jul 11, 2013 3:36 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| sunny_30 wrote: |
| I have more control of what I can deploy |
The art of good WMB development is letting go of control. Trust your WMB infrastructure. The whole point of WMB development is that 90 percent of the code is pre-written for you. Learn to trust the force, Luke.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jul 11, 2013 3:55 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
| The whole point of WMB development is that 90 percent of the code is pre-written for you. Learn to trust the force, Luke. |
Shhhhhh!!!!!
you are going to do a lot of us out of a job if the PHB's/Beancounters get wind of that 
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 11, 2013 4:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Look, either you've tested the entire application with the changed subflow, or you haven't.
If you haven't tested the entire application with the changed subflow, then why do you care whether you redeploy the whole thing or not? You've said it doesn't matter if this change breaks things or not.
If you have tested the entire application with the changed subflow, *then why do you care* whether you redeploy the whole thing or not?
Yes, it would be great if this were different. Yes, please complain to IBM, please support RFEs, please file PMRs, please harrange your sales reps.
Until it's different, please make the best use of all available functions of the version of the product you're using, and don't ignore major features simply because some aspects of them are inconvenient under certain specific conditions.
Every software has annoyances. Change management is a good thing precisely because it helps you deal with them in sensible fashion. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
