| Author |
Message
|
| 4integration |
 Posted: Tue May 26, 2009 11:20 pm Post subject: Message conversion |
 |
|
Disciple
Joined: 04 Sep 2006
Posts: 197
Location: Gothenburg, Sweden
|
Hello,
I am thinking of using data conversion feature in WMQ. However I am not sure if it will work....
Data conversion (converting between different code pages/encodings); is that only available when you have two or more queue managers communicating over the sender/receiver channel ?
Will it be possible to utilize WMQ data conversion if you have the following scenario ?
[QM1] <=[ServerConnChannel1]=> [MyJavaApp] <=[ServerConnChannel1]=> [QM1]
To give some more background....The JavaApp is a configurable, meta data driven router and can be executed within a JavaComputeNode in WMB (using MQIn/Output Nodes) OR running as a standalone JavaSE application (using MQJMS or JMS)
_________________
Best regards
4 Integration |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed May 27, 2009 12:01 am Post subject: Re: Message conversion |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| 4integration wrote: |
| Data conversion (converting between different code pages/encodings); is that only available when you have two or more queue managers communicating over the sender/receiver channel ? |
It's more usual to have it performed when the message is retrieved from the queue using a convert option of the get.
Note that if this app is running inside a Java Compute node things change a bit.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 27, 2009 12:04 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
WMB can do the data conversion for you, or the MQinput node can specify the convert option to allow WMQ to do it on the MQGET.
No need for channel conversion if you have WMB. |
|
| Back to top |
|
|
| jsware |
| Posted: Wed May 27, 2009 12:04 am Post subject: Re: Message conversion |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| 4integration wrote: |
Will it be possible to utilize WMQ data conversion if you have the following scenario ?
[QM1] <=[ServerConnChannel1]=> [MyJavaApp] <=[ServerConnChannel1]=> [QM1]
To give some more background....The JavaApp is a configurable, meta data driven router and can be executed within a JavaComputeNode in WMB (using MQIn/Output Nodes) OR running as a standalone JavaSE application (using MQJMS or JMS) |
If I understand you correctly, your Java app could MQGET with convert the message, asking for it in the destination format. Then you MQPUT the same message to the other queue manager.
I wonder other than MQGETting from 1 qm and MQPUTting to the other qm, what is your Java App doing (assuming both qms are MQ and you are not writing a bridge between different messaging providers.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| 4integration |
| Posted: Wed May 27, 2009 1:33 am Post subject: |
|
|
Disciple
Joined: 04 Sep 2006
Posts: 197
Location: Gothenburg, Sweden
|
I will try to give some more information..
The component (here called MDR; Meta Data Router) is a generic Java library that handles dynamic routing based upon a set of rules and endpoints. It supports patterns Pub/Sub, Fire n' Forget (same behaviour as Pub/Sub but only one endpoint) and Request/Reply.
This library is currently deployed into two runtime environments, Standalone JavaSE and in WMB. Each specific runtime env has some infrastructure "glue" around this component (i.e. to utilize nice WMB features in that env). The functionality has to be the same on all runtime env.
MDR internally it should be UTF-16 (UCS-2).
To visualize the scenarios, I have uploaded two images:
MDR Inbound - MDR want to have the message converted into UTF-16 no matter of the original encoding
MDR Outbound - MDR get a 1..N endpoint(s); each having a configured destination encoding which is used dynamically in the PUT. Would then like WMQ to hande the conversion.
Do you have any thoughts/ideas if this is doable ?
NOTE: PROT is an inhouse protocol as well as the gateway between PROT and WMQ.
_________________
Best regards
4 Integration |
|
| Back to top |
|
|
| jsware |
| Posted: Wed May 27, 2009 2:53 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
Looking at the Enterprise Integration Patterns symbols you have been using and what you seem to be suggesting, I would suggest you look at Apache Camel at http://camel.apache.org. This implements most EI patterns from Hophe/Woolf's book and can be deployed in multiple environments.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| 4integration |
| Posted: Wed May 27, 2009 11:43 pm Post subject: |
|
|
Disciple
Joined: 04 Sep 2006
Posts: 197
Location: Gothenburg, Sweden
|
jsware: Yes, you are correct. Camel is an nice option of doing this but will not solve the conversion issue, right?! So I assume it will not be any real value of rewriting the core.
Will take a deeper look into Camel in future enhancement but due too budget restrictions I can not do that at current time (if it will solve the issues; it's another thing  ).
_________________
Best regards
4 Integration |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 28, 2009 7:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
For your outbound 1 to n with conversion...
Have you given any thought about using MQ or WMB pub/sub with a JMS/XMS receiver? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| 4integration |
| Posted: Thu May 28, 2009 11:20 pm Post subject: |
|
|
Disciple
Joined: 04 Sep 2006
Posts: 197
Location: Gothenburg, Sweden
|
| fjb_saper wrote: |
For your outbound 1 to n with conversion...
Have you given any thought about using MQ or WMB pub/sub with a JMS/XMS receiver? |
For this component, no. Of course the thought have been there since we are frequent user of WMB Pub/Sub.
In this component we support pub/sub-style pattern but since it extends the subscriber side to make use of some in-house developed protocols (with some special handling) WMB Pub/Sub does not give the value that we need.
I would say that our solution is quite elegant....the subscribers/applications have a queue for inbound messages and doesn't have to care about topics etc. The publisher application just put a message on the MDR in-queue with some company standard metadata properties such as MsgType, MsgTypeVersion,... (with support for application specific metadata as well).
MDR-Governance can then decide what messages (based upon metadata) goes where.
_________________
Best regards
4 Integration |
|
| Back to top |
|
|
|
|
