Re: [sca-bindings] ISSUE 4: JMS binding can be used as pub/sub workaroundingreference multiplicity

[Eric Johnson <eric@tibco.com>]

Thinking aloud a little bit, hopefully to the benefit of others:

At the edges of a composite, with bindings on promotions, is there
anything that we can do here?  I don't think there is, since a point of
promoting a reference is to interact with systems that you may not
control.  Multiplicity and topics is just a small problem here, re-using
queues would be even more problematic.

Inside of a composite, I don't see the use case.  If anyone in the
process is concerned about what I think of as "topic collision", they
could mandate - for their development team - late binding of JMS.  That
is, you don't specify the JMS binding specifically, but perhaps an
intent to use a JMS binding, and let the deployment/runtime process
figure out the details, and whether queues or topics are used.  Or even
this level of detail might be spurious - just use the SCA binding,
however that happens to occur.

My take, then is that we may be in agreement that this issue is
out-of-scope with respect to our current effort.  So long as closing
this issue doesn't later preclude opening an issue around adding
language identifying what and why, specifically, about this item is out
of scope, I'd be content to close the issue.

For comparison, in the SOAP/JMS effort we added explicit text around the
whys and wherefores behind putting the use of topics out-of-scope.  That
was a separate decision from actually putting them out of scope.

-Eric.

Peshev, Peter wrote:
> Hi Michael,
> 
> I was little bit worried that by having "broadcast" bindings, the whole
> concept of reference multiplicity becomes very vague and such binding
> usage may interfere with any pub/sub concepts that the assembly TC may
> come up with (in-scope of their project charter)
> 
> So I was hoping to ban "pub/sub" usage of bindings, but I am also ok
> with not opening of that specific issue.
> 
> Peter
> 
> 
> 
> -----Original Message-----
> From: Michael Rowley [mailto:mrowley@bea.com] 
> Sent: Monday, 8. October 2007 18:18
> To: sca-bindings@lists.oasis-open.org
> Subject: RE: [sca-bindings] ISSUE 4: JMS binding can be used as pub/sub
> workarounding reference multiplicity
> 
> 
> I do not believe that this should be opened as an issue, since it is a
> description of what is already possible.
> 
> Michael
> 
> -----Original Message-----
> From: Eric Johnson [mailto:eric@tibco.com] 
> Sent: Friday, October 05, 2007 12:30 PM
> To: sca-bindings@lists.oasis-open.org
> Subject: [sca-bindings] ISSUE 4: JMS binding can be used as pub/sub
> workarounding reference multiplicity
> 
> Logged as http://www.osoa.org/jira/browse/BINDINGS-4
> 
> -Eric.
> 
> Peshev, Peter wrote:
>> TARGET:
>> JMS Binding Specification Version 1.1, Working Draft  25 September
> 2007
>>
>> DESCRIPTION:
>>
>> Suppose that a component A has reference with multiplicity 1 and is
>> wired to a component B via  binding.jms over a jms topic, and there is
> a
>> component C that is wired to a component D via jms binding OVER THE
> SAME
>> TOPIC. That will mean that by the semantics of the JMS that whenever
> the
>> reference from the component A is being invoked, the message will be
>> sent to component B AND AT THE SAME TIME it will be sent as well to
> the
>> component D.
>> (Here the JMS binding specifies that operations should be oneway if
>> topic is used, so technically there are no problems  with such
> scenario)
>>
>> In other words if there is a reference with the following definition 
>>
>>
>>     <reference name="MyReference">
>>         <interface.java interface="myInterface"/>
>>         <binding.jms>
>>             <destination name="MyTopic" type="topic" />
>>         </binding.jms>
>>     </service>
>>
>>
>> Than there will be a pub/sub to all components who have exposed
> services
>> :
>>
>>     <service name="MyService">
>>         <interface.java interface="myInterface"/>
>>         <binding.jms>
>>             <destination name="MyTopic" type="topic"/>
>>         </binding.jms>
>>     </service>
>>
>>
>>
>> In that way the assembler via a creative usage of JMS binding can form
> a
>> pub/sub (one invocation from A is broadcasted) eventhough the
> component
>> developer has put multiplicity "1" on the reference in "A". Is this an
>> issue that needs solving ?
>>
>> PROPOSED SOLUTION
>>  None
>>
>>
>>
>>