jee-based implementation
405 views
Skip to first unread message
K.Ciesielski
Oct 8, 2011, 8:19:22 AM10/8/11
to ddd-cqrs-sample
Hi,
I would like to propose an alternative implementation of some
technical parts. It would be interesting to have an alternative based
on pure JEE6 stack, replacing Spring. The idea is to add alternative
code to current project and configure additional build profile. Let me
start with some initial overview:
1. Command Handler Provider
The CDIHandlersProvider is very similar to SpringHandlersProvider. It
uses the BeanManager instance loaded with JNDI to lookup for
appropriate handler. There are, however, two notes to consider:
1.1. SpringHandlersProvider implements onApplicationEvent(), which
refreshes handler registry. In CDIHandlersProvider I replaced this by
a method annotated with @PostConstruct, which will register handlers
only once during application lifecycle.
1.2. I still don't know if CDI decorators or interceptors work fine
with beans loaded by BeanManager.getReference(). Need to investigate
that.
1.3. Handlers must be transactional, so they need to be EJBs. We don't
want to pollute code with @Stateless annotations, so we can introduce
good old ejb-jar.xml descriptor. For leaven purposes this descriptor
can be 'hand-made', but for bigger projects one can consider
generating such file with a custom maven plugin, basing on
@CommandHandlerAnnotation.
2. Application and Domain Event Publishers
Using CDI events with asynchronous EJB methods we can achieve a pretty
simple event engine.
CDIEventPublisher class fires the event into Event<> container, I also
added an additional EJB with @Asynchronous method for dispatching
events with
@Inject @AsynchronousEvent<Serializable> events.
Such approach has two flaws:
2.1. Listeners are polluted with cdi-specific anntations:
public void handle(@Observers @AsynchronousEvent CustomerCreatedEvent
event)
It's not a big deal and we can modify the spring-based event
dispatcher to process these annotations.
2.2. Synchronous event listeners also must be annotated, otherwise
they will receive all kind of events, which is a possible source of
nasty errors caused by forgetful programmers.
3. TODO:
Implement Saga Registry, think about how to deal with
NamedParameterJdbcOperations in @Finders, check if the spring-based
presentation layer works without active spring context.
To be continued...
I would like to propose an alternative implementation of some
technical parts. It would be interesting to have an alternative based
on pure JEE6 stack, replacing Spring. The idea is to add alternative
code to current project and configure additional build profile. Let me
start with some initial overview:
1. Command Handler Provider
The CDIHandlersProvider is very similar to SpringHandlersProvider. It
uses the BeanManager instance loaded with JNDI to lookup for
appropriate handler. There are, however, two notes to consider:
1.1. SpringHandlersProvider implements onApplicationEvent(), which
refreshes handler registry. In CDIHandlersProvider I replaced this by
a method annotated with @PostConstruct, which will register handlers
only once during application lifecycle.
1.2. I still don't know if CDI decorators or interceptors work fine
with beans loaded by BeanManager.getReference(). Need to investigate
that.
1.3. Handlers must be transactional, so they need to be EJBs. We don't
want to pollute code with @Stateless annotations, so we can introduce
good old ejb-jar.xml descriptor. For leaven purposes this descriptor
can be 'hand-made', but for bigger projects one can consider
generating such file with a custom maven plugin, basing on
@CommandHandlerAnnotation.
2. Application and Domain Event Publishers
Using CDI events with asynchronous EJB methods we can achieve a pretty
simple event engine.
CDIEventPublisher class fires the event into Event<> container, I also
added an additional EJB with @Asynchronous method for dispatching
events with
@Inject @AsynchronousEvent<Serializable> events.
Such approach has two flaws:
2.1. Listeners are polluted with cdi-specific anntations:
public void handle(@Observers @AsynchronousEvent CustomerCreatedEvent
event)
It's not a big deal and we can modify the spring-based event
dispatcher to process these annotations.
2.2. Synchronous event listeners also must be annotated, otherwise
they will receive all kind of events, which is a possible source of
nasty errors caused by forgetful programmers.
3. TODO:
Implement Saga Registry, think about how to deal with
NamedParameterJdbcOperations in @Finders, check if the spring-based
presentation layer works without active spring context.
To be continued...
Sławek Sobótka
Oct 8, 2011, 5:32:38 PM10/8/11
to ddd-cqrs-sample
At first I would like to say that having a Java EE impl is a grat
progress and is worth fighting for.
> 1.3. Handlers must be transactional, so they need to be EJBs. We don't
> want to pollute code with @Stateless annotations, so we can introduce
> good old ejb-jar.xml descriptor. For leaven purposes this descriptor
> can be 'hand-made', but for bigger projects one can consider
> generating such file with a custom maven plugin, basing on
> @CommandHandlerAnnotation.
Yes, for educational purpose we can use XML.
But if someone would like to adopt code in own project than I would
suggest to "pollute" code with platform specific annotations:)
> 2. Application and Domain Event Publishers
>
> Using CDI events with asynchronous EJB methods we can achieve a pretty
> simple event engine.
> CDIEventPublisher class fires the event into Event<> container, I also
> added an additional EJB with @Asynchronous method for dispatching
> events with
In production system asynch events should be technically dispatched
via JMS or sth to provide durability
> @Inject @AsynchronousEvent<Serializable> events.
>
> Such approach has two flaws:
>
> 2.1. Listeners are polluted with cdi-specific anntations:
>
> public void handle(@Observers @AsynchronousEvent CustomerCreatedEvent
> event)
>
> It's not a big deal and we can modify the spring-based event
> dispatcher to process these annotations.
I must think about this, because pure Spring projects will need to
depend on sth that they actually dont need to:/
> 2.2. Synchronous event listeners also must be annotated, otherwise
> they will receive all kind of events, which is a possible source of
> nasty errors caused by forgetful programmers.
>
> 3. TODO:
>
> Implement Saga Registry, think about how to deal with
> NamedParameterJdbcOperations in @Finders, check if the spring-based
> presentation layer works without active spring context.
JSF presentation would be great:)
Actually I can develop it in free time (next year I guess:)
progress and is worth fighting for.
> 1.3. Handlers must be transactional, so they need to be EJBs. We don't
> want to pollute code with @Stateless annotations, so we can introduce
> good old ejb-jar.xml descriptor. For leaven purposes this descriptor
> can be 'hand-made', but for bigger projects one can consider
> generating such file with a custom maven plugin, basing on
> @CommandHandlerAnnotation.
But if someone would like to adopt code in own project than I would
suggest to "pollute" code with platform specific annotations:)
> 2. Application and Domain Event Publishers
>
> Using CDI events with asynchronous EJB methods we can achieve a pretty
> simple event engine.
> CDIEventPublisher class fires the event into Event<> container, I also
> added an additional EJB with @Asynchronous method for dispatching
> events with
via JMS or sth to provide durability
> @Inject @AsynchronousEvent<Serializable> events.
>
> Such approach has two flaws:
>
> 2.1. Listeners are polluted with cdi-specific anntations:
>
> public void handle(@Observers @AsynchronousEvent CustomerCreatedEvent
> event)
>
> It's not a big deal and we can modify the spring-based event
> dispatcher to process these annotations.
depend on sth that they actually dont need to:/
> 2.2. Synchronous event listeners also must be annotated, otherwise
> they will receive all kind of events, which is a possible source of
> nasty errors caused by forgetful programmers.
>
> 3. TODO:
>
> Implement Saga Registry, think about how to deal with
> NamedParameterJdbcOperations in @Finders, check if the spring-based
> presentation layer works without active spring context.
Actually I can develop it in free time (next year I guess:)
Marcin Derylo
Oct 9, 2011, 4:15:41 AM10/9/11
to ddd-cqr...@googlegroups.com
W dniu sobota, 8 października 2011, 23:32:38 UTC+2 użytkownik Sławek Sobótka napisał:
At first I would like to say that having a Java EE impl is a grat
progress and is worth fighting for.
Yup, would be worth seeing how such impl compares to Spring-powered one. Personally, though, I would be more interested in framework-less implementation ;) Kind of the extreme Greg suggests to get the people thinking about whether they really need IoC containers and other frameworks. But it would be cool to have the a platform-agnostic implementation that could work with Spring, JEE or any other platform (or without any at all).with just external configuration, without changing the code. Easy with Spring but I suppose not really possible with JEE (at least now without drowning in XML)?
Sławek Sobótka
Oct 9, 2011, 11:42:26 AM10/9/11
to ddd-cqrs-sample
> Yup, would be worth seeing how such impl compares to Spring-powered one.
> Personally, though, I would be more interested in framework-less
> implementation ;)
> Kind of the extreme Greg suggests to get the people
> thinking about whether they really need IoC containers and other frameworks.
There is one place to add all features provided by framework:
> Personally, though, I would be more interested in framework-less
> implementation ;)
> Kind of the extreme Greg suggests to get the people
> thinking about whether they really need IoC containers and other frameworks.
http://code.google.com/p/ddd-cqrs-sample/source/browse/trunk/ddd_cqrs-sample/src/main/java/pl/com/bottega/cqrs/command/impl/RunEnvironment.java
Adding security or transactions in this place to get rid of all AOP
magic is easy...
But implementing own DI does not make much sense imho:)
We need injections not only into Handlers but also into some DDD BB.
> But it would be cool to have the a platform-agnostic implementation that
> could work with Spring, JEE or any other platform (or without any at
> all).with just external configuration, without changing the code. Easy with
> Spring but I suppose not really possible with JEE (at least now without
> drowning in XML)?
stuff - this could scare people:)
K.Ciesielski
Oct 9, 2011, 2:59:49 PM10/9/11
to ddd-cqrs-sample
I managed to create the SagaRegistry. Tested on SimpleSaga, works
fine. I had to apply some tweaks to SimpleSagaEngine and
SagaEventHandler, now I need to check if that did not mess up the
Spring-based solution.
This brings me to some philosophical issues...
When the "vanilla-jee" implementation is ready we need to consider if
it is a good idea to merge it with spring-based code in one project.
Watching the progress of this proof of concept shows that it's
interesting and doable. The question is: do we want to put it all in
one artifact? I understand reasons against splitting the leaven in
multple modules. I saw one CQRS example based on ~7 maven artifacts
and it was way too challenging to understand them, then build, then
deploy the whole thing and see how it works. You do not want to scary
curious beginners. One of the strongest advantages of your leaven is
its clear design and easy deployment. Adding alternative jee-based
'guts' and build configurations may filter out some valuable people,
who will drop the leaven because of this "framework duality" and all
the confusion that it brings.
On the other hand, if we created another, lightweight jee-only
project, it would be very hard (if not impossible) to maintain
consistency.
fine. I had to apply some tweaks to SimpleSagaEngine and
SagaEventHandler, now I need to check if that did not mess up the
Spring-based solution.
This brings me to some philosophical issues...
When the "vanilla-jee" implementation is ready we need to consider if
it is a good idea to merge it with spring-based code in one project.
Watching the progress of this proof of concept shows that it's
interesting and doable. The question is: do we want to put it all in
one artifact? I understand reasons against splitting the leaven in
multple modules. I saw one CQRS example based on ~7 maven artifacts
and it was way too challenging to understand them, then build, then
deploy the whole thing and see how it works. You do not want to scary
curious beginners. One of the strongest advantages of your leaven is
its clear design and easy deployment. Adding alternative jee-based
'guts' and build configurations may filter out some valuable people,
who will drop the leaven because of this "framework duality" and all
the confusion that it brings.
On the other hand, if we created another, lightweight jee-only
project, it would be very hard (if not impossible) to maintain
consistency.
Sławomir Sobótka
Oct 10, 2011, 5:48:47 PM10/10/11
to ddd-cqr...@googlegroups.com
Yes, "forces" that "tears" the project are exactly as You mentioned...
For example we have PHP or .NET people who are interested in general
design decisions - seven Maven artifacts (I know what project You have
in mind and I think that it's approach is technically very good and
would solve our Spring/EE problem) would simply kill curiosity of all
non-Java folks.
Before making a decisions (which should be common) I would like to
gather opinion of as much people as possible.
K.Ciesielski
Dec 4, 2011, 6:05:53 PM12/4/11
to ddd-cqrs-sample
I performed a few commits with major modifications to the JEE branch.
Just a short update what's new:
Just a short update what's new:
- Event dispatching engine based on BeanManager (similar to Spring
solution)
I really tried to involve CDI events with @Observes, but it's just
not good enough to provide handling generic event types in one
publisher.
- Integration tests for Sagas, Events and product ordering scenario.
All tests running with Arquillian on Glassfish-embedded.
- Many minor fixes
In progress:
- Asynchronous events
- Presentation in JSF 2.0
- JBehave story tests
I am not sure if this branch is going to be 'mergeable' in any way,
even partially, with the trunk. We could consider making it a 'fork'.
Sławek Sobótka
Dec 13, 2011, 8:17:05 PM12/13/11
to ddd-cqrs-sample
Krzysiek's post on project blog:
http://ddd-cqrs-leaven.blogspot.com/2011/12/alternative-implementation-in-jee.html
http://ddd-cqrs-leaven.blogspot.com/2011/12/alternative-implementation-in-jee.html
Reply all
Reply to author
Forward
0 new messages