[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-bindings] ISSUE 12: Usage of JMS selectors
Updating the proposal as per the Action item : [Peter Peshev] Provide detailed write up for Issue 12 now that it has been accepted. PROPOSAL New element - subscriptionHeaders is suggested that is parallel to the current element - "headers". The current headers governs options when sending messages (MessageProducers), while the new element will provide the options for consuming messages (MessageConsumer). (Besides selector it can host in the future topic durable subscriber names & durability flag, the noLocal option, session acknowledge mode for non-transacted, and any vendor specific properties.) The current headers element is defined as well in the operationProperties, allowing Message headers to be redefined for a particular operation, while the new element will make sense only for the complete binding The pseudo-schema on line 100 is augmented to : <headers JMSType="string"? JMSCorrelationId="string"? JMSDeliveryMode="string"? JMSTimeToLive="int"? JMSPriority="string"?> <property name="NMTOKEN" type="NMTOKEN">* </headers>? <subscriptionHeaders JMSSelector="string"?> <property name="NMTOKEN" type="NMTOKEN">* </headers>? <operationProperties name="string" nativeOperation="string"?> <property name="NMTOKEN" type="NMTOKEN">* <headers JMSType="string"? JMSCorrelationId="string"? JMSDeliveryMode="string"? JMSTimeToLive="int"? JMSPriority="string"?> <property name="NMTOKEN" type="NMTOKEN">* </headers>? </operationProperties>* The description on line 187 is augmented to : * /binding.jms/headers - this element allows JMS headers to be set to the given values for all operations. These values apply to requests from a reference and responses from a service. * /binding.jms/subscriptionHeaders - this element allows JMS subscription options to be set. These values apply to a service subscribing to the destination or for a reference subscription to the callback\reply-to destinations. * /binding.jms/headers/@JMSType, @JMSCorrelationID, @JMSDeliveryMode, @JMSTimeToLive, @JMSPriority - specifies the value to use for the JMS header property. If these attributes are specified they must not appear in the URI. * /binding.jms/subscriptionHeaders/@JMSSelector - specifies the value to use for the JMS selector. If the attribute is specified it must not appear in the URI. The definition of uri on line 12 is changed to : (the slector is added in the uri as well)" * /binding.jms/@uri - (from binding) URI that identifies the destination, connection factory or activation spec, and other properties to be used to send/receive the JMS message The URI has the following format: o jms:<jms-dest>? connectionFactoryName=<Connection-Factory-Name> & destinationType={queue|topic} deliveryMode=<Delivery-Mode> & timeToLive=<Time-To-Live> & priority=<Priority> & selector=<Selector> & <User-Property>=<User-Property-Value> & ... The following new example is added in the example section : 8.5 External Service Example The following example shows how the JMS binding is used in order to consume messages from existing JMS infrastructure. The JMS binding subscribes using selector : <?xml version="1.0" encoding="ASCII"?> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="MyValueComposite"> <service name="MyValueService"> <binding.jms> <interface.java interface="services.myvalue.MyValueService"/> <destination name="MyValueServiceTopic" create="never"/> <connectionFactory name="StockQuoteServiceTCF create="never" /> <subscriptionHeaders JMSSelector="Price>1000"/> </binding.jms> </service> </composite> The following change in the XSD in Appendix A is made <complexType name="SubscriptionHeaders"> <sequence> <element name="property" type="string" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="JMSSelector" type="string"/> </complexType> The following line is added on line 539 (where the defintion for binding.jms is defined) <element name="subscriptionHeaders " type="sca: SubscriptionHeaders " minOccurs="0"/> -----Original Message----- From: Eric Johnson [mailto:eric@tibco.com] Sent: Thursday, 25. October 2007 20:36 To: Peshev, Peter Cc: sca-bindings@lists.oasis-open.org Subject: Re: [sca-bindings] ISSUE 12: Usage of JMS selectors New issue logged as: http://www.osoa.org/jira/browse/BINDINGS-12 -Eric. Peshev, Peter wrote: > TARGET: JMS Binding > > DESCRIPTION: > JMS message selectors serve as a filter for JMS consumers allowing for > them to specify only messages they are interested in. Since the JMS > binding has a use case of bridging SCA components to existing JMS > infrastructure, some assemblers may be interested in usage of JMS > selectors especially for topics. > > The current spec is not saying whether they should be supported or not. > There is no place in the schema to define them, however the current spec > allows configuration of usage of activation spec javabeans and resource > adapter for the JMS. As per the JCA 1.5 spec (section B.2.1.3) the > methods get/setMessageSelector() are commonly used to supply the JMS > selector. > > It should be clarified whether JMS selectors will be supported by the > JMS binding (in that case they should be added in the schema), if those > are not supported than the spec must say explicitly that providing them > via ActivationSpec should lead an error, or whether selectors should be > ignored. > > > PROPOSAL: > > Include JMS selector support in the JMS binding. More detailed proposal > will follow if there is agreement on such resolution. > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]