Re: [sca-assembly] some of our concerns with the eventing proposal

[Jim Marino <jim.marino@gmail.com>]

On Sep 9, 2009, at 4:13 PM, Martin Chapman wrote:

>
>
>> -----Original Message-----
>> From: Jim Marino [mailto:jim.marino@gmail.com]
>> Sent: 09 September 2009 14:56
>> To: Martin Chapman
>> Cc: 'Scott Vorthmann'; 'OASIS Assembly'
>> Subject: Re: [sca-assembly] some of our concerns with the eventing  
>> proposal
>>
>> Hi Martin,
>>
>> I had one question below.
>>
>> Thanks,
>> Jim
>>
>> On Sep 9, 2009, at 2:44 PM, Martin Chapman wrote:
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Scott Vorthmann [mailto:scottv@tibco.com]
>>>> Sent: 09 September 2009 08:47
>>>> To: OASIS Assembly
>>>> Subject: [sca-assembly] some of our concerns with the eventing
>>>> proposal
>>>>
>>>>
>>>> To inform the technical discussion we'll be having tomorrow, I'd  
>>>> like
>>>> to shed some light on TIBCO's concerns with the existing proposal.
>>>> The following is not exhaustive or terribly detailed, but is enough
>>>> to
>>>> begin discussion.
>>>>
>>>> 1. Eventing and publish-subscribe messaging are not the same thing.
>>>> While it is useful for SCA to define a pub-sub alternative for the
>>>> current wiring paradigm, that does not have to imply definition of
>>>> new
>>>> componentType concepts like consumer and producer.  We believe that
>>>> pub/sub messaging can and should be fit into SCA without affecting
>>>> the
>>>> developer model.
>>>
>>> [<MartinC>] Would have to disagree here. I think the developer does
>>> want to know if it is processing an event (i.e. can do what it
>>> wants with it) vs servicing an explicit request from a client. So
>>> some annotation or syntactic differentiation is required IMHO.
>>>
>>
>> Assuming a service is one-way and not bidirectional (in SCA terms),
>> why would handling an event be any different than handling an
>> invocation from a developer/implementation perspective? In other
>> words, how would the difference between event data and invocation  
>> data
>> manifest itself?
>
> [<MartinC>] with an event, there is no  semantic contractual  
> expectation on the side of the sender as to what the receiver will do
> upon receipt - the operation name is meaningless for an event but  
> carries some semantics for normal invocations.
> e.g debitBankAccount(200) vs an event that says an Account has gone  
> overdrawn.
>

Martin,

Services may also have the same behavior, i.e. lack a "semantic  
contractual expectation on the side of the sender...". It depends on  
how the contract is defined. For example, the following is a valid  
service contract:

public interface AccountEventListenerService {

	@OneWay
	void onEvent(TransactionEvent event);

}

What semantic contract is implied by the AccountEventListenerService  
inteface between the client and provider? Non-blocking behavior may be  
implied but the same can be said for eventing. Local invocation  
semantics are also implied, but I would assume eventing would allow  
for local optimizations.

My original question was related to your statement that the developer  
wants to know if s/he is processing an event or an invocation. At the  
programming model level, I am starting with the assumption that there  
should not be any difference. Rather, the developer only needs to know  
the contract semantics, not whether the call is an event or an  
invocation. For example, the developer will need to know if reliable  
delivery is enabled. Reliable delivery is a contract semantic that may  
impact the implementation as the latter will need to handle cases such  
as duplicate messages if they are not idempotent. However, in the case  
above (a one-way, non-bidirectional contract), it makes no difference  
to the implementation if the data (TransactionEvent) arrived as the  
result of a client invocation or channel/eventing infrastructure.

To illustrate this point, what would an eventing consumer look like in  
Java? We could start with this:

public interface AccountEventListenerService {

	void onEvent(TransactionEvent event);

}


public class AccountEventListenerServiceImpl implements  
AccountEventListenerService {

	public void onEvent(TransactionEvent event) {
		
		// do something or just ignore....

	}

}

What would the contents of the onEvent method be that would require a  
developer to know if the TransactionEvent data were the result of a  
client invocation or eventing notification?

Jim