[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]