[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Proposed SCA Event Processing Model
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]