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 Soap/Jms? 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 types. 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 prefixes? 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 implements. 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 soap/jms? Apologies for the length of this note. Please responsd to wsif-dev if anyone has any commentts/suggestions, Thanks, Mark Mark Whitlock, IBM Hursley Web Services
