1:51 a.m.
IBM has raised the issue of event processing in a distributed
environment, and we (Red Hat) have promised to address this issue in
the revised public draft.
The Web Beans event bus provides a very nice way for stateful
components to synchronize their state (transactionally) with changes
that take place in the application. Event processing is *much* more
important in an environment with stateful object such as SFSBs than it
is in an environment with only stateless objects such as SLSBs or
Spring beans. Furthermore, event processing must be aware of the
transaction completion lifecycle (many applications today have bugs
when transaction rollbacks occur). Therefore, I believe that event
processing is an essential feature of Web Beans.
However, the event bus we have today is a purely local construct and
does not help when the application is distributed across multiple
cluster nodes or multiple physical tiers.
Designing a distributed event bus would potentially be a very
difficult undertaking, with so many issues to think about: QoS,
asynchronicity, transactionality, routing, etc. Fortunately, JMS
already has the features we need, and is what is sometimes used today
to solve the problems we're talking about:
* asynchronous, distributed semantics
* a notion of both 1-of-N and N-of-N semantics (queues and topics)
* a notion of logical channels (to allow routing of events between
tiers and applications)
* support for a range of QoS semantics
* transactionality
Furthermore, JMS is well-understood and well-supported.
If the spec simply defines that events were distributed via JMS,
absolutely nothing would stop vendors from also supporting alternative
distribution mechanisms as proprietary extensions (for example, in
JBoss we could provide support for JGroups).
And when EE finally gets a WorkManager API, a future version of Web
Beans could also define that distribution of local asynchronous events
is via the WorkManager.
The application developer would not be exposed to the JMS APIs. The
actual interaction with JMS would be handled by the container. All the
developer would need to do is specify that events with a specific type
and binding types would be distributed by a certain queue or topic.
(web-beans.xml would be the right place to specify this mapping.)
What I'm thinking is the following:
(1) Event observers may specify that they receive events asynchronously:
void invalidateCache(@Observes @Asynchronously @Created Product
product) { ... }
or even:
void invalidateCache(@Observes(ASYNCHRONOUSLY) @Created Product
product) { ... }
By default, an asynchronous observer is a purely local construct.
However, unlike synchronous observers, an asynchronous observer is
called in a different set of web beans contexts to the contexts in
which the event was fired.
(2) A topic or queue declaration may specify a set of events which are
distributed via that queue/topic:
<Topic>
<destination>java:comp/env/jms/CacheInvalidationEvents</destination>
<connectionFactory>java:comp/env/jms/TopicConnectionFactory</connectionFactory>
<events>
<myapp:Product>
<myapp:Created/>
</myapp:Product>
</events>
</Topic>
This declaration means that any event that is "assignable" to the
specified type and binding types is a distributed event, distributed
by the named JMS topic.
(3) The Web Bean manager would validate that all observers for any
event distributed via JMS are declared to be asynchronous observers,
and throw an exception if there are any synchronous observers for the
event.
(4) We need to think carefully about the concept of an asynchronous
transaction completion event observer. The following combinations are
semantically correct, and need to be supported, even for the distributed
case:
@Observes @Asynchronously @AfterTransactionCompletion
@Observes @Asynchronously @AfterTransactionSuccess
@Observes @Asynchronously @AfterTransactionFailue
However, this combination is not meaningful:
@Observes @Asynchronously @BeforeTransactionCompletion
(5) Finally, since JMS is a transactional medium, we could support a
further setting which writes the event transactionally to the queue/topic.
However, this setting needs to be a global setting for the event type.
Perhaps an @Transactional annotation for the event type?
WDYT?
2:40 a.m.
New subject: [webbeans-dev] Re: Distributed event channels
Blogged here:
http://in.relation.to/Bloggers/DistributedEventsForWebBeans
On Sun, Dec 21, 2008 at 6:51 PM, Gavin King <gavin(a)hibernate.org> wrote:
IBM has raised the issue of event processing in a distributed
environment, and we (Red Hat) have promised to address this issue in
the revised public draft.
The Web Beans event bus provides a very nice way for stateful
components to synchronize their state (transactionally) with changes
that take place in the application. Event processing is *much* more
important in an environment with stateful object such as SFSBs than it
is in an environment with only stateless objects such as SLSBs or
Spring beans. Furthermore, event processing must be aware of the
transaction completion lifecycle (many applications today have bugs
when transaction rollbacks occur). Therefore, I believe that event
processing is an essential feature of Web Beans.
However, the event bus we have today is a purely local construct and
does not help when the application is distributed across multiple
cluster nodes or multiple physical tiers.
Designing a distributed event bus would potentially be a very
difficult undertaking, with so many issues to think about: QoS,
asynchronicity, transactionality, routing, etc. Fortunately, JMS
already has the features we need, and is what is sometimes used today
to solve the problems we're talking about:
* asynchronous, distributed semantics
* a notion of both 1-of-N and N-of-N semantics (queues and topics)
* a notion of logical channels (to allow routing of events between
tiers and applications)
* support for a range of QoS semantics
* transactionality
Furthermore, JMS is well-understood and well-supported.
If the spec simply defines that events were distributed via JMS,
absolutely nothing would stop vendors from also supporting alternative
distribution mechanisms as proprietary extensions (for example, in
JBoss we could provide support for JGroups).
And when EE finally gets a WorkManager API, a future version of Web
Beans could also define that distribution of local asynchronous events
is via the WorkManager.
The application developer would not be exposed to the JMS APIs. The
actual interaction with JMS would be handled by the container. All the
developer would need to do is specify that events with a specific type
and binding types would be distributed by a certain queue or topic.
(web-beans.xml would be the right place to specify this mapping.)
What I'm thinking is the following:
(1) Event observers may specify that they receive events asynchronously:
void invalidateCache(@Observes @Asynchronously @Created Product
product) { ... }
or even:
void invalidateCache(@Observes(ASYNCHRONOUSLY) @Created Product
product) { ... }
By default, an asynchronous observer is a purely local construct.
However, unlike synchronous observers, an asynchronous observer is
called in a different set of web beans contexts to the contexts in
which the event was fired.
(2) A topic or queue declaration may specify a set of events which are
distributed via that queue/topic:
<Topic>
<destination>java:comp/env/jms/CacheInvalidationEvents</destination>
<connectionFactory>java:comp/env/jms/TopicConnectionFactory</connectionFactory>
<events>
<myapp:Product>
<myapp:Created/>
</myapp:Product>
</events>
</Topic>
This declaration means that any event that is "assignable" to the
specified type and binding types is a distributed event, distributed
by the named JMS topic.
(3) The Web Bean manager would validate that all observers for any
event distributed via JMS are declared to be asynchronous observers,
and throw an exception if there are any synchronous observers for the
event.
(4) We need to think carefully about the concept of an asynchronous
transaction completion event observer. The following combinations are
semantically correct, and need to be supported, even for the distributed
case:
@Observes @Asynchronously @AfterTransactionCompletion
@Observes @Asynchronously @AfterTransactionSuccess
@Observes @Asynchronously @AfterTransactionFailue
However, this combination is not meaningful:
@Observes @Asynchronously @BeforeTransactionCompletion
(5) Finally, since JMS is a transactional medium, we could support a
further setting which writes the event transactionally to the queue/topic.
However, this setting needs to be a global setting for the event type.
Perhaps an @Transactional annotation for the event type?
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
8:30 p.m.
New subject: [webbeans-dev] Re: Distributed event channels
I have not yet heard *any* feedback from the group on this issue.
We now have 3 weeks to finish the revised public draft, so I need to
start writing this up soon.
On Sun, Dec 21, 2008 at 6:51 PM, Gavin King <gavin(a)hibernate.org> wrote:
IBM has raised the issue of event processing in a distributed
environment, and we (Red Hat) have promised to address this issue in
the revised public draft.
The Web Beans event bus provides a very nice way for stateful
components to synchronize their state (transactionally) with changes
that take place in the application. Event processing is *much* more
important in an environment with stateful object such as SFSBs than it
is in an environment with only stateless objects such as SLSBs or
Spring beans. Furthermore, event processing must be aware of the
transaction completion lifecycle (many applications today have bugs
when transaction rollbacks occur). Therefore, I believe that event
processing is an essential feature of Web Beans.
However, the event bus we have today is a purely local construct and
does not help when the application is distributed across multiple
cluster nodes or multiple physical tiers.
Designing a distributed event bus would potentially be a very
difficult undertaking, with so many issues to think about: QoS,
asynchronicity, transactionality, routing, etc. Fortunately, JMS
already has the features we need, and is what is sometimes used today
to solve the problems we're talking about:
* asynchronous, distributed semantics
* a notion of both 1-of-N and N-of-N semantics (queues and topics)
* a notion of logical channels (to allow routing of events between
tiers and applications)
* support for a range of QoS semantics
* transactionality
Furthermore, JMS is well-understood and well-supported.
If the spec simply defines that events were distributed via JMS,
absolutely nothing would stop vendors from also supporting alternative
distribution mechanisms as proprietary extensions (for example, in
JBoss we could provide support for JGroups).
And when EE finally gets a WorkManager API, a future version of Web
Beans could also define that distribution of local asynchronous events
is via the WorkManager.
The application developer would not be exposed to the JMS APIs. The
actual interaction with JMS would be handled by the container. All the
developer would need to do is specify that events with a specific type
and binding types would be distributed by a certain queue or topic.
(web-beans.xml would be the right place to specify this mapping.)
What I'm thinking is the following:
(1) Event observers may specify that they receive events asynchronously:
void invalidateCache(@Observes @Asynchronously @Created Product
product) { ... }
or even:
void invalidateCache(@Observes(ASYNCHRONOUSLY) @Created Product
product) { ... }
By default, an asynchronous observer is a purely local construct.
However, unlike synchronous observers, an asynchronous observer is
called in a different set of web beans contexts to the contexts in
which the event was fired.
(2) A topic or queue declaration may specify a set of events which are
distributed via that queue/topic:
<Topic>
<destination>java:comp/env/jms/CacheInvalidationEvents</destination>
<connectionFactory>java:comp/env/jms/TopicConnectionFactory</connectionFactory>
<events>
<myapp:Product>
<myapp:Created/>
</myapp:Product>
</events>
</Topic>
This declaration means that any event that is "assignable" to the
specified type and binding types is a distributed event, distributed
by the named JMS topic.
(3) The Web Bean manager would validate that all observers for any
event distributed via JMS are declared to be asynchronous observers,
and throw an exception if there are any synchronous observers for the
event.
(4) We need to think carefully about the concept of an asynchronous
transaction completion event observer. The following combinations are
semantically correct, and need to be supported, even for the distributed
case:
@Observes @Asynchronously @AfterTransactionCompletion
@Observes @Asynchronously @AfterTransactionSuccess
@Observes @Asynchronously @AfterTransactionFailue
However, this combination is not meaningful:
@Observes @Asynchronously @BeforeTransactionCompletion
(5) Finally, since JMS is a transactional medium, we could support a
further setting which writes the event transactionally to the queue/topic.
However, this setting needs to be a global setting for the event type.
Perhaps an @Transactional annotation for the event type?
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
9:15 p.m.
New subject: [webbeans-dev] Re: Distributed event channels
On Jan 1, 2009, at 6:30 PM, Gavin King wrote:
I have not yet heard *any* feedback from the group on this issue.
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.
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.)
Some details on the points below:
If the spec simply defines that events were distributed via JMS,
absolutely nothing would stop vendors from also supporting alternative
distribution mechanisms as proprietary extensions (for example, in
JBoss we could provide support for JGroups).
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.
Besides, JMS is designed as a facade around a real messaging system.
It's not really suitable for low-level messaging.
>
> What I'm thinking is the following:
>
> (1) Event observers may specify that they receive events
> asynchronously:
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.
> By default, an asynchronous observer is a purely local
construct.
> However, unlike synchronous observers, an asynchronous observer is
> called in a different set of web beans contexts to the contexts in
> which the event was fired.
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.
>
>
> (2) A topic or queue declaration may specify a set of events which
> are
> distributed via that queue/topic:
>
> <Topic>
> <destination>java:comp/env/jms/CacheInvalidationEvents</
> destination>
> <connectionFactory>java:comp/env/jms/
> TopicConnectionFactory</connectionFactory>
> <events>
> <myapp:Product>
> <myapp:Created/>
> </myapp:Product>
> </events>
> </Topic>
>
> This declaration means that any event that is "assignable" to the
> specified type and binding types is a distributed event, distributed
> by the named JMS topic.
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.
Creating this kind of bridge would be fairly straightforward, but
really doesn't belong in the spec. (At least this version.)
> (3) The Web Bean manager would validate that all observers for
any
> event distributed via JMS are declared to be asynchronous observers,
> and throw an exception if there are any synchronous observers for the
> event.
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.)
> (4) We need to think carefully about the concept of an
asynchronous
> transaction completion event observer. The following combinations are
> semantically correct, and need to be supported, even for the
> distributed
> case:
>
> @Observes @Asynchronously @AfterTransactionCompletion
> @Observes @Asynchronously @AfterTransactionSuccess
> @Observes @Asynchronously @AfterTransactionFailue
>
> However, this combination is not meaningful:
>
> @Observes @Asynchronously @BeforeTransactionCompletion
>
> (5) Finally, since JMS is a transactional medium, we could support a
> further setting which writes the event transactionally to the queue/
> topic.
> However, this setting needs to be a global setting for the event
> type.
> Perhaps an @Transactional annotation for the event type?
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.
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.
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.
-- Scott
>
>
> WDYT?
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
10:18 p.m.
New subject: [webbeans-dev] Re: Distributed event channels
On Fri, Jan 2, 2009 at 2:15 PM, Scott Ferguson <ferg(a)caucho.com> wrote:
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.
I certainly don't want to do anything that's incomplete. But I happen
to believe that we can create something fairly complete here, since we
are simply providing a facade over something that is *already* very
complete (JMS).
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.)
Well, it's not a hard dependency. The event functionality works w/o
JMS, but if you
(a) happen to have a JMS provider, and
(b) *want* to map the events to distribution via JMS, you can.
I believe that the target environment (the EE Web Profile) requires
support for the JMS client libraries, so the APIs that the web beans
implementation would be interacting with are already there.
Nothing stops anyone from implementing alternative (non-JMS)
distribution technologies, and, indeed, I believe that the APIs we'll
define here (e.g. @Asynchronous) will be just as relevant for other
distribution technologies.
If the spec simply defines that events were distributed via JMS,
absolutely nothing would stop vendors from also supporting alternative
distribution mechanisms as proprietary extensions (for example, in
JBoss we could provide support for JGroups).
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.
If we want to support distributed event processing, we have two choices:
(1) define, from scratch, all the various event-processing semantics
like QoS, 1ofN/NofN, routing, transactionality, routing, etc.
(2) simply leverage JMS, which already defines all those things.
The reality is that we are *never* going to do (1). Web Beans is never
going to grow into a spec that defines an async messaging system.
Forget it. For one thing, it would wind up competing with JMS, or
would at least be perceived to compete with JMS by other people. Not
gunna happen.
So, if we are going to have support for distributed event processing,
we are going to have to utilize a technology that pre-exists. The only
available candidate is JMS, and I think the mapping is really quite
natural.
I would *much* rather see the spec define a standard mapping from Web
Beans events to JMS, leaving open the possibility of other,
proprietary mappings to proprietary messaging technologies than have
the whole event bus removed from the spec due to the objection that
it's incomplete.
Besides, JMS is designed as a facade around a real messaging system.
It's
not really suitable for low-level messaging.
I don't understand the difference between "real" messaging and
"low-level" messaging. There are plenty of lightweight, pure-Java
implementations of JMS.
What I'm thinking is the following:
(1) Event observers may specify that they receive events asynchronously:
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.
Actually, what I was thinking is something *exactly* like the
semantics of @Asynchronous, @Timeout or of message-driven beans. The
EJB spec already gives us a good definition of what an "asynchronous"
listener is, which we can simply copy/paste :-)
By default, an asynchronous observer is a purely local construct.
However, unlike synchronous observers, an asynchronous observer is
called in a different set of web beans contexts to the contexts in
which the event was fired.
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.
I mean the Web Beans contexts like the request context, etc.
This declaration means that any event that is "assignable"
to the
specified type and binding types is a distributed event, distributed
by the named JMS topic.
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.
Yes, correct, it's basically a simple facade over JMS, making JMS
*much* easier to use for the special case of event processing inside a
single application. Currently the JMS APIs are utterly inappropriate
for this usecase, and EE offers no other alternative solution.
Creating this kind of bridge would be fairly straightforward, but
really
doesn't belong in the spec. (At least this version.)
OK, but what I'm hearing from other people is that if Web Beans
*doesn't* have this functionality in this version, then it should not
have *any* event functionality in this version. While I don't
completely agree with this, I do think they have a very strong point
in that the event functionality is fundamentally incomplete if the
event processing doesn't work in a clustered or tiered deployment.
So at this point we are effectively left with a choice between:
(1) Do distributed events
(2) Drop events entirely from the spec.
(3) The Web Bean manager would validate that all observers for any
event distributed via JMS are declared to be asynchronous observers,
and throw an exception if there are any synchronous observers for the
event.
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.)
It's not difficult for guys like you and me, but it *is* the kind of
thing that is difficult for many developers.
(5) Finally, since JMS is a transactional medium, we could support a
further setting which writes the event transactionally to the queue/topic.
However, this setting needs to be a global setting for the event type.
Perhaps an @Transactional annotation for the event type?
If fireEvent() becomes transactional, wouldn't that logically imply that it
could rollback?
Um, no, that's not what I meant at all. What I'm referring to is the
notion of persistent messages (DeliveryMode.PERSISTENT).
(For topics, durable subscribers may also come into this.)
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.
No, I definitely don't want to define anything new here, since it is
already defined by JMS. All I'm trying to do is map notions that
already exist in JMS back up into the Web Beans APIs.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
12:40 a.m.
New subject: [webbeans-dev] Re: Distributed event channels
On Jan 1, 2009, at 8:18 PM, Gavin King wrote:
I certainly don't want to do anything that's incomplete. But
I happen
to believe that we can create something fairly complete here, since we
are simply providing a facade over something that is *already* very
complete (JMS).
See below for some more details about JMS. I like @Asynchronous in
the EJB spec, and if you reread it, it's completely defined without
any JMS reference. That kind of definition is complete and well
defined. Copying @Asynchronous it for WebBeans would be fine. JMS
under WebBeans is not fine.
> If we want to support distributed event processing, we have two
> choices:
(1) define, from scratch, all the various event-processing semantics
like QoS, 1ofN/NofN, routing, transactionality, routing, etc.
(2) simply leverage JMS, which already defines all those things.
No, JMS does not define those things. Most importantly in this
context, JMS does not define routing at all. That's left as an
implementation detail.
Since the WebBeans event bus is all about routing (i.e. finding an
observer for an event), there's a mismatch between the abstraction of
the two specs. JMS doesn't address that problem at all. (I'm not
criticizing JMS for this. It's not what JMS is designed for.)
The reality is that we are *never* going to do (1). Web Beans is
never
going to grow into a spec that defines an async messaging system.
I assume you mean async distributed messaging system. I'd certainly
agree with that.
As you pointed out, an async local messaging system is essentially the
EJB @Asynchronous, which would be fine.
Forget it. For one thing, it would wind up competing with JMS, or
would at least be perceived to compete with JMS by other people. Not
gunna happen.
So, if we are going to have support for distributed event processing,
we are going to have to utilize a technology that pre-exists. The only
available candidate is JMS, and I think the mapping is really quite
natural.
I would *much* rather see the spec define a standard mapping from
Web
Beans events to JMS, leaving open the possibility of other,
proprietary mappings to proprietary messaging technologies than have
the whole event bus removed from the spec due to the objection that
it's incomplete.
I think this will explain the problem.
A WebBeans event is a <object,binding> pair. The object maps
trivially to the JMS ObjectMessage, but the binding maps to nothing
natural in JMS. Remember, destinations (topics/queues) in JMS are
opaque from the spec's point of view. Any structure is implementation-
dependent.
From WebBeans to JMS, someone can easily write an @Observer bridge to
route the object to the proper queue or topic (based on @BindingType
of the @Observer), but there's no way WebBeans can possibly define
that mapping itself because JMS doesn't provide enough detail to map
bindings to queues/topics, and it would be inappropriate for WebBeans
to impose extra detail on top of JMS.
From JMS to WebBeans, someone could write a message-driven bean (or
equivalent), to forward JMS objects to WebBeans events, and they could
add appropriate @BindingType to the fireEvent. WebBeans could define
a specialized message-driven bean for this purpose, but that would
effectively pull in MDB logic into the WebBeans spec. And given XA
(and pooling, etc), that logic is not trivial.
WebBeans defines a nice local event bus, and someone can write a
bridges nicely with JMS, but extending WebBeans to a distributed bus
is not at all as simple as bolting on JMS.
> Besides, JMS is designed as a facade around a real messaging
> system. It's
> not really suitable for low-level messaging.
I don't understand the difference between "real" messaging and
"low-level" messaging. There are plenty of lightweight, pure-Java
implementations of JMS.
"real" meaning concrete, as opposed to abstract (not "real" vs
"bogus").
"low-level" meaning basic queuing of objects/requests (like EJB
@Asynchronous), not high-level facades like the Message API.
For example, any messaging implementation needs to have a routing
architecture. A low-level specification messaging (like Jabber/XMPP
or SMTP) defines things like addressing/routing. WebBeans defines
routing. JMS does not, i.e. JMS is a facade around a concrete
architecture.
Actually, what I was thinking is something *exactly* like the
semantics of @Asynchronous, @Timeout or of message-driven beans. The
EJB spec already gives us a good definition of what an "asynchronous"
listener is, which we can simply copy/paste :-)
Sure. Of course, I'd like all aspects defined in either spec to apply
to any components in any spec.
> By default, an asynchronous observer is a purely local construct.
> However, unlike synchronous observers, an asynchronous observer is
> called in a different set of web beans contexts to the contexts in
> which the event was fired.
I mean the Web Beans contexts like the request context, etc.
Gotcha.
> Creating this kind of bridge would be fairly straightforward, but
> really
> doesn't belong in the spec. (At least this version.)
OK, but what I'm hearing from other people is that if Web Beans
*doesn't* have this functionality in this version, then it should not
have *any* event functionality in this version.
It's a decent argument. There's certainly a strong need for
distributed events. I think the local events are a much more
specialized application, and I'm not sure how valuable they are.
While I don't completely agree with this, I do think they have a
very strong point
in that the event functionality is fundamentally incomplete if the
event processing doesn't work in a clustered or tiered deployment.
The WebBeans events are not suitable for a distributed event system in
the current state, and adding JMS does not solve the underlying
problem. So, if the event system isn't useful for local-only
applications, I'd have to say it should be put off.
Now, a spec that used the WebBeans ideas to solve the distributed
event problem would be a very interesting spec, but way out of scope
for this group.
So at this point we are effectively left with a choice between:
(1) Do distributed events
(2) Drop events entirely from the spec.
Given only those two choices, I'd have to recommend #2.
And then start a new JSR to solve #1, possibly using many of the
concepts already developed in the draft.
> 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.)
It's not difficult for guys like you and me, but it *is* the kind of
thing that is difficult for many developers.
Certainly. I was thinking in terms of a specification/implementation
layered on top of WebBeans.
> (5) Finally, since JMS is a transactional medium, we could support a
> further setting which writes the event transactionally to the queue/
> topic.
> However, this setting needs to be a global setting for the event
> type.
> Perhaps an @Transactional annotation for the event type?
>
> If fireEvent() becomes transactional, wouldn't that logically imply
> that it
> could rollback?
Um, no, that's not what I meant at all. What I'm referring to is the
notion of persistent messages (DeliveryMode.PERSISTENT).
See the "transacted send" concept in the EJB 3.1 draft (4.4.2).
Logically, the concept would apply to the fireEvent() call.
Persistent messages is really a QoS thing, not really transactional
(although of course the implementation details are intertwined.)
-- Scott
(For topics, durable subscribers may also come into this.)
> 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.
No, I definitely don't want to define anything new here, since it is
already defined by JMS. All I'm trying to do is map notions that
already exist in JMS back up into the Web Beans APIs.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
4:06 a.m.
New subject: [webbeans-dev] Re: Distributed event channels
On Fri, Jan 2, 2009 at 5:40 PM, Scott Ferguson <ferg(a)caucho.com> wrote:
On Jan 1, 2009, at 8:18 PM, Gavin King wrote:
> I certainly don't want to do anything that's incomplete. But I happen
> to believe that we can create something fairly complete here, since we
> are simply providing a facade over something that is *already* very
> complete (JMS).
See below for some more details about JMS. I like @Asynchronous in the EJB
spec, and if you reread it, it's completely defined without any JMS
reference. That kind of definition is complete and well defined. Copying
@Asynchronous it for WebBeans would be fine. JMS under WebBeans is not
fine.
@Asynchronous methods in EJB do not support stuff like persistency,
logical channels, N-of-N vs 1-of-N semantics, etc. It's not
semantically sufficient for what we need here.
>> If we want to support distributed event processing, we have
two choices:
>
> (1) define, from scratch, all the various event-processing semantics
> like QoS, 1ofN/NofN, routing, transactionality, routing, etc.
> (2) simply leverage JMS, which already defines all those things.
No, JMS does not define those things. Most importantly in this context, JMS
does not define routing at all. That's left as an implementation detail.
It does not define routing but it does define the notion of logical
channels, which is what you need if you want to do routing. It
certainly does define certain QoS semantics (e.g. persistent messages
and transactional sessions), and 1-of-N vs N-of-N (queues vs. topics).
i.e. exactly the things we need :-)
> The reality is that we are *never* going to do (1). Web Beans is
never
> going to grow into a spec that defines an async messaging system.
I assume you mean async distributed messaging system. I'd certainly agree
with that.
As you pointed out, an async local messaging system is essentially the EJB
@Asynchronous, which would be fine.
Yeah, more or less. It's a *much* simpler problem.
A WebBeans event is a <object,binding> pair. The object maps
trivially to
the JMS ObjectMessage, but the binding maps to nothing natural in JMS.
Remember, destinations (topics/queues) in JMS are opaque from the spec's
point of view. Any structure is implementation-dependent.
I don't understand what you are saying here. I don't agree that there
is no natural mapping from event type/bindings to JMS.
* Event type -> JMS channel (topic/queue), and
* event binding -> JMS message property
is very natural to me. Then the observed event bindings can be
expressed as a message selector :-)
Note that we don't have to define in detail exactly how event bindings
map to message properties, since from the point of view of the
application, this is an implementation detail.
From WebBeans to JMS, someone can easily write an @Observer bridge to
route
the object to the proper queue or topic (based on @BindingType of the
@Observer), but there's no way WebBeans can possibly define that mapping
itself because JMS doesn't provide enough detail to map bindings to
queues/topics, and it would be inappropriate for WebBeans to impose extra
detail on top of JMS.
I just don't see the problem here. Why can the user not specify that
event type X is distributed on topic T declaratively?
From the user point of view, that is a hell of a lot easier than
having to write code in an observer method to wrap the event up in an
ObjectMessage and put it on the topic, and then a message driven bean
that unwraps the event and calls fireEvent().
All we are doing is providing a mechanism to do declaratively exactly
what the user would have to write code to do.
From JMS to WebBeans, someone could write a message-driven bean (or
equivalent), to forward JMS objects to WebBeans events, and they could add
appropriate @BindingType to the fireEvent. WebBeans could define a
specialized message-driven bean for this purpose, but that would effectively
pull in MDB logic into the WebBeans spec. And given XA (and pooling, etc),
that logic is not trivial.
It doesn't pull in MDB stuff at all. Exactly how the Web Beans
implementation implements this stuff is none of our business.
Serioulsy, dude, specifying this stuff is not difficult, because it
can all be expressed in terms of concepts that exist in JMS, without
needing to pull in anything about MDBs, etc.
WebBeans defines a nice local event bus, and someone can write a
bridges
nicely with JMS, but extending WebBeans to a distributed bus is not at all
as simple as bolting on JMS.
I believe it *is* that simple :-)
Perhaps nobody will believe me unless I actually start writing this
stuff up in more detail :)
For example, any messaging implementation needs to have a routing
architecture. A low-level specification messaging (like Jabber/XMPP or
SMTP) defines things like addressing/routing. WebBeans defines routing.
JMS does not, i.e. JMS is a facade around a concrete architecture.
Hrm, I'm really not sure I agree with that. JMS defines things like
topics/queues, and a whole expression language (message selectors)
that is MUCH more powerful than web beans binding types.
>> Creating this kind of bridge would be fairly straightforward,
but really
>> doesn't belong in the spec. (At least this version.)
>
> OK, but what I'm hearing from other people is that if Web Beans
> *doesn't* have this functionality in this version, then it should not
> have *any* event functionality in this version.
It's a decent argument. There's certainly a strong need for distributed
events. I think the local events are a much more specialized application,
and I'm not sure how valuable they are.
So this is something that we seem to more or less have consensus on :-)
The WebBeans events are not suitable for a distributed event system
in the
current state, and adding JMS does not solve the underlying problem. So, if
the event system isn't useful for local-only applications, I'd have to say
it should be put off.
In the current state, no. Certain semantics are totally wrong for
distributed events, namely:
* synchronicity
* context propagation
However, this semantic mismatch can be solved via introduction of the
@Asynchronous observer.
Now, a spec that used the WebBeans ideas to solve the distributed
event
problem would be a very interesting spec, but way out of scope for this
group.
> So at this point we are effectively left with a choice between:
>
> (1) Do distributed events
> (2) Drop events entirely from the spec.
Given only those two choices, I'd have to recommend #2.
And then start a new JSR to solve #1, possibly using many of the concepts
already developed in the draft.
It is and remains my very strong view that unless we provide a very
easy-to-use mechanism that allows state synchronization between
stateful components to occur as part of the transaction completion
lifecycle, then actual web beans applications are going to be riddled
with bugs. They are going to break the minute a transaction rollback
occurs. Many Java EE applications already have this kind of bug, since
it is difficult to code for, and even more difficult to test for.
Since Web Beans encourages stateful components, these bugs will become
even more common!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
2:27 p.m.
New subject: [webbeans-dev] Re: Distributed event channels
It is and remains my very strong view that unless we provide a very
easy-to-use mechanism that allows state synchronization between
stateful components to occur as part of the transaction completion
lifecycle, then actual web beans applications are going to be riddled
with bugs. They are going to break the minute a transaction rollback
occurs. Many Java EE applications already have this kind of bug, since
it is difficult to code for, and even more difficult to test for.
Since Web Beans encourages stateful components, these bugs will become
even more common!
I strongly agree, you really can't discard the event part of the spec
without understanding the consequences of doing so. Being able to hold
off events from being fired (and thus observers from being notified)
until the transaction completes successfully is a cornerstone of the
stateful programming model. I'd love to see what Gavin writes up
because perhaps I think it will make the feasibility much more clear.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat, Inc. | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
7:42 a.m.
New subject: [webbeans-dev] Re: Distributed event channels
OK, after thinking this through over the last couple of days I've come
to the conclusion that we can live with something slightly less
general. The usecase for this stuff is really state synchronization
and therefore N-of-N semantics is the only thing that makes sense, and
supporting guaranteed delivery sounds to me like total overkill.
Of course, if you guys think it's important, it's not hard add support
for 1-of-N semantics and for persistent (guaranteed) events, but I
really don't think it's something we need to do in 1.0.
So the attached draft adds:
* asynchronous event observers
* topic mapped events
* a definition of the tx, security and web beans contexts for all
kinds of observers
Take a look at 8.5.7-8.5.9 and 8.8, and let me know if you think
something is missing or wrong.
Thanks!
On Sun, Dec 21, 2008 at 6:51 PM, Gavin King <gavin(a)hibernate.org> wrote:
IBM has raised the issue of event processing in a distributed
environment, and we (Red Hat) have promised to address this issue in
the revised public draft.
The Web Beans event bus provides a very nice way for stateful
components to synchronize their state (transactionally) with changes
that take place in the application. Event processing is *much* more
important in an environment with stateful object such as SFSBs than it
is in an environment with only stateless objects such as SLSBs or
Spring beans. Furthermore, event processing must be aware of the
transaction completion lifecycle (many applications today have bugs
when transaction rollbacks occur). Therefore, I believe that event
processing is an essential feature of Web Beans.
However, the event bus we have today is a purely local construct and
does not help when the application is distributed across multiple
cluster nodes or multiple physical tiers.
Designing a distributed event bus would potentially be a very
difficult undertaking, with so many issues to think about: QoS,
asynchronicity, transactionality, routing, etc. Fortunately, JMS
already has the features we need, and is what is sometimes used today
to solve the problems we're talking about:
* asynchronous, distributed semantics
* a notion of both 1-of-N and N-of-N semantics (queues and topics)
* a notion of logical channels (to allow routing of events between
tiers and applications)
* support for a range of QoS semantics
* transactionality
Furthermore, JMS is well-understood and well-supported.
If the spec simply defines that events were distributed via JMS,
absolutely nothing would stop vendors from also supporting alternative
distribution mechanisms as proprietary extensions (for example, in
JBoss we could provide support for JGroups).
And when EE finally gets a WorkManager API, a future version of Web
Beans could also define that distribution of local asynchronous events
is via the WorkManager.
The application developer would not be exposed to the JMS APIs. The
actual interaction with JMS would be handled by the container. All the
developer would need to do is specify that events with a specific type
and binding types would be distributed by a certain queue or topic.
(web-beans.xml would be the right place to specify this mapping.)
What I'm thinking is the following:
(1) Event observers may specify that they receive events asynchronously:
void invalidateCache(@Observes @Asynchronously @Created Product
product) { ... }
or even:
void invalidateCache(@Observes(ASYNCHRONOUSLY) @Created Product
product) { ... }
By default, an asynchronous observer is a purely local construct.
However, unlike synchronous observers, an asynchronous observer is
called in a different set of web beans contexts to the contexts in
which the event was fired.
(2) A topic or queue declaration may specify a set of events which are
distributed via that queue/topic:
<Topic>
<destination>java:comp/env/jms/CacheInvalidationEvents</destination>
<connectionFactory>java:comp/env/jms/TopicConnectionFactory</connectionFactory>
<events>
<myapp:Product>
<myapp:Created/>
</myapp:Product>
</events>
</Topic>
This declaration means that any event that is "assignable" to the
specified type and binding types is a distributed event, distributed
by the named JMS topic.
(3) The Web Bean manager would validate that all observers for any
event distributed via JMS are declared to be asynchronous observers,
and throw an exception if there are any synchronous observers for the
event.
(4) We need to think carefully about the concept of an asynchronous
transaction completion event observer. The following combinations are
semantically correct, and need to be supported, even for the distributed
case:
@Observes @Asynchronously @AfterTransactionCompletion
@Observes @Asynchronously @AfterTransactionSuccess
@Observes @Asynchronously @AfterTransactionFailue
However, this combination is not meaningful:
@Observes @Asynchronously @BeforeTransactionCompletion
(5) Finally, since JMS is a transactional medium, we could support a
further setting which writes the event transactionally to the queue/topic.
However, this setting needs to be a global setting for the event type.
Perhaps an @Transactional annotation for the event type?
WDYT?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
2:16 p.m.
New subject: [webbeans-dev] Re: Distributed event channels
On Jan 15, 2009, at 5:42 AM, Gavin King wrote:
OK, after thinking this through over the last couple of days I've
come
to the conclusion that we can live with something slightly less
general. The usecase for this stuff is really state synchronization
and therefore N-of-N semantics is the only thing that makes sense, and
supporting guaranteed delivery sounds to me like total overkill.
Is it possible to reuse the @Asynchronous annotation from EJB 3.1 with
the exact same semantics? They seem essentially the same to me, and
having a shared definition for that aspect would be fantastic
(especially from a documentation perspective.) Having two very-
similar but different annotations may be hard to keep track of. Plus
the current EJB definition is more complete.
-- Scott
Of course, if you guys think it's important, it's not hard add support
for 1-of-N semantics and for persistent (guaranteed) events, but I
really don't think it's something we need to do in 1.0.
So the attached draft adds:
* asynchronous event observers
* topic mapped events
* a definition of the tx, security and web beans contexts for all
kinds of observers
Take a look at 8.5.7-8.5.9 and 8.8, and let me know if you think
something is missing or wrong.
Thanks!
On Sun, Dec 21, 2008 at 6:51 PM, Gavin King <gavin(a)hibernate.org>
wrote:
> IBM has raised the issue of event processing in a distributed
> environment, and we (Red Hat) have promised to address this issue in
> the revised public draft.
>
> The Web Beans event bus provides a very nice way for stateful
> components to synchronize their state (transactionally) with changes
> that take place in the application. Event processing is *much* more
> important in an environment with stateful object such as SFSBs than
> it
> is in an environment with only stateless objects such as SLSBs or
> Spring beans. Furthermore, event processing must be aware of the
> transaction completion lifecycle (many applications today have bugs
> when transaction rollbacks occur). Therefore, I believe that event
> processing is an essential feature of Web Beans.
>
> However, the event bus we have today is a purely local construct and
> does not help when the application is distributed across multiple
> cluster nodes or multiple physical tiers.
>
> Designing a distributed event bus would potentially be a very
> difficult undertaking, with so many issues to think about: QoS,
> asynchronicity, transactionality, routing, etc. Fortunately, JMS
> already has the features we need, and is what is sometimes used today
> to solve the problems we're talking about:
>
> * asynchronous, distributed semantics
> * a notion of both 1-of-N and N-of-N semantics (queues and topics)
> * a notion of logical channels (to allow routing of events between
> tiers and applications)
> * support for a range of QoS semantics
> * transactionality
>
> Furthermore, JMS is well-understood and well-supported.
>
> If the spec simply defines that events were distributed via JMS,
> absolutely nothing would stop vendors from also supporting
> alternative
> distribution mechanisms as proprietary extensions (for example, in
> JBoss we could provide support for JGroups).
>
> And when EE finally gets a WorkManager API, a future version of Web
> Beans could also define that distribution of local asynchronous
> events
> is via the WorkManager.
>
> The application developer would not be exposed to the JMS APIs. The
> actual interaction with JMS would be handled by the container. All
> the
> developer would need to do is specify that events with a specific
> type
> and binding types would be distributed by a certain queue or topic.
> (web-beans.xml would be the right place to specify this mapping.)
>
> What I'm thinking is the following:
>
> (1) Event observers may specify that they receive events
> asynchronously:
>
> void invalidateCache(@Observes @Asynchronously @Created Product
> product) { ... }
>
> or even:
>
> void invalidateCache(@Observes(ASYNCHRONOUSLY) @Created Product
> product) { ... }
>
> By default, an asynchronous observer is a purely local construct.
> However, unlike synchronous observers, an asynchronous observer is
> called in a different set of web beans contexts to the contexts in
> which the event was fired.
>
> (2) A topic or queue declaration may specify a set of events which
> are
> distributed via that queue/topic:
>
> <Topic>
> <destination>java:comp/env/jms/CacheInvalidationEvents</
> destination>
> <connectionFactory>java:comp/env/jms/
> TopicConnectionFactory</connectionFactory>
> <events>
> <myapp:Product>
> <myapp:Created/>
> </myapp:Product>
> </events>
> </Topic>
>
> This declaration means that any event that is "assignable" to the
> specified type and binding types is a distributed event, distributed
> by the named JMS topic.
>
> (3) The Web Bean manager would validate that all observers for any
> event distributed via JMS are declared to be asynchronous observers,
> and throw an exception if there are any synchronous observers for the
> event.
>
> (4) We need to think carefully about the concept of an asynchronous
> transaction completion event observer. The following combinations are
> semantically correct, and need to be supported, even for the
> distributed
> case:
>
> @Observes @Asynchronously @AfterTransactionCompletion
> @Observes @Asynchronously @AfterTransactionSuccess
> @Observes @Asynchronously @AfterTransactionFailue
>
> However, this combination is not meaningful:
>
> @Observes @Asynchronously @BeforeTransactionCompletion
>
> (5) Finally, since JMS is a transactional medium, we could support a
> further setting which writes the event transactionally to the queue/
> topic.
> However, this setting needs to be a global setting for the event
> type.
> Perhaps an @Transactional annotation for the event type?
>
> WDYT?
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
<Web Beans 20090116.pdf>
5:18 p.m.
New subject: [webbeans-dev] Re: Distributed event channels
On Fri, Jan 16, 2009 at 7:16 AM, Scott Ferguson <ferg(a)caucho.com> wrote:
On Jan 15, 2009, at 5:42 AM, Gavin King wrote:
> OK, after thinking this through over the last couple of days I've come
> to the conclusion that we can live with something slightly less
> general. The usecase for this stuff is really state synchronization
> and therefore N-of-N semantics is the only thing that makes sense, and
> supporting guaranteed delivery sounds to me like total overkill.
Is it possible to reuse the @Asynchronous annotation from EJB 3.1 with the
exact same semantics? They seem essentially the same to me, and having a
shared definition for that aspect would be fantastic (especially from a
documentation perspective.) Having two very-similar but different
annotations may be hard to keep track of. Plus the current EJB definition
is more complete.
I will ask Ken about that. Note that EJB also has
@BeforeCompletion/@AfterCompletion annotations which are also very
similar to our @BeforeTransactionCompletion/@AfterTransactionCompletion.
There are a couple of minor mismatches:
* the EJB annotations are in javax.ejb instead of javax.annotations
* they don't have @AfterTransactionSuccess/@AfterTransactionFailure
(instead a boolean value is passed, which doesn't really work for us
* ours are currently specified on the parameter instead of the method
But none of these differences seems like anything really killer.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
4:23 p.m.
New subject: [webbeans-dev] Re: Distributed event channels
https://jira.jboss.org/jira/browse/WBRI-100
On 15 Jan 2009, at 13:42, Gavin King wrote:
OK, after thinking this through over the last couple of days I've
come
to the conclusion that we can live with something slightly less
general. The usecase for this stuff is really state synchronization
and therefore N-of-N semantics is the only thing that makes sense, and
supporting guaranteed delivery sounds to me like total overkill.
Of course, if you guys think it's important, it's not hard add support
for 1-of-N semantics and for persistent (guaranteed) events, but I
really don't think it's something we need to do in 1.0.
So the attached draft adds:
* asynchronous event observers
* topic mapped events
* a definition of the tx, security and web beans contexts for all
kinds of observers
Take a look at 8.5.7-8.5.9 and 8.8, and let me know if you think
something is missing or wrong.
Thanks!
On Sun, Dec 21, 2008 at 6:51 PM, Gavin King <gavin(a)hibernate.org>
wrote:
> IBM has raised the issue of event processing in a distributed
> environment, and we (Red Hat) have promised to address this issue in
> the revised public draft.
>
> The Web Beans event bus provides a very nice way for stateful
> components to synchronize their state (transactionally) with changes
> that take place in the application. Event processing is *much* more
> important in an environment with stateful object such as SFSBs than
> it
> is in an environment with only stateless objects such as SLSBs or
> Spring beans. Furthermore, event processing must be aware of the
> transaction completion lifecycle (many applications today have bugs
> when transaction rollbacks occur). Therefore, I believe that event
> processing is an essential feature of Web Beans.
>
> However, the event bus we have today is a purely local construct and
> does not help when the application is distributed across multiple
> cluster nodes or multiple physical tiers.
>
> Designing a distributed event bus would potentially be a very
> difficult undertaking, with so many issues to think about: QoS,
> asynchronicity, transactionality, routing, etc. Fortunately, JMS
> already has the features we need, and is what is sometimes used today
> to solve the problems we're talking about:
>
> * asynchronous, distributed semantics
> * a notion of both 1-of-N and N-of-N semantics (queues and topics)
> * a notion of logical channels (to allow routing of events between
> tiers and applications)
> * support for a range of QoS semantics
> * transactionality
>
> Furthermore, JMS is well-understood and well-supported.
>
> If the spec simply defines that events were distributed via JMS,
> absolutely nothing would stop vendors from also supporting
> alternative
> distribution mechanisms as proprietary extensions (for example, in
> JBoss we could provide support for JGroups).
>
> And when EE finally gets a WorkManager API, a future version of Web
> Beans could also define that distribution of local asynchronous
> events
> is via the WorkManager.
>
> The application developer would not be exposed to the JMS APIs. The
> actual interaction with JMS would be handled by the container. All
> the
> developer would need to do is specify that events with a specific
> type
> and binding types would be distributed by a certain queue or topic.
> (web-beans.xml would be the right place to specify this mapping.)
>
> What I'm thinking is the following:
>
> (1) Event observers may specify that they receive events
> asynchronously:
>
> void invalidateCache(@Observes @Asynchronously @Created Product
> product) { ... }
>
> or even:
>
> void invalidateCache(@Observes(ASYNCHRONOUSLY) @Created Product
> product) { ... }
>
> By default, an asynchronous observer is a purely local construct.
> However, unlike synchronous observers, an asynchronous observer is
> called in a different set of web beans contexts to the contexts in
> which the event was fired.
>
> (2) A topic or queue declaration may specify a set of events which
> are
> distributed via that queue/topic:
>
> <Topic>
> <destination>java:comp/env/jms/CacheInvalidationEvents</
> destination>
> <connectionFactory>java:comp/env/jms/
> TopicConnectionFactory</connectionFactory>
> <events>
> <myapp:Product>
> <myapp:Created/>
> </myapp:Product>
> </events>
> </Topic>
>
> This declaration means that any event that is "assignable" to the
> specified type and binding types is a distributed event, distributed
> by the named JMS topic.
>
> (3) The Web Bean manager would validate that all observers for any
> event distributed via JMS are declared to be asynchronous observers,
> and throw an exception if there are any synchronous observers for the
> event.
>
> (4) We need to think carefully about the concept of an asynchronous
> transaction completion event observer. The following combinations are
> semantically correct, and need to be supported, even for the
> distributed
> case:
>
> @Observes @Asynchronously @AfterTransactionCompletion
> @Observes @Asynchronously @AfterTransactionSuccess
> @Observes @Asynchronously @AfterTransactionFailue
>
> However, this combination is not meaningful:
>
> @Observes @Asynchronously @BeforeTransactionCompletion
>
> (5) Finally, since JMS is a transactional medium, we could support a
> further setting which writes the event transactionally to the queue/
> topic.
> However, this setting needs to be a global setting for the event
> type.
> Perhaps an @Transactional annotation for the event type?
>
> WDYT?
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
<Web Beans
20090116.pdf>_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
5819
days inactive
5844
days old
11 comments
4 participants
participants (4)
-
Dan Allen -
Gavin King -
Pete Muir -
Scott Ferguson