axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaime Meritt <>
Subject RE: [wsif] contribution on SOAP over JMS part
Date Thu, 20 Nov 2003 16:56:30 GMT
The easiest thing to do (from my perspective) is to modify the
SimpleJMSListener/Worker to accept TextMessage as well as BytesMessage
instances.  That would allow it to interact with WSIF clients as well as
Axis ones.

The correlation id issue:

There are many ways of correlating messages including but not limited to the

1) Per-request response destinations (the correlator is the destination you
receive it from)
2) Put the message id into the responses correlation id (very common)
3) Correlation at the app level in the message content (also very common)

Axis clients use option 1 in the near term (this is not appropriate for a
long term solution).  I don't think that adding the correlation code below
(option 2) to the SimpleJMSWorker is appropriate.  

Due to the multi-paradigm nature of correlation I would suggest a strategy
pattern on both the client and server to handle correlation.  Correlation
strategy would be a part of the contract that the web service has with the
client (I could envision WS-Policy assertions in the WSDL or something like
that).  This way we could use a WS-* implementation for correlation, a JMS
id based approach, etc.


-----Original Message-----
From: [] 
Sent: Thursday, November 20, 2003 11:29 AM
Subject: RE: [wsif] contribution on SOAP over JMS part


> Thierry,
> The main motivation to use BytesMessage was due to the potential inclusion
> of attachments in the message with a non-text encoding (DIME for example).

Ok I understand the problem...

> The long term intent is to provide the ability for the vendor adapter to
> determine the message type to deliver specific to the broker

What do you think, is better: define a provider for TextMessage ( which
come from a WSIF call ) or patch WSIF to send BytesMessage?
In the first case, how can I code a vendor adapter?

> For example in SonicMQ we have extended message types such as XML and
> Multipart.  Therefore the SonicMQ vendor adapter would use XMLMessage
> instances for no attachments and multipart (potentially not encoded) for
> those that do have it.

Moreover to interact with WSIF, I put this code to have the jms message
id in the param JMS_CORRELATION_ID in order WSIF associates the response
to the call.

org.apache.axis.transport.jms.SimpleJMSWorker ( line 142 to 158 )

  // now we need to send the response
  Destination destination = message.getJMSReplyTo();
  if(destination == null)
  JMSEndpoint replyTo
      = listener.getConnector().createEndpoint(destination);
  HashMap properties=new HashMap();
  ByteArrayOutputStream out = new ByteArrayOutputStream();
catch(Exception e)

Perhaps, it could be great to add it in SimpleJMSWorker code?

> Thanks,
> Jaime Meritt
> Sonic Software

Thanks for your answer

Les informations contenues dans ce message sont confidentielles et peuvent
constituer des informations privilegiees. Si vous n etes pas le destinataire
de ce message, il vous est interdit de le copier, de le faire suivre, de le
divulguer ou d en utiliser tout ou partie. Si vous avez recu ce message par
erreur, merci de le supprimer de votre systeme, ainsi que toutes ses copies,
et d en avertir immediatement l expediteur par message de retour.
Il est impossible de garantir que les communications par messagerie
electronique arrivent en temps utile, sont securisees ou denuees de toute
erreur ou virus. En consequence, l expediteur n accepte aucune
responsabilite du fait des erreurs ou omissions qui pourraient en resulter.
--- ----------------------------------------------------- ---
The information contained in this e-mail is confidential. It may also be
legally privileged. If you are not the addressee you may not copy, forward,
disclose or use any part of it. If you have received this message in error,
please delete it and all copies from your system and notify the sender
immediately by return e-mail.
E-mail communications cannot be guaranteed to be timely secure, error or
virus-free. The sender does not accept liability for any errors or omissions
which arise as a result.

View raw message