ws-wsif-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Whitlock" <>
Subject Re:Re: JMS issues
Date Thu, 13 Feb 2003 11:29:04 GMT
Hi Nirmal, Thank you for your response. My comments are below between <mw>
Mark Whitlock, IBM Hursley Web Services

----- Forwarded by Mark Whitlock/UK/IBM on 13/02/03 10:08 -----
                      Mukhi/Watson/IBM@        To:          
                      IBMUS                    cc:                                       
                                               Subject:  Re: JMS issues                  
                      12/02/03 17:49                                                     
                      Please respond to                                                  

<mw>On (1) and (5): I have discovered that to support mime/jms, I need to
send the Content-Type with the JMS message, because the Content-Type
contains (amongst other things) the mime boundary information. So I have
stored  the Content-Type in a WSIFContentType JMS property (dashes are not
allowed in JMS property names). Now I can send and receive attachments
using MIME/Jms. There are other HTTP headers which I think I should map to
JMS properties, in particular Content-Location. Do you think this is the
right approach? I think I could send attachments using the Java provider,
since the DataHandler would not get serialized. I could never send
attachments using the EJB provider, since DataHandlers and not
Serializable. I'm not sure of the best solution for the NativeJms provider,
though.  I could send the attachment as a mime message (without a soap
body), or I could just read it into a byte array and send that. I think I
favour the byte array. What do you think?</mw>

On (2): If a JMS binding in WSDL has <jms:property> tag in the output
section of the binding operation, isn't this enough to tell us that that
particular property is of interest?
<mw> <jms:property> maps properties onto parts, which is useful when using
stubs. But for stubless invocation, users can set JMS properties by setting
them in the message context, and so would expect to be able to get output
properties from the message context as well. But properties passed via the
message context aren't mentioned in the WSDL. So how do I know which output
properties to copy into the message context? I guess either I'll copy them
all, or else I could put the JMS message itself in the message context. I
think I'll copy all the output properties into the message context for

On (7): the jmsVendorURI is currently in the <port> section right? So
choosing between alternative vendor URIs comes down to choosing between
multiple ports, for which we have good support. Or am I misunderstanding?
<mw> I agree. I think I was just asking, if the JMS implementation is
MQSeries (for instance), should jmsVendorURI="IBM MQSeries" or jmsVendorURI
="", so we can give advice to prevent possible clashes, or more
likely, so that multiple jmsVendorURI strings don't all mean MQ. </mw>

On (11): It looks like in the future there may be two alternative styles to
locating a particular stateful web service instance - using correlation
fields as in BPEL4WS, or using a factory mechanism, as in OGSI. Both of
these approaches are binding independent and will be mapped to protocol
specific mechanisms - correlation fields in BPEL are mapped to WSDL
properties which are carried within SOAP messages as message parts. OGSI's
factory mechanism advocates runtime creation and exchange of a service
reference, which is usually a WSDL snippet (for example just the "port"
section, with addressing information for a particular instance. But both of
these approaches propose non standard WSDL extensions. For now I think we
might have to do an ad hoc solution for the JMS case, as has been done for
SOAP (in implementations such as WASP), where a particular header field
identifies the relevant instance.
<mw> I was interested in a simple solution that could be implemented now.
Typically there may be a single request queue, which many clients will send
requests to, and a single listener (MDB) servicing requests for that queue.
If the listener can associate a request with other requests from the same
client, and differentiate them from requests other clients make, then the
listener can hold state information for that client, which amounts to an
instance of a web service. This would behave like a stateful session bean.
This could be achieved by WSIF setting the JMSCorrelationID of the request
message to the message ID of the previous request in this sequence of
requests. I guess it may be simpler to set the JMSCorrelationID to the
message ID of the first request in this sequence. If WSIF stored this
correlation ID in the WSIFPort, all operations using the same port instance
would use the same instance of the web service, and new'ing a WSIFPort
would zero the correlation ID so creating a new instance of the web
service. This has the same behaviour as the Java, EJB, Soap/Http and
Axis/Http providers (since the call object and therefore the cookies are
stored in the WSIFPort). The JMS2HTTPBridge would have to associate cookies
with correlation IDs. I guess a listener could return other clients'
correlation IDs allowing multiple clients to share the same web service

On (17) & (18): IMHO a client should be allowed to call
executeRequestResponseOperation only for a request response operation, and
executeInputOnly operation only for a one way (input only) operation; if
this is not used properly WSIF should throw an exception.
<mw>I believe we agree about (17) and (18a). None of our unit tests test
the (18b) situation so I don't know what WSIF will do currently. I don't
feel strongly about this - I am open to persuasion.</mw>


    "Mark Whitlock"                                                        
    <>                        To:                  
    02/12/2003 12:15 PM                               Subject:        JMS  
    Please respond to wsif-dev                issues                       

Here is the current list of issues that I have with the JMS support in WSIF
(in no particular order) ...

1) Attachments over JMS. Is there anything else necessary in the message or
in the WSDL extension to support MIME or DIME messages over JMS. Soap/Jms
messages are TextMessage's currently in WSIF. Does this imply codepage
translation? If so, would this mess with embedded images?

2) JMS output properties. WSIF should support these properly. Should all
the JMS output properties be copied to the WSIFMessageContext on every call
whether the application is interested in them or not? Can we tell whether
the application is interested in them?

