← Prev in month
← Prev in thread
Next in thread →
Next in month →
Proposed resolution to issue BINDINGS-44
This proposed resolution applies to JMS binding spec cd01 Notes on this proposal: I don't propose any new wireFormat or operationSelector elements other than the jms.default ones. That would need to be done via a separate issue with justification required. Any additional standardised wireFormat elements would increase the portability of JMS bindings, so long as they are actually usable in a reasonable number of real-world scenarios. Two very common cases are likely to be JMS text message to a single string parameter, and JMS bytes message to a single byte[] parameter. Do we think we should push to include these (wireFormat.text, wireFormat.bytes, or possibly just wireFormat.singleValue) in the standard? We could replace the single default jms wire format by two or three that describe the different cases, which would then be more specific about what is supported... wireformat.xml, wireformat.jmsmessage We could define explicitly in the wireFormat.jmsdefault an attribute that defines the jms message type to be used when creating messages to send, bytes or text. e.g. <wireFormat.jmsdefault createdType="text or bytes or dontCare"?> - not currently in the proposed resolution. Alternatively we could add a new attribute to the JMS binding itself that defines the JMS message type of created messages, which separates it from the wireFormat consideration. --------------------------------------------------------------- Move Section 2 down to section 5 and reword as shown below. Section 4: Add the <wireFormat> and <operationSelector> elements to the pseudo-schema within the <binding.jms> element. Add a <wireFormat> element within the <response> element Add descriptions of these elements to the list below the pseudo-schema: /binding.jms/wireFormat – identifies the wire format used by requests and responses sent or received by this binding. /binding.jms/response/wireFormat – identifies the wire format used by responses sent or received by this binding. This value overrides the wireFormat specifed at the binding level. /binding.jms/operationSelector – identifies the operation selector used when receiving requests for a service. If specified for a reference this provides the default operation selector for callbacks if not specified via a callback service element.Rename the nativeOperation attribute to selectedOperation: /binding.jms/operationProperties/@selectedOperation – The value generated by the operationSelector that corresponds to the operation in the service or reference interface identified by the operationProperties/@name attribute. If this attribute is omitted then the value defaults to the value of the operationProperties/@name attribute. The value of this attribute MUST be unique across the containing binding.jms element.Update description of the property element: /binding.jms/operationProperties/property – specifies properties specific to this operation. These properties are intended to be used to parameterize the wireFormat identified for the binding for a particular operation. The SCA runtime SHOULD make the operationProperties element corresponding to the selectedOperation available to the wireFormat implementation.Section 5: rename to "Operation Selectors and Wire Formats" Insert before section 5.1 (text based on what was in Section 2): In general messaging providers deal with message formats and destinations. There is not usually a built-in concept of “operation” that corresponds to that defined in a WSDL portType [WSDL]. Messages have a format which corresponds in some way to the schema of an input or output message of an operation in the interface of a service or reference, however additional information is required in order for an SCA runtime to know how to identify the operation and understand the format of messages. The process of identifying the operation to be invoked is operation selection; the information that describes the contents of messages is a wire format. The binding element as described in the SCA Assembly specification [ref needed] provides the means to identify specific operation selection via the operationSelector element and the format of messages received and to be sent using the wireFormat element. The JMS binding defines a default operation selector and wire format and the corresponding operationSelector and wireFormat elements ; SCA providers may provide additional such elements. No standard means is provided for linking the wireFormat or operationSelector elements with the runtime components that implement their behaviour. Section 5.1 "Default Operation Selector", add the following paragraph: "The use of this operation selector can be explicitly specified in a binding.jms using the <operationSelector.jmsdefault> element; if no operationSelector element is specified then SCA runtimes MUST use this as the default." Update the last paragraph: "An SCA runtime SHOULD provide the means for identifying alternative operation selectors via additional <operationSelector> elements." Replace "native operation name" with "selected operation value" throughout this section. Section 5.2 "Default Data Binding", rename to "Default Wire Format" and reword to that effect throughout; add the following paragraph: The use of this wire format can be explicitly specified in a binding.jms using the <wireFormat.jmsdefault> element; if no wireFormat element is specified then SCA runtimes MUST use this as the default. Update the last paragraph: "An SCA runtime SHOULD provide the means for identifying alternative wire formats to support any other type of JMS message via additional <wireFormat> elements." --------------------------------------------------------------- Simon Holdsworth STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898 Internet - Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
← Prev in month
← Prev in thread
Next in thread →
Next in month →