ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Help in Design

Post new topic  Reply to topic Goto page Previous  1, 2
 Help in Design « View previous topic :: View next topic » 
Author Message
mqjeff
PostPosted: Wed Mar 23, 2011 7:06 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

lancelotlinc wrote:
Each instance of Singleton (one per execution group) communicates with the others.


So now in addition to having to know how to build a Singleton (not that much advanced java), you have to build logic to handle sophisticated interprocess communication?
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Wed Mar 23, 2011 7:45 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

mqjeff wrote:
lancelotlinc wrote:
Each instance of Singleton (one per execution group) communicates with the others.


So now in addition to having to know how to build a Singleton (not that much advanced java), you have to build logic to handle sophisticated interprocess communication?


JMX does this for you semi-automagically. If someone doesn't like JMX, they could use shared memory, rpc, queues, or database to do same.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Wed Mar 23, 2011 7:56 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Aggregation nodes ensure that only the relevant responses get read by the right EG, no IPC required.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Wed Mar 23, 2011 8:08 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

mqjeff wrote:
Aggregation nodes ensure that only the relevant responses get read by the right EG, no IPC required.


Aggregation offers a low-intelligence solution, no doubt.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
rekarm01
PostPosted: Sun Mar 27, 2011 5:44 pm    Post subject: WMB is not Java Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 1415

lancelotlinc wrote:
A common way to implement this mediation intelligence is through a Singleton, ...

Singletons, like global variables, are all too common, and for much the same reason. But they are not the solution to every problem.

The WMB aggregation pattern that mqjeff describes is more than sufficient to meet the OP's stated requirements. Trying to use Java instead (with or without singletons) only complicates the message flow, for no good reason.

mqjeff wrote:
You really shouldn't use threads in a JavaCompute node unless you have extensive experience already with creating and running threads in Java.

Not to mention that the broker imposes additional constraints for Java threads; don't use them without first understanding how they need to interact with the broker.

lancelotlinc wrote:
IMHO, the solution to this is more experience. Shying away from a challenge because you have not conquered it before is not a path to learning.

Procedural programmers use singletons to shy away from object-oriented programming. Java programmers use Java to shy away from native WMB. The challenge to be conquered here is to learn how not to use them inside the broker.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sun Mar 27, 2011 8:40 pm    Post subject: Re: WMB is not Java Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

rekarm01 wrote:

lancelotlinc wrote:
IMHO, the solution to this is more experience. Shying away from a challenge because you have not conquered it before is not a path to learning.

Procedural programmers use singletons to shy away from object-oriented programming. Java programmers use Java to shy away from native WMB. The challenge to be conquered here is to learn how not to use them inside the broker.


I'd even go a step further and say that the challenge is to evaluate all possibilities and choose the most simple and effective to achieve the solution in an easy and maintainable way. If your shop is java and you have little to no experience in ESQL then by all means your solution should be java. However this does not detract from using the aggregation pattern (even in java) where it makes sense.

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
lancelotlinc
PostPosted: Mon Mar 28, 2011 3:53 am    Post subject: Re: WMB is not Java Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

rekarm01 wrote:
lancelotlinc wrote:
A common way to implement this mediation intelligence is through a Singleton, ...

Singletons, like global variables, are all too common, and for much the same reason. But they are not the solution to every problem.

The WMB aggregation pattern that mqjeff describes is more than sufficient to meet the OP's stated requirements. Trying to use Java instead (with or without singletons) only complicates the message flow, for no good reason.

mqjeff wrote:
You really shouldn't use threads in a JavaCompute node unless you have extensive experience already with creating and running threads in Java.

Not to mention that the broker imposes additional constraints for Java threads; don't use them without first understanding how they need to interact with the broker.

lancelotlinc wrote:
IMHO, the solution to this is more experience. Shying away from a challenge because you have not conquered it before is not a path to learning.

Procedural programmers use singletons to shy away from object-oriented programming. Java programmers use Java to shy away from native WMB. The challenge to be conquered here is to learn how not to use them inside the broker.


Good morning rek.

Thank you for your comments. I highly respect your opinion. I appreciate the pace at which WMB product is advancing. The need to code outside the WMB toolset gets smaller with each major release. For instance, adding solidDB support is a major advancement which can be used as a cache mechanism and status repository for in-flight requests.

While the progress is good, we need more major features. For example, we need better organization of the build process out-of-the-box. Alot of churn occurs because there is not a clear path to simple build automation. Therefore, a wizard to create Ant scripts would be nice (feature request submitted last year for same). Also, some out-of-the-box Hudson/CruiseControl/BuildForge scripting helpers would also advance the cause.

