| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CDATA alternatives - base64Binary / SwA / MIME / MTOM |
« View previous topic :: View next topic » |
| Author |
Message
|
| Mercator |
 Posted: Tue Jul 21, 2009 11:54 am Post subject: CDATA alternatives - base64Binary / SwA / MIME / MTOM |
 |
|
Apprentice
Joined: 21 Jul 2009
Posts: 34
|
I am in the design stages of a large WMB / WTX implementation and wanted to solicit opinions for one specific aspect of the design. The data is HIPAA X12 (EDI). WTX will be used to not only transform the data, but to extract enough information from the X12 in order for broker to route appropriately. Therefore, we will be passing around some metadata (XML) and the message itself (X12). It seems I have quite a few options with how to implement the message, some of which are:
#1: XML message with inline X12 in CDATA.
#2: XML message with inline X12 in tag as base64Binary.
#3: SOAP with Attachments / MIME
#4: SOAP MTOM / XOP
I'm sure there are many others I've missed. Option #1 is out due to the possibility of the HIPAA X12 containing an embedded XML document and potential nested CDATA. Option #4 feels right to me, but the entry / exit points of the flows will be MQ so I don't believe its an option in the current version. There will actually be a few queue hops throughout the life of the message.
90% of the HIPAA X12 data will be < 50k. What is the most efficient way to do this realizing that anything that is encoded, will have to be decoded prior to WTX.
Thanks in advance,
Rob |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue Jul 21, 2009 1:55 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I can't answer the question, but I can provide some information.
I agree that #1 is a non-starter. CDATA is not intended for including non-XML data within XML.
#2 might work nicely. You could exploit the automatic decoding of base64Binary by the XMLNSC parser. That would require you to enable validation and set the parser option 'Build tree using XML schema'
#3 could work, but I suspect that #2 might give more control over the encoding of the X12 data
#4 might work really nicely. It could work out almost exactly like #2, but with a little more XML wrapping, and the base64 encoding/decoding being done automatically.
Obviously, you need to look critically at all of these suggestions, and make your decision based on what you know about the requirements. |
|
| Back to top |
|
|
| Mercator |
| Posted: Tue Jul 21, 2009 2:17 pm Post subject: |
|
|
Apprentice
Joined: 21 Jul 2009
Posts: 34
|
| kimbert wrote: |
#4 might work really nicely. It could work out almost exactly like #2, but with a little more XML wrapping, and the base64 encoding/decoding being done automatically. |
Thanks Tim. I really like the MTOM option for all of the out-of-the-box functionality, not to mention the fact that I am dealing with HIPAA data and if the requirement for securing the payload every comes to pass, it would be much easier to implement.
Are my assumptions correct that even though this could be the best option, its not applicable since everything is MQ based in our architecture? From what I researched, the only way to get MTOM / XOP is via the SOAP nodes.
Thanks,
Rob |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jul 21, 2009 10:34 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Option 2 (XML + Base64) works very well in a Broker project I have worked on.
We use the Base64 bit to carry an encrypted JPG image.
I had to do nothing special to handle it, in fact once we got a solid XSD everything was pretty easy.
I also use this for our standard MQ Output Error Handler. The Base64 bit contains the original message + the exceptionlist compressed with the Zip Node Support Pack.
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