3) Transactions. There are lots of issues here. (a) Which API should WSIF
use to query/control JMS transactions? (b) If there is a current client
transaction, the put message is done transactionally, so it won't complete
until that unit of work completes. That is probably not what's wanted
because it means for synchronous JMS, WSIF can't do a get message in that
unit of work without deadlocking. It would be better to do the put in a
separate transaction (which could be syncpointed immediately by WSIF), and
enable the backend MDB/process to run in the same unit of work as the
client. Then if the client later rolls back, the backend would also be
rolled back. (c) How does this fit in with the WS-Transaction and
WS-Coordination standards? The WS- standards may appear soap/http specific
and we may not want to support them today, but we should be aware of these
standards so our architecture is extendable to support them in the future.

4) Doc-style. Is there anything else necessary to do to support doc-style
messages over JMS? I (vaguely) remember Ant saying that sometimes the
operation name is not in the doc-style message. If that were true, then
maybe the operation name should be passed as a JMS property.

5) Mapping soap and http headers to JMS properties. The current
JMS2HTTPBridge doesn't do this correctly at all. I guess the soap headers
are in the soap envelope, which is put into the JMS message, so all soap
headers are currently passed as default. What http headers are passed and
should this information be passed as equivalent JMS properties? I guess we
need a complete list of soap/http/jms headers/properties and how they map
to one another, and which protocols they are valid for, etc.

6) Other JMS properties. WSIF does not support the full set of JMS
properties, for example acknowlegement. There are also
implementation-specific properties which may concern us.

7) jmsVendorURI. This can be set in the WSDL to specify which JMS
implementation should be used to send the message. The client should be
able to query this and invoke, indirectly through WSIF, the correct
implementation. The mechanism and exactly what values jmsVendorURI can
take, should be described.

8) SOAP/MQ. There are three flavours of this. (a) Specify in the WSDL the
MQ names of the queues and qcf's and then use the JMS API to invoke them.
This would mean writing a WSIFJMSFinderForMq in the current WSIF
implementation. The MQ names of the queues and qcf's could be specified in
the jmsImplementationSpecificURI. (b) Use the JMS API to construct a
message that looks as though it has been created by a non-JMS (MQ) client.
(c) Use the MQ API directly. (b) and (c) would be different implementations
producing the same message. But how could a service administrator specify
in the WSDL the difference between (a) and (b/c), since they would produce
mutally incompatible messages?

9) jmsImplementationSpecificURI. Define what the
jmsImplementationSpecificURI should contain for specific JMS
implementations. I guess this is really part of 8a.

10) Security. (a) How can applications invoke web services securely using
WSIF over soap/jms? (b) How do I authenticate myself to a JMS
implementation (MQ)? (c) How does a JMS implementation authorise me to use
queues/qcfs? (d) Do I need authorisation to get JNDI definitions, or is the
authorisation done only when using the queue, or both? (e) Will JMS
implementations do encryption for me? (f) Are any of these security options
supported by JMS or are they all implementation-specific? (g) I guess
customers would want authorisation based on the web service, not based on
the queue or MDB.  How would this be done? (h) How does this fit in with
the WS-Security standards? Even if we do not want to support WS-Security
using soap/jms today, the architecture should be extendable so we are able
to in the future.

11) Static and instance methods. There are four ways of deploying a web
service. (a) Invoke a new instance of the web service on every invocation.
(b) Invoke the same instance of the web service, but there is a different
instance of the web service for every client. (c) There are many instances
of web services and any client can discover which instances exist, and can
invoke any of them. (d) There is one global web service instance
(singleton) which any client can invoke. So this is implemented in the
existing providers, using static and instance methods in the Java provider,
scope=Request|Session|Application in an axis/http server and using
stateless/stateful session/entity beans in the EJB provider. So how are
these different ways of deploying/invoking a web service possible over

12) Message types. Currently Soap/jms messages are always sent as
TextMessage. Could they be sent as different types (BytesMessage) depending
on the WSDL. Certainly for NativeJms, we should support other message

13) Reserved property names. WSIF uses JMS properties that start with WSIF
for NativeJms. We should document that we reserve all property names that
start with WSIF, and maybe WSDL. Are there any other reserved property

15) Topics. I think we should decide how we could invoke web services using
Topics. There are scenarios that are solved most easily by Topics. For
instance, insurance companies that register with an insurance broker to
supply quotes. Clients could invoke a web service using WSIF which would
publish the request to the broker's topic, to which all the insurance
companies subscribe. Responses would be put to the client's replyTo queue.

15) Queue managers. Are there any issues if the client and server run on
separate queue managers?

16) Web service invoked with the same interface that the WSIF client stub

17) Input-only shouldn't wait for a response. Currently, the WSIF Axis/Jms
provider expects a response from the web service even if it was invoked
using executeInputOnlyOperation and it doesn't have an output message in
the WSDL. This situation should mean "fire-and-forget", whereas an empty
output message invoked using executeRequestResponseOperation should mean
that the client would like to know whether the operation succeeded, even
though there aren't any output parameters.

18) Invoking executeInputOnlyOperation and specifying input-only in the
WSDL. (a) What does it mean if a web service does not have an output
message in the WSDL, but the client invokes it using
executeRequestResponseOperation? I think WSIF should throw an exception,
otherwise this call will hang. (b) What does it mean if a web service does
have an output message in the WSDL, but the client invokes it using
executeInputOnlyOperation? I think this should mean "fire-and-forget". WSIF
should not wait for the response.

19) Other WS- standards. Are there any other WS- standards which may affect

Apologies for the length of this note. Please responsd to wsif-dev if
anyone has any commentts/suggestions,
Mark Whitlock, IBM Hursley Web Services

View raw message