The Aggregation Pattern is a low-intelligence offering. It does not meet the needs of many business use cases. For example, when a orchestration or mediation context is needed to do comparisons of downstream results and figure out what to do next. If it is possible to do in a flow, the flow quickly becomes very wieldy and convoluted. For simple tasks, yes, I would select Aggregation Pattern. For tasks where WPS is overkill but Aggregation is not enough, a Singleton works well.

I respectfully disagree with your assessment that Singletons are not effective tool. I do not consider Singletons an Antipattern. Singletons are very useful, and highly effective.

Lance
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
lancelotlinc
PostPosted: Mon Mar 28, 2011 4:11 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

mqjeff wrote:
You really shouldn't use threads in a JavaCompute node unless you have extensive experience already with creating and running threads in Java.

And you really should use Broker standard methods - multiple flows and multiple instances - wherever possible.

This will ensure that the solution is maintainable and supportable.


I often use background processing to move database accesses outside of the transaction window (decreases latency). I also use memory cache mechanisms to pre-load normally static data into memory rather than hit the database or downstream provider every message (decreases latency). This is also done in the background. Another example is pre-loading, re-loading classes from Jars in the background using a thread (allows you to change behaviour of programs on-the-fly without a Broker or EG or Message Flow restart).

In my experience, I have not encountered any difficulty using threads. I have read the Broker documentation. I have attended all Broker training offerings in-person from IBM led by IBM instructors. I am not aware of any limitations imposed by Broker other than what the Broker configures the JVM for.

Please explain your assertion that Broker handles threads differently than any other OS process.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Mon Mar 28, 2011 4:35 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

lancelotlinc wrote:
Please explain your assertion that Broker handles threads differently than any other OS process.


What kind of threads are we talking about? Java Threads? C++ threads?

Broker uses both.

I also did not make the assertion you are asking me to explain. I said "Don't use threads in Broker from Java unless you know how to use threads from Java".

Please also do *try* to remember that you have significantly more experience in general, and in a very specific and tightly controlled area, than most of the posters and while it is a nice idea to offer advanced, sophisticated solutions, it is generally incorrect to do so without a full understanding of the situation of the individual poster.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Mon Mar 28, 2011 4:42 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

@mqjeff: I agree with you sir.

Rek made a clarification on your original post: "Not to mention that the broker imposes additional constraints for Java threads; don't use them without first understanding how they need to interact with the broker. "

It seems that there is an assertion that Broker uses Java threads in a unique way, or prevents normal usage of same.

I am asking for clarification on this assertion as I am not aware of any limitation other than the ones that apply to all JVM processes.


Also, I will support your request to make clear when I suggest advanced techniques that people should have a clear understanding of Broker and the technique before attempting.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
joebuckeye
PostPosted: Mon Mar 28, 2011 7:11 am    Post subject: Reply with quote

Partisan

Joined: 24 Aug 2007
Posts: 364
Location: Columbus, OH

Quote:
I respectfully disagree with your assessment that Singletons are not effective tool. I do not consider Singletons an Antipattern. Singletons are very useful, and highly effective.


Singletons are very overused in Java coding and I believe they are considered a refactoring "smell".

Singletons have a habit of becoming a "God object" and need to be carefully considered before being used.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Mon Mar 28, 2011 7:44 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

joebuckeye wrote:
Quote:
I respectfully disagree with your assessment that Singletons are not effective tool. I do not consider Singletons an Antipattern. Singletons are very useful, and highly effective.


Singletons are very overused in Java coding and I believe they are considered a refactoring "smell".

Singletons have a habit of becoming a "God object" and need to be carefully considered before being used.


I think American-made cars are an antipattern. I buy Hondas. If only the Honda del Sol was still in production! Does not mean I would reject a Ford Mustang if that were offered to me at the rental car counter.

American-made cars are over-priced to support the union's unreasonable demands for retirees.

Singletons, which may be incorrectly used, still have a valid place in design. Just because some people do not use it correctly, does not mean it should be banned forever. If you pointed me to a better solution, I would consider it.

Need a design that will load a constructor once, on the first message through, and can manage Java classes in cache. What would you suggest if not a Singleton?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
rekarm01
PostPosted: Tue Mar 29, 2011 5:25 am    Post subject: Re: WMB is not Java Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 1415

lancelotlinc wrote:
The Aggregation Pattern is a low-intelligence offering.

It's not either/or. There are two separate parts: the aggregation, which covers the fanning-out of multiple requests and the fanning-in of multiple replies; and the mediation, which covers the handling of multiple replies.

