Re: [ebxmlms-develop] Serverside JMS 'listener'

[Ronald v. K. <rv...@ab...>]

You are extremely right. There is a byte[] option as well, i'll try 
implementing both, thanks for the code.

The thing is that I currently have a thread running (just like the 
mailmonitor) that reads command objects from a queue, command objects 
like the ones that are generated by the Request class. Since they 
already contain a ebxmlmessage in the command object (generated by the 
client), it is the easiest way to process a call like this (just forward 
the object to 'processCommand()'. But it is not to difficult to do some 
checking if the JMSMessage is of type byte[], use your code and then 
deliver it to some method to process it.

The mayor thing was refactoring processCommand (still needs some work) 
so it does not need a response object all the way down (4 levels deep). 
The web-interface for monitoring/configuring hermes is going fast now. 
Have a look at http://ronald.vankuijk.net:8080/ebxmlweb/

Ronald

Mayne, Peter wrote:

> My current (nearly) production setup serialises an object called 
> IncomingMessage into a JMS ObjectMessage. (I use the IncomingMessage 
> object because there are one or two other pieces of data I wanted to 
> carry around, which with hindsight I could probably do without.)
>
> Essentially, this object is just a wrapper around a byte[] which 
> contains the serialised EbxmlMessage, so the JMS recipient 
> (theoretically) gets the same bytes that came in on the wire to 
> Hermes. The bytes are produced by EbxmlMessage.writeTo(), and fairly 
> easily turned back into a SOAPMessage (see below).
>
> If I was starting again, I would just use a bare byte[] rather than 
> wrapping a Java object around a byte[].
>
> Using a Java object is no good for non-Java JMS recipients, as you say.
>
> Text format is no good: binary attachments will get messed up.
>
> I'd say stick with a bare byte[], since that is what the message comes 
> in as, and it's very little more work than using a Java object.
>
> A method for turning a byte[] back into a SOAPMessage (where 
> messageBytes is the byte[] containing the serialised EbxmlMessage):
>
>     public SOAPMessage getMessage() throws IOException, SOAPException
>     {
>         MimeHeaders headers = new MimeHeaders();
>         ByteArrayInputStream messageStream = new 
> ByteArrayInputStream(messageBytes);
>        
>         // Does this SOAPMessage have a MIME boundary?
>         //
>         String s = null;
>         InputStreamReader inputStreamReader = new 
> InputStreamReader(messageStream, "UTF-8");
>         BufferedReader reader = new BufferedReader(inputStreamReader);
>         s = reader.readLine();
>         while(s!=null && !(s.startsWith("--")))
>         {
>             s = reader.readLine();
>         }
>
>         // If there isn't a MIME boundary, then this is a straight XML 
> SOAPMessage.
>         // Otherwise, this is a MIME multipart message (with 
> attachments).
>         //
>         String contentType;
>         if(s==null)
>         {
>             contentType = "text/xml";
>         }
>         else
>         {
>             contentType = "multipart/related; type=\"text/xml\"; 
> boundary=" + "\"" + s.substring("--".length()) + "\";charset=\"utf-8\"";
>
>         }
>         headers.setHeader("Content-Type", contentType);
>
>         messageStream.reset();       
>         MessageFactory messageFactory = MessageFactory.newInstance();
>         SOAPMessage message = messageFactory.createMessage(headers, 
> messageStream);
>        
>         return message;
>     }
>
> PJDM
> -- 
> Peter Mayne
> Technology Consultant
> Spherion Technology Solutions
> Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
> T: 61 2 62689727  F: 61 2 62689777
>
> > -----Original Message-----
> > From: Ronald van Kuijk [mailto:rv...@ab...]
> > Sent: Tuesday, 20 January 2004 10:38 AM
> > To: ebx...@li...
> > Subject: Re: [ebxmlms-develop] Serverside JMS 'listener'
> >
> >
> > One additional question about the JMSListener is the type of
> > the message
> > it receives. There are two options.
> > - An object (native java), easier to implement and probably a
> > lot faster
> > than the next option
> > - Text format, provides the possibility to have other clients
> > (c, c++)
> > to connect to a JMS server
> >
> > My first implementation will be using serialized objects (in a
> > 'command'), generated by the client (Request class).
> >
> > Any objections?
> >
> > Ronald
>
>The information contained in this email and any attachments to it:
>
>(a) may be confidential and if you are not the intended recipient, any interference with, 
>use, disclosure or copying of this material is unauthorised and prohibited; and
>
>(b) may contain personal information of the recipient and/or the sender as defined 
>under the Privacy Act 1988 (Cth). Consent is hereby given by the recipient(s) to 
>collect, hold and use such information and any personal information contained in a 
>response to this email, for any reasonable purpose in the ordinary course of 
>Spherion's 
>business, including forwarding this email internally or disclosing it to a third party. All 
>personal information collected by Spherion will be handled in accordance with 
>Spherion's Privacy Policy. If you have received this email in error, please notify the 
>sender and delete it.
>
>(c) you agree not to employ or arrange employment for any candidate(s) supplied in 
>this email and any attachments without first entering into a contractual agreement with 
>Spherion. You further agree not to divulge any information contained in this document 
>to any person(s) or entities without the express permission of Spherion.
>
>
>  
>