Hi,
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?
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?
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.
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.
Thanks,
Nirmal.
| "Mark Whitlock" <[EMAIL PROTECTED]>
02/12/2003 12:15 PM
|
To: [EMAIL PROTECTED] cc: Subject: JMS 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
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
