Re: [soa-rm-ra] Proposed SCA Event Processing Model

[Francis McCabe <frankmccabe@mac.com>]

I have real heart burn with the notion of using an event to invoke a  
service.

Incidentally, I got my comparison wrong, the encoding for A is 65 not  
64 :)
On May 7, 2009, at 10:06 AM, Lublinsky, Boris wrote:

> Thanks Frank,
> Very eloquent comparison, as usual, but...
> The way to look at it is to use event as a delivery mechanism for
> invoking a service using an interface. This in fact what SCA binding  
> is
> defining. For me event is a decoupling mechanism for invocation.  
> Instead
> of invoking service directly, I send the request (message or event) to
> the intermediary, without knowing who is usually interested in this.  
> In
> this case one-way call fulfills event's semantics
>
>
> -----Original Message-----
> From: Francis McCabe [mailto:frankmccabe@mac.com]
> Sent: Thursday, May 07, 2009 10:46 AM
> To: Lublinsky, Boris
> Cc: mpoulin@usa.com; soa-rm-ra@lists.oasis-open.org
> Subject: Re: [soa-rm-ra] Proposed SCA Event Processing Model
>
> The RA *does* already have a notion of event. An event is a report of
> an occurrence.
> And to say that a one way invocation is the same as an event is
> analogous to declaring that because 64 has the same binary encoding as
> the letter A, they are the same thing.
>
> On May 7, 2009, at 7:47 AM, Lublinsky, Boris wrote:
>
>> How about event interfaces?
>> There is really very little difference between events and and one
>> way invocations. Also, as Heather mentions WS-eventing is all based
>> on well defined interfaces.
>>
>> -----Original Message-----
>> From: mpoulin@usa.com [mailto:mpoulin@usa.com]
>> Sent: Thursday, May 07, 2009 9:21 AM
>> To: soa-rm-ra@lists.oasis-open.org
>> Subject: RE: [soa-rm-ra] Proposed SCA Event Processing Model
>>
>> Boris,
>>
>> With all same respect, anything in the service which communicates
>> with external world other than through official interfaces
>> constitutes degree of coupling.
>>
>> In particular, an event in one service may not listen to an event
>> inside another service in other way than though officially defined
>> services event-dedicated interface.
>>
>> This is what I mean. Otherwise, we will be unable using the service
>> freely in different service compositions.
>>
>> - Michael
>>
>> ===========================================
>> Subject: RE: [soa-rm-ra] Proposed SCA Event Processing Model
>> 	From: "Lublinsky, Boris" <boris.lublinsky@navteq.com>
>> 	To: <mpoulin@usa.com>, <soa-rm-ra@lists.oasis-open.org>
>> 	Date: Thu, 7 May 2009 08:19:15 -0500
>> ________________________________________
>> Michael
>> With all do respect, event-based does not create additional
>> coupling. Furthermore, considering an industry buzz around events, I
>> think it will be prudent To include events in RA. SCA has done a
>> good job incorporating events, basically through intermediary, thus
>> marrying events and interfaces
>>
>>
>> The information contained in this communication may be CONFIDENTIAL
>> and is intended only for the use of the recipient(s) named above.
>> If you are not the intended recipient, you are hereby notified that
>> any dissemination, distribution, or copying of this communication,
>> or any of its contents, is strictly prohibited.  If you have
>> received this communication in error, please notify the sender and
>> delete/destroy the original message and any copy of it from your
>> computer or paper files.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/ 
>> my_workgroups.php
>>
>
>
>
> The information contained in this communication may be CONFIDENTIAL  
> and is intended only for the use of the recipient(s) named above.   
> If you are not the intended recipient, you are hereby notified that  
> any dissemination, distribution, or copying of this communication,  
> or any of its contents, is strictly prohibited.  If you have  
> received this communication in error, please notify the sender and  
> delete/destroy the original message and any copy of it from your  
> computer or paper files.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

smime.p7s