The Aggregation pattern is a necessary part of either a "low-intelligence offering" or a more complex orchestration.

lancelotlinc wrote:
It does not meet the needs of many business use cases. For example, when a orchestration or mediation context is needed ...

There was only one business use case under consideration. The OP did not ask for a complex orchestration or mediation context; it was at best misleading to advise that a simple aggregation requires a custom, high-maintenance Java solution.

lancelotlinc wrote:
I respectfully disagree with your assessment that Singletons are not effective tool. I do not consider Singletons an Antipattern. Singletons are very useful, and highly effective.

Singletons are not necessarily an anti-pattern. Singletons can be very useful and highly effective, when used wisely. But the overuse of Singletons can be an anti-pattern, or can introduce other anti-patterns. Of the several dozen different classical design patterns available, the Singleton seems to be the only one that everybody can remember.

If it's necessary to use oxymoronic phrases like "Each instance of a singleton", or to add complex IPC to make it work, maybe singletons aren't the best tool for that particular job, or at the very least maybe the broker is not the best place to put one.

Consider the (many) recent recommendations to use singletons as a substitute for shared variables, custom cache node, Environment tree, Aggregation nodes, EmailInput node, broker properties, (log4j) log manager, and a file reader. The broker already natively implements half of those cases, and simple static initializers and class members can implement most of the rest.

lancelotlinc wrote:
Please explain your assertion that Broker handles threads differently than any other OS process.

That's not quite what the assertion was. The JavaCompute node (or external procedure) is not a stand-alone component; it runs within a larger broker context, and the java should probably not stomp all over whatever the broker is trying to do. Search the documentation for "Restrictions on Java routines" and "Threading considerations for user-defined extensions".

lancelotlinc wrote:
Need a design that will load a constructor once, on the first message through, and can manage Java classes in cache. What would you suggest if not a Singleton?

First, is it really necessary to instantiate a singleton object? In many cases, static class members (with or without static initializers) is sufficient. For example, it only takes one static HashMap to implement a caching file reader with a JavaCompute node:
Code:
public final class CachedFileReader extends MbJavaComputeNode
{
    /**  The class-wide cache for storing the contents of external files.  */
    private static final HashMap fileCache = new HashMap();
    // voilà ...

Second, is it really necessary to implement a singleton inside the broker? If, for example, an aggregation requires more mediation than the broker can natively provide, might it not be better to implement (and to maintain) the mediation externally?

lancelotlinc wrote:
American-made cars are over-priced to support the union's unreasonable demands for retirees.

Whether that allegation is true or false, future versions of WMB are unlikely to address it.
Back to top
View user's profile Send private message
RebeccaBarnes
PostPosted: Mon Jun 13, 2022 6:41 am    Post subject: Reply with quote

Newbie

Joined: 13 Jun 2022
Posts: 2

mqjeff wrote:
Please make sure I understand the question. I think there are many comments here that are not addressing the question that is being asked.

Is this the requirements?
You want to send the same request to 4 vendors.
You want to do this in parallel.
You want to save the state of the requests - vendor A was successful, vendor B was successful, vendor C timed out, vendor D timed out - for the next set of requests.
For the next set of requests, you want to send only to those vendors that were successful (A and B in the sample).
If a vendor times out, you do not need to do anything.

If these are the requirements then you need to understand that nothing that happens inside a single flow instance in Broker runs in parallel. The usual mechanism for making parallel requests is to use multiple flows. So what you would do is create a new flow that had MQinput-><nodes to make the request to a single vendor>->MQReply. Then this would be the thing that you aggregate - the response messages from all of these 4 flows.

This configuration would also let you understand what all 4 responses were in the context of the original message - particularly if you took some steps to add the original message to the aggregation. Then you could make the necessary compensating transactions if you really had a requirement to do so, without using a singleton or any other custom code - but it does not seem like you have a requirement for compensating transactions?

You could also write your own code in a JavaCompute or PHPCompute to create new threads and run the requests to the vendors in parallel that way - but this is significantly more advanced, and more complicated to maintain over time.
Also, do not forget about the visual component of your projects, as it plays a big role in the perception of this or that information. You can take color schemes for yourself here https://create.vista.com/colors/color-names/whitesmoke/ , with an indication of the hex code, which you then add to your work and clearly know what and how it will look like.

Thank you very much for the information, it is very useful and informative as I am just starting to understand questions on this topic and I am looking for all possible help from different sources, thanks and respect to you.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Help in Design
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.