I 've read SCA's Assembly Model Spec., Extension of Event
Processing and Pub/Sub. The major extension I have found is that SCA has
renamed messages into events. Now, they can 'send event', receive event',
'filter event'... it is worth than a heart burn, IMO
- Michael
----- Original Message -----
From: "Francis McCabe"
To: "Lublinsky, Boris"
Cc: mpoulin@usa.com, soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Proposed SCA Event Processing Model
Date: Thu, 07 May 2009 10:26:38 -0700
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"
>> To: ,
>> 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 >>