| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Using Java Compute nodes and shared java libs |
« View previous topic :: View next topic » |
| Author |
Message
|
| youssef |
 Posted: Sat Sep 09, 2006 2:43 am Post subject: Using Java Compute nodes and shared java libs |
 |
|
Novice
Joined: 09 Sep 2006
Posts: 12
|
Folks,
I am new to the EAI field yet I used to be java ee developer and designer for 6 years now. I would like to know your onion on the following approach:
1) Depend solely on Java compute node and get rid of the ESQL.
2) Consolidate the integration logic and common functionalities in a common shared jar files to be deployed on the message broker shared lib folder.
_________________
Regards,
Youssef |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Sat Sep 09, 2006 5:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, these are things that can be done.
As in all things, you have to weigh the cost against the value.
For example, if you put all the logic for all your flows into one jar... then you have to stop everything in order to change one thing.
And, for example, if you have ten developers who are well trained on ESQL, and you decide to use Java exclusively, you have to spend time retraining those developers. Likewise if the developers know Java, but not ESQL - but learning ESQL is a *lot* easier than learning Java.
In general, for someone with your background moving into the EAI space, the first thing you should do is forget that you think Java is the solution to all of life's problems. It's very obvious to the rest of us that MQ is that solution ... 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| youssef |
| Posted: Sat Sep 09, 2006 8:26 am Post subject: |
|
|
Novice
Joined: 09 Sep 2006
Posts: 12
|
Thank you for the info.
I agree with you that we have to be aware of the tradeoffs. But these are the things that I had in mind when I proposed that:
1) As per the IBM article there is a performance gain to use java compute nodes over ESQL ones.
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0605_crocker/0605_crocker.html
2) Java is OOP language that will make us gain the benefits of OO (abstraction, dependency injection,).
3) It wasn't clear to us that ESQL can even be procedural language. Can we create packages and common ESQL files to be imported (included) by different message flows!
4) The idea of having common shared jars was to isolate cross cutting concerns (security, auditing, filtering, ... ) from the functional areas of a certain message flows. By this way, changing the shared library to new version will apply the changes to all flows and not the contrary.
5) We are thinking that this common shared libraries can be extended for, example, to provide some useful services like (rule engines, native jdbc data source pools, ....)
I also agree with you that my technical *orientation* makes thinking about Java but i am totally open to switch to other alternatives.
Your valuable thoughts are highly appreciated.
_________________
Regards,
Youssef |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Sep 09, 2006 8:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Again, you have to restart every flow that is using a shared resource in order for it to pick up that change. And, usually, you have to redeploy all those resources as well. This is equally true for message flows, message sets, ESQL resources and Java resources.
You might not have to redeploy stuff for changes to java code in shared classes to be picked up - but now you're inventing a new deployment mechanism and ignoring the existing ones. You could equally well deploy all your WAS code into a standalone jar file that you added to the app server classpath... but you'd be ignoring the benefits of EAR files.
And, in fact, you're reading that article wrong. What it's saying is that the Java nodes perform almost as well as the ESQL nodes, not the other way around.
ESQL is entirely procedural at this point. All ESQL must execute inside a procedure of some kind or another, and must be inside a module as well.
It is entirely possible to build shared libraries of ESQL code, and package them separately. A) put the code into it's own file, B) put that file into it's own project, c) Reference that project in the properties of other projects into the Tooling.
Also look at "broker namespaces". It's java packages for ESQL.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| youssef |
| Posted: Sat Sep 09, 2006 9:53 am Post subject: |
|
|
Novice
Joined: 09 Sep 2006
Posts: 12
|
Again, thank you for your valuable reply. It seems that I started to think outside Java :). I do have some few questions though:
1) If I go for shared libraries in ESQL, well I need to deploy all flows that references it.
2) Are there any ESQL libraries over there that provide tools and utilities?
3) Can "broker namespaces" be used outside a message flow (in the shared project)?
Sorry for reading the article wrong. I didn't know that "Java compares favorably with ESQL" means in English, almost as well as! I will need to add this to my vocabulary anyway.
_________________
Regards,
Youssef |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Sep 09, 2006 11:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, you'll need to redeploy everything that uses a shared ESQL file. ESQL doesn't exist in broker outside the flow itself.
I'm not aware of any ESQL libraries. Most of the code that people write in broker is very very specific to the flow it's in - because broker is focused on routing and transformation of data and so code is always data driven. That said, there are Support Packs.
Again, a broker namespace is just a java package for ESQL. And, again, there's no way to EXECUTE ESQL outside of a message flow... So broker namespaces don't exist outside of a flow, but they do not have to be in a project that has a message flow in it. So, yes, you can use them in your shared project.
"Java compares favorably with ESQL" is actually ambiguous as a statement. But the numbers should have made the author's meaning a bit clearer...
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
