<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 1, 2009, at 6:30 PM, Gavin King wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I have not yet heard *any* feedback from the group on this issue.</div></blockquote><div><br></div>I'm not sure this is a wise extension to make in this version. It's fairly simple to create a bridge from WebBeans events to JMS, and to write an EJB message bean as a bridge from JMS to Web Beans. That's probably not the long term solution, but I'd think it would be better to put off a more complete proposal until after this version.</div><div><br></div><div>For one thing, I'm not convinced it's a good idea to tie the WebBeans spec directly with JMS at all. The two should be orthogonal, so they'll work together but not have any dependencies. (I've never liked the explicit tie with EJB either, and would prefer for that dependency to be hidden behind a EjbBean extends Bean implementation, not in this spec.)</div><div><br></div><div>Some details on the points below:</div><div><br></div><div><blockquote type="cite">If the spec simply defines that events were distributed via JMS,<br></blockquote><blockquote type="cite">absolutely nothing would stop vendors from also supporting alternative<br></blockquote><blockquote type="cite">distribution mechanisms as proprietary extensions (for example, in<br></blockquote><blockquote type="cite">JBoss we could provide support for JGroups).<br></blockquote><div><font class="Apple-style-span" color="#144FAE"><br></font></div><div><font class="Apple-style-span" color="#144FAE">Introducing that dependency on JMS is a terrible idea. There's no intrinsic reason for WebBeans to be dependent on JMS. It's like the EJB dependence on CORBA, or JAX-RPC (or JAX-WS). Unnecessary, complicating implementations, and freezing up the spec for all future revisions.</font></div><div><font class="Apple-style-span" color="#144FAE"><br></font></div><div><font class="Apple-style-span" color="#144FAE">Besides, JMS is designed as a facade around a real messaging system. It's not really suitable for low-level messaging.</font></div><div><font class="Apple-style-span" color="#144FAE"><br></font></div></div><div><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite">What I'm thinking is the following:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(1) Event observers may specify that they receive events asynchronously:</blockquote></div></blockquote><div><br></div><div>Do you mean introducing a queuing system and threading into the event system? Like the EJB @Asynchronous? That opens up a whole mess of issues, and just saying "JMS will solve it" is the wrong answer entirely.</div><div><br></div></div><div><blockquote type="cite"><div><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">By default, an asynchronous observer is a purely local construct.</span></blockquote><blockquote type="cite">However, unlike synchronous observers, an asynchronous observer is<br></blockquote><blockquote type="cite">called in a different set of web beans contexts to the contexts in<br></blockquote><blockquote type="cite">which the event was fired.</blockquote></div></blockquote><div><br></div>Do you mean classloader context? Or some other context? Presumably WebBeans could define that a fireEvent() call always dispatches events in the manager's classloader context. That would be the most logical. The same context rule could be applied to the getInstance() methods of Manager.</div><div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(2) A topic or queue declaration may specify a set of events which are<br></blockquote><blockquote type="cite">distributed via that queue/topic:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> <Topic><br></blockquote><blockquote type="cite"> <destination>java:comp/env/jms/CacheInvalidationEvents</destination><br></blockquote><blockquote type="cite"> <connectionFactory>java:comp/env/jms/TopicConnectionFactory</connectionFactory><br></blockquote><blockquote type="cite"> <events><br></blockquote><blockquote type="cite"> <myapp:Product><br></blockquote><blockquote type="cite"> <myapp:Created/><br></blockquote><blockquote type="cite"> </myapp:Product><br></blockquote><blockquote type="cite"> </events><br></blockquote><blockquote type="cite"> </Topic><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This declaration means that any event that is "assignable" to the<br></blockquote><blockquote type="cite">specified type and binding types is a distributed event, distributed<br></blockquote><blockquote type="cite">by the named JMS topic.</blockquote></div></blockquote><div><br></div>This is essentially implementing a message-driven bean as a bridge and defining a particular JMS message syntax, which goes well beyond what WebBeans really should be involved in.</div><div><br></div><div>Creating this kind of bridge would be fairly straightforward, but really doesn't belong in the spec. (At least this version.)</div><div><br><blockquote type="cite"><div><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">(3) The Web Bean manager would validate that all observers for any</span></blockquote><blockquote type="cite">event distributed via JMS are declared to be asynchronous observers,<br></blockquote><blockquote type="cite">and throw an exception if there are any synchronous observers for the<br></blockquote><blockquote type="cite">event.</blockquote></div></blockquote><div><br></div><div>If an application wanted to handle its own queuing rather than container-managed queuing, it would want a "synchronous" observer. (Which is kind of the point. It's already straightforward to design this kind of system on top of the web beans API, which would be a cleaner, more layered design.)</div></div><div><br><blockquote type="cite"><div><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">(4) We need to think carefully about the concept of an asynchronous</span></blockquote><blockquote type="cite">transaction completion event observer. The following combinations are<br></blockquote><blockquote type="cite">semantically correct, and need to be supported, even for the distributed<br></blockquote><blockquote type="cite">case:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> @Observes @Asynchronously @AfterTransactionCompletion<br></blockquote><blockquote type="cite"> @Observes @Asynchronously @AfterTransactionSuccess<br></blockquote><blockquote type="cite"> @Observes @Asynchronously @AfterTransactionFailue<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> However, this combination is not meaningful:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> @Observes @Asynchronously @BeforeTransactionCompletion<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(5) Finally, since JMS is a transactional medium, we could support a<br></blockquote><blockquote type="cite">further setting which writes the event transactionally to the queue/topic.<br></blockquote><blockquote type="cite">However, this setting needs to be a global setting for the event type.<br></blockquote><blockquote type="cite">Perhaps an @Transactional annotation for the event type?</blockquote></div></blockquote><div><br></div>If fireEvent() becomes transactional, wouldn't that logically imply that it could rollback? It's an example of the kinds of issues that would need to be resolved if this idea goes forward. Logically, you'd be creating a transactional messaging/queueing model inside WebBeans, so would need to specify all the relevant behavior.</div><div><br></div><div>For a future spec, these ideas are concepts that can be added, but creating a queuing/threading model that's also transactionally aware this late in the process is just not a good idea.</div><div><br></div><div>If the fireEvent is synchronous (in the sense of the same thread calling @Observes), then anyone can build a clean, transactional queuing model on top of it, without introducing a dependency on the Web Beans spec at all. Just write the appropriate bridges. For now, that would be the far preferable approach.</div><div><br></div><div>-- Scott</div><div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">WDYT?<br></blockquote><blockquote type="cite"><br></blockquote><br><br><br>-- <br>Gavin King<br><a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>http://in.relation.to/Bloggers/Gavin<br>http://hibernate.org<br>http://seamframework.org<br><br><br></div></blockquote></div><br></body></html>