Proposal for JMS Binding
I would like to propose a JMS Binding in Tuscany based on the following white paper. http://osoa.org/display/Main/SCA+Bindings+White+Paper It's important to note that the JMS binding specification is still work in progress and is not published.
The intent of this proposal is to create a JMS binding based on the concepts introduced by the white paper and then posibly to influence the specification work group by providing feedback based on our experiance in implementing the binding. The author of this proposal participates in the specification working group and hopes to provide a feedback loop to the spec group based on the Tuscany JMS Binding implementation.
Concepts in a Nutshell
The Messaging binding defines 3 concepts for a generic messaging binding. The JMS binding extends this to provide JMS specific connection to resources and databinding. Simillarly other messaging frameworks could also extend the generic message binding.
- Defines the connection to a JMS resouce via a URI
It also defines the concept of an OperationSelector.
- The operation selector defines the mechanism to determine the "operation name" based on the native message. In this instance it's the JSM message
- This element specifies the default data binding for input and/or out messages of a particular operation
- Defines the manner in which messages are mapped from their native form to that expected by the SCA runtime and target component
I propose to implement the JMS binding modeled on the existing spi. We may run into some problems as the messaging binding may not be as trivial as WS or RMI which are more service oriented. Mapping service artifacts into the messaging world is done using the above concepts. Hopefully we can solve these issues through discussions on the mailling list.
We will have to leverage/extend an existing data binding (ex xmlbeans, ADB ..etc) when we define the JMSDatabinding.
Comments/suggestions/ideas are greatly appreciated.