| Author |
Message
|
| mca |
 Posted: Wed Jul 13, 2005 8:10 am Post subject: [solved] UPES FrameWork |
 |
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
Hi All,
In our earlier project involving WF we had an UPES step. This is monitored by a trigger monitor by the initiation Queue. When triggered it picks message form a User-defined Queue in FMCQM, parses it, does the work with the values and puts a response message back to the WF default Queue which is EXEXMLINPUTQUEUE.
Now in our upcomming project we have 2 more UPES steps. In my opinion
The trigger monitor remains the same which is already running on that box.
The Queue Manager remains same(FMCQM).
The Queue from which UPES picks messages vary. Will define some new Queue with new process definition for the trigger monitor.
The Queue to which i put back response message remains same(EXEXMLINPUTQUEUE).
When i am all set to do this, one of my collegue says, for 1 UPES step there will be 1 JVM running at a particular time. For 5 UPES steps 5 JVMs running (Worst Case) at one time. This is not good for any system performance. So, what he suggested is to have a look at UPES Framework provided by IBM which comes under single tree, like same Queues for taking and putting messages and it is well managed one after another.
When i made a search on IBM i did find an UPES frame work(fmcoupes_2.0.2.zip), but didnot understand what exactly it is.
Now my question is,
1. Is our assumption, 5 JVMs running for 5 UPES steps at one time (Worst case) correct?
2. If so, Will i have to adopt this frame work or is it OK if i go ahead with my earlier opinion which i explained earlier.
I know its been a lenthy Post but i badly need some advice in this issue. So, trying to explain what i am doing to have a better idea.
Thanks.
Last edited by mca on Sat Jul 16, 2005 9:15 am; edited 1 time in total |
|
| Back to top |
|
 |
| Ratan |
| Posted: Wed Jul 13, 2005 8:36 am Post subject: |
|
|
Grand Master
Joined: 18 Jul 2002
Posts: 1245
|
Your approach is Ok if you do not have a lot of concurrent UPES Steps.
Otherwise using a single UPES to spawning thread for each activity request is a better approach. All your UPES activities should point to the same UPES. Your UPES program should differentitate the activity based on the ActivityName and invoke the appropriate programs which implement it.
_________________
-Ratan |
|
| Back to top |
|
|
| mca |
| Posted: Wed Jul 13, 2005 8:46 am Post subject: |
|
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
Thans Ratan for the prompt reply.
| Quote: |
if you do not have a "lot" of concurrent UPES Steps
|
Can you please appro. suggest a number for "lot" on AIX 5.2 box.
Also is my assumption of 5 JVMs running for 5 seperate UPES Steps correct which are running under one trigger monitor.
Thanks again. |
|
| Back to top |
|
|
| vennela |
| Posted: Wed Jul 13, 2005 9:05 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
If you have 5 queues for 5 UPES activities, then you will have 5 jvms which is true.
But, what Ratan is suggesting you is: You define one queue for all the 5 UPES activites and that one queue will get all the UPES activity XML messages. Now the program that is triggered, should be able to handle 5 different types of activity messages.
Other than running the samles using framework, I have not done much. But UPES framework does exactly what is described above You will have to use the UPES framework API to do what you have to. |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Jul 13, 2005 11:38 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
My two cents on this:
I prefer to have each UPES Activity have its own queue.
I have only played with the IBM Upes Framework, these days I use the EmeriCon developed framework which handles all of the "background" chores (i.e deals with MQ, the parsing, transactional processing etc). And allows me to quickly write any UPES by coding a single class.
Of course, I am somewhat biased, but I think the EmeriCon framework makes UPES implementation quite easy, and I am sure I could convince someone to contact you with information on the framework should you desire 
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| hos |
| Posted: Wed Jul 13, 2005 10:58 pm Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
OK, another two (€-) cent from me:
in my opinion what Venella said is correct. That does not mean that you have to use the IBM UPES framework - although it comes for free 
What I often see is that users start/test with few load on the system and once the program is in production the load increases over time and the program is not designed for it and has to be redesigned.
I would avoid to run multiple JVMs and spent the additional design effort at the beginning of the project. That means design a multithreaded UPES that is capable to handle multiple parallel requests for multiple activity instances. The UPES framework just helps you by providing the basic classes to communicate with MQ and MQWF, that's all it does.
Having such a general purpose UPES available you can still decide to use different queues / UPES instances for different activities. |
|
| Back to top |
|
|
| mca |
| Posted: Thu Jul 14, 2005 7:20 am Post subject: |
|
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
Thanks all for these wonderful replies.
Now its clear for me. But i still have 1 question. As told, i am putting all messages of 3 UPES steps belonging to 1 project on 1 queue and differentiating them by their activity names. I am doing this differentiation in MQGet after picking message from Queue.
If i have 5 UPES steps in next project pointing out to the same queue discussed earlier, then i guess i will have to change my MQGet program to take 5 more different path from there basing on activity names and business logic. That means i am changing the code of a program that is triggered when message comes on this Queue and this code(MQGet) is already in production for the before project. Is this a good approach to do it in this way? |
|
| Back to top |
|
|
| Ratan |
| Posted: Thu Jul 14, 2005 2:42 pm Post subject: |
|
|
Grand Master
Joined: 18 Jul 2002
Posts: 1245
|
| Quote: |
| If i have 5 UPES steps in next project pointing out to the same queue discussed earlier, then i guess i will have to change my MQGet program to take 5 more different path from there basing on activity names and business logic. That means i am changing the code of a program that is triggered when message comes on this Queue and this code(MQGet) is already in production for the before project. Is this a good approach to do it in this way? |
Looks like you are hard coding your Activity Names and Class that needs to be invoked. Any type of hard coding is bad.
Use a config file to list your activity names and the Java Class that implements it. Your MQGET Program needs to get the info from the config file. This way if you have a new UPES, all you do is add the entry in the config file (Ofcourse you have to implement its business logic).
_________________
-Ratan |
|
| Back to top |
|
|
| mca |
| Posted: Sat Jul 16, 2005 9:15 am Post subject: |
|
|
Disciple
Joined: 09 Mar 2005
Posts: 196
|
| thanks ratan, this information helps. |
|
| Back to top |
|
|
|
|
