OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: NEW ISSUE: JMS binding URI should follow JMS IRI scheme submitted to IETF



Target:

SCA JMS Binding Specification, section 1.4 (JMS Binding Schema)

Description:

The current schema defines a URI syntax for a JMS URI.  Where possible we should not be inventing new URI syntaxes.  There is an existing submission to IETF for a JMS IRI, and we should follow that approach.


Proposal:

Modify the URI syntax definition to refer to the IETF submission

Regards, Simon

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 - Simon_Holdsworth@uk.ibm.com



"Peshev, Peter" <peter.peshev@sap.com>

29/11/2007 19:52

To
"Eric Johnson" <eric@tibco.com>
cc
<sca-bindings@lists.oasis-open.org>
Subject
RE: [sca-bindings] ISSUE 12: Usage of JMS selectors





Hi Eric,

As seen from your comments, the existing URI format that this TC is
having  already differs from the link you have provided (and since your
name is there as a con7ributor I guess we can trust you :)


The latest draft version (without my proposal) says

o                 jms:<jms-dest>?
connectionFactoryName=<Connection-Factory-Name> &
destinationType={queue|topic}
deliveryMode=<Delivery-Mode> &
timeToLive=<Time-To-Live> &
priority=<Priority> &
 <User-Property>=<User-Property-Value> & ...
 

Your points (no custom properties, URI should no longer includes
destinationType, etc.) are against the current spec, so I think that
should be addressed as totally new issue(s).


Btw, IF the work under this OASIS TC is supposed to be synchronized to
"URI proposal that the SOAP/JMS group has submitted to the IETF " (which
at least to me is a totally new requirement and assumption) than it
might be a good idea to remove the URI definitions here and instead link
to that proposal directly.

Best Regards
Peter

-----Original Message-----
From: Eric Johnson [mailto:eric@tibco.com]
Sent: Thursday, 29. November 2007 21:03
To: Peshev, Peter
Cc: sca-bindings@lists.oasis-open.org
Subject: Re: [sca-bindings] ISSUE 12: Usage of JMS selectors

I almost certainly need to study this proposal more carefully.

One point did jump out at me from the first glance over it,

Peshev, Peter wrote:
> Updating the proposal as per the Action item : [Peter Peshev] Provide
> detailed write up for Issue 12 now that it has been accepted.
>
> PROPOSAL
[snip]


> *                 /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 URI proposal that the SOAP/JMS group has submitted to the IETF does
not follow this format.
The current version of the proposed spec is here:
http://www.ietf.org/internet-drafts/draft-merrick-jms-iri-00.txt

The URI would instead look something like:
jms:jndi:DestinationName?jndiConnectionFactoryName=____&priority=___...

Several points here:
* Note the arrival of the "variant", in this case "jndi:" added after
the "jms:"
* connectionFactoryName --> jndiConnectionFactoryName
* The proposed URI no longer includes destinationType.
* "selector" would be an extension to the IETF proposal
* I don't think we should mention "user properties" unless we have a
specific plan for them in this specification. The SOAP/JMS specification
notes them because it passes the URI as one of the message properties
for the message carrying a SOAP payload. The destination can then treat
those additional parameters much the same way that an HTTP web service
might interpret additional parameters to an HTTP URL.

-Eric.


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


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








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